hron reported this in #50 while walking the KDE Plasma 6 verification matrix. On his 3840x2160 display at 125% scale, wdotool mousemove 1920 0 lands the cursor at (2400, 0). 1920 * 1.25 = 2400, which is the obvious suspect. Reproduces on mousemove --relative too. Works correctly at 100% scale.
Looks like a double-scale: I send a coordinate through libei, and KWin scales it again by the user's compositor scale factor before placing the cursor. Either I should be sending coords in device pixels and I'm sending logical pixels, or it's the other way around. I haven't traced the exact contract yet.
Affected surface is the libei backend on KDE with any fractional scale factor. The wlroots backend is unaffected because it uses zwlr_virtual_pointer_v1.motion_absolute against per-output mode dimensions directly.
Repro (on KDE Plasma 6, 125% display scale, 3840x2160 panel):
wdotool mousemove 1920 0
wdotool getmouselocation
# Expected: x:1920 y:0
# Actual: x:2400 y:0
Investigating for the next release. Could land in v0.6.0 if the fix is small.
References #1.
hron reported this in #50 while walking the KDE Plasma 6 verification matrix. On his 3840x2160 display at 125% scale,
wdotool mousemove 1920 0lands the cursor at (2400, 0). 1920 * 1.25 = 2400, which is the obvious suspect. Reproduces onmousemove --relativetoo. Works correctly at 100% scale.Looks like a double-scale: I send a coordinate through libei, and KWin scales it again by the user's compositor scale factor before placing the cursor. Either I should be sending coords in device pixels and I'm sending logical pixels, or it's the other way around. I haven't traced the exact contract yet.
Affected surface is the libei backend on KDE with any fractional scale factor. The wlroots backend is unaffected because it uses
zwlr_virtual_pointer_v1.motion_absoluteagainst per-output mode dimensions directly.Repro (on KDE Plasma 6, 125% display scale, 3840x2160 panel):
Investigating for the next release. Could land in v0.6.0 if the fix is small.
References #1.