Hey Salvatore. On Wed, 2023-02-15 at 07:12 +0100, Salvatore Bonaccorso wrote: > Just to be sure, that I understood you correctly. That is if on the > current system with the issue you roll back just only the kernel back > to 6.1.8-1, then the issue dissaper?
Exactly, and the roll back even only in the sense of just booting the previous one (I do not even reinstall packages or so). > If this is the case, would you be testing as well directly 6.1.8 and > 6.1.11 upstream (please do as well 6.1.12, 6.1.12-1 though just > uploaded to unstable earlier today), and if reproducible, bisect the > changes between the two versions to find the introducing bad commit? I've tested 6.1.12 in the meantime, ... still has the problem. In fact it seems as if any changes I make with the synclient tool to the relevant settings e.g.: $ synclient MinSpeed=0.5 MaxSpeed=1.5 AccelFactor=0.5 have no longer any effect at all. Even if I set extreme values, nothing seems to change. I've also taken the src:linux package (as of 6.1.12) recompiled it just with: 6816478c0db15ad0dbe7f9b6ffaff9ad6db5e74d reverted. That seemed the most promising one, despite me NOT having an HP notebook (which that commit is allegedly about, but rather a Fujitsu). But no change with that. If you want me to test 6.1.8/12 upstream... is it enough to simply take the Debian source packages and unapply any Debian patches? I'm always quite reluctant of taking any code which I cannot properly verify myself (and I don't trust github or https enough ;-) ) Thanks, Chris.
