<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - RFE: keyboard debouncing" href="https://bugs.freedesktop.org/show_bug.cgi?id=105222#c11">Comment # 11</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - RFE: keyboard debouncing" href="https://bugs.freedesktop.org/show_bug.cgi?id=105222">bug 105222</a> from <a class="email" href="mailto:peter.hutterer@who-t.net" title="Peter Hutterer <peter.hutterer@who-t.net>"> Peter Hutterer</a> <pre>ok, if the threshold has to be at 70ms, then that's not a good sign. That threshold will lead to dropped key events if we ever enable this for a non-bouncing keyboard. It will likely also lead to dropped key events when we're bouncing, see my timing of press/release events. > A user who has a bouncy keyboard should be able to turn it on and set the > threshold, either via a configuration setting or (maybe at some point) > through a GUI panel in the system keyboard settings. I think it may be > hard to find a single threshold value that works perfectly for everyone, > hence the need to let users set it. problem here: after implementing libinput's debouncing support you now need to modify every single Wayland compositor to support that feature and provide a configuration option for it. In addition, you need a GUI that is accessible to actually configure it. Which means that the chances of this ever being consistently supported are almost nil. Aside from figuring out what the configuration options are going to be. You need an on/off toggle, a threshold, a keyboard selector (?), etc. These are all moving targets because you need all this in place before you can ship it to the public and get testing results. I think it might be 'easier' to write an evdev wrapper for the keyboard to debounce at the kernel event level. Then you can just run this on your machine and thus filter events there. less integration needed, and a bit more shoulder-shrugging allowed when something doesn't work ;) Process is basically: * open keyboard device, EVIOCGRAB so no-one else sees the events * create a uinput device that looks identical * read events from physical device, forward to uinput device after filtering Using python-libevdev this is probably less than 200 LOC and at least should indicate if the solution can work.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>