Re: [Qemu-devel] Large USB patch

[nix.wie.weg@gmx.de]

Hello Lonnie,

First,  thank you for the answer.

Lonnie Mendez wrote:
> nix.wie.weg@gmx.de wrote:
>
>> printer was not even detected under qemu. So I started to work on it.
>>
>   Are you sure such vast changes are necessary?  What was it exactly
> that happened when you attached the printer/scanner?  I'd be
> interested in seeing a packet log without all the changes that seem to
> "break stuff."
Yes I am absolutly sure we need this changes. The usb protocoll is a
very sophisticated work. There is an exactly defined sequence in which
packets are send. (I have made some small documentation about this:
http://217.20.126.200/tino/usb-order-of-events.pdf
http://217.20.126.200/tino/usb-order-of-events.odg)
If you do not keep track of this, you will never be able to get most
devices running. The qemu-specialcase-1.patch is the result of ignoring
these sequence. At the moment I'm not even sure, if we have to implement
the states in which a device is in (I mean default state, adress state
... USB Spec. 1.1 chapter 9).
>
>> changed the handling of special messages like usb_reset or usb_attach
>> 8. I made the necessary changes to usb-hid.c and usb-hub.c
>> 9. I wrote a lot of source comments
>>  
>>
>   I'm in favor of a new api but with only one controller there is
> almost no point in doing this yet.  
Sorry I can't agree on that point with you. We will get more
controller/devices if we can provide an easy api for implementing them.
I would really be interrested  to see an EHCI Controller - maybe I will
even implement it by myself.
> It may make more sense to either be able to specify either grabbing
> all or a few interfaces to proxy to the guest.  Also, libusb is ok for
> a generic handler, but there is no way you'll get someone to jump
> through all the hoops necessary to get usb working under windows with
> libusb-win32 or even mac os x.  On win32 host you have to manually
> create an inf file with the PID/VID and then install that for every
> device you try to use.  It's not a good idea to use the filter driver
> unless the corresponding host driver is unbinded (especially for mass
> storage).  On mac os x you would supposedly creates codeless kernel
> extensions with the PID/VID to unbind the device.  That could be done
> through scripts, but none exist.
>
On that point you have probably misunderstood me. I dont want to
liquidate any native usb-host files. On the contrary, with that patch it
is easier to get more such native interfaces running. We could even
implement on some platforms more than one interface. I for instance
would like it, if I could have libusb and linux native support enabled
at the same time so I could make such things like:
$ qemu -usb controller=uhci -usb device=libusb:002:003,addto=001:001
-usb device=linux:001:002,addto=001:002
and it should now not be so difficult to implement.
>   Also keep in mind the people here probably don't know about the
> all-in-one patch on my webserver.  I've never posted about it here
> except for on the user forums.
>> this patch breaks some things:
>>
>   I'll try to look at the patch this weekend.
Thanks
>> known problems:
> The reset function in libusb causes the device to have a new address
> when it reconnects therefore forcing you to rescan and open the device
> again.  Perhaps this is the problem.
Yes I know this and I implemented it. But it does still not work. We get
a STALL on the devices when the code is enabled.


With kind regards
Tino H. Seifert