Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)

[andrzej zaborowski]

On 09/04/06, Leonardo E. Reiter <address@hidden> wrote:
> Yeah, the min/max value thing would be a pain for sure.  The X server
> config method seems to be the best bet.
>
> On another note, I am trying to imagine what would make logical sense
> for say, a touch screen.  For example, an LCD panel has a native
> resolution, say 1024x768.  It would then emulate (or transparently
> expand) other VESA resolutions, such as 640x480, on the fly.  I would
> think that if it had touchscreen capabilities, the coordinates would
> always be reported in native mode.  So the guest OS must have to scale
> them down... especially if the device reports the range early on in the
> identification process.
>
As Brad Campbell noted, touchscreens always report absolute
coordinates that need to be scaled by the OS. I have a working
emulation for the TSC2301 touchscreen controller (used in PDAs) in
QEMU and what this chipset does is simply report raw voltage values
from the three wires that connect the touchscreen device and chipset
(through a configurable 12-bit A/D converter). These three signals (X,
Y and pressure) usually take values in the range from about 300 to
about 4000 (while the LCD resolution is 320x320) and contain some
noise, but still the resolution of the touchscreen is much higher than
the LCD's.
Under Linux, userspace can read these values using either evdev or
tsdev (deprecated), both of which report only absolute coordinates. X
compiled with tslib support works really nice with this touchscreen
(both in QEMU and on real devices). Tslib performs the calibration,
noise reduction (averaging) and other tricks.
In QEMU I use parts of Anthony Liguori's WACOM patch for absolute
coordinates, except the cursor hiding, because the guest doesn't know
where the cursor is until it receives the pen-down event (i.e until
you click on QEMU window).

> If this were done in QEMU, we'd have to pick an arbitrary "native"
> resolution - for example, 1600x1200, the max the cirrus device can go.
> We would then have to scale it down automatically based on the set
> resolution, so that the guest OS can scale it up.
>
> I'm just thinking out loud.  The good news is that making changes to the
> open source bits on guests (like Xorg) is trivial... it's, as been said,
> the closed source guests that would be the most problematic.  So
> sticking to the HID protocol to make this happen would be best.
>
> - Leo
>
> Anthony Liguori wrote:
> > I was looking through the Xorg evdev driver and it doesn't appear to
> > support absolute coordinate reporting.  evdev is how the USB mouse would
> > show up to userspace.  A little googling confirmed it for me:
> >
> > http://lists.freedesktop.org/archives/xorg/2005-September/010140.html
> >
> > USB wacom still seems the most promising to me but I fear getting it to
> > work under Windows will be a pain.
> >
> > Regards,
> >
> > Anthony Liguori
> >
> >
> > 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.
> >>
> >> It's not clear to me [yet] how the scroll wheel comes into play, and
> >> whether or not it (the dz coordinate) can be kept relative for ease of
> >> implementation.  Also the code would need to be changed to report
> >> coordinates in 16-bits rather than 8, and of course made to report
> >> absolute coordinates (like from sdl.c, etc.)  Still it looks fairly
> >> easy to implement - the USB spec is pretty simple.
> >>
> >> So to reiterate, my patch does virtually nothing - in fact it will
> >> break usb-hid.c so please don't use it.  I was just illustrating how
> >> to get it to report the device as providing 16-bit absolute
> >> coordinates instead of 8-bit relative ones.  If anyone wants to chime
> >> in with more info, I'd be glad to make this a discussion.  *If* using
> >> the USB HID device only, not any real USB devices, can be done without
> >> slowing down QEMU, then I think this is a great way to get a tablet
> >> emulated without having to deal with drivers on either side.  Plus, in
> >> the long run, it probably means other neat stuff like being able to
> >> get away from ISA bus emulation, and also it's portable to other
> >> targets (for example, OS-X on PPC would talk to the USB HID device the
> >> same way theoretically), so it's likely the most portable and cleanest
> >> option.
> >>
> >> Regards,
> >>
> >> Leo Reiter
> >>
> >> Brad Campbell wrote:
> >>
> >>> Apparently USB HID supports absolute input devices natively. Given we
> >>> have a HID mouse driver of sorts in qemu I wonder if that is another
> >>> avenue perhaps ?
> >>>
> >>>
> >>
> >
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
> --
> Leonardo E. Reiter
> Vice President of Product Development, CTO
>
> Win4Lin, Inc.
> Virtual Computing from Desktop to Data Center
> Main: +1 512 339 7979
> Fax: +1 512 532 6501
> http://www.win4lin.com
>
>
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Regards,
Andrew
--
balrog 2oo6

Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258