Comment by sergeykish | Hacker News Reader

Comment by sergeykish | Hacker News Reader

Parent Full thread

I'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-det...

[2] https://gitlab.freedesktop.org/libinput/libinput/-/blob/f2ba...

[3] https://gitlab.freedesktop.org/libinput/libinput/-/issues/19...

[4] http://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-l...

[5] https://aur.archlinux.org/packages/?O=0&K=libinput

[6] https://gitlab.freedesktop.org/libinput/libinput/-/issues/43...

Thanks 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.

Sounds 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

Thanks for updating your answer with your diff. Arch really looks great in how easy it was to try that. I'm running Ubuntu and have experience compiling custom kernels so this should be slightly easier to try, thanks once again for such a great reply.

Ultimately, I would prefer that this kind of feature is configurable in userland. Wayland's documentation page mentions that "Data from touchpads showed that almost all palm events during tying on a Lenovo T440 happened in the left-most and right-most 5% of the touchpad. The T440 series has one of the largest touchpads", and this may have been true several years ago, but it's quite common now to have larger and wider form-factor touchpads.

Wow, I didn't know how easy to do these things in arch. You made my day!

Reply on news.ycombinator.com