From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FSd5c-0006ew-Er for qemu-devel@nongnu.org; Sun, 09 Apr 2006 12:48:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FSd5a-0006ec-Nv for qemu-devel@nongnu.org; Sun, 09 Apr 2006 12:48:39 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FSd5a-0006eU-G6 for qemu-devel@nongnu.org; Sun, 09 Apr 2006 12:48:38 -0400 Received: from [203.190.192.17] (helo=wasp.net.au) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FSdA1-0007xc-Ux for qemu-devel@nongnu.org; Sun, 09 Apr 2006 12:53:14 -0400 Message-ID: <44393B34.1090907@wasp.net.au> Date: Sun, 09 Apr 2006 20:49:56 +0400 From: Brad Campbell MIME-Version: 1.0 Subject: Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server) References: <443802FB.9060700@win4lin.com> <44381AE0.1020106@wasp.net.au> <443825D8.3080602@win4lin.com> <44388F43.20207@us.ibm.com> <44393064.2050300@win4lin.com> In-Reply-To: <44393064.2050300@win4lin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Leonardo E. Reiter 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. Every touchscreen I've ever used (which would be serial and USB Intellitouch and serial MicroTouch) used to report fixed absolute positions and the driver scaled them after a simple 2 or 5 point calibration routine. So they were indexed to the position on the monitor glass, not what was underneath it. We never changed screen resolutions so that was never an issue itself.. On LCD's it worked great and never needed recalibrating as the pixels don't move. On CRT's we needed to recalibrate every time some donkey fiddled with the H&V pos/scale knobs. Interestingly enough the Intellitouch reports z axis as well. It delivers an 8 bit force value. From what I've been able to figure thus far, the min/max thing seems to be the device telling the OS what it's minimum and maximum values are on each axis. It's then up to the OS to relate that to the current screen resolution. And after finding my old code buried under many TB of other garbage.. I note my memory failed me partially. The mouse events were poked directly into the windows message queue with MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE and the X and Y values were calculated from the touchscreen calibration values, scaled to be 0x0->0xffff and poked in as dwords. This was all cool as I had the cursor turned off. If the cursor needed to be displayed/moved also then it was set with SetCursorPos() which of course uses resolution dependent coordinates. Nice of windows to be consistent! Time to do some 'sperimenting I guess.. -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams