On 2023-11-15 10:15:35 +0700, Max Nikulin wrote: > On 15/11/2023 05:01, Vincent Lefevre wrote: > > > On Tue, Nov 14, 2023 at 10:21:13PM +0100, Vincent Lefevre wrote: > > > > # $ wget -qO- > > > > 'https://qa.debian.org/madison.php?package=emacs&text=on&s=oldstable,stable,testing,unstable,experimental&a=source,all,x86_64' > > The same request without s=... returns versions for all dists and it is > valid way to call get_newqueue_available. I agree that oldstable-backports > is confusing, but perhaps it is better to leave decision to common sense of > users. Too strict filtering might have negative effect in corner cases.
https://qa.debian.org/madison.php?package=linux-image-6.1.0-13-amd64&text=on&a=source,all,x86_64 just gives linux-image-6.1.0-13-amd64 | 6.1.55-1 | bookworm | amd64 And if you mean the request https://qa.debian.org/madison.php?package=linux-image-amd64&text=on&a=source,all,x86_64 then I get linux-image-amd64 | 3.16+63+deb8u2 | jessie | amd64, i386 linux-image-amd64 | 3.16+63+deb8u7 | jessie-security | amd64, i386 linux-image-amd64 | 4.9+80+deb9u11 | stretch | amd64 linux-image-amd64 | 4.9+80+deb9u17 | stretch-security | amd64 linux-image-amd64 | 4.19+105+deb10u4~bpo9+1 | stretch-backports | amd64 linux-image-amd64 | 4.19+105+deb10u16 | buster | amd64 linux-image-amd64 | 4.19+105+deb10u20 | buster-security | amd64 linux-image-amd64 | 5.10.127-2~bpo10+1 | buster-backports | amd64 linux-image-amd64 | 5.10.191-1 | bullseye-security | amd64 linux-image-amd64 | 5.10.197-1 | bullseye | amd64 linux-image-amd64 | 6.1.38-4~bpo11+1 | bullseye-backports | amd64 linux-image-amd64 | 6.1.52-1 | bookworm-security | amd64 linux-image-amd64 | 6.1.55-1 | bookworm | amd64 linux-image-amd64 | 6.5.3-1~bpo12+1 | bookworm-backports | amd64 linux-image-amd64 | 6.5.10-1 | trixie | amd64 linux-image-amd64 | 6.5.10-1 | sid | amd64 But "reportbug linux-image-6.1.0-13-amd64" still says The following newer release(s) are available in the Debian archive: bullseye-backports (backports-policy): 6.1.55+1~bpo11+1 This doesn't match bullseye-backports in the above list. In any case, it would have been *much* better to give the bookworm-backports one. > > Yes, because the plan is to upgrade the machine to unstable. > > But I'm trying to solve the touchpad issue first. Since the bookworm-backports kernel is similar to unstable, perhaps I should fully upgrade the machine to unstable, and see. In any case, if the issue still occurs, it would not be specific to unstable. [Off-topic for this thread...] > I mostly use mouse, but I have realized that what you described may be > similar to what I have seen as well. It might be intended behavior: > > https://wayland.freedesktop.org/libinput/doc/latest/clickpad-softbuttons.html#id5 > > Left: moving a finger into the right button area does not trigger a > > right-button click. > > After moving cursor, position of finger is likely determined by desired > cursor position that may be inside the area of an arbitrary clickbutton. On > the other hand it is too aggressive protection against clicking a wrong > button. When the issue occurs, the kernel does not report any click, whatever the position of the finger. And this can last several minutes. I don't see any reason and any relation with the libinput behavior. Moreover, it is said "libinput ignores such button clicks, this behavior is intentional". So it is libinput that ignores button clicks. In my case, it is the kernel that does not generate click events (as seen with evtest). > Have you tried tools specific to libinput instead of xinput? I don't use xinput. But what needs to be fixed is on the kernel side. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
