Bug 26948

Summary: Xinerama: stuck cursors with nomodeset
Product: xorg Reporter: Peter Hutterer <peter.hutterer>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED INVALID QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: matthieu.herrb, peter.hutterer
Version: 7.4 (2008.09)   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Peter Hutterer 2010-03-07 21:50:35 UTC 
airlied wasn't sure if it's a driver or a server bug, so feel free to reassign.

When booting with nomodeset, the xf86ScreenLayouts get set up with width 1024 and an offset of 2048 (and -2048 for the second one). This leads to a stuck cursor on the right display as xf86CursorOffScreen enters a weird loop.

given x < 0, the first condition would reset the screen to screen 0 but add the edge offset (2048) to the x coordinate. The second condition would then notice that x > screen->width (2048 - x is greater than 1024) resetting the cursor to the second screen. result is a stuck cursor on the right screen.

in the second server generation however xf86ScreenLayouts is configured with the right value and everything is nice and dandy.

reproducible:
boot with nomodeset. xinerama setup, move cursor to second screen - it gets stuck.
reset server by running any client that disconnects again (xdpyinfo is handy), then notice how the cursor can now move between the screens.

server 1.7.5
xf86-video-ati on 1b7e9a2e5 (radeon: fixes for zaphodheads option)
Comment 1 Alex Deucher 2010-10-19 19:20:34 UTC 
Is this still an issue with a newer xserver?
Comment 2 Peter Hutterer 2017-02-03 05:01:44 UTC 
ETIMEOUT

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.