On Fri, Mar 18, 2022 at 2:11 PM Takashi Iwai <tiwai@xxxxxxx> wrote: > > On Fri, 18 Mar 2022 14:07:40 +0100, > José Expósito wrote: > > > > Hi Takashi, > > > > Thanks for reporting the regression here. > > > > On Fri, Mar 18, 2022 at 12:42:31PM +0100, Takashi Iwai wrote: > > > Hi, > > > > > > we received a bug report about the regression of the touchpad on Dell > > > 7750 laptop, the right touchpad button is disabled on recent kernels: > > > https://bugzilla.suse.com/show_bug.cgi?id=1197243 > > > > > > Note that it's a physical button, not a virtual clickpad button. > > > > > > The regression seems introduced by the upstream commit > > > 37ef4c19b4c659926ce65a7ac709ceaefb211c40 ("Input: clear > > > BTN_RIGHT/MIDDLE on buttonpads") that was backported to stable 5.16.x > > > kernel. > > > > > > The device is managed by hid-multitouch driver, and the further > > > investigation revealed that it's rather an incorrectly recognized > > > buttonpad property; namely, ID_DG_BUTTONTYPE reports it being 0 = > > > clickable touchpad although it's not. I built a test kernel to ignore > > > this check and it was confirmed to make the right button working again > > > by the reporter. Yep, I came to the same conclusion this morning with the reporter of the libinput bug José was mentioning. > > > > > > Is this check really correct in general? Or do we need some > > > device-specific quirk? The device firmware is clearly wrong here. It's the first time I see this failing like that and I hope this is just an isolated case. The device advertises itself as a buttonpad, when it's not. However, the fact that it passed MS certification (even if I doubt Microsoft ever got that touchpad in their own hands) leads me to believe that the certification doesn't enforce that setting too much, and that we might see more devices coming in with that same bug. To sum up, I am not happy that this commit introduced a regression that we can not work around in userspace: given that BTN_RIGHT gets removed from the device, all of the values are filtered out and userspace can not resolve that situation by itself. I wish I had a better way of fixing this than having to quirk the device. > > > > A couple of days ago another user with the same laptop (Dell Precision > > 7550 or 7750) emailed me to report the issue and I sent him a patch for > > testing. > > > > I he confirms that the patch works, I'll send it to the mailing list. > > > > I believe that your analysis of the regression is correct and I think > > that we'd need to add a quirk for the device. > > > > In case you want to have a look to the patch, I added it to this > > libinput [1] report. > > Great, I'll try to build and ask the reporter to test with the patch. > As noticed on the libinput bug, I think the patch is wrong (not by a lot). We should base the class on MT_CLS_WIN8, not MT_CLS_DEFAULT. The testers might say that it's working, but this might create some corner cases where it's not leading to more and more headaches with your users. Cheers, Benjamin > Thanks! > > > Takashi > > > > Thanks, > > Jose > > > > [1] https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/726#note_1303623 > > >
