[RFC] Global binding

Quentin Glidic sardemff7+wayland at sardemff7.net
Fri Dec 20 08:24:05 PST 2013


With the recent security concerns about the screenshoter interface, a
sibling topic came back to surface: global keyboard/mouse listening.

TL;DR: We need to have a global binding mechanism. I suggest a simple
request to bind an *action* which is fully controlled by the compositor.

The must-have use case we will have to support is the “Push to talk”.
Any Teamspeak or Mumble user is well aware of that feature, let me
explain it quickly for others.
These two programs are low-latency VoIP applications targeting
multiplayer game players. Their point is to send only relevant
information (voice) to your teammates. Two ways exist to achieve that:
Push-to-talk or Voice activation. Voice activation means monitoring the
sound input and sending the data only when you hit a preconfigured
threshold. Push-to-talk is to send the data only when the user is
pushing a key or a mouse button, and stopping on release.

The latter is obviously non working with the current Wayland protocols,
due to the isolation design. The exact same mechanism is used by media
players (mainly music players) to allow one to start and stop the
playing while not focusing the application (they just drop either the
push or release event).

Here is the simple way I think we could solve this problem: a
wl_seat.bind(action) request.

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).

This request creates a wl_seat_binding object, which have two events:
pushed and released. I hope these ones are obvious. :-)

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

The third point: which application to send the events to?
I will steal the idea from the media-keys plugin of
gnome-settings-daemon. All applications can bind whichever action they
want (even non existing one, read further). The *last focused*
application is the only one to receive the events. If none was ever
focused, the compositor is free to select one or maybe the last one bound.

The fourth (optional?) point: the compositor can have complex heuristics
to prefer one client to another.
When I launch my video player, I probably want media keys to play/pause
my movie. I may have my music player running in the background, paused.
I do not want the keys to resume my music if I focus the music player by
mistake (say, the cat chasing my mouse).
To address that, we may have a setting to always prefer a client to any
other. A saner way may be to have multiple actions on the same binding,
which are ordered (by the user, but with a sane default). In this
example, I would have "video-toggle" and "music-toggle", and only
"video-toggle" would be sent if an application registered it.

Last but not least: what about input statistics applications?

On 19/12/2013 18:53, Maarten Baert wrote:
> Another example, for an application that collects mouse and keyboard
> statistics (if you think this is silly or dangerous, consider that
> WhatPulse <https://en.wikipedia.org/wiki/Whatpulse> is very popular
> and you probably won't be able to convince users to stop using it):

Being popular does not prevent an application to be silly, users can be 
silly too, and most actually are…

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 was planning to send this mail for some time now, and I hope the 
overall idea is clear enough. I will happily answer to your comments and 
fill any gap I may have left.

If enough people seem interested in this idea, I may find the motivation 
to hack a PoC patch for Weston by the end of the year.



Quentin “Sardem FF7” Glidic

More information about the wayland-devel mailing list