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
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
