Separate screens with xrandr

[bitnick]

Yep, I can get Zaphod mode with this setup:

Section "ServerLayout"
	Identifier     "X.org Configured"
	Screen      0  "Screen0" 0 0
	Screen      1  "Screen1" Rightof "Screen0"
EndSection

Section "ServerFlags"
	Option "AutoAddDevices" "true"
	Option "AutoEnableDevices" "true"
	Option "AllowEmptyInput" "true"
EndSection

Section "Files"
	ModulePath   "/usr/lib64/xorg/modules"
	FontPath     "/usr/share/fonts/misc/"
	FontPath     "/usr/share/fonts/TTF/"
	FontPath     "/usr/share/fonts/OTF"
	FontPath     "/usr/share/fonts/Type1/"
	FontPath     "/usr/share/fonts/100dpi/"
	FontPath     "/usr/share/fonts/75dpi/"
EndSection

Section "Module"
	Load  "extmod"
	Load  "xtrap"
	Load  "glx"
	Load  "dri"
	Load  "record"
	Load  "dbe"
EndSection

Section "Monitor"
	#DisplaySize	  540   350	# mm
	Identifier   "Monitor0"
	VendorName   "HWP"
	ModelName    "HP LP2475w"
	HorizSync    30.0 - 94.0
	VertRefresh  48.0 - 85.0
	Option	    "DPMS"
EndSection

Section "Monitor"
	Identifier   "Monitor1"
	VendorName   "PHL"
	ModelName    "200WP"
	Option	    "DPMS"
EndSection

Section "Device"
        ### Available Driver options are:-
        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
        ### [arg]: arg optional
        #Option     "NoAccel"            	# [<bool>]
        #Option     "SWcursor"           	# [<bool>]
        #Option     "Dac6Bit"            	# [<bool>]
        #Option     "Dac8Bit"            	# [<bool>]
        #Option     "BusType"            	# [<str>]
        #Option     "CPPIOMode"          	# [<bool>]
        #Option     "CPusecTimeout"      	# <i>
        #Option     "AGPMode"            	# <i>
        #Option     "AGPFastWrite"       	# [<bool>]
        #Option     "AGPSize"            	# <i>
        #Option     "GARTSize"           	# <i>
        #Option     "RingSize"           	# <i>
        #Option     "BufferSize"         	# <i>
        #Option     "EnableDepthMoves"   	# [<bool>]
        #Option     "EnablePageFlip"     	# [<bool>]
        #Option     "NoBackBuffer"       	# [<bool>]
        #Option     "DMAForXv"           	# [<bool>]
        #Option     "FBTexPercent"       	# <i>
        #Option     "DepthBits"          	# <i>
        #Option     "PCIAPERSize"        	# <i>
        #Option     "AccelDFS"           	# [<bool>]
        #Option     "IgnoreEDID"         	# [<bool>]
        #Option     "DisplayPriority"    	# [<str>]
        #Option     "PanelSize"          	# [<str>]
        #Option     "ForceMinDotClock"   	# <freq>
        #Option     "ColorTiling"        	# [<bool>]
        #Option     "VideoKey"           	# <i>
        #Option     "RageTheatreCrystal" 	# <i>
        #Option     "RageTheatreTunerPort" 	# <i>
        #Option     "RageTheatreCompositePort" 	# <i>
        #Option     "RageTheatreSVideoPort" 	# <i>
        #Option     "TunerType"          	# <i>
        #Option     "RageTheatreMicrocPath" 	# <str>
        #Option     "RageTheatreMicrocType" 	# <str>
        #Option     "ScalerWidth"        	# <i>
        #Option     "RenderAccel"        	# [<bool>]
        #Option     "SubPixelOrder"      	# [<str>]
        #Option     "ShowCache"          	# [<bool>]
        Option     "DynamicClocks"	"true"
        #Option     "VGAAccess"          	# [<bool>]
        #Option     "ReverseDDC"         	# [<bool>]
        #Option     "LVDSProbePLL"       	# [<bool>]
        Option     "AccelMethod"	"EXA"
        #Option     "DRI"                	# [<bool>]
        #Option     "ConnectorTable"     	# <str>
        #Option     "DefaultConnectorTable" 	# [<bool>]
        #Option     "DefaultTMDSPLL"     	# [<bool>]
        #Option     "TVDACLoadDetect"    	# [<bool>]
        #Option     "ForceTVOut"         	# [<bool>]
        #Option     "TVStandard"         	# <str>
        #Option     "IgnoreLidStatus"    	# [<bool>]
        #Option     "DefaultTVDACAdj"    	# [<bool>]
        #Option     "Int10"              	# [<bool>]
        #Option     "EXAVSync"           	# [<bool>]
        #Option     "ATOMTVOut"          	# [<bool>]
        #Option     "R4xxATOM"           	# [<bool>]
	Identifier  "Card0"
	Driver      "radeon"
	VendorName  "ATI Technologies Inc"
	BoardName   "Radeon HD 3870"
	BusID       "PCI:1:0:0"
	Screen	0
EndSection

Section "Device"
	Identifier  "Card1"
	Driver      "radeon"
	VendorName  "ATI Technologies Inc"
	BoardName   "Radeon HD 3870"
	BusID       "PCI:1:0:0"
	Screen	1
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Card0"
	Monitor    "Monitor0"
	SubSection "Display"
		Viewport   0 0
		Depth     1
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     4
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     8
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     15
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     16
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     24
	EndSubSection
EndSection

Section "Screen"
	Identifier "Screen1"
	Device     "Card1"
	Monitor    "Monitor1"
	SubSection "Display"
		Viewport   0 0
		Depth     24
	EndSubSection
