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?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.
Of course it is NOT the same controller.One is called usbehci.sys and the other is called usbohci.sys.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.
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.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.
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: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.
"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 )
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.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:\".
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.
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.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.
Who said that? 0oSixth: The power management of USB devices has nothing to do with HID.
Who said that?0oSeventh: Compound devices are not related to HID (sorry it was too easy ).
Yes i said that:Basically usbccgp.sys is a usbport.sys for compound devices.
"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.
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.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.
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