[RFC] compositor: Simple key repeat implementation.

[Daniel Stone]

Hi,

On 8 March 2012 18:20, Joakim Sindholt <opensource at zhasha.com> wrote:
> I think that wayland should be consistent across the board and act
> *only* as a display server and otherwise implement only the minimum set
> of features necessary for proper operation. That entails (what I think
> was the original intent) only redirecting pointer input and absolutely
> nothing else.
> What I think is important to remember is that wayland isn't itself a
> pointing device, and only really serves as a way to push buffers to a
> screen. Letting toolkit developers agree on how to do things is the
> default position and in this case I don't think it's warranted to
> complicate the server more by making it responsible for reinterpreting
> input devices past simply picking and redirecting.
>
> A good example of why wayland shouldn't make these decisions: there
> would be no arguments over how to generate imaginary events in the
> server.

The counter-argument, though, is that you'll be generating imaginary
events anyway.  If someone steals focus from you or the keyboard is
grabbed or the compositor decides for any reason to do anything at all
that affects your interpretation of the key, it'll have to synthesise
a fake release to the client to avoid it repeating endlessly.  That
also involves creating more (not less) protocol to communicate the key
repeat settings - which keys need to repeat, the delay before they
should start repeating, and the rate at which they should repeat.  Not
to mention that it also involves adding more timestamps, whereas if
the compositor handles repeating, we can just get away with serial
numbers.

So, I don't think pushing it to the clients simplifies anything or
solves any problems, while it actually creates problems.

Cheers,
Daniel