After upgrading from xserver 1.12.99.905 (the very last 1.13 RC) to xserver 1.13.0, screen crossings have ceased to work correctly, in a 2-screen Zaphod setup. The pointer starts on the left screen (0); when attempting to move it rightwards across the boundary to the right screen (1), instead of actually changing screens, the pointer teleports all the way to the left of the screen it's already on. Bisection pinpoints the following: bafbd99080be49a17be97d2cc758fbe623369945 is the first bad commit commit bafbd99080be49a17be97d2cc758fbe623369945 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Wed Aug 8 11:34:32 2012 +1000 dix: work around scaling issues during WarpPointer (#53037) In WarpPointer calls, we get input in screen coordinates. They must be scaled to device coordinates, and then back to screen coordinates for screen crossing and root coordinates in events. The rounding errors introduced (and clipping in core/XI 1.x events) can lead to the actual position being different to the requested input coordinates. e.g. 200 scales to 199.9999, truncated to 199 in the event. Avoid this by simply overwriting the scaled screen coordinates with the input coordinates for the POINTER_SCREEN case. X.Org Bug 53037 <http://bugs.freedesktop.org/show_bug.cgi?id=53037> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com> :040000 040000 f187f7ca2569a510c2f614cc75f9d5e3f4b09b85 394c22bc56781077b7384804648db21c6354eca8 M dix Reverting this commit on top of 1.13.0 resolves the issue.
Hi, Arch (stable) upgraded xorg-server to 1.13. I use a similar Zaphod configuration as described above and I'm facing the same annoying bug now. Any news on this issue? With best regards, Till
In the meantime, you can still revert the commit without any other problems but that's probably a little easier to do on Gentoo (my distro) than it is on Arch. ;)
I guess my comment was a bit misleading... :) While it would be possible to revert the commit (thanks to Nick), I just wanted to ask if the issue will be addressed in 1.13.1. The status is still set to NEW. Shouldn't the "Component" be changed to "Input/*"? Not sure if Peter Hutterer knows about this regression. Unfortunately, I'm not familiar with the inner workings of X to provide a patch. ~Till
(In reply to comment #3) > While it would be possible to revert the commit (thanks to Nick), I just > wanted to ask if the issue will be addressed in 1.13.1. The status is still > set to NEW. Yes, it would be nice to have some feedback about this 11th-hour regression. What's the point in testing the release candidates if regressions are going to be introduced (and apparently reports ignored) right before release anyway? > Shouldn't the "Component" be changed to "Input/*"? That's what I thought at first, but all the Input/ components seem to be for specific drivers. This issue isn't driver-specific, it's a problem with the server. That being said, this bugtracker has waaaaaaaaay too many components.
*** Bug 55993 has been marked as a duplicate of this bug. ***
Wouldn't it make sense to assign this bug report to Peter Hutterer?
Created attachment 68748 [details] [review] 0001-dix-fix-zaphod-screen-scrossing-54654.patch adding the offset of the new screen should be enough, can you please test this? thanks
(In reply to comment #7) > Created attachment 68748 [details] [review] [review] > 0001-dix-fix-zaphod-screen-scrossing-54654.patch > > adding the offset of the new screen should be enough, can you please test > this? thanks Seems to work, thanks!
Thanks. I can also confirm this patch to work on two different zaphod setups.
FWIW, it fixes the problem for me too. Is this going to be merged at some point? I don't see it in git yet.
Looking good here, thanks Peter.
commit e7cd5cce740e653000fb1192b600268dcf77dde2 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Thu Oct 18 15:11:31 2012 +1000 dix: fix zaphod screen scrossing (#54654)
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.