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

[David Herrmann]

Hi

On Tue, Mar 8, 2016 at 4:41 PM, Ray Strode <halfline at gmail.com> wrote:
> 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+.
[...]
> 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.
[...]
> 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.

This still suffers from your priority-starvation-bug. If a simple
ping/pong protocol barrier doesn't solve the issue, why would the
timer? You'd have to put the timer on lowest priority to make that
work, but then again you can do the same for wl_display_sync.

Btw., if your compositor stalls for a bit more, you end up with an
evdev-queue overrun and have more trouble than you can solve. Is it
really worth solving that single race, while there're still several
known other issues that happen on stalling compositors? Why not rather
put keyboard handling on high-priority? It is low-throughput, anyway.

David