[Sugar-devel] future of the grab key?

[Tomeu Vizoso]

Hi Paul,

this looks as awesome work!

If I understood correctly what you did, nor applications nor the shell
need to be modified in order to benefit from this, right?

If so, then I guess this is something as independent from Sugar as the
Geode X driver may be and you don't need to worry about Sugar
schedules. Just about the schedules of the people that you want to
ship this ;)

I recommend you the same I recommended Michael on #sugar: once Sugar
on a Stick gets a bit more stable on the XO, build your own images
with your software in and ask people to try it. Or if you don't need
so much wide testing, just package it and tell people to install the
rpm on top of SoaS on the XO.

Regards,

Tomeu

On Tue, Feb 24, 2009 at 21:31,  <pgf at laptop.org> wrote:
> 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
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>