Hi, On Tue, Mar 8, 2016 at 7:09 AM, Daniel Stone <dan...@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+. No, the first draft of the patch was implemented that way for GTK+, but Jonas pointed out a problem with the approach. Not all key events lead to screen updates. For instance, some users hold down backspace for a few seconds if they bungle their password at a terminal. The expectation is that holding down backspace in that case, should do the same thing as hitting ctrl-u I guess (clear everything).
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. Anyway, clearly, the compositor stalling is bad, but if it happens we shouldn't send a stream of the last character the user typed into the application. That turns a momentary lock up into unpredictable interaction with the application. that's awful. 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. --Ray _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel