[PATCH xserver 2/2] xwayland: add a server sync before repeating keys

[Daniel Stone]

Hi,

On 8 March 2016 at 12:08, Olivier Fourdan <fourdan at gmail.com> wrote:
> On 8 March 2016 at 13:06, Olivier Fourdan <fourdan at gmail.com> wrote:
>> On 8 March 2016 at 12:59, Daniel Stone <daniel at fooishbar.org> wrote:
>>> On 7 March 2016 at 17:45, Olivier Fourdan <ofourdan at redhat.com> wrote:
>>> > Key repeat is handled by the X server, but input events need to be
>>> > processed and forwarded by the Wayland compositor first.
>>> >
>>> > Make sure the Wayland compositor is actually processing events, to
>>> > avoid repeating keys in xwayland while the Wayland compositor cannot
>>> > deal with input events for whatever reason, thus not dispatching key
>>> > release events, leading to fictious repeat keys while the use has
>>> > already released the key.
>>>
>>> I worry about the potential for deadlock here: what happens if the
>>> compositor is blocked on a roundtrip to the X server (which can easily
>>> happen with Mutter I believe), but the server processes the key repeat
>>> timer before the client request? At that point, no-one can make
>>> progress ...
>>
>>
>> The key repeat is simply discarded, ie no (fake, repeated) key press event
>> will be emitted but the X server is not blocked and still process other
>> events, so I am not sure how we could end up in a deadlock. Unless I don't
>> understand what you mean.
>>
>> BTW, this patch is simply a proof of concept, I'll post a slightly less
>> "hack-y-ish" patch is a short while.

Ah yes, right you are. More coffee required.

We don't really make any effort to dispatch the queue though, so this
could also trigger just because the X server itself has been blocked
for too long and hasn't dispatched the Wayland event queue, or because
the server has fired the repeat timer before it's processed the
Wayland event queue. But this is easily fixed by just adding a
dispatch before the check.

Cheers,
Daniel