[RFC] compositor: Simple key repeat implementation.

[Joakim Sindholt]

On Fri, 2012-03-09 at 10:53 +0000, Daniel Stone wrote:
> 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.

Let me try to address these concerns one by one:
1. You will not need to generate events. You send a focus-lost event
when the buffer loses focus and let the client work out how to reset its
own state.
2. You don't need to communicate any configuration data. The toolkits
can agree on where to retrieve that from.
3. evdev events are already timestamped, aren't they? I don't see the
problem here.

The only real problem I have with this is that it doesn't absolutely
need to be in the compositor, and you will be sending data that doesn't
absolutely need to be sent. A client can easily create these events by
itself (if necessary). I don't believe it's up to the compositor to say
how input devices work.

- Joakim