From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDXTn-0001Py-B1 for qemu-devel@nongnu.org; Mon, 17 Sep 2012 05:19:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDXTh-0006im-FY for qemu-devel@nongnu.org; Mon, 17 Sep 2012 05:18:59 -0400 Received: from mout.web.de ([212.227.17.12]:53051) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDXTh-0006ic-5J for qemu-devel@nongnu.org; Mon, 17 Sep 2012 05:18:53 -0400 Message-ID: <5056EAF2.60205@web.de> Date: Mon, 17 Sep 2012 11:18:42 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <5054AC57.205@web.de> <5056E876.9010400@redhat.com> In-Reply-To: <5056E876.9010400@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC62269BEB5A6001F65A64598" Subject: Re: [Qemu-devel] [PATCH] usb-redir: Allow to attach USB 2.0 devices to 1.1 host controller List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede Cc: qemu-devel , Gerd Hoffmann This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC62269BEB5A6001F65A64598 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-09-17 11:08, Hans de Goede wrote: > Hi, >=20 > On 09/15/2012 06:27 PM, Jan Kiszka wrote: >> From: Jan Kiszka >> >> This follows the logic of host-linux: If a 2.0 device has no ISO >> endpoint and no interrupt endpoint with a packet size > 64, we can >> attach it also to an 1.1 host controller. In case the redir server doe= s >> not report endpoint sizes, play safe and remove the 1.1 compatibility = as >> well. >> >> Signed-off-by: Jan Kiszka >=20 > Interesting thanks for the patch. I like the approach you took (simple > code), > but unfortunately it won't work, if you look at usbredir_device_connect= (), > where you do the dev->dev.speedmask |=3D USB_SPEED_MASK_FULL, it also > actually attaches the device to the controller, from which point on the= > guest will see the device. >=20 > What happens on the wire is that the usbredir-host sends (in order): > -ep_info + interface_info > -device_connect message >=20 > So your clearing of the speed-mask will never trigger, unless ep-info > gets repeated later (which it does under certain circumstances). Hmm, what a pity... >=20 > I suggest instead changing the code to set a "fullspeed_compatible" fla= g > in struct USBRedirDevice from usbredir_device_disconnect(), clear that > flag from usbredir_ep_info and use it to add to the mask in > usbredir_device_connect(). OK. >=20 > ### >=20 > Another issue is what happens if a device "grows" incompatible endpoint= s > after being attached, ie a webcam could have no isoc endpoints in alt > setting 0, and then grow an isoc endpoint on a set_interface. So we > would need a check for a device becoming not fullspeed compat while > being attached at fullspeed in usbredir_ep_info(), and then call > usbredir_reject_device() when this happens. =2E..and this patch started so simple. OK. >=20 > Although not pretty I'm ok with this, since I actually want to add > similar code to allow usb-3 (superspeed) devices like a usb-3 usb-stick= > to work with ehci or uhci controllers :) Great, that would have been my next question, but I don't have hardware for that around yet. BTW, I'm facing several incompatibilities with passed-through CDC/ACM devices (e.g. a Galaxy S2), independent of my patch. Both host-linux and redir doesn't allow to use them properly but show different symptoms. Need to analyze and report once time permits. Jan --------------enigC62269BEB5A6001F65A64598 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBW6vcACgkQitSsb3rl5xSj8QCgrKdOyI+uTCocRSh7vAT/RQuz dBAAoLGDwTixhcB/xgPw4iVv6GE4Ko3I =v7lZ -----END PGP SIGNATURE----- --------------enigC62269BEB5A6001F65A64598--