I'll need an evemu-record of a palm interaction please. When does this problem occur? during typing or other interactions?

Thanks Peter.

It seems to me - though I've now switched to the synaptic driver - that the problem occured both when typing (which is when it is really serious) but also when not (i.e. when I merely hover over the keyboard, but accidentally brush the keyboard).

I do not know how to generate an 'evemu-record'.

for evemu, see: https://wayland.freedesktop.org/libinput/doc/latest/reporting_bugs.html#evemu

@Peter

I've  done the recording (and in so doing noticed that palm detection seems to *partially* work), but I do not know what file the recording has gone into to. Please advise.

Also, it seems you might need this:

$ udevadm info /sys/class/input/event6
P: /devices/platform/i8042/serio1/input/input5/event6
N: input/event6
S: input/by-path/platform-i8042-serio-1-event-mouse
E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-event-mouse
E: DEVNAME=/dev/input/event6
E: DEVPATH=/devices/platform/i8042/serio1/input/input5/event6
E: ID_INPUT=1
E: ID_INPUT_TOUCHPAD=1
E: ID_INPUT_TOUCHSCREEN=1
E: ID_PATH=platform-i8042-serio-1
E: ID_PATH_TAG=platform-i8042-serio-1
E: ID_SERIAL=noserial
E: LIBINPUT_DEVICE_GROUP=11/2/7/1a1:isa0060/serio1
E: LIBINPUT_MODEL_SYNAPTICS_SERIAL_TOUCHPAD=1
E: MAJOR=13
E: MINOR=70
E: SUBSYSTEM=input
E: USEC_INITIALIZED=2596385

please read the man page and/or the link I posted, explaining things one-by-one doesn't scale

(In reply to Peter Hutterer from comment #5)
> please read the man page and/or the link I posted, explaining things
> one-by-one doesn't scale

I am sympathetic. Yet, (1) I find it hard to do what you want of me, and (2) it seems likely that many people will be affected by this bug.

In elaboration of 1: `man evemu` produces nothing; `man evemu-tools' produces nothing; I find nothing on the link you gave about the file the recording produces.

An inference from 2: the onus here is on the developers.

I add: I have fixed this problem to my satisfaction, in that I have have made the synaptics driver work decently; I reported this problem in an attempt to help libinput and those who use it.

the man page is for evemu-record. If you run the command as in the linked page:

$ sudo evemu-record > scroll.evemu

The output of evemu is in the 'scroll.evemu' file, you can obviously change the name of that.

> I add: I have fixed this problem to my satisfaction, in that I have have made 
> the synaptics driver work decently; I reported this problem in an attempt to 
> help libinput and those who use it.

the synaptics driver is in maintenance mode, i.e. it doesn't see any new features beyond maybe the odd crasher fix. So in a year's time or so, whenever you switch to a Wayland compositor or new HW requires you to use the new features, you'll run into the same bug again if it doesn't get fixed in libinput. Plus, you get the warm fuzzy feeling of fixing it for everyone with the same HW rather than just for yourself. I'd be interested in what synaptics options you used to tweak this, that'll likely provide a hint too.

While it did seem to me that the situation had been somewhat improved for a

Created attachment 138826 [details]
scroll.evemu file

What am I looking at here? I can see a few movements and a few taps. They all seem to be correctly sending events. But what am I supposed to be looking for here? There are some touches that look large enough to be possible palms but the touchpad doesn't have a palm threshold defined.

So the first course of action would be to run the "libinput measure touchpad-pressure" tool to figure out the touch ranges. Once you've narrowed those down, a hwdb entry can be added and that should make at least the high-pressure palm interference go away. See this link for the details:
https://wayland.freedesktop.org/libinput/doc/latest/touchpad_pressure.html

Peter,

The problem is failed palm-detection. The recording is of me typing and in so doing suffering from failed palm-detection. Beyond that, I can't tell you what to look for (since the problem is something that *fails* to register or, at least, to be acted upon).

After working out that I needed several python modules, and installing them, 'libinput measure touchpad-pressure' generated this message: 'Failed to open device'. If run with 'sudo', the command produces a lot of error-message text, and concludes with, 'module "pyudev" has no attribute "Devices".'

Am I right in thinking that anything I manage to generate from the 'libinput measure touchpad-pressure' tool will be incorporated into libinput, such that others will not have the problems I have had?

right, the main problem we have with evemu is that it can only record a single device at a time (and your version of evemu is... old). libinput git master has a libinput record tool that can be used to record touchpad and keyboard at the same time, thus indicating when dwt doesn't work.

What's the initial output of libinput debug-events --verbose, before any events. It should show the keyboard being paired with the touchpad for dwt, if that doesn't happen then that's the main issue here.

You can git clone and build libinput to run the tool, it's safe to do so if you never install it (and you can run sudo ./builddir/libinput-record). Probably even easier than getting python to work ;)

> 'module "pyudev" has no attribute "Devices".'

urgh. this is the first time I've seen that issue, I suspect that mint has an old pyudev model or something. Looking at the pyudev source, this should work with pyudev >= 0.18 which was released in 2015. So not exactly bleeding edge...

> Am I right in thinking that anything I manage to generate from the 'libinput measure touchpad-pressure' tool will be incorporated into libinput, such that others will not have the problems I have had?

Yep, that's the idea behind it. One person suffers so others don't have to ;)

> What's the initial output of libinput debug-events --verbose, before any events

It's as follows, though at present I have the synaptic driver installed and running. (Previously, whenever I have worked on this bug, I have disabled synaptics, which is a pain, because so doing is involved and makes my touchpad work poorly. However, for this test, I've used my normal setup. I think. It's all rather confusing.) (Also, I am unsure what counts as 'before any events'.)

event2  - Power Button: is tagged by udev as: Keyboard
event2  - Power Button: device is a keyboard
event4  - Video Bus: is tagged by udev as: Keyboard
event4  - Video Bus: device is a keyboard
event1  - Lid Switch: not tagged as supported input device
event1  - not using input device '/dev/input/event1'
event0  - Sleep Button: is tagged by udev as: Keyboard
event0  - Sleep Button: device is a keyboard
event5  - A4Tech USB Mouse: is tagged by udev as: Mouse
event5  - A4Tech USB Mouse: device is a pointer
event8  - Integrated Camera: Integrated C: is tagged by udev as: Keyboard
event8  - Integrated Camera: Integrated C: device is a keyboard
event9  - HDA Intel PCH Mic: not tagged as supported input device
event9  - not using input device '/dev/input/event9'
event10 - HDA Intel PCH Headphone: not tagged as supported input device
event10 - not using input device '/dev/input/event10'
event11 - HDA Intel PCH HDMI/DP,pcm=3: not tagged as supported input device
event11 - not using input device '/dev/input/event11'
event12 - HDA Intel PCH HDMI/DP,pcm=7: not tagged as supported input device
event12 - not using input device '/dev/input/event12'
event13 - HDA Intel PCH HDMI/DP,pcm=8: not tagged as supported input device
event13 - not using input device '/dev/input/event13'
event14 - HDA Intel PCH HDMI/DP,pcm=9: not tagged as supported input device
event14 - not using input device '/dev/input/event14'
event15 - HDA Intel PCH HDMI/DP,pcm=10: not tagged as supported input device
event15 - not using input device '/dev/input/event15'
event3  - AT Translated Set 2 keyboard: is tagged by udev as: Keyboard
event3  - AT Translated Set 2 keyboard: device is a keyboard
event6  - tagged as LIBINPUT_MODEL_SYNAPTICS_SERIAL_TOUCHPAD
event6  - SynPS/2 Synaptics TouchPad: is tagged by udev as: Touchpad Touchscreen
event6  - SynPS/2 Synaptics TouchPad: no resolution or size hints, assuming a size of 69x50mm
event6  - using pressure-based touch detection (25:30)
event6  - palm: pressure threshold is 130
event6  - thumb: enabled thumb detection (+pressure)
event6  - SynPS/2 Synaptics TouchPad: device is a touchpad
event7  - ThinkPad Extra Buttons: is tagged by udev as: Keyboard
event7  - ThinkPad Extra Buttons: device is a keyboard
-event2   DEVICE_ADDED     Power Button                      seat0 default group1  cap:k
-event4   DEVICE_ADDED     Video Bus                         seat0 default group2  cap:k
-event0   DEVICE_ADDED     Sleep Button                      seat0 default group3  cap:k
-event5   DEVICE_ADDED     A4Tech USB Mouse                  seat0 default group4  cap:p left scroll-nat scroll-button
-event8   DEVICE_ADDED     Integrated Camera: Integrated C   seat0 default group5  cap:k
-event3   DEVICE_ADDED     AT Translated Set 2 keyboard      seat0 default group6  cap:k
-event6   DEVICE_ADDED     SynPS/2 Synaptics TouchPad        seat0 default group7  cap:pg  size 70x50mm tap(dl off) left scroll-nat scroll-2fg-edge click-buttonareas-clickfinger dwt-on
-event7   DEVICE_ADDED     ThinkPad Extra Buttons            seat0 default group8  cap:k

I am glad my pain will benefit others.

fwiw, all the libinput <foo> tools create their own context, so they don't care what X driver is in use.

I was expecting a line like this in the output:

  event17 - palm: dwt activated with SynPS/2 Synaptics TouchPad<->AT Translated Set 2 keyboard

This line missing means that dwt doesn't actually enable on your box, which explains the issues. Most likely reason is that your keyboard isn't tagged as internal keyboard which is a bit weird. The rule/hwdb entry for this has been in since 1.7.

What's the output of udevadm info /sys/class/input/event3 (your keyboard)? And attach the output of "sudo udevadm test /sys/class/input/event3" as well, thanks.

Created attachment 138935 [details]
Output of: udevadm info /sys/class/input/event3

Created attachment 138936 [details]
Output of:  udevadm info /sys/class/input/event10

Created attachment 138937 [details]
Output of: sudo udevadm test /sys/class/input/event3

Created attachment 138938 [details]
Output of: sudo udevadm test /sys/class/input/event10

I have added attachments. The following may help make sense of them.

$ xinput
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ A4Tech USB Mouse                        	id=9	[slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad              	id=11	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=8	[slave  keyboard (3)]
    ↳ Integrated Camera: Integrated C         	id=13	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=10	[slave  keyboard (3)]
    ↳ ThinkPad Extra Buttons                  	id=12	[slave  keyboard (3)]

Thanks.

thanks. fwiw, event10 is your sound card. The X device IDs are independent of the event nodes.

Still doesn't make a lot of sense to me. You should have 
LIBINPUT_ATTR_KEYBOARD_INTEGRATION=internal
in the udevadm test event3 output but you don't. Which makes me think your .hwdb file is missing this bit:

libinput:keyboard:input:b0011v*
 LIBINPUT_ATTR_KEYBOARD_INTEGRATION=internal

But there's no reason why this would be missing. If it's there, run sudo udevadm hwdb --update, then run the udevadm test /sys/class/input/event3 command again, any changes?

Also, what line is IMPORT builtin 'hwdb' /lib/udev/rules.d/90-libinput-model-quirks.rules:38. My 1.10.3 here says that's this line:

ENV{ID_INPUT_MOUSE}=="1", \
  IMPORT{builtin}="hwdb --subsystem=input --lookup-prefix=libinput:mouse:"

But this line shouldn't do anything because ID_INPUT_MOUSE isn't set on the keyboard. None of this makes sense tbh, sorry.

What's the evemu-record output for the keyboard? (event3)

Sorry, where am I meant to seek the following?

 LIBINPUT_ATTR_KEYBOARD_INTEGRATION=internal

Anyhow, I ran

sudo udevadm hwdb --update

and then udevadm test /sys/class/input/event3

and I attach the output.

As to /lib/udev/rules.d/90-libinput-model-quirks.rules, I am afraid I don't really understand - and so I will simply attach the whole file.

Created attachment 138939 [details]
Output of NEW sudo udevadm test /sys/class/input/event3

Created attachment 138940 [details]
/lib/udev/rules.d/90-libinput-model-quirks.rules

ok, I don't know what version of libinput you have but that rules file is *not* from 1.10.3. Which suggests that your hwdb file is probably outdated as well which would be the source of that bug.

This is either some Mint distribution issue or some local screwup. Do you have anything in /etc/udev/rules.d or /etc/udev/hwdb.d/ that looks like a local copy?

> Do you have anything in /etc/udev/rules.d or /etc/udev/hwdb.d/ that looks like a local copy?

No. For, the content of /etc/udev/rules.d is

60-vboxdrv.rules  98-50-AC-power.rules  99-50-batt-power.rules

and /etc/udev/hwdb.d is entirely empty (though that folder itself exists).

Peter,

I would appreciate any help you could give in making the driver work on my system. I would be happy also to report anything to the Mint maintainers that you think should be brought to their attention, although it might have more impact coming directly from you.

ok, I just got mint 18.03 and checked the libinput version and it's 1.6.3. That version is over a year old, so most of the palm detection behaviour simply missing. Mint needs to update the package.

tbh, you're probably better off just installing libinput from git. It's stable enough that you can even run git master any day without having to worry about breakages.

https://wayland.freedesktop.org/libinput/doc/latest/building_libinput.html

Thanks, but it will not build on my system. For, I get this error:

     Native dependency gtk+-3.0 found: NO found '3.18.9' but need: '>= 3.20'

Still, Mint is about to be put onto the Ubuntu 18 base, which will mean a new libinput (and indeed a new gtk).

you don't need gtk, that's only for the debugging tool. supply
-Ddebug-gui=false to meson and it'll get past this bit. Same with
-Ddocumentation=false if you don't have all the doc stuff.

Thank you very much. I compiled and installed. However, I am unsure it installed correctly. For, while

     libinput --version

yields

     1.10.900

The verification step listed on the page you mention yields this:

     ls: cannot access '/usr/lib64/libinput.*': No such file or directory

And the palm detection has gone back to being non-existent, suggesting that I have moved from synaptics to the *old* version of libinput.

Perhaps I need installed, as well as the compiled stuff from git, not 'xserver-xorg-dev' but 'xserver-xorg-dev-hwe-16.04'?

Sorry to bang on.

The library folder that is at issue, on Mint, seems to be:

/usr/lib/x86_64-linux-gnu/

and have I deleted a linibinput shortcut therein to an older version of libinput. But I am still unsure that libinput palm detection is working properly. So I am minded to return to synaptics until Mint 19 arrives and then see how its version of libinput works.

Note you'll also need to run udevadm hwdb --update afterwards, and check for the various udev properties we talked about. Without that, it won't pick things up.

You can check with sudo ./builddir/libinput-debug-events (i.e. in the git tree) and see if palm detection roughly works there. That's a separate context and won't interfere with the xserver libinput context. Check for the dwt pairing message. If it  all works there, the rest is just a matter of making sure the .so files are in the right place. The X server itself has no effect here, this is all libinput-internal.

Of course, you need to make sure you're not using the synaptics driver (xinput list-props <device name> will tell you which driver is used).

Thanks Peter but I can't get it to work - even with your latest advice - and trying some Debian packages that were more recent than the Mint packages did not work either. So, as I proposed: I'll use synpatics at least until Mint 19. I have spent too much time on this already.