Input and games.

[Bill Spitzak]

On 04/23/2013 11:26 PM, David Herrmann wrote:

> I'm currently looking into an interface that provides file-descriptors
> for wl_keyboard/wl_mouse for clients. The FDs are muted (EVIOCMUTE
> proposed on linux-input by krh) while clients are inactive and unmuted
> when they get input focus. This is basically a performance boost
> because input events no longer pass through the compositor.
> However, this mechanism could be easily used to forward any other
> input fd to clients. A wl_gamepad interface could be just empty except
> for this FD-passing logic.

Anything like this (and also database of device key mappings) is going 
to have trouble if Wayland supports remote clients. All of this would 
have to be forwarded to the client from the remote display, introducing 
a lot of complexity and nasty bugs when clients disagree with the server 
about what device mapping is being used. It also looks impossible to 
support apis like RDP where this translation is already done, except by 
really kludgy inverse keymaps (which cause stupid bugs in NX right now 
so I think they are a bad idea).

Also even the current wayland behavior with keyboards seems to conflict 
with input methods. You communicate with input methods with wayland 
requests and events, and the input method has to do all the work of 
decoding the keystrokes anyway.