BIG REQUEST: Donate for USB !

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

vicmarcal
Test Team
Posts: 2732
Joined: Mon Jul 07, 2008 12:35 pm

Re: BIG REQUEST: Donate for USB !

Post by vicmarcal » Sun Apr 04, 2010 1:20 pm

Thanks for the replies, VicMarcal and MjMartin.

First: the picture in your blog Vic comes from Microsoft and it explains the Windows XP stack not the other stacks, please refer to MSDN for the other schematics. And your answer is not related to what I said: That it's possible to achieve enough user compatibility by implementing the Windows 2K USB stack.
Please send me the "other schematics" links related to the "other stacks"(vista/7), i will redo the info if needed.But i think we are mimicking here the XP-NT architecture.I will be very pleased to remake it. Did USB stack change a lot its architecture from XP to 7?
Second: I would say that the main difference between Windows usbehci.sys and usbohci.sys is related to the fact that the controller is not the same.
Of course it is NOT the same controller.One is called usbehci.sys and the other is called usbohci.sys. :)
per se it's not related to the USB standard. In fact USB 2.0 devices could go at USB 1.1 low speed also and ohci and uhci are examples of the same USB 1.1 standard but incompatible implementation.
Right.This is extra info, which completes the main idea,and that i avoided consciously to make it easier to understand. The blog is not developers oriented, but users oriented.You are providing extra info but the Blog post doesnt say anything incorrect: "If you attach a USB 2.0 device the system will load usbehci.sys while if you connect a USB device 1.1 you will load usbohci.sys."Of course we can make a USB 2.0 device running in 1.1 and other non-normal things,but it is out of scope and maybe misleading to non-developers.
Third: the role of the hub is not to manage different classes of devices. Its role consists to enumerate devices that are connected to the hub. Indeed if you have more than one device connected to a hub you must have some way to route your URBs to the one device that you are interested in and not the other. This need arise from the fact that USB didn't use a bus architecture design but instead a more complicated tree architecture design.
I think here Google Translator has translated wrongly some parts of the Post.Since in no place the post is saying that "manage different classes of devices".A fast translation would be:
"USBHUB.sys. But in a PC we dont have just one USB port, but some.One are going to be empty, while in others we have some USB devices attached(mouse,printers,etc...),and maybe we can have a USB hub in a port which expands the USB ports.Who manages this mess?:USBHUb.sys
An incorrect work of USBhub.sys will make that the USB port where Mouse is connected will recieve a file which should be copied to the pendrive attached to the other USBport."

(Here i think it is clear enough that I am talking about devices,not classes,and that "it is the way to route your URBs to the one device you are interested and not the other" that you correctly pointed, but in short-understandable words via example)
Indeed more,i continue saying....
"And now what?As you can see in the diagram we can call a USB client Driver Device or calling usbccgp.sys, which will load the USB Client Driver Devices needed."
(I didnt use the word "Classes" until this point, and much less the sentence:"to manage different classes of device".I think that maybe it is a wrong Google translation )

Fourth: the role of the usbport.sys is very vague in your description "the usbport is responsible to perform common tasks". In fact the usbport.sys must attach the devices to the internal naming system of Windows, thus making it "visible" for userland applications. It means that an application can use the standard userland calls like "DeviceIoControl" to dialog with USB drivers with names like "\\comp01 "SanDisk Cruzer" " or even a drive letter "F:\".
Yes. It is vague as the idea of that Post is just to give a general overview of the different parts of the USB stack so people can understand a little bit better mjmartin commits/work.As i said this Blog is User/Followers oriented and not Dev oriented,and never will. :)
Also the Blog is my-grandma oriented,if she doesnt understand something i rewrite the whole post. For technical info we have the valuables Z98-newsletters or MSDN :).People likes "ReactOS wordpress Blog"because they understand the content. :) If i begin explaining the "DeviceIOControl" or what does the " \\" means in "\\comp01" they will get lost easily.I have to avoid the technical stuff when possible and this sometimes leads to vague descriptions or maybe to a not correct 100% description. After having a global overview(thanks to the Post) anyone is free to complete his knowledge with MSDN or other Devs-oriented blogs.

