<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Key repeat cancel under Wayland should depend on which key is repeating" href="https://bugzilla.gnome.org/show_bug.cgi?id=781285#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Key repeat cancel under Wayland should depend on which key is repeating" href="https://bugzilla.gnome.org/show_bug.cgi?id=781285">bug 781285</a> from <a href="page.cgi?id=describeuser.html&login=dant%40pnym.net" title="Dan Torop <dant@pnym.net>"> Dan Torop</a> <pre>(In reply to Olivier Fourdan from <a href="show_bug.cgi?id=781285#c1">comment #1</a>) Hi Olivier, Glad to hear back! > That looks very similar to <a class="bz_bug_link bz_status_NEW " title="NEW - Wayland: Make key repeat more resilient to keys not being released" href="show_bug.cgi?id=781896">bug 781896</a> and <a href="attachment.cgi?id=350636&action=diff" name="attach_350636" title="[PATCH] Wayland: Cancel repeat only on last key press">attachment 350636</a> <a href="attachment.cgi?id=350636&action=edit" title="[PATCH] Wayland: Cancel repeat only on last key press">[details]</a> <a href='review?bug=781285&attachment=350636'>[review]</a> Indeed <a class="bz_bug_link bz_status_NEW " title="NEW - Wayland: Make key repeat more resilient to keys not being released" href="show_bug.cgi?id=781896">bug 781896</a> and this one both address the same underlying problem. > > Can you see if this works for you? Mixed results: <a href="attachment.cgi?id=350636&action=diff" name="attach_350636" title="[PATCH] Wayland: Cancel repeat only on last key press">attachment 350636</a> <a href="attachment.cgi?id=350636&action=edit" title="[PATCH] Wayland: Cancel repeat only on last key press">[details]</a> <a href='review?bug=781285&attachment=350636'>[review]</a> does solve <a class="bz_bug_link bz_status_NEW " title="NEW - Wayland: Make key repeat more resilient to keys not being released" href="show_bug.cgi?id=781896">bug 781896</a>, but it doesn't produce expected behavior in the second case of this bug. To rewrite that case as in your (clearer) steps in <a class="bz_bug_link bz_status_NEW " title="NEW - Wayland: Make key repeat more resilient to keys not being released" href="show_bug.cgi?id=781896">bug 781896</a>: Steps to reproduce: 1. Press key "a" and keep the key pressed. 2. Press key "b" and release. 3. Press key "b" and keep the key pressed. 4. Release key "a". Actual result: Key "a" is repeated. Once key "b" is pressed and released, all repeats stop. Then key "b" is repeated when it is pressed again, but all repeat stops when key "a" is released. Expected result: Once key "a" is released, key "b" should continue to repeat, as it is still depressed and was one repeating. The expected result may well be debatable, and is the proverbial corner case! But I put it in to suggest that counting the number of keys pressed is not actually pertinent. And this counting is easy to fool. So in the case above, in your patch, I believe that this is happening: 1. Press key "a" and keep the key pressed [nkeys = 1] 2. Press key "b" [nkeys = 2] and release [nkeys = 0, as have released the repeated key] 3. Press key "b" and keep the key pressed [nkeys = 1] 4. Release key "a". [nkeys = 0, and hence repeating stops, though "b" is still pressed and was repeating] I'd argue that what really matters here isn't the count of keys pressed, but rather whether the key released is the currently repeated key. Hence my <a href="attachment.cgi?id=349836&action=diff" name="attach_349836" title="[PATCH] wayland: selectively cancel key repeat on key release">attachment 349836</a> <a href="attachment.cgi?id=349836&action=edit" title="[PATCH] wayland: selectively cancel key repeat on key release">[details]</a> <a href='review?bug=781285&attachment=349836'>[review]</a> entirely eliminates the nkeys counter, and just uses a flag (repeat_active). As an aside, in your patch, you init repeat_key to 0. In my patch, I didn't initialize repeat_key, but do test it, assuming that, as it was only tested after a key release, it would by then have already been set by a keypress. Your approach is certainly safer! This bug report came from a problem with darktable to under Wayland (<a href="https://redmine.darktable.org/issues/11535#note-14">https://redmine.darktable.org/issues/11535#note-14</a>), and both your <a href="attachment.cgi?id=350636&action=diff" name="attach_350636" title="[PATCH] Wayland: Cancel repeat only on last key press">attachment 350636</a> <a href="attachment.cgi?id=350636&action=edit" title="[PATCH] Wayland: Cancel repeat only on last key press">[details]</a> <a href='review?bug=781285&attachment=350636'>[review]</a> and my <a href="attachment.cgi?id=349836&action=diff" name="attach_349836" title="[PATCH] wayland: selectively cancel key repeat on key release">attachment 349836</a> <a href="attachment.cgi?id=349836&action=edit" title="[PATCH] wayland: selectively cancel key repeat on key release">[details]</a> <a href='review?bug=781285&attachment=349836'>[review]</a> solve that problem. I don't have the big picture of Wayland devices which you have, and would hate to blithely advocate removal of nkeys, but do want to put it out there for consideration! Thank you, Dan</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>