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

Fri Mar 11 10:40:54 UTC 2016

Hi,

Just an addition to my previous explanation.

The systematic server side key repeating only is also a good solution,
if we made the hypothesis that long key press are a lot less frequent
than short key pressing.

And this solution is less complex.

Best regards.

Le 11/03/2016 11:25, Benoit Gschwind a écrit :
> Hi Olivier,
> 
> Le 11/03/2016 10:22, Olivier Fourdan a écrit :
>> 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?
> 
> Yes, my current proposal is hybrid, instead of always reporting
> repeating key for any key combination, the server wait for a request
> from the client. Once the client made the request, the client get
> repeating key events until the client cancel the request or key release
> happen. In other words the server generate only valid repeating key events.
> 
>>
>>> 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?
> 
> This to avoid the client to send a request on every guessed repeating
> keys. the current proposal look like the following sequence:
> 
> 1. key press event
> 2. after some time client request the repeat event, because client guess one
> 3. the sever reply by repeat event (if necessary, else he send key release)
> 4. server send a repeat event again
> 5. server send a repeat event again
> [...]
> 10. server send a repeat event again
> 11. server send a release event.
> 
> and this avoid a lot of useless client requests, most of the time, as
> the following sequence show:
> 
> 1. key press
> 2. after some time client request the repeat event.
> 3. the sever reply by repeat event (if necessary)
> 4. after some time client request the repeat event.
> 5. the sever reply by repeat event (if necessary)
> 6. after some time client request the repeat event.
> 7. the sever reply by repeat event (if necessary)
> [...]
> 11. server send a release event.
> 
>>
>> 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?
> 
> The client may want to cancel the recursive repeating from the server,
> telling him that he doesn't want repeating any more. For example you
> reach the scroll boundary. The client may also want to change the
> frequency. Some application have 2 frequency a slow one at first and
> them a fast one if the key press is long enough.
> 
>>
>>> 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.
> 
> The client never guess the key repeat, he ask the server to send them if
> they actually had happen, i.e. the key wasn't released. In the case
> above (Xwayland), Xwayland ask for repeating keys, if the key still
> pressed the repeat event are sent else the release event is sent, fixing
> the issue. Afterward, If new repeat event arrive he can sent those
> events to the X11 client because he has the certitude that this events
> are valid.
> 
>>
>> 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).
> 
> imo, you are wrong here, a server side only key repeating will flood the
> client, like games or for scrolling. a client side (i.e. the client
> validate each repeat request) will flood the server. My proposal
> mitigate both.
> 
>>
>> 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.
> 
> In my proposal, the client should not expect that repeat are provided
> with accurate timing, but the compositor ensure that repeating are
> valid. The compositor try his best to follow the requested timing, but
> he may be not able to provide them in time, most likely because he is
> busy. In that case the client have to wait, and do not flood the server
> for key repeating request (that will make the server even more busy)
> 
>>
>> Cheers,
>> Olivier
>>
> 
> I hope this clarify my point of view :)
> 
> Best Regards.
> 
> 
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 