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

[Leonardo E. Reiter]

Brad Campbell wrote:
> 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..
There's actually a GDI call you can make if you are in user space that 
will allow you to do absolute cursor addressing.  The problem is that 
you have be in user space, and you have to be able to talk to the 
display.  By the time this happens, it's way too late in general - for 
example, you already got past the Windows login screen, etc.  It's 
basically what we do on Win4Lin Pro now, but it's not really adequate 
for the long run and it's not too fast.  Ideally, a USB HID device would 
"just work" with the Windows HID "class" driver, and the rest will be 
history.  HID device drivers are ubiquotous and work on every major OS, 
not just Windows obviously (Linux, *BSD, OS-X, etc.), so it truly would 
be the most universal solution.  And, keeping with the spirit of QEMU, 
this solution would mean not having to modify anything in the guest 
either.  Not too mention how it's 100 times easier (at least) to hack 
QEMU than to code a Windows device driver of any sort (IMHO anyway.)

> 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..
Actually the usb-hid.c already seems to be sending Z axis events (the 
wheel most likely)... it's just not clear, from reading the USB HID 
spec, how this relates to the data, or how this event is described.  I 
admit I'm pretty new to deciphering USB, and also I haven't actually 
played with QEMU's usb-hid device either.  As for the X and Y 
coordinate, they would have to be sent in some precision greater than 
8-bits because screen resolutions are so high.  A touchscreen is an 
ideal example of the type of device we need, even more so than a tablet. 
 Thankfully USB makes us not really care what type of physical device 
it actually is, as long as we can describe it properly to the consumer 
(Windows/etc.).  But anyway, we would want to be able to describe 
coordinates up to at least 1600x1200 since that is the max that 
cirrus_vga accepts, and that would require at least 11 bits per axis. 
You'd have to add 2 padding bits in the descriptor if you did it that 
way - easier would be 12-bits per axis.  Then [I assume], when you send 
the motion packet, you would need to send the 24-bits packed rather than 
8 and 8 as is done now.  I just am not sure what happens to the dz part, 
since it's not really described anywhere that I can see.  The code I'm 
referring to is in hw/usb-hid.c, in the function usb_mouse_poll().  It 
looks like the VM requests the Z axis value selectively, and the code 
handles this.  I'm starting to believe that your dual-device idea makes 
good sense, because for example, a touchscreen doesn't have a Z axis. 
It will take some trial and error I suspect.

- Leo

--
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