Grab key scrolling
Zephaniah E. Hull
warp at aehallh.com
Thu Apr 19 05:51:05 EDT 2007
On Thu, Apr 19, 2007 at 11:47:22AM +0200, Marco Pesenti Gritti wrote:
> On Thu, 2007-04-19 at 01:41 -0400, Zephaniah E. Hull wrote:
> > 2: This is where you have choices and tradeoffs.
> > You can simply grab the core pointer events and let the pointer move
> > around, this has the problem of not being able to scroll in one
> > direction once the pointer has reached the edge of the screen.
> Yeah, this won't work.
> > You can do a full pointer grab, as many games do, usually making the
> > pointer invisible at the same time. This allows you to scroll
> > around however you want, but without some tricks to save/restore
> > pointer position, this leaves the pointer in the middle of the
> > screen when you let go.
> What do you mean with full pointer grab exactly? This is what SDL does:
> XGrabPointer(SDL_Display, SDL_Window, True, 0,
> GrabModeAsync, GrabModeAsync,
> SDL_Window, None, CurrentTime);
> I tried it out with neverball and once you reach the edge you can't move in that
> direction anymore.
Extra work is needed, specificly you have to move the pointer to the
center of the screen, and on each movement move the pointer back to the
center of the screen.
It's ugly, but it's also how X applications have stolen the pointer for
> > Both of those methods only work on things that move the core pointer
> > around as a relative device. This doesn't allow the PT to be
> > used.
> > 3: With the newer input code in X, you have another option.
> > Go through the list of input devices, set the ones you want to grab
> > to not send core events, open them, depending on usage you may want
> > to switch the PT to rel mode, as above treat the incoming X/Y data
> > as scrolling control.
> > I'd probably select devices on the simple basis that anything that's
> > sending core events and is a pointer is fair game.
> > Just remember on release that you close, and restore the settings
> > you changed (send core events, rel vs abs).
> > You can't currently do this in X because you can't do that to the
> > device that's the core pointer, it _is_ possible to hack around that
> > to do this in the current X server by adding a null driver acting as
> > a mouse, but that adds to the work involved by some amount, if
> > that's worth it for gen1 is someone else's call.
> How much work would it be to add the null driver?
> If that's the only possibility to get an acceptable behavior for the
> drag key IHMO we should do it.
We would need to ship xf86-input-void, and include it in the config
The trick is to use the xinput extension to make the null pointer the
core pointer while you grab the other devices, and put things back when
(So that things that change settings on the core pointer actually change
Zephaniah E. Hull.
1024D/E65A7801 Zephaniah E. Hull <warp at aehallh.com>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
It was then I realized how dire my medical situation was. Here I was,
a network admin, unable to leave, and here was someone with a broken
network. And they didn't ask me to fix it. They didn't even try to
casually pry a hint out of me.
-- Ryan Tucker in the SDM.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the Devel