Look at xrandr -q below, VGA_CRT1/DAC_A - is secondary monitor (external for my notebook). But all applications (gdm, metacity, etc) assume that it external monitor is primary. The way to mark PANEL_LCD1/LVDS/TMDS as default output is required. $ xrandr -q Screen 0: minimum 320 x 200, current 2680 x 1050, maximum 3280 x 1050 VGA_CRT1/DAC_A connected 1280x1024+1400+0 376mm x 301mm 1280x1024 60.0*+ 75.0 59.9 1280x960 59.9 1152x864 75.0 74.8 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 75.0 72.8 66.7 60.0 720x400 70.1 PANEL_LCD1/LVDS/TMDS unknown connection 1400x1050+0+0 305mm x 228mm 1400x1050 60.0*+ 50.0 1280x1024 59.9 1024x768 60.0 800x600 60.3 640x480 60.0 59.9 DVI-I_DFP1/TMDS_A disconnected $
This is a general issue with RandR - it has no notion of "primary" and "secondary" viewports, just one big framebuffer. AFAIK there is no way to tell the Xinerama emulation which of those viewports should be first, and which one secondary.
In radeonhd we now have an RROutputOrder option - but IMHO this should be handled differently in the base Xinerama implementation.
This looks like a duplicate of bug 12594. I've nearly stopped using dual-head because of this issue. I'd like to try to fix it. Where does the Xinerama emulation code live in the source tree? Am I right in guessing that what matters here is the order the video driver calls xf86OutputCreate?
(In reply to comment #3) > I've nearly stopped using dual-head because of this issue. I'd like to try to > fix it. Where does the Xinerama emulation code live in the source tree? Am I > right in guessing that what matters here is the order the video driver calls > xf86OutputCreate? Well... yes, the order they are represented in the Xserver depends on the order of the xf86OutputCreate() calls. However, you actually don't gain anything by reordering, except for the time being. How applications actually handle this might change from version to version. If they assume an implicit order this will help you. I think the best option to fix this is somewhere in the vicinity of xf86OutputCreate(). You should probably implement an option that specifies the wished output order, and change xf86OutputCreate() to reflect this order incrementally. That said, I think the really correct solution would need some availability of meta information (screen position & type, user preference) and change in the applications.
So, the most correct solution would be to have a RandR output property indicating which output is primary? Is something like this planned for the upcoming RandR 1.3 spec? Where could I find the draft? For backwards-compatibility purposes it would be nice if XineramaQueryScreens listed the primary output first -- as far as I can tell, this is the heuristic used by gdm, gnome-panel and other applications to decide which monitor is primary. FWIW I now see that the order of outputs doesn't matter that much -- ProcRRXineramaQueryScreens (randr/rrxinerama.c in the xserver tree) loops through crtcs, not outputs. I haven't figured out the exact relationship between outputs and crtcs yet.
(In reply to comment #5) > So, the most correct solution would be to have a RandR output property > indicating which output is primary? Is something like this planned for the > upcoming RandR 1.3 spec? Where could I find the draft? I don't think it is that trivial. You have to really think that through, and I promise you will find more problematic setups than just a cloned dualhead system. > For backwards-compatibility purposes it would be nice if XineramaQueryScreens > listed the primary output first -- as far as I can tell, this is the heuristic > used by gdm, gnome-panel and other applications to decide which monitor is > primary. Fair enough. For that, reordering the internal database would be enough, this should be easy to implement. > FWIW I now see that the order of outputs doesn't matter that much -- > ProcRRXineramaQueryScreens (randr/rrxinerama.c in the xserver tree) loops > through crtcs, not outputs. I haven't figured out the exact relationship > between outputs and crtcs yet. Then you might have to change this loop. I assume this works in radeonhd only because all outputs can be used on all crtcs.
15115 may be another duplicate of this one.
This should be configurable with the new xrandr primary stuff. Closing as fixed.
*** Bug 12594 has been marked as a duplicate of this bug. ***
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.