Fifth: the HID topic is only remotely connected to the USB topic. HID means that an HID application will interact with an HID device which have a specific naming system. An application using a USB device doesn't have to be a HID application (think about the file explorer). It's messy because the USB standard defines also classes that are very similar in names to the HID classes but it's only remotely related.
There i am just enumerating some of the USB CLIENT DEVICE DRIVERS as HID driver is, as PowerManagement driver is or a Mass Storage driver is, among others.It helps to clarify what a USB CLIENT DEVICE DRIVER is imo.
Sixth: The power management of USB devices has nothing to do with HID.
Who said that? 0o
Seventh: Compound devices are not related to HID (sorry it was too easy ;-) ).
Who said that?0o
Basically usbccgp.sys is a usbport.sys for compound devices.
Yes i said that:
"Resumiendo: Si el dispositivo es COMPUESTO entonces primero se carga el DRIVER GENÉRICO PATERNO(el usbccgp.sys)"
"Summing up: If the device is a Compound device then first is loaded the Usbccgp.sys". This is written in ORANGE words. :)

As I am an old engineer, when I state something it's well thought, I would appreciate that before one answer he or she invests as much time in it as the few hours than I generally spent on it. You can perfectly call me an old fart, but please be precise and accurate on technical subjects.
I am just a young engineer.Industrial and not IT.As i said the Blog is focused in giving Information about ReactOS development to non-developers .Sometimes, in order to explain Aicom,Janderwald or Mjmartin work it is needed a minimun base of knowledge.
Since that Blog Post, maybe not 100% accurate and that can make old-fart-engineer eyes bleeding,some of the ReactOS Followers/Users can understand a little bit more any Mjmartin commit :) or at least saying,"oh, he is working in this file,or in this other,or wow,he finished this driver..we are a step near" or the thing that i tried to reflect in this case: "USB work means at least coding 5 or 6 drivers, which means it is a difficult and long task"

Thanks for all your comments :), they are highly appreciated.
PS:I dont want to be a "young fart" but if implementing Windows 2k USB stack is so easy, do it.All of this thread readers will appreciate your USB work :)
Image

bugboy
Developer
Posts: 39
Joined: Thu May 22, 2008 9:23 pm

Re: BIG REQUEST: Donate for USB !

Post by bugboy » Fri Apr 09, 2010 9:01 am

JPLR,
Eighth: It is said in the "MjMartin section that he is trying to create a usbehci.sys. As the role of it is very simple, thanks to the architect of Windows and the USB standard body, why can't you use the code from the drivers that already do that? You receive well described messages (IOCTL) and produce well described messages (URB). As I have said it many times there are several implementation open source doing it. There is a clear and easy to understand implementation in NDISWrapper in this function: static USBD_STATUS wrap_process_nt_urb(PIRP irp)
Thanks for the information on usb stuff in NDISWrapper. I had no idea this existed.
I am already using code from a driver that does most all this. The xen pvdriver already fit right in with the windows xp stack.
So now it basically translating the library coded parts, fill in some missing things that look like are implemented in NDISWrapper and implement the actually communication with the controller based on source code already available.
But when I read your post i get the feeling, maybe incorrectly, that you think we can just copy and paste
some code from sources youve already mentioned and have a fully windows compliant working usb stack.

mjmartin
Image

AlexEagar
Posts: 6
Joined: Sun May 14, 2006 12:42 am

Re: BIG REQUEST: Donate for USB !

Post by AlexEagar » Fri Apr 23, 2010 3:10 am

For anyone who just wants to see their donation go toward achieving a specific goal, in a short time frame, for a reasonable bounty, I suggest donating to the Booting from EFI funding idea. It's currently the only idea listed with a small donation goal and small time frame for completion. Perhaps its completion would motivate the developers who are in charge of other goals to come up with more specific time estimations and donation requirements.

I don't have a computer with EFI, but to show my support and to encourage donations, I'll match the first 25 Euro donated toward this goal over the next seven days. One small donation on your part could help fund 1/50 of the funding needed to make ReactOS boot from EFI!

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], DotBot [Crawler], Google [Bot] and 15 guests