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. > > > _______________________________________________ > [email protected]: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
