Created attachment 1711377 [details] Kernel Log for not working kernel (5.7.14-200.fc32) 1. Please describe the problem: The touchpad is a touchpad with dedicated separated buttons underneath; it is not a clickpad and does not click like a clickpad. This is on a dell Precision 7550. After kernel upgrade touchpad right click does not work anymore; checking with libinput debug-events shows no event generated on right clicking, but instead an error "kernel bug: received BTN_RIGHT button event on a clickpad" shows up. Left clicking also does not generate an event (but left click works regardless). There is also a middle click button that works and registers events. A left click event is generated when I hold a single finger on the touchpad and press the left click button; a right click event is generated when I hold 2 fingers on the touchpad and press that same left click button. I've attached some examples of clicking buttons with libinput debug-events. I've also attached the output of 'libinput list-devices' for the working and non-working kernels; the touchpad entry is different but the other possible input devices (MOUSE, UNKNOWN) seem the same. This is without any external mice/etc connected. The laptop also does not have a touchscreen. 2. What is the Version-Release number of the kernel: 5.7.14-200.fc32 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Yes; last version it worked on was 5.6.8-300.fc32. Confirmed to be messed up on the next FC32 kernel I could find at koji which was 5.7.10-200.fc32 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Yes; simply try to right click and note that it does not do anything. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Yes 6. Are you running any modules that not shipped with directly Fedora's kernel?: No 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag.
Created attachment 1711378 [details] Kernel Log for last working kernel (5.6.8-300.fc32)
Created attachment 1711379 [details] NOT WORKING libinput list-devices
Created attachment 1711380 [details] WORKING libinput list-devices
Created attachment 1711382 [details] WORKING libinput debug-events
Created attachment 1711384 [details] NOT WORKING libinput debug-events
I happened upon a reddit thread of a review by someone with the same laptop: https://www.reddit.com/r/Dell/comments/hw1o4c/dell_precision_laptop_7550_1_month_in/ A commenter (thanks emjotes!) thinks the reason for the touchpad problems is libinput seeing the property: INPUT_PROP_BUTTONPAD Which the kernel is setting although it should not be set; I've tested using evemu-describe and in the working kernel only this is listed: Property Type 0 (INPUT_PROP_POINTER) Whereas in the nonworking kernel(s) these are both listed: Property Type 0 (INPUT_PROP_POINTER) Property Type 2 (INPUT_PROP_BUTTONPAD) He thinks dell has modified their supported ubuntu kernel to unset this specifically.
Good detective work on finding the Ubuntu thread. I've been looking at changes to drivers/hid/hid-multitouch.c between 5.6 and 5.7 which could explain this, but nothing stands out. So I'm going to ask a colleague who knows morea bout this to take a look. He is probably going to want the HID descriptors for your touchpad to debug this. I see that you already have secureboot disabled, which makes debugging stuff like this easier. Can you run the following command: sudo cat /sys/kernel/debug/hid/0018:0488:120A.0001/rdesc > rdesc And then attach the generated rdesc file here?
This same issue is also being discussed here: https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/481 You are sure it did work correctly with the 5.6 kernel, right and the PROP_BUTTONPAD did not show up there?
Created attachment 1714128 [details] Touchpad rdesc Attached rdesc. I didn't know whether to use one from the working or broken kernel, but diff says they are the same.
Yes; 5.6 does not show the PROP_BUTTONPAD. I checked again just to make sure I didn't misread. The strange thing is I tried out some other distros just to see (ubuntu, Debian, arch, opensuse) and even after installing a 5.6 kernel they are all showing PROP_BUTTONPAD and having the same issue; I even tried going several kernel versions back until my WiFi drivers didn't work anymore but they all still did the same wrong behavior. So far only the patched kernel provided by dell on Ubuntu 18.04 and the ones from Fedora have worked (with libinput, I haven't tested synaptics).
Created attachment 1714265 [details] eBPF program for debugging Thanks for the logs. This is similar to https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/481 My assumption is that the firmware gives us a wrong value when we request the touchpad type. For that, I'd like you to run the attached script that will dump the raw I2C access we make from the i2c-hid driver. You'll need to install `bcc` (`sudo dnf install bcc`) for being able to run it. Then, in a first terminal: `sudo python debug-i2c-hid-get.py` Once it says "Tracing... Hit Ctrl-C to end.", run in a second terminal: `sudo rmmod hid_multitouch; sudo modprobe hid_multitouch` In the trace terminal, hit Ctrl-C and send us the output of the program. Note: it should show something similar to: HID_REQ_SET_REPORT -> 15 (0x0f) len: 2: 0f 01 HID_REQ_GET_REPORT -> 8 (0x08) len: 2: 08 05 HID_REQ_GET_REPORT -> 8 (0x08) len: 2: 08 05
Created attachment 1714284 [details] debug-i2c-hid-get results Attached output from debug-i2c-hid-get. Also, maybe this is expected behavior but I noticed once I removed the hid_multitouch module my touchpad seemed to function as a touchscreen; the mouse cursor disappeared from Gnome but touching the "correct" area on the pad as if it was overlayed on the screen (and scaled up in size) set focus to the correct windows. Swiping up from the bottom of the pad presented an on screen keyboard which did work with pressing areas on the bottom of the touchpad although picking the correct letters was impossible because of the size of the touchpad.
I've been watching those libinput developments; they have added a quirk that targets this specific model and fixes the problem. I assume since it's fixed there upstream is appropriate. Thanks!