[RFC] Global binding

Maarten Baert maarten-baert at hotmail.com
Fri Dec 20 09:53:10 PST 2013

On 20/12/13 17:24, Quentin Glidic wrote:
> The first important point is here: the client only binds an *action*.
> The action is a describing string and does not leak the key which is
> bound. There would be a set of standard actions, some vendors ones, and
> user custom ones (which application would have to support too with a
> custom setting). 
I really like this idea. KDE applications already do this by default,
all keyboard shortcuts are collected and configured in one place. I do
hope that applications will have some way to suggest default keybindings
(which the compositor is free to ignore) so the user won't have to open
their system settings and configure everything manually for every new
application that he/she installs (it's also hard to write tutorials for
applications if every user has different keybindings, and annoying for
people that sometimes use other user accounts than their own). The
paranoid user is still free to configure his/her compositor to ignore
all default keybindings or maybe pop up a confirmation dialog before
accepting them.

> The second point: which key(s)/mouse button(s) to bind?
> This is the compositor’s job to choose that (hey, based on the user
> settings of course). It can have a GUI, a key file, whatever. I think we
> should allow the same binding to have multiple actions (see the fourth
> point). 
And vice versa: one action can have multiple bindings (e.g. a mouse
gesture and a keyboard shortcut). We shouldn't limit it to just keyboard
and mouse, the compositor should be free to use any mechanism it wants,
such as gestures, joystick buttons, maybe even voice commands.

> I think this really specific use case *must not* be mixed with global
> bindings. We should probably have a global binding mechanism opened to
> every application and a specific trusted one for WhatPulse and friends.
> It could even be a system-wide LD_PRELOAD-like (*-like*, e.g. a
> specific hooking mechanism in wayland-server) thing that hooks in the
> wayland-server component and shipped with WhatPulse directly.
I agree. The two are completely different use cases and different
behaviour is expected.

The crucial difference is that a global binding will 'eat' the
mouse/keyboard event, i.e. the event will not go to the current
application. If a user decides that the T key will be his push-to-talk
key, then they probably don't want the application to see that keypress
(this is actually a problem with Mumble right now). A global binding is
also not a security risk (like a keylogger) because it would be obvious
to the user that the keyboard isn't working (assuming untrusted programs
can't generate artificial keypresses). In that sense it is no more
dangerous than focus stealing.

On the other hand a global mouse/keyboard listener is essentially an
invisible keylogger and this functionality should only be given to
trusted clients.

I think in the long term Wayland will need both, just like X11 has both:
the former is XGrabKey (which has a lot of problems and limitations that
I hope Wayland will solve), and the latter is the XTest extension. The
first one is probably more important though, so let's focus on that first.

Maarten Baert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131220/c61d053f/attachment-0001.html>

More information about the wayland-devel mailing list