clickpad troubles after 5.12 update

meerr · 08-05-2021, 05:42 PM

Hi linux users,

I'am usung Fedora 34, wayland. After updating to kernel 5.12 the clickpad of my laptop has some troubles. Secondairy click is gone, Fedora doesnt emulate it anymore. Gnome 40 doesn't let me use 'Tweaks' either to set an virtual button on the left site of the clickpad or use two fingers to emulate an secondairy button.

ibinput list-devices says;
event 7 PCT1336:00 093A:1336touchpad: kernel bug : Clickpad with right button, assuming it is not a clickpad

Every distro with kernel 5,12 and beyond has the same problem.

edit; on 5.11 kernel libinput says; kernel bug, clickpad is advertising right button

I hope there is some who knows how to fix this!

clipping · 08-08-2021, 11:02 AM

I think I am hitting similar on Slackware-current. Libinput v1.18.1 on 5.13.8

On Debian 11 live (an RC, but had it to hand) the touchpad's right click button does work (as does middle emulation). That too uses libinput.

Under Slackware, if I change from libinput to synpatics (I'm using X) the touchpad buttons work as expected. But I cannot rest a finger on a button ready to click it, as the top surface is also touchable: synpatics sees two touchs and then won't move the pointer. Libinput does tolerate my finger/thumb resting.

Anyway, I have found a difference between Slack-current and Debian, and that is the "Click methods" `libinput list-devices` reports for the touchpad. Slack has "none", Deb has "*button-areas clickfinger".

Also, I found some capabilities differences with a udev report. But how this is getting different capabilities on different distros but the same hardware I don't know.

After about 2 weeks of owning this laptop I found, just last night, the same touchpad might be available but showing different manufacturers. My device is synpatics, 093a:0255. But there also seems to be uniwood and HTIX or something with the same product ID. Uniwood might be when on an AMD system? People with those other touchpads have had similar problems from various threads I had mostly dismissed.

Right now I am tempted to downgrade libinput to about 1.16.x, the same as that which seems to work in Debian 11 Live.

That kernel bug message I see under Slack and Deb, where it works in the latter. In the last post here simonw suggests that message is a red herring, and I think I agree. https://forum.endeavouros.com/t/clic...allation/15668

I've found only a couple of people on the whole web otherwise that seem to have noticed the click methods are none when right-click does not work. little-dude using nixos has notice the "Click methods" discrepancy between NixOS and Arch, https://discourse.nixos.org/t/touchp...-working/12276. The above EndeavourOS thread is about the same problem, but ends with a confused user seeing behaviour vanish.

Also, quirks might be tripping you up. Run this, where N is your touchpad, likely 0 or 1.
`libinput quirks list /dev/input/mouseN --verbose`
It will say if there is a match for a quirk, and for me a laptop like mine matches for the right button being disabled. I have made a quirks file for my laptop and tried to use the same method to force the r-click to be enabled, but no luck.

clipping · 08-08-2021, 11:37 AM

Quote:

Originally Posted by clipping

Also, I found some capabilities differences with a udev report. But how this is getting different capabilities on different distros but the same hardware I don't know.

Replying to myself, because otherwise I'll just edit that post too much.

I suspect udev finding/providing different capabilities is the cause of why the right button is not seen by libinput. I think synaptics doesn't care as much about what udev says, too, which is why using that driver under X makes the clickable buttons on my touchpad work as pressable buttons.

So this command gives lots of output, but the touchpad hardware is near the top, with a event at the top.
udevadm info --attribute-walk --path $(udevadm info --query=path --name=/dev/input/mouseN)

Under Debian 11 RC2 (5.10.0 with libinput 1.16.4 - where my r-click works), this is a the details for just the touchpad. There's quite a few capabilities.

Code:

looking at parent device '/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-SYNA3602:00/0018:093A:0255.0001/input/input12':
    KERNELS=="input12"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{capabilities/abs}=="2e0800000000003"
    ATTRS{capabilities/ev}=="1b"
    ATTRS{capabilities/ff}=="0"
    ATTRS{capabilities/key}=="e520 30000 0 0 0 0"
    ATTRS{capabilities/led}=="0"
    ATTRS{capabilities/msc}=="20"
    ATTRS{capabilities/rel}=="0"
    ATTRS{capabilities/snd}=="0"
    ATTRS{capabilities/sw}=="0"
    ATTRS{id/bustype}=="0018"
    ATTRS{id/product}=="0255"
    ATTRS{id/vendor}=="093a"
    ATTRS{id/version}=="0100"
    ATTRS{name}=="SYNA3602:00 093A:0255 Touchpad"
    ATTRS{phys}=="i2c-SYNA3602:00"
    ATTRS{power/async}=="disabled"
    ATTRS{power/control}=="auto"
    ATTRS{power/runtime_active_kids}=="0"
    ATTRS{power/runtime_active_time}=="0"
    ATTRS{power/runtime_enabled}=="disabled"
    ATTRS{power/runtime_status}=="unsupported"
    ATTRS{power/runtime_suspended_time}=="0"
    ATTRS{power/runtime_usage}=="0"
    ATTRS{properties}=="5"
    ATTRS{uniq}==""

Under Slackware the same device is seen like this:

Code:

  looking at parent device '/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-7/i2c-SYNA3602:00/0018:093A:0255.0001/input/input18':
    KERNELS=="input18"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{uniq}==""
    ATTRS{inhibited}=="0"
    ATTRS{properties}=="5"
    ATTRS{phys}=="i2c-SYNA3602:00"
    ATTRS{name}=="SYNA3602:00 093A:0255 Touchpad"

I need to patch my brain to know what to do about these differences, the lack of capabilities. What a suitable shortcoming

The same data I think is also reflected in places like /sys/bus/i2c/devices.... and /proc/bus/input/devices. Still doesn't help me know what is up.

clipping · 08-08-2021, 05:16 PM

OK, good result here uninstalling libinput 1.18 and going back to 1.16.5. I picked that version because 1.16.4 works on Debian, 1.16.5 existed as the next minor before 1.17.

Not sure how you'd try that on Fedora, yum --something-or-other is my limit

meerr · 08-17-2021, 08:11 PM

Quote:

Originally Posted by clipping

OK, good result here uninstalling libinput 1.18 and going back to 1.16.5. I picked that version because 1.16.4 works on Debian, 1.16.5 existed as the next minor before 1.17.

Not sure how you'd try that on Fedora, yum --something-or-other is my limit

Hey, thanks! I downgraded from 1.18 to 1.17. On 1.17 libinput says that the click method is button area clickfinger, on 18 is says non. 17 does emulate richt-click just fine. On libinput 1.18 the kernel bug warning is saying that libinput is assuming the clickpad is not a clickpad. There it goes wrong. becuase it needs tot assume it IS a clickpad.

whats is the kernel bug on your end? same?

The thing i dont get is where does libinput gets its info from, how is the clickpad advertising a right click-button?

greets,