From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42549 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PFUXE-0002FV-7n for qemu-devel@nongnu.org; Mon, 08 Nov 2010 11:25:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PFUXC-0007wd-SG for qemu-devel@nongnu.org; Mon, 08 Nov 2010 11:25:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:20222) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PFUXC-0007vl-IP for qemu-devel@nongnu.org; Mon, 08 Nov 2010 11:25:30 -0500 From: Hans de Goede Date: Mon, 8 Nov 2010 17:26:07 +0100 Message-Id: <1289233570-6529-1-git-send-email-hdegoede@redhat.com> Subject: [Qemu-devel] [PATCH 0/3] usb-linux do not send unnecessary GET_CONFIGURATION List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: spice-devel@lists.freedesktop.org, Gerd Hoffmann Hi All, First a short self-into. I've been a FOSS developer for 10+ years, working on a large variety of projects. Most relevant for my appearing here on the qemu list is my experience in reverse engineering and writing usb webcam drivers for the Linux kernel and libgphoto2 camlibs for various small usb keychain picture frames (with proprietary protocols). I've been a Red Hat employee for 2 years now and in August this year I've joined Red Hat's SPICE team. I'm currently tasked with looking into / developing an usb redirection solution for SPICE. So for starters I've begun looking into the current usb redirection support in qemu. It failed at the first device I threw at it (a usb keychain picture frame), the problem is that this (el cheapo) device does not seem to grok GET_CONFIGURATION. This patch sets makes this device work (and stops qemu from unnecessary sending a GET_CONFIGURATION ctrl msg in general) by reading this value directly from sysfs. Regards, Hans p.s. While looking at the code I also noticed that the ep numeration in usb-linux seems completely wrong for multifunction devices. I'll go test that and fix it (assuming I'm right about it being wrong) tomorrow.