What happens
Scroll deltas reaching DesktopManagerCtx.Scroll are in the xf86-input-neko driver's scroll units, 120 per wheel notch (server/pkg/xinput/types.go:63, added in #12). When the write to the driver socket fails, Scroll falls back to XTest (server/internal/desktop/xorg.go:29-32), and XScroll clicks a wheel button once per unit (server/pkg/xorg/xorg.c).
So on that fallback a single wheel notch replays as 120 XTest clicks, and a coalesced gesture as thousands. I ran into this driving a Kernel browser from a native client that sends 120-unit deltas: when the driver socket hiccups, one notch jumps the page by a screenful.
Fix, if you want it
possibilities:fix/xtest-scroll-fallback-units — 4 files, +182/-1, no C changes.
Converts the delta to whole notches with a carried sub-notch remainder, on the driver-enabled fallback path only, through a new xorg.ScrollUnits. xorg.Scroll is untouched and keeps upstream's semantics where the delta is a click count, so deployments running with desktop.input.enabled=false behave exactly as before. Page scrolling and Control-held zooming accumulate separately so a remainder from one cannot discharge as a notch of the other. The arithmetic is unit tested; the fallback itself needs a running X server and is not covered.
Separate question
utils/xorg-deps/xf86-input-neko/src/neko.c in this repo has no scroll support at all — NEKO_SCROLL (0x80) falls through to xf86PostTouchEvent — while the copy kernel-images builds registers XI2 scroll valuators for it. Since Dockerfile.tmpl builds this repo's copy into the base image, a standalone base-image deployment with the driver enabled gets a driver that cannot scroll.
possibilities:driver-sync-wip takes src/neko.c verbatim from kernel-images at 18e75774 (kernel/kernel-images#196) and documents the message in the README. Nothing in CI compiles utils/**, so I would build the base image locally before offering it.
Would you like either of these as a PR, or would you rather own these yourselves? Happy to go either way.
What happens
Scroll deltas reaching
DesktopManagerCtx.Scrollare in thexf86-input-nekodriver's scroll units, 120 per wheel notch (server/pkg/xinput/types.go:63, added in #12). When the write to the driver socket fails,Scrollfalls back to XTest (server/internal/desktop/xorg.go:29-32), andXScrollclicks a wheel button once per unit (server/pkg/xorg/xorg.c).So on that fallback a single wheel notch replays as 120 XTest clicks, and a coalesced gesture as thousands. I ran into this driving a Kernel browser from a native client that sends 120-unit deltas: when the driver socket hiccups, one notch jumps the page by a screenful.
Fix, if you want it
possibilities:fix/xtest-scroll-fallback-units— 4 files, +182/-1, no C changes.Converts the delta to whole notches with a carried sub-notch remainder, on the driver-enabled fallback path only, through a new
xorg.ScrollUnits.xorg.Scrollis untouched and keeps upstream's semantics where the delta is a click count, so deployments running withdesktop.input.enabled=falsebehave exactly as before. Page scrolling and Control-held zooming accumulate separately so a remainder from one cannot discharge as a notch of the other. The arithmetic is unit tested; the fallback itself needs a running X server and is not covered.Separate question
utils/xorg-deps/xf86-input-neko/src/neko.cin this repo has no scroll support at all —NEKO_SCROLL(0x80) falls through toxf86PostTouchEvent— while the copy kernel-images builds registers XI2 scroll valuators for it. SinceDockerfile.tmplbuilds this repo's copy into the base image, a standalone base-image deployment with the driver enabled gets a driver that cannot scroll.possibilities:driver-sync-wiptakessrc/neko.cverbatim from kernel-images at 18e75774 (kernel/kernel-images#196) and documents the message in the README. Nothing in CI compilesutils/**, so I would build the base image locally before offering it.Would you like either of these as a PR, or would you rather own these yourselves? Happy to go either way.