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 ?
