<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body><a class="email" href="mailto:peter.hutterer@who-t.net" title="Peter Hutterer <peter.hutterer@who-t.net>"> Peter Hutterer</a> changed <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - possibility to disable various timeouts?" href="https://bugs.freedesktop.org/show_bug.cgi?id=90613">bug 90613</a> <table border="1" cellspacing="0" cellpadding="8"> <tr> <th>What</th> <th>Removed</th> <th>Added</th> </tr> <tr> <td style="text-align:right;">Status</td> <td>NEW </td> <td>ASSIGNED </td> </tr> <tr> <td style="text-align:right;">CC</td> <td> </td> <td>peter.hutterer@who-t.net </td> </tr></table> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - possibility to disable various timeouts?" href="https://bugs.freedesktop.org/show_bug.cgi?id=90613#c1">Comment # 1</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - possibility to disable various timeouts?" href="https://bugs.freedesktop.org/show_bug.cgi?id=90613">bug 90613</a> from <a class="email" href="mailto:peter.hutterer@who-t.net" title="Peter Hutterer <peter.hutterer@who-t.net>"> Peter Hutterer</a> <pre>(In reply to Mantas Mikulėnas from <a href="show_bug.cgi?id=90613#c0">comment #0</a>) > Well, in short, it has many false positives. I think it could at least > exclude the Tab key, and/or keypresses when a modifier key is being held? > That would take care of many false-positives with Ctrl/Alt/Super shortcut > keys. whoops, tab should definitely be in the list here, and the menu keys too. I'll get a fix out for that. The "while modifier key is down" gets a bit trickier because that partially depends on the key layout but it should be doable. Note that there is a much shorter timeout for single key presses, so if you just type Ctrl+A you shouldn't be hitting the long timeout. I also have another patch in the works for <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - Accept (some) touches after palm detection timeout" href="show_bug.cgi?id=90501">Bug 90501</a> which should probably remove or at least reduce most of your pain points. > Anyway, I see the changelog has "the feature is currently enabled for all > touchpads but will be reduced in the future to only apply to touchpads where > finger width or pressure data is unreliable". So I'll just wait for that. > I'm fine with having to add hwdb entries or something. fwiw, we need thumb detection for that first (<a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - Add thumb detection" href="show_bug.cgi?id=90528">Bug 90528</a>) > — The drag timeout (recently increased to 500 ms). — > > I know it can be cancelled with a tap, and I'm trying to get used to that, > but it still feels as if the driver is buggy (or lagging like hell). > > I can see the timeout being useful with slow cursor speeds, when one needs > several swipes to drag something across the screen. But it's something that > varies greatly between touchpads and AccelSpeed settings. In my case, it's > mostly useless even with AccelSpeed of 0.0, and outright annoying with 1.0. > So if the speed is adjustable, I think this timeout should be as well? At the risk of saying something along the lines of "we know better than you" but I'm really thinking about getting users to re-train themselves to use the tap to end the drag. It's a new feature (at least in linux) but I've used it in OS X for years and it is superior (well, for us driver writers anyway ;) and becomes second nature quickly. I don't know that we can change the timeouts around much, that would require quiet complex and error-prone heuristic (and we don't actually know if the pointer moves on the screen). Either way, if you want to continue the discussion on the drag timeout please file a separate bug for that so we don't mix up the two issues.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>