EndSection

mplayer output is controlled by setting the DISPLAY environment variable. 'DISPLAY=:0.1 mplayer ...' gives output on the second screen.

However, DRI is not supported in this mode - from Xorg.0.log: "(WW) RADEON(0): Direct Rendering Disabled -- Zaphod Dual-head configuration is not working with DRI at present. Please use the xrandr 1.2 if you want Dual-head with DRI."

This means I also got no xv adaptors, which means no HW scaling of video (there's no overlay on R600). And even my Core2 Duo chokes on full-screen video without HW scaling.

So I guess the only option is to make xfce4/wait for xfce4 to become aware of randr type dual-screen? Or is there any hope of getting full support for multiple X Screens with the radeon driver, incl DRI? After all, the "multiple separate screen" approach is what I really want.

Edit: Actually, it seems xrandr-1.2 dual screen mode is equivalent to Zaphod mode if only the WM handles it correctly. So perhaps Zaphod support should not be a priority after all. Is Zaphod mode "officially" deprecated? What says the radeon developers?

[agd5f]

Edit: Actually, it seems xrandr-1.2 dual screen mode is equivalent to Zaphod mode if only the WM handles it correctly. So perhaps Zaphod support should not be a priority after all. Is Zaphod mode "officially" deprecated? What says the radeon developers?

It's not well maintained at the moment. It's tested every now and then, but the xserver side breaks more often than the driver side since it's not used much. zaphod should be possible with kms and will be much easier to implement.

[bitnick]

What would be the benefits of Zaphod mode compared to xrandr multi-screen? I guess what I'm asking is: why support several different ways to do the same thing?

[agd5f]

What would be the benefits of Zaphod mode compared to xrandr multi-screen? I guess what I'm asking is: why support several different ways to do the same thing?

I don't personally have much use for zaphod, but some people like it. The difference is that with zaphod each head is and independent screen (:0.0 and :0.1). It only becomes one big desktop spanning multiple displays if you run xinerama. In that case it's just like xrandr, but inferior.

[rohcQaH]

The difference is that with zaphod each head is and independent screen (:0.0 and :0.1).

..and as such each screen can run a different colour depth and each screen's applications can vsync to the correct output.

mostly useful when your outputs aren't next to each other, i.e. running a monitor and a tv/projector.

[bitnick]

Does anyone run anything other than 24 bit colour depth today?

Different xrandr outputs can already have different vertical refresh rates. How is application vsync to different xrandr outputs implemented today?

[agd5f]

Does anyone run anything other than 24 bit colour depth today?

Different xrandr outputs can already have different vertical refresh rates. How is application vsync to different xrandr outputs implemented today?

For textured Xv we sync to whichever head more of the video is on, for clone modes, we choose the first crtc. The anti-tearing stuff only works when the dri is enabled, so it won't work with zaphod mode.

[adamk]

So I guess the only option is to make xfce4/wait for xfce4 to become aware of randr type dual-screen?

xfce4 already does, and has for quite a while.

Adam

[bitnick]

Ehm... no?

It handles zaphod mode correctly: the display-settings dialog, accessible through Xfce Menu->Settings->Display, shows two screens and lists their resoutions and frequency correctly. The menu bars are the correct size on Screen 0, and no menu is visible on Screen 1. Apps fullscreen to the correct resolution and position on the different screens.

Running xrandr dual-screen however, menu bars stretch over the full virtual desktop (so are partly invisible if the monitors are different resolutions). The display-settings dialog shows only one screen, and its resolution seem to be set to the same as the resolution of smallest of the connected monitors. Apps full-screen to the wrong resolution and position.

Looking at the code (xfce4-settings-4.6.1):

main.c:

/* not available yet */
#undef HAS_RANDR_ONE_POINT_TWO

xfce-randr.c:

        /* TODO: load defaults */
        randr->mode[n] = 0;
        randr->rotation[n] = 0;
        randr->status[n] = XFCE_OUTPUT_STATUS_NONE;

(this is in xfce_randr_new() which is responsible for filling in data structures that keep info on screens, their modes etc, if I understand the code correctly.)

Much randr-aware code seems to be in place, but it is not finished, and it does not work correctly today using the functions and structures in "xfce-randr-legacy".

[adamk]

Ehm... Yes.

You can't configure separate xrandr controlled monitors using the xfce4 settings manager (which is fine with me, I configure it statically in xorg.conf), but xfce4 definitely handles window position, panel position, and window maximization properly when using xrandr (at least if you configure the xfwm4 source with the --enable-xinerama option).

http://68.45.151.98/xfce-xrandr.png

Notice how the panels extend across the top and bottom of only the first monitor (and I can move it to another monitor by right clicking on the panel and selecting "Customize"). Maximizing a window maximizes it to just the monitor it was on.

This, of course, assumes that Xorg conveys the correct monitor information via the XINERAMA extension.

[ adamk@sorrow - ~ ]: xdpyinfo -ext XINERAMA | grep head
  head #0: 1280x1024 @ 0,0
  head #1: 1280x1024 @ 1280,0

EDIT:

Here's another screenshot, with different resolutions, one panel on one monitor, the other panel on the other monitor:

http://68.45.151.98/xfce-xrandr2.jpg

[ adamk@sorrow - ~ ]: xdpyinfo -ext XINERAMA | grep head
  head #0: 1280x1024 @ 0,0
  head #1: 1600x1200 @ 1280,0

xfce4 handles window placement and maximization flawlessly, just as gnome and KDE do.