From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FSKrz-0000fy-I6 for qemu-devel@nongnu.org; Sat, 08 Apr 2006 17:21:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FSKrx-0000fW-D2 for qemu-devel@nongnu.org; Sat, 08 Apr 2006 17:21:22 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FSKrx-0000fT-9o for qemu-devel@nongnu.org; Sat, 08 Apr 2006 17:21:21 -0400 Received: from [203.190.192.17] (helo=wasp.net.au) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FSKwD-00063G-Ig for qemu-devel@nongnu.org; Sat, 08 Apr 2006 17:25:46 -0400 Message-ID: <4438299F.3010604@wasp.net.au> Date: Sun, 09 Apr 2006 01:22:39 +0400 From: Brad Campbell MIME-Version: 1.0 Subject: Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server) References: <443802FB.9060700@win4lin.com> <44381AE0.1020106@wasp.net.au> <443825D8.3080602@win4lin.com> In-Reply-To: <443825D8.3080602@win4lin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Leonardo E. Reiter wrote: > This is by no means a complete patch (do not apply it as it will break > usb-hid.c), but it adjusts the report descriptor in usb-hid.c to provide > position in 16-bits, and in absolute coordinates: > > Index: usb-hid.c > =================================================================== > RCS file: /cvsroot/qemu/qemu/hw/usb-hid.c,v > retrieving revision 1.1 > diff -a -u -r1.1 usb-hid.c > --- usb-hid.c 5 Nov 2005 16:57:08 -0000 1.1 > +++ usb-hid.c 8 Apr 2006 20:56:02 -0000 > @@ -117,7 +117,7 @@ > 0x15, 0x00, 0x25, 0x01, 0x95, 0x03, 0x75, 0x01, > 0x81, 0x02, 0x95, 0x01, 0x75, 0x05, 0x81, 0x01, > 0x05, 0x01, 0x09, 0x30, 0x09, 0x31, 0x15, 0x81, > - 0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06, > + 0x25, 0x7F, 0x75, 0x16, 0x95, 0x02, 0x81, 0x02, > 0xC0, 0xC0, > }; > > According to: > http://72.14.203.104/search?q=cache:wVYUTwc33f8J:www.usb.org/developers/devclass_docs/HID1_11.pdf+usb+hid+specification+absolute+relative&hl=en&gl=us&ct=clnk&cd=1 > > > I'm still trying to figure out how the logical min/max apply if we are > to report absolute (unsigned) positions in 16-bits. Obviously 8-bits is > not enough for absolute coordinates. You could theoretically use only > 12-bits per coordinate but that would make life difficult I think, and > probably unnecessarily frugal in a software emulation. From what I have managed to read up on thus far, the absolute coordinates are pretty much fed directly to the application as mouse move events. Now it's a long time since I've hacked on it but I wrote a userspace touch screen driver for win9x years ago that did just this.. I seem to recall having to scale the real touchscreen values to between 0x0 and 0xffff before feeding them in to the windows message queue. From memory 0,0 was top left and ffff,ffff was bottom right.. as applied to the current screen resolution. Windows worked the rest out itself.. Like I said.. very hazy memory.. I'll have a look in the morning and see if I can dig that code out to figure out what I did, but given the way windows mouse events work that seems logical and would be relatively easy to do in qemu. As for the wheel.. I have no idea. An idea I had a while back was to feed the wheel and buttons to the ps2 port and get the positioning info in some other fashion. Ugly.. very ugly.. -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams