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

[Hans de Goede]

Hi,

On 07-03-16 19:23, Hans de Goede wrote:
> Hi,
>
> On 07-03-16 18:44, Olivier Fourdan wrote:
>> Key repeat is handled by the X server, but for Wayland, the key
>> press/release events need to be processed and forwarded by the Wayland
>> compositor first.
>>
>> If the Wayland compositor get stuck for whatever reason and does not
>> process the key release event fast enough, this may cause the Xwayland
>> server to generate spurious key repeat events.
>>
>> That actually can lead to a complete hang of both the Wayland compositor
>> and Xwayland as seen in the following GNOME bug:
>>
>>    https://bugzilla.gnome.org/show_bug.cgi?id=762618
>>
>> Basically, what happens here is that the Wayland compositor takes longer
>> to actually process the fullscreen/unfullscreen transition than the
>> repeat delay.
>>
>> As a result, while the user has released the F11 key that triggers the
>> fullscreen/unfullscreen transition, the Wayland compositor is stuck
>> is a graphical operation and cannot process the key release events, which
>> triggers the auto-repeat in Xwayland, and therefore cause even more
>> fullscreen transitions. Only way out here is to kill the Xwayland
>> application and wait for the queued up event to clear out...
>>
>> While this is arguably a bug in the Wayland compositor, there is no
>> way that I can think of to guarantee that this cannot happen.
>>
>> One possiblity to mitigate the problem is to block the key repeat until
>> we are sure the Wayland compositor is actually processing events.
>>
>> The idea comes from a similar patch for gtk+ by Ray Strode here:
>>
>>    https://bug757942.bugzilla-attachments.gnome.org/attachment.cgi?id=322876
>>
>> from bug https://bugzilla.gnome.org/show_bug.cgi?id=757942
>>
>> While the following patches do fix the issue in my case, they are not
>> perfect and only a mitigation of the problem (e.g. they could easily be
>> defeated by a Wayland compositor that would have different priority for
>> Wayland protocol and input processing), that's why I send these couple
>> of patches as an RFC for now.
>
> Why not simply rely on the keyrepeat of the compositor and forward repeat
> events from it ? That way xwayland will also end up using the compositors
> keyrepeat settings which would mean the user does not need to worry
> about configuring this in multiple places ?
>
> Or is keyrepeat left to the toolkit under wayland ? In that case please
> ignore my comment :)

OK, I've just seen that key-repeat is indeed left to the client / toolkit
under wayland. I'm wondering if that is a deliberate decision or more
of an accident, and if maybe we need a protocol ext for optional compositor
side key-repeat, that seems better then all clients needing to implement
this workaround.

Regards,

Hans