- From: Klaas Heidstra <klaas1988@gmail.com>
- Date: Wed, 24 Aug 2011 05:47:04 +0200
- To: Vincent Scheib <scheib@google.com>
- Cc: Glenn Maynard <glenn@zewt.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Jonas Sicking <jonas@sicking.cc>, robert@ocallahan.org, Brandon Andrews <warcraftthreeft@sbcglobal.net>, Olli@pettay.fi, Ryosuke Niwa <rniwa@webkit.org>, Adam Barth <w3c@adambarth.com>, "Gregg Tavares (wrk)" <gman@google.com>, Charles Pritchard <chuck@jumis.com>, Kenneth Russell <kbr@google.com>, public-webapps@w3.org
- Message-ID: <CAHtyvgbcTkjAK5B_Br8oj+gkpGf8sezO-z1JYhBL7VyATOg2mg@mail.gmail.com>
You could constrain the mouse cursor on linux using a combination of XQueryPointer and XWarpPointer. By moving the cursor when it hits the edge of an element. The same solution could be used for Mac where there also doesn't seem to be a direct method for constraining the mouse cursor. When searching for a solution for Mac the first thing I got was the question you posted on stack overflow a couple of hours ago :P. The linux equivalent of WM_INPUT mouse data would be "/dev/input/mice". On Mac it appears to be a little more difficult, but I think it could be implemented by using what's described at: http://developer.apple.com/library/mac/#documentation/DeviceDrivers/Conceptual/USBBook/USBDeviceInterfaces/USBDevInterfaces.html . Concerning your question about the units of raw mouse input. The mouse sends the number of movements that happened since the last time the mouse was polled(by default I believe the polling rate for USB is 100Hz, but with some gaming mice you can increase this to 1000Hz). The maximum number of movements the mouse can record during that interval depends on the DPI. When you have a mouse of 2000dpi and the polling rate is 100Hz and you move it 1 inch in a certain direction, during that 1 second you get 100 times an average value of 2000/100 = 20. If the polling rate is increased to 1000Hz you would get 1000 times a value of 2 per second. This polling rate is the number of times per second the WM_INPUT is called for mouse movement on windows and on linux its the frequency at which /dev/input/mice is updated. In this case using raw input is the only way to take optimal advantage of high resolution gaming mice and because of this possible high frequency IMO it should be in a separate event as I pointed out in my mail an hour ago. 2011/8/23 Vincent Scheib <scheib@google.com> > The 'component' version (separate orthogonal features for mouse deltas, > constraining movement of mouse, and hiding cursor) seems preferable to the > 'composite' api as currently drafted. That is, if implementable and > specifiable. We need to answer a few questions (I'll research this, but if > anyone already has pointers/answers to the information it will accelerate > the process): > > Can the mouse be constrained on all platforms? If so, can it be constrained > to arbitrary rectangles or only a window (this is a nice to have, would be > good to have web apps able to confine the mouse to only a region of a > page). > - Windows: ClipCursor provides this. Does it work over remote desktop (just > a nice to have? warping may not either)? > - Linux: XGrabPointer can constrain to a window's area (is there a way to > specify arbitrary rects?) > - Mac: ? > > What are the units of .movementX/Y if we're reading 'raw' input device > coordinates? Are they consistent across devices and platforms? Can we > specify them? If not, I'm hesitate to cause web application developers to > deal with calibrating to arbitrary and unknown units for .movementX/Y. > - Windows WM_INPUT does not include ballistics (mouse acceleration), and > that's OK/arguably preferable. But what are the units? Using > the WM_MOUSEMOVE data and warping the cursor position allows us to specify > precisely what the units are of .movementX/Y, in current spec draft, "The > members movementX and movementY must provide the change in position of the > mouse, as if the values of e.g. clientX were stored between two subsequent > mousemove events e1 and e2 and the difference taken e2.clientX-e1.clientX." > >
Received on Wednesday, 24 August 2011 03:47:32 UTC