[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Leonardo E. Reiter
Subject: Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
Date: Sat, 08 Apr 2006 17:36:20 -0400
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051013)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]