[Sugar-devel] future of the grab key?

[pgf at laptop.org]

since we're examining unloved features today, i have something
to show and tell, too.

i'd like to get input on some work i've done to get the grab
key(s) on the XO working.  i don't think what i've done is quite
how they were originally planned to work, but maybe it's close
enough.  i also know erik did a bunch of work on this last fall
(see extensive patches on #447), and i've never been sure why
that hasn't gotten picked up, so i'd like to know more about
that, too.

background:  i've been working on a (non-XO) project recently
that led me to implement a userspace virtual keyboard.  as the last
step of that project, i implemented modifier-based scrolling -- i
can hold a key, use the joystick (on the keyboard device in
question), and instead of getting motion events, scroll-button-press
events are generated and injected into the uinput device.  it
works very nicely.

when i asked a question related to my project a few weeks ago on
IRC, tomeu asked if i was thinking about the grab key.  i wasn't
back then, but the thought stuck with me.

so:  i've now implemented a fairly small daemon that sits between
the XO keyboard/touchpad pair and the evdev kernel driver.  it
opens the keyboard and touchpad /dev/input/eventN nodes (in such
a way that X will skip them when it starts), creates a third
eventN node via uinput, and shuttles events in between.  the only
thing it does with the data is watch for the grab keys -- when it
sees one, it does as described above:  ensuing touchpad events
are translated into a smaller number of scroll-button events, and
as a result the window moves instead of the mouse pointer.

but as i was finishing it up and testing it, i realized that it
doesn't really do what i pictured the grab key as doing.

i had pictured the grab key as causing the mouse cursor to, well,
"grab" the window contents, to allow dragging it around.  (just
like clicking and dragging on google maps.)

but what i'd done was different:  when one's finger moved on the
touchpad, the _scrollbars_ moved.  the mouse pointer stayed
stationary with respect to the window edges, and the window
contents moved in the _opposite_ direction from the finger on
the touchpad.

since i wasn't sure what to make of this frame-of-reference
reversal, i did the obvious thing:  i reversed the behavior, but
added a commandline option to put it back, just in case.  (the
original "backward" behavior still feels more correct on the
joystick pointer of my original project, for instance.)

since the mouse cursor remains stationary on the screen, it still
doesn't feel like you're "grabbing" the contents, but it's may be
more intuitive than the way it was.  any thoughts on this?

you can try it if you'd like:
    http://dev.laptop.org/git?p=users/pgf/grabkeyd
it needs to be started before X, and uinput needs to be loaded. 
(happily, uinput is already in the XO releases.) initially the
easiest way to test it is:
    # modprobe uinput
    # init 3
    # ./grabkeyd -l
    [ check that grabkeyd is running, check /var/log/messages
	for failure ]
    # init 5

as i recall, one of the objections to erik's implementation last
year was that it required the XTEST extension, which is considered
a security risk.  as far as i know, there's no risk to my current
implementation.  (other than, if it dies, you lose your mouse and
keyboard.  uh oh -- better run it from init.  :-)

because it's in a fairly critical path, grabkeyd has facility for
running at an elevated scheduling priority.  currently this is a
SCHED_FIFO priority, which is probably safe, but perhaps
overkill.  it's not the default.

comments solicited...


paul
=---------------------
 paul fox, pgf at laptop.org