On Opensuse 12.2, M4, the proprietary ATI fglrx driver for my Radeon 6540 is incompatible with the last xorg-server, v. 1.12 (see bug nr. 761939). So I start with nomodeset, and hence with the radeon driver, which gives me a graphical login screen, but only on one monitor, not on the two I have. The KDE “System settings” report I don’t have a dual monitor setup, which is not true.
Is there a way to set up dual monitor use with this driver? Preferably without creating an xorg.conf by hand, as explained in X.Org/Dual Monitors - Gentoo Linux Wiki (at the moment, there is no xorg.conf in /etc/Xorg/).
You’re running Milestone 4, that’s considered unstable. Things like this are likely to happen. If you didn’t know this, please download and install 12.1, which is the latest stable release. If this was on intention, please let know as well, I will be moving your post to Prerelease/Beta.
Thanks for such a quick reply.
It was on intention, I have a stable 12.1 running on a raid-5 assembly on the same machine. This 12.2M4 etc. is for testing purposes only.
I didn’t notice the Prerelease/Beta section, my apologies…
To restate the problem: I am unable to define dual monitors for my Radeon HD6450 on x86_64, in the (experimental) OpenSuse v. 12.2M4.
There are two lines of possible solutions:
find out how the open source radeon driver supports or can support the use of dual monitors. This is the line I prefer, because - well, it’s open source. And that is where this tread gets it’s name from. I doubt if the answer in this line has got anything to to with this OS-version being experimental, but on the other hand, I’m not sure it is not.
Since the first line is being worked upon, and probably will lead to a solution, the second question remains to be answered for as far as I know.
Indeed I’m not keen on editing xorg.conf manually. Afaik it’s use is depreciated nowadays (actually I don’t have one at the moment), and besides I think enabling a multi-monitor setup should be more user friendly than that.
xrandr doesn’t seem to see my second monitor:
xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1600 x 1200, current 1600 x 1200, maximum 1600 x 1200
default connected 1600x1200+0+0 0mm x 0mm
1600x1200 77.0*
though I’m not sure I understand the use of xrandr enough. I tried
I wouldn’t say its depreciated, rather that its a case that Xorg has moved, away from requiring a xorg.conf file, to an automatic configuration of hardware. However, to address cases where “automagic” configuration fails, users can:
tailor configurations via the particular .conf files contained in the /etc/X11/xorg.conf.d/ directory, or
similar as to the case in the past, fall back to the classic/legacy method of using an xorg.conf file to set up their hardware with their X environment
(actually I don’t have one at the moment), and besides I think enabling a multi-monitor setup should be more user friendly than that.
Absolutely! Unfortunately, for whatever reason, the automagic configuration of your hardware has not worked.
xrandr doesn’t seem to see my second monitor:
xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1600 x 1200, current 1600 x 1200, maximum 1600 x 1200
default connected 1600x1200+0+0 0mm x 0mm
1600x1200 77.0*
I don’t think its so much a case of not seeing the 2nd monitor; rather, I suspect its a case of improper detection and configuration of your video adapter (i.e. your Radeon 6540 device). I see several things of notoriety in your console output for the xrandr command:
its detecting only one output on the device, which it resorts to calling it “default” … if things were properly detected you would have seen outputs like VGA-0, DVI-0 or such, as well as details for each respective output detected on the adapter
the “failed to get size of gamma” for the one and only output it detects
and the rather strange refresh rate of 77.0 that is being used for the display … maybe this is correct, I don’t know, but it strikes me as incorrect – digital connections are usually 60.0 and analog, like VGA, typically default to 75 … because autoconfig has resulted in providing the output a default name of “default”, only you currently can tell us whether this is a VGA or DVI or HDMI output
though I’m not sure I understand the use of xrandr enough. I tried
xrandr --screen 1 --output 1 --left-of 0
but it answers
Invalid screen number 1 (display has 1)
You would want to use --screen 0 … the two displays are constituted within the one x session (screen 0) … just as an FYI, using a screen 1 would be applicable for other setups (such as running dual video adapters, necessitating two x sessions; multi-seat …)
In any regard, you will have to get the second output on the 6540 working. I’m not an xrandr expert, so perhaps someone else can help you configure it … (I prefer to use the Krandr GUI app … which I believe you already utilized via KDE’s “System settings” > Hardware > Display and Monitor )
To elaborate a bit about the configuration of the X environment, I will re-write what I wrote above by amending it with somewhat paraphrased content from elsewhere:
xorg.conf isn't and has never been obsolete. Rather, Xorg has moved, away from requiring a xorg.conf file, to an automatic configuration of hardware. However, to address cases where "automagic" configuration fails, or when the customization of particular environment settings or features are desired, users can:
tailor configurations via the particular .conf files contained in the /etc/X11/xorg.conf.d/ directory, or
similar as to the case in the past, fall back to the classic/legacy method of using an xorg.conf file to set up their hardware with their X environment
What’s obsolete is the default approach, and need, of using an everything-including-the-kitchen-sink xorg.conf file. Now you can use xorg.conf.d and create just the section where you’re configuring something. Everything else is autodetected (unless you want to customize those things too and then you can include those in xorg.conf.d as well, as you now have the flexibility of multiple config files). The idea is the same, but if it makes it easier to wrap your head around it, think of xorg.conf as xorg.conf.d/99-something.conf
So, for example, say it’s disabling your video driver’s use of SwapBuffersWait that you’re interested in doing – under the new configuration method, you only need to include the Device section for the graphics driver and set it accordingly to your wishes … you create the Device section and only that – everything else is autodetected
Lastly, note that the configuration precedence for X envirnoment settings is given by:xorg.conf file (if specified)** >** /etc/X11/xorg.conf.d/nn-yyyyy.conf files (if specified) > automatic Xorg configuration
… I’m just asking … I confess I don’t know xrandr well (as I’ve never had to use it much … as typically it ‘just works’ for me without any custom arguments).
If he were to need to pass the --screen option then, yeah, that would represent the general form of the command – with the big caveat being provided that things were configured correctly.
However (and while I’m not bothering to re-read the problem carefully)
But he more important issue was the “–output” names … 1 and 0 would be problematic; as as they aren’t even defined / known … so, randr wouldn’t have helped to get the problem solved … it would have been like trying to force a square peg into a round hole … (I believe I missed that pt. first time round).
But, as I said, the “–screen 0” would be redundant (as the default case is “Screen 0”), and the command wouldn’t have done anything because the outputs he was trying to configure weren’t even known/setup/defined themselves to begin with.
In other words, the root of the problem lies further upstream then what randr is capable of solving … randr is dependent upon those outputs to be existent (i.e. for xorg to recognize/configure/set them up) before randr can apply its configurations
Hi
This is an old thread from a milestone version of 12.2. Please start a new thread with details of the hardware, GPU and openSUSE version as well as the desktop environment your using.
