3 ms·
I love Linux desktop but miss these creature comforts too. For me, my biggest input issue is the lack of customisation around trackpad deadzones, i.e. the 15% o
by andrewmackrodt 6y ago
I love Linux desktop but miss these creature comforts too. For me, my biggest input issue is the lack of customisation around trackpad deadzones, i.e. the 15% or so deadzone on the left and right of the trackpad. My trackpad is exactly in the center of my laptop but my palm is usually offset slightly to the left. This means my first interaction with the trackpad often happens in this deadzone area on the left-hand side of the trackpad, so no input gets registered until I lift my finger and "enter" it more towards the center.
There are a huge variety of laptops with different size trackpads, different positions, varying levels of palm rejection etc but there's zero customisability around this seemingly simple behaviour.
My Windows dualboot has no such issue and macOS of course (using a MacBook) works fantastically without this limitations.
- cmurf 6y agoSounds like a libinput bug. https://www.freedesktop.org/wiki/Software/libinput/ https://www.freedesktop.org/wiki/Software/libinput/ https://wayland.freedesktop.org/libinput/doc/latest/touchpad-pressure-debugging.html#debugging-touch-size-ranges https://wayland.freedesktop.org/libinput/doc/latest/touchpad... I'd file a bug though, and see if whatever's wrong can be fixed for every trackpad of that same make/model.
- andrewmackrodt 6y agoThanks for the links, particularly the second one. It looks like something I may have experimented with before but I'll try again. It could be that my touchpad does not support ABS_MT_TOUCH_MAJOR (Dell XPS 2-in-1 2019). My "issue" is described as expected behaviour in this documentation: https://wayland.freedesktop.org/libinput/doc/latest/palm-detection.html#palm-exclusion-zones https://wayland.freedesktop.org/libinput/doc/latest/palm-det... (the "A" event).
- sergeykish 6y agoI've never noticed such issue, quick search shows that one has to start on edge and movement in vertical direction [1]. Vanilla edges are 8% of the width on each side [2]. There was a proposal to add configuration option [3], rejected — they've tried this route before, it was impossible to test. Fortunately source is there and it is easy to patch (try to set 0%). That's quite common, for example there are several patched libinput on AUR [5]. Does your hardware has firmware palm detection mechanism? Current bug [6] (Palm exclusion zones are not worth it on some hardware). [1] https://wayland.freedesktop.org/libinput/doc/latest/palm-detection.html#palm-exclusion-zones https://wayland.freedesktop.org/libinput/doc/latest/palm-det... [2] https://gitlab.freedesktop.org/libinput/libinput/-/blob/f2baea50c01f9e10fb2076f5dd64311347ac5c3e/src/evdev-mt-touchpad.c#L3265 https://gitlab.freedesktop.org/libinput/libinput/-/blob/f2ba... [3] https://gitlab.freedesktop.org/libinput/libinput/-/issues/190 https://gitlab.freedesktop.org/libinput/libinput/-/issues/19... [4] http://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-lot-of-config.html http://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-l... [5] https://aur.archlinux.org/packages/?O=0&K=libinput https://aur.archlinux.org/packages/?O=0&K=libinput [6] https://gitlab.freedesktop.org/libinput/libinput/-/issues/433 https://gitlab.freedesktop.org/libinput/libinput/-/issues/43...
- andrewmackrodt 6y agoThanks for your detailed reply. Unfortunately the Microsoft Precision Touchpad on my Dell XPS 2-in-1 2019 (Wacom HID 48EE Finger) does not support ABS_MT_TOUCH_MAJOR; it's worth mentioning however that Windows works perfectly and palm rejection seems to work on a hardware/firmware level (no output when running "libinput debug-events" and moving a palm) making libinput restrictions unnecessary and most definitely unwanted. The touchpad is about 7 fingers in width and the palm exclusion zones are a little more than one finger on each side; this is roughly 30% of the trackpad, or 15% each side, certainly bigger than 8% and even that would be too much. Additionally, although the documentation does state that rejections should only happen for a vertical like movement, it also happens for a completely horizontal one.
- sergeykish 6y agoSounds extremely strange. You should fill an issue. My Dell Latitude E7440 follows description and I believe same is true for most of the users. I have to start movement at least diagonally, once it catches further direction does not matter. It produces no output when running `libinput debug-events`. I've recompiled my version with 0% just to check. /* palm edges are 8% of the width on each side */ - mm.x = min(8, width * 0.00); + mm.x = min(8, width * 0.08); edges = evdev_device_mm_to_units(device, &mm); tp->palm.left_edge = edges.x; - mm.x = width - min(8, width * 0.00); + mm.x = width - min(8, width * 0.08); edges = evdev_device_mm_to_units(device, &mm); tp->palm.right_edge = edges.x; Disabled. I like how it is easy Arch allows such experiments: $ yay -G libinput $ cd libinput $ makepkg -so ==> Verifying source file signatures with gpg... libinput-1.16.4.tar.xz ... FAILED (unknown public key E23B7E70B467F0BF) ==> ERROR: One or more PGP signatures could not be verified! $ gpg --recv-key E23B7E70B467F0BF $ makepkg -so $ vim src/libinput-1.16.4/src/evdev-mt-touchpad.c $ makepkg -fei
- beci 6y agoWow, I didn't know how easy to do these things in arch. You made my day!
- Yaggo 6y ago> I love Linux desktop Which "Linux" desktop are you referring to?
- andrewmackrodt 6y agoI answered generically because my comment was about a libinput "issue" which affects all distributions and desktop environments. (Queue 2021 is the year of linux desktop). Personally, I see this change as a regression from the highly configurable synaptics driver. As you've asked, distribution wise I typically run an Ubuntu LTS with Gnome 3 but rolling releases such as Manjaro and lightweight DE like XFCE are also very nice.