Currently, the pointer axes scale across the virtual screen allocated by randr instead of the current physical screen. This behaviour is quite disorienting while using a touchpad with multiple screens. The pointer does *NOT* go where you expect it to go, and you have to constantly compensate for the changed diagonal. The behaviour of other OSes (I tested Windows 7 and OSX) is to move the pointer according to the current physical screen, and when the pointer moves to the edge of the screen and is moved to the other screen, the axis changes again. I don't think the current behaviour is desirable I asked about this on #xorg as well, and we didn't find any bugs about this; the only things we found were about absolute input devices (touchscreens and the like)[1], about axis inversion/rotation[2], and other problems with scaling[3]. 1. https://bugs.freedesktop.org/show_bug.cgi?id=38923 2. https://bugs.freedesktop.org/show_bug.cgi?id=21129 3. https://bugs.freedesktop.org/show_bug.cgi?id=25182
Are we really talking about touchpads here? Seems a bit odd that they are supposed to be screen-bound. I know they don't behave greatly right now, but having them screen-bound seems wrong too
(In reply to comment #1) > Are we really talking about touchpads here? Seems a bit odd that they are > supposed to be screen-bound. I know they don't behave greatly right now, but > having them screen-bound seems wrong too Well, I can see the same axis-changing behaviour with mice as well (both managed by evdev), so it's not limited to just touchpads. A related problem is that the change in screen size changes the pointer speed and acceleration as well, which (I think) is a result of this same behaviour.
Created attachment 64311 [details] scale to CRTC rather than screen bounds Agh. As far as I can tell, the problem, at least when using Synaptics, is this: - touchpad posts relative event through GetPointerEvents etc - accelPointer correctly accelerates based on delta only - moveRelative calls add_to_scroll_valuator (most misleadingly-named function on earth) which computes the final value, leaving it in device co-ord space, i.e. [min_touchpad..max_touchpad] - scale_to_desktop does a simple scaling from axis -> screen So, the behaviour of your touchpad when your screen is 1920x1280, is radically different from when your screen is 3840x1280. I think the solution is -- if we're RandR-capable -- to maintain a current CRTC rather than a current screen, scale from device co-ordinates to CRTC co-ordinates, and then convert those into screen co-ordinates with simple addition? This would make it such that the exact same amount of physical touchpad motion would at least translate into the exact same percentage of CRTC coverage. It looks like this would be kinda invasive though. I think you'd essentially have to combine moveRelative and scale_to_desktop, and have it do something like the attached pseudo-ish-code. I don't know if that's strictly ideal -- for example, the same motion that would move 960 pixels on the 1920x1280 screen would only move 720 pixels on a 1440x900 screen, if you have a laptop and a large external LCD -- but it at least stops the enormous distortion, which is really disconcerting. The other option would be to pick one CRTC (the primary?) to calculate the scaling factor for, and always use that scaling factor for the conversion to screen co-ordinates, regardless of which CRTC we're on. That would give us consistent number-of-pixel coverage rather than consistent percentage-of-CRTC coverage. ... thoughts?
This seems to not be a problem anymore with xorg-server-1.16.3, but I'm not sure when this was fixed or how. :)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/584.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.