[CCing the regression list, as it should be in the loop for regressions: https://docs.kernel.org/admin-guide/reporting-regressions.html] Hi, Thorsten here, the Linux kernel's regression tracker. On 16.02.24 12:51, Raphaël Halimi wrote: > > (sorry for the long CC list, it looks quite long to me, but I tried to > follow the issue reporting guide as closely as possible) > > Since patches [1], [2] and [3] were applied to the kernel, there is a > regression with Lenovo ThinkPad Compact USB Keyboard (old model, not II). > > [1] > https://github.com/torvalds/linux/commit/46a0a2c96f0f47628190f122c2e3d879e590bcbe > [2] > https://github.com/torvalds/linux/commit/2f2bd7cbd1d1548137b351040dc4e037d18cdfdc > [3] > https://github.com/torvalds/linux/commit/43527a0094c10dfbf0d5a2e7979395a38de3ff65 > > The regression is that a middle click is performed when releasing middle > button after wheel emulation. How did you identify these three commits? Or do you just suspect that it's one of them? And did you try to check which of the three is the actual culprit? Either by reverting them on top of master or by checking the parent for each of the commits (git show '2f2bd7cbd1d^' shows the parent for 2f2bd7cbd1d). > The bug appears randomly, it can be after 5 minutes or 1 hour of > keyboard usage, and can only be worked around by unplugging/re-plugging > the keyboard. (I ended up resorting to simulate an unplug/replug, with a > script which echoes 0 then 1 to /sys/bus/usb/devices/<id>/authorized, > since I was afraid to damage the Micro-USB outlet by physically > unplugging/re-plugging too much). > > Those spurious clicks are very annoying, since they can open links in > new tabs when scrolling in Firefox, or pasting text when scrolling in > terminals, or other unwanted stuff. > > I witnessed it with latest kernels (Debian unstable) as well as stable > kernels (Debian 12 Bookworm, stable). > > On Debian Stable, the last working kernel was 5.10.127, the regression > appeared in 5.10.136 (i read all changelogs on kernel.org between those > two releases but couldn't find anything about hid-lenovo, so I can't > tell exactly in which release the regression appeared, Debian upgraded > directly from .127 to .136). Why not bisect between .127 and .136 then? > I reported it in Debian [4], and apparently I'm not the only person > suffering from it [5]. > > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058758#32 > [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058758#42 > > I would understand that such bugs would end up in a development kernel > like the ones provided by Debian Unstable, but not with stable kernels > like the ones provided by Debian Stable. A bug report like yours can do the trick sometimes, as it might be enough to ring a bell for one of the developers. But given that nobody replied yet it looks like that is not the case. Then you most likely will need to perform a bisection to identify the exact commit that broke things. FWIW, I'm currently working on a new document describing the bisection, maybe it's of help for you: https://www.leemhuis.info/files/misc/How%20to%20bisect%20a%20Linux%20kernel%20regression%20%e2%80%94%20The%20Linux%20Kernel%20documentation.html Ciao, Thorsten P.S.: To be sure the issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression tracking bot: #regzbot ^introduced v5.10.127..v5.10.136 #regzbot title HID: lenovo: Lenovo ThinkPad Compact USB Keyboard sometimes sends middle-click #regzbot ignore-activity Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr That page also explains what to do if mails like this annoy you.
