[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Large USB patch

From: Lonnie Mendez
Subject: Re: [Qemu-devel] Large USB patch
Date: Fri, 21 Apr 2006 02:04:36 -0500
User-agent: Mozilla Thunderbird 1.0.7 (X11/20050923)

address@hidden wrote:


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:
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).
Well I'm glad someone took a deeper look at it. I never addressed it as a correct solution to the problem. And indeed with the patch applied the transaction log is clean.

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.
  Sounds good.  Not sure what I was going on about there.

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.
Yes, I have misunderstood you. It sounds like a good plan. I'll ready the bsd redirector around the api tomorrow if possible. From some limited testing it fails rather early on a linux guest so it shouldn't be too hard to fix on that. There is quite a bit here and the person that would merge this into CVS is Fabrice Bellard. He would have to review all this before it ever touches CVS.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]