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

[Ray Strode]

Hi,

On Tue, Mar 8, 2016 at 7:09 AM, Daniel Stone <daniel at fooishbar.org> wrote:
>> If one justification for server-side repeat is that if the compositor
>> is hosed and the user cannot see how many characters have been
>> repeated, then you could as well solve that in the client too, by
>> throttling your repeats to frame callbacks, but only when it makes sense
>> and undoing repeats is not feasible.
>
> This is what has just been implemented for GTK+.
No, the first draft of the patch was implemented that way for GTK+, but
Jonas pointed out a problem with the approach.  Not all key events lead
to screen updates.  For instance, some users hold down backspace for
a few seconds if they bungle their password at a terminal.  The expectation
is that holding down backspace in that case, should do the same thing
as hitting ctrl-u I guess (clear everything).

The current approach uses wl_display_sync to throttle, but that has a
problem too: clutter processes hardware input events at a lower priority
than mutter processes wayland events
( G_PRIORITY_HIGH_IDLE + 50 (150) vs G_PRIORITY_DEFAULT + 1 (1),
 lower is more urgent), so it's possible the sync could reply before a user
release event is processed.  It might be possible to fix that in
mutter/clutter, but might be tricky.

Anyway, clearly, the compositor stalling is bad, but if it happens we
shouldn't send a stream of the last character the user typed into the
application. That turns a momentary lock up into unpredictable
interaction with the application.  that's awful.

I guess if we don't do server repeat events, an alternative would be to
add a server timer protocol.  a client could request to be notified when
n milliseconds has passed.  Might be useful for other use cases too.

--Ray