USB hub driver working

I would love to sing some ode right now because I just found a bug and get a working hub driver, but I am afraid that I would be dressed down by my father because it is half past 1am. So, hence this post to let the euphoria out ;-).

Today (well, yesterday) we had a "coding session" and our whole USB team worked on HelenOS/USB. As a result of this and previous meeting, we can announce some real progress.

First, we tried to tame the HID reports and tried to come up with compromise of simplicity vs. extensibility vs. finishability. Because of the complexity of HID reports in general, we ended (so far) with something very simple but it shall be sufficient for most USB keyboards (fingers crossed). We decided to simply search for the proper usage and usage page and ignore all the rest (see the incomprehensible USB HID specification for more details if you want to know what usage and usage page means). This shall work for keyboard but I am afraid that for rats this would be way to restrictive. We will see.

Next, actual work was started on the keyboard driver itself. So far, there was no use writing "blind" code when there was not possibility to connect the driver to some device. Writing the driver would also include hacking into console to enable more keyboards (simply, we can't allow to cut-off the standard keyboard). At first sight, it looks quite easy... Hopefully, the second sight would confirm that ;-).

And finally, we did quite a lot of work on the hub driver. That included hunting some bugs in the virtual host controller and studying USB specification (chapter 11) again and again to find out what is the correct behavior. Both virtual USB host controller and the hub driver needs some refactoring but they are able to communicate with each other, at least...

And if you plug in a virtual USB keyboard, the hub driver is actually able to detect the change on the port, enable the port and launch the proper driver. Applause expected ;-). All right, I know that after several months that is not that much but in the last weeks we are really accelerating and producing something that even works :-).

If you want to see it by yourself, you can try it. First, get sources from our development branch

bzr://helenos-usb.bzr.sourceforge.net/bzrroot/helenos-usb/development

and compile it:

make HANDS_OFF=y PROFILE=ia32

And then launch it in QEMU. And now be quick :-). Switch to console eight (F8) and you will see devman starting. You shall see that a driver called vhc (for virtual host controller) is started. This driver immediately announces its child device, a root hub and assigns USB address 1 to it. And this root hub is driven by the hub driver.

You will see that the hub driver first asks for hub configuration descriptors and then enables power on all ports (for testing, we reduced the number of ports to only 2). The VHC prints which USB transfers it processes and also status of the ports. You shall see that they start in - (meaning not configured) and enters a disconnected state X. The hub driver then periodically checks for the their change. It is time to plug in the virtual USB keyboard.

Switch to console one and type ls /dev/devices to see also following lines, informing about existing virtual USB devices.

\virt
\virt\usbhc
\virt\usbhc\hub

And now you can start the keyboard. Simply type vuk (stands for virtual USB keyboard) and quickly get back into devman console. You shall see that the port status of port 1 (yeah, ports are numbered starting at 1) changed to disabled (D), quickly went through the resetting state (R) and ended in enabled one (E). Once it entered the enabled state, a new address was assigned to the device and device descriptors were queried to determine the device kind. It all ends with messages by devman, announcing that new device was detected and that it searches for a proper driver.

And driver is actually found and started. If you switch back to the console with vuk, you will see that it reports some pressed keys and that the driver polls the device for its status. Isn't that great? And, of course, listing /dev/devices reveals that a new device was added. The name is awful (something like \virt\usbhc\hub\usb0x00017a00) but using device structure address was the simplest way to avoid name clashes...

And that's all. Just do not look at the code ;-). It needs polishing. It needs a lot of polishing. Once we have done that I will definitely inform you about it and invite you to go through it ;-).

I hope the text makes at least some sense and that it is not full of grammatical and spelling mistakes. And I also hope that I have not offended anyone when writing we...