[PATCH xserver 0/2] RFC: Sync key repeat with Wayland compositor

[Olivier Fourdan]

Hi Benoit,

----- Original Message -----
> Hello,
> 
> Here is my little contribution to the discussion, following a discussion
> on #wayland irc channel.
> 
> The issue discussed here, as far I understood, is due to a client that
> miss interpret a high latency of the compositor as a repeating key. This
> happen when a client receive a key press event but do not receive the
> corresponding release event for a large enough time even if this event
> have physically happened.

If I understand correctly your description, then yes, that sounds accurate.

In short, we want to avoid spurious client-side repeat events.
 
> The current xwayland is an instance of unexpected consequence of this
> issue but this issue is not limited to xwayland. Thus this issue must be
> fixed at the protocol level and not at software level.

I do agree a protocol would be useful to solve this problem in a more satisfactory manner.
 
> Trying to take in account all gathered comments, I built the following
> proposal.
> 
> First I propose to keep current behavior, i.e. client receive press and
> release events. But when a client is about to guess a repeating event,
> instead of guessing it, it have to request the server to provide
> repeating events.

So that would be both client-side and server-side key repeat?

> To do so, the client send a request with a parameter
> that represent a frequency or a special value (like 0) and something to
> identify the related key press event. if a key release have happened
> before the repeat request the server send the key release immediately
> and ignore the repeat request, else he send a repeat event immediately
> and try to send repeat event at the requested frequency until key
> release happen or another repeating request arrive.

Why would it need to send repeat key at a given frequency? The client requests the key repeat only once at first?

In which case another repeating request would occur in this scenario, how/why the client would emit a new repeat request while waiting for repeat events from the server?

> if a new repeating
> request arrive the frequency is updated to the new one if necessary or
> the repeat is canceled if the frequency is set to a special value (let's
> say 0). if the client does not receive release event or repeating key,
> he have to guess that the server is busy and wait for events.
> 
> This approach is very flexible, allowing client to request repeating
> only when needed. This solve the issue above and ensure that client get
> valid repeat event. This approach also avoid that the client make a
> request on every guessed repeat event.

But how does that solve the case where the client is already repeating keys while the user has released the key already, but the compositor hasn't propagated the event? This actually more likely to happen because the rate is usually higher than the initial delay to repeat.

I think such a proposal would benefit from a more formal description, because I am not sure I completely follow your explanation.

FWIW, I fancy simple solutions (where applicable), so I'd rather have a client-side repeat or a server side repeat, but not a mix of the two (but maybe I did not fully understand your description).

Assuming we want to keep client-side repeat, the client needs to make sure the compositor is still providing the events accurately, in time, to avoid spurious key repeats, any time it's about to emit a repeated event. But maybe I am over simplifying the problem.

Cheers,
Olivier