A few comments on the recently added timers/timeouts. — The recently added "disable while typing" timer. — It's a bit difficult to determine what is "typing" and what is not. Currently it triggers on all non-modifier key events – which means, I lose the touchpad every time I switch between programs with Alt+Tab, or terminal tabs with Alt+1/2/3…, or browser tabs with Ctrl+Tab, or select files with Ctrl+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. 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. — 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?
(In reply to Mantas Mikulėnas from comment #0) > 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 Bug 90501 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 (Bug 90528) > — 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.
commit fe0ccc8c74d38e4173fefb386dfbeadfb4e06d96 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Mon May 25 08:48:25 2015 +1000 touchpad: extend the key blacklist for disable-while-typing
commit b8518f8f7c1611c58badb9d73e66d9c722849b55 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Tue Jun 2 13:04:44 2015 +1000 touchpad: reduce tap-n-drag timeout to 300ms technically not the fix you asked for in this bug since it's not a configuration option but still. The timeout is now a lot shorter so it doesn't feel quite as laggy anymore and of course the tap-to-end-drag still works too. So in short, my hope now is that you don't require a config option for this anymore now :) I'm going to close this bug as fixed, if you still have issues with DWT enabling when it shouldn't please give me a list of typical key presses when it enables erroneously.
Thanks. The latest git version is much more usable now.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.