Bug 100345

> $ xinput
> ⎡ Virtual core pointer                          id=2    [master pointer  (3)]
> ⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
> ⎜   ↳ ALP000D:00 044E:120C                      id=10   [slave  pointer  (2)]

^^^ this is most likely your problem. The touchpad looks a i2c device and the
"AlpsPS/2 ..." device is just a mute kernel device now. synclient most
likely configures the wrong one, so the settings are applied to a device
that never sends events. You should be able to verify that with sudo
evemu-record, check where the events are coming from. And compare that with
the list-props output for the two devices.

PS: you can use the device name instead of the number:
    xinput list-props "ALP000D:00 044E:120C"

Thanks Peter! 

You are right. If I use the touchpad and run evemu-record, then it shows events only for the 'ALP000D:00 044E:120C' thing. 

However, shouldn't the settings in xorg.conf affect both devices? I am using:

Section "Inputclass"
    Identifier "Touchpad"
    Driver "synaptics" 
    MatchIsTouchpad "on" 
    Option "VertEdgeScroll" "on"
    Option "VertTwoFingerScroll" "off"
    Option "PalmDetect" "on"
    Option "TapButton2" "2"
    Option "SoftButtonAreas" "50% 0 0 81% 0 0 82% 0"
EndSection


Is there a way to tell synclient which device to configure? Or to make the events come from the right device? I am not sure if I'm looking at a bug here or if things work as intended and I'm just unable to configure the right device..

those settings should affect everything, but depending on the DE you use it may overwrite the settings at runtime. Attach your full xorg.log, that should contain the info whether it's applied at start.

synclient doesn't take a device argument iirc, it just picks the first touchpad device it finds which is usually the legacy PS2 one. This is a kernel-level driver decisiion, so unless you want to force the kernel to load the ps2 driver, you cannot change which device generates events (and we don't recommend it anyway).

I've attached the full Xorg.log. I am using i3 and xsettingsd, so I don't think anything else is messing with the settings.

Created attachment 130417 [details]
Xorg log

looks like the device is assigned the evdev driver - I wonder why. Attach an evemu-describe of the ALP000.. device please.

Created attachment 130444 [details]
evemu-describe

Attached output of 'sudo evemu-describe /dev/input/event17 > evemu-describe.txt'.

ok, this is a i2c touchpad (ALP000D:00 044E:120C) that should be supported by v4.8 and later, 120C was introduced by kernel commit 2562756dde5. But the touchpad is still in relative mouse emulation mode. So either hid-i2c is missing from your kernel or something else is going wrong here. Please attach your dmesg, thanks.

(In reply to Peter Hutterer from comment #8)
> ok, this is a i2c touchpad (ALP000D:00 044E:120C) that should be supported
> by v4.8 and later, 120C was introduced by kernel commit 2562756dde5. But the
> touchpad is still in relative mouse emulation mode. So either hid-i2c is
> missing from your kernel or something else is going wrong here. Please
> attach your dmesg, thanks.

Well, it looks like commit 819d64e51d6260 in the kernel reverted the hid-core change, meaning that the device gets picked by hid-generic, not hid-alps.

Nikolaus, could you check if manually unbinding the device from hid-generic and rebinding it to hid-alps makes the touchpad working?

For that please look for a symlink named 0018:044E:120C.0001 (the last number might differ). Then run as root:
#> modprobe hid-alps
#> echo 0018:044E:120C.0001 > /sys/bus/hid/drivers/hid-generic/unbind
#> echo 0018:044E:120C.0001 > /sys/bus/hid/drivers/hid-alps/bind

Keep an eye on the dmesg, it should show that the device is now handled by hid-alps. If the enumeration works properly and the touchpad is functional again, I can send these settings by default upstream. Note that at the next reboot, you will have to redo this manual switch between the 2 drivers.

Created attachment 130486 [details]
dmesg output

dmesg output is attached.

# modprobe hid-alps

[0] root@thinkpad:~
# cd /sys/bus/hid/drivers/hid-generic/

[0] root@thinkpad:.../hid/drivers/hid-generic
# dir
total 0
drwxr-xr-x 2 root root    0 Mar 27 02:58 .
drwxr-xr-x 4 root root    0 Mar 27 02:58 ..
lrwxrwxrwx 1 root root    0 Mar 27 10:33 0003:0D3D:0001.0002 -> ../../../../devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.1/1-4.1.2/1-4.1.2:1.0/0003:0D3D:0001.0002
lrwxrwxrwx 1 root root    0 Mar 27 10:33 0003:0D3D:0001.0003 -> ../../../../devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.1/1-4.1.2/1-4.1.2:1.1/0003:0D3D:0001.0003
lrwxrwxrwx 1 root root    0 Mar 27 10:33 0003:1A7C:0191.0004 -> ../../../../devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.1/1-4.1.1/1-4.1.1:1.0/0003:1A7C:0191.0004
lrwxrwxrwx 1 root root    0 Mar 27 10:33 0018:044E:120C.0001 -> ../../../../devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-8/i2c-ALP000D:00/0018:044E:120C.0001
--w------- 1 root root 4.0K Mar 27 10:33 bind
lrwxrwxrwx 1 root root    0 Mar 27 10:33 module -> ../../../../module/hid_generic
--w------- 1 root root 4.0K Mar 27 10:33 new_id
--w------- 1 root root 4.0K Mar 27 02:58 uevent
--w------- 1 root root 4.0K Mar 27 10:33 unbind

[0] root@thinkpad:.../hid/drivers/hid-generic
# echo 0018:044E:120C.0001 > /sys/bus/hid/drivers/hid-generic/unbind

[0] root@thinkpad:.../hid/drivers/hid-generic
# echo 0018:044E:120C.0001 > /sys/bus/hid/drivers/hid-alps/bind
-bash: echo: write error: No such device

(In reply to Nikolaus Rath from comment #11)
> [0] root@thinkpad:.../hid/drivers/hid-generic
> # echo 0018:044E:120C.0001 > /sys/bus/hid/drivers/hid-alps/bind
> -bash: echo: write error: No such device

Sorry, I missed that 819d64e51d6260 removed the catch-all in hid-alps.

Before calling bind on the device, you would need to add it to the supported devices:
#> echo 18 044e 120c 0 > /sys/bus/hid/drivers/hid-alps/new_id
#> echo 0018:044E:120C.0001 > /sys/bus/hid/drivers/hid-alps/bind

Still the same problem:


[0] root@thinkpad:~
# echo 0018:044E:120C.0004 > /sys/bus/hid/drivers/hid-generic/unbind

[0] root@thinkpad:~
# echo 18 044e 120c 0 > /sys/bus/hid/drivers/hid-alps/new_id

[0] root@thinkpad:~
# echo 0018:044E:120C.0004 > /sys/bus/hid/drivers/hid-alps/bind
-bash: echo: write error: No such device

(id is different now, presumably because of reboot)

FYI, Alps just sent a patch supporting this device: https://lkml.org/lkml/2017/3/29/994

hooray! closing this bug then, let's get that kernel patch sorted and then we can revisit if it's still an issue then.

Uh. I just tried that patch (on top of 4.10), and it just disables the touchpad completely. xinput says

$ xinput
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ AlpsPS/2 ALPS GlidePoint                	id=14	[slave  pointer  (2)]
⎜   ↳ Chicony Wireless Device                 	id=9	[slave  pointer  (2)]
⎜   ↳ Chicony Wireless Device                 	id=11	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=8	[slave  keyboard (3)]
    ↳ HP HD Camera                            	id=12	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=13	[slave  keyboard (3)]
    ↳ HP Wireless hotkeys                     	id=15	[slave  keyboard (3)]
    ↳ HP WMI hotkeys                          	id=16	[slave  keyboard (3)]
    ↳ Chicony Wireless Device                 	id=10	[slave  keyboard (3)]


I guess I should take this to the kernel list?

always check with evemu-record, not xinput just in case a driver filters a device out. if evemu-record doesn't show the device either, then it's definitely a kernel bug, not something we'll likely fix here.

(In reply to Nikolaus Rath from comment #16)
> Uh. I just tried that patch (on top of 4.10), and it just disables the
> touchpad completely. xinput says
> 
> I guess I should take this to the kernel list?

Yes please. Put in CC Masaki Ota, the email is in the patch. He'll likely ask for dmesg and such, but you'll figure it out.

And yes, as Peter said, this bug is for libinput/xorg-synaptics. We are allowed to discuss kernel things here, but the resolution/status of the bug concerns only libinput.