Created attachment 27077 [details]
/var/log/Xorg.0.log

Created attachment 27078 [details]
~/.xsession-errors

Created attachment 27079 [details]
/etc/X11/xorg.conf

  This is just a configuration problem (would alomst have downgraded all of Xorg!). By de-selecting 'unify outputs' in krandrtray the old behaviour could be restored so that
xrandr --output DVI-D_1 --mode 1920x1200 --right-of PANEL;
has again done what it should.
  How can I achieve the same by an xrandr command line?
  I wish the old behaviour back as soon as possible. Anway this is a bug since correct xinerama-xorgs now cease to work and since auto coupling will be kept deactivated also for new Xorgs once it is gone (please deactivate that at all). 

Please post the output of xrandr --verbose, and of the switching xrandr mode (with --verbose as well).

This could be a standard problem of an older xrandr I fixed in git. Make sure you're using xrandr 1.2.3 or xrandr 1.3.0 (NOT earlier ones or 1.2.99.*).

> xrandr -v
Server reports RandR version 1.3

I remember xrandr --version has outputted something like
screen 0: 3840x1200
display 0: 1920x1200
... but yet no error message (though it did not work at all).

Now there is only one line of output:
> xrandr --verbose --output DVI-D_1 --mode 1920x1200 --right-of PANEL;
crtc 0:    1920x1200   60.0 +1920+0 "DVI-D_1"

Then your xrandr is affected (it doesn't unclone). Easy workaround: add --crtc 1
Real solution: install newer xrandr (1.3.0).

Unfortunately, xrandr doesn't print it's own version with --version.

Xrandr says that it is already of version 1.3 (if that should not suffice how can I check out xrandr and compile it myself).
The xinerama setup should work merely by xorg.conf without having to invoke xrandr manually.
It somehow does not work with the crtc-option either (None of these commands succeed in uncloning):

> xrandr --verbose --output DVI-D_1 --crtc 1 --mode 1920x1200 --right-of PANEL;
xrandr: cannot find crtc for output DVI-D_1
> xrandr --verbose --output DVI-D_1 --crtc 0 --mode 1920x1200 --right-of PANEL;
screen 0: 3840x1200 1116x349 mm  87.34dpi
crtc 0:    1920x1200   60.0 +1920+0 "DVI-D_1"
> xrandr --verbose --output DVI-D_1 --mode 1920x1200 --right-of PANEL;
screen 0: 3840x1200 1116x349 mm  87.34dpi
crtc 0:    1920x1200   60.0 +1920+0 "DVI-D_1"
> xrandr --verbose --output PANEL --crtc 0 --mode 1920x1200 --left-of DVI-D_1;
xrandr: cannot find crtc for output DVI-D_1
> xrandr --verbose --output PANEL --crtc 1 --mode 1920x1200 --left-of DVI-D_1;
screen 0: 3840x1200 1116x349 mm  87.34dpi
crtc 0:    1920x1200   60.0 +1920+0 "DVI-D_1"
crtc 1:    1920x1200   60.0 +0+0 "PANEL"
> xrandr --verbose --output PANEL --mode 1920x1200 --left-of DVI-D_1;
screen 0: 3840x1200 1116x349 mm  87.34dpi
crtc 0:    1920x1200   60.0 +1920+0 "DVI-D_1"

(In reply to comment #7)
> Unfortunately, xrandr doesn't print it's own version with --version.

Please read this again. xrandr prints the *server* protocol version, not it's own version.

(In reply to comment #8)
> The xinerama setup should work merely by xorg.conf without having to invoke
> xrandr manually.

I thought in the original description you wrote that the static config is working?!? Your xorg.conf has a number of issues:

- The screen section shouldn't have a Montior any more - though with 1.2.5 this should work
- You can use a Modes section only once. So you would have to duplicate it for the two monitors.
- MonitorLayout + Co are radeon only, not radeonhd, which only supports RandR style configuration.
- You still have a fglrx config in the xorg.conf. Make sure that there are no traces of the driver, especially not the module (it must not be loaded, unloading is not enough, you need to reboot) and the libGL.

> It somehow does not work with the crtc-option either (None of these commands
> succeed in uncloning):

try
xrandr --verbose --output DVI-D_1 --off
xrandr --verbose --output PANEL --crtc 0 --mode 1920x1200
xrandr --verbose --output DVI-D_1 --crtc 1 --mode 1920x1200
xrandr --verbose --output PANEL --pos 1920x0

> > xrandr --verbose --output PANEL --crtc 1 --mode 1920x1200 --left-of DVI-D_1;
> screen 0: 3840x1200 1116x349 mm  87.34dpi
> crtc 0:    1920x1200   60.0 +1920+0 "DVI-D_1"
> crtc 1:    1920x1200   60.0 +0+0 "PANEL"

What has happened after this command? The config looks good.

In a fact nothing happens (tried again) though the output looks promising.

- The screen section shouldn't have a Montior any more - though with 1.2.5 this
should work
* removed; already configured in device section anyway

- You can use a Modes section only once. So you would have to duplicate it for
the two monitors.
* why? That would be very conterintuitive and hulking.
Anyway this does not seem to be a problem since the full list of modes is displayed by xrandr -q for both displays.

- MonitorLayout + Co are radeon only, not radeonhd, which only supports RandR
style configuration.
* already commented out; added a comment: radeon only, not radeonh

- You still have a fglrx config in the xorg.conf. Make sure that there are no
traces of the driver, especially not the module (it must not be loaded,
unloading is not enough, you need to reboot) and the libGL.
* fglrx is not installed; purged these sections anyway

As said if the X-server starts everything is all right (likely not an error of xorg.conf).
The clone mode is then set by accident during startkde.

Alas, xrandr-configuration is the source of so many errors!! 
 Lately both screens turned black after disabling PANEL and then could not be restored because of xrandr saying 'configuring crtc0 failed'.- and my total KDE session was lost.
 I would regard Bug 20888, Bug 20628 and Bug 18592 as related; all of them video mode configuration errors as initiated by xrandr.
 If the radeonhd-driver can not offer competetive 3D-support it should at least support xinerama and dual-screen configurations well (as well: Bug 17788)!

(In reply to comment #11)
> As said if the X-server starts everything is all right (likely not an error of
> xorg.conf).
> The clone mode is then set by accident during startkde.

So, is everything fine?  If the modechange is initiated by KDE, then there is nothing that can be done by the driver.

  Perhaps I should have opened another bug as super issue. Comment #13 is not about clone mode any more. It is simply about xrandr not doing its job in this and so many other cases (see referenced bugs) with various xorg.confs. I did not see any sense in opening another bug on the same core issue as all these bugs seem to be related. Comment #13 in a fact describes a very own bug. Feel free to ask me in opening another request in behalf of Comment #13 (own issue).

Lets just stick to addressing the original issue.

Please just provide what is asked for in Comment #5.

The information has already been provided by Comment #8.- and it has revealed some much more severe deficency of xrandr.

(In reply to comment #15)
> Lets just stick to addressing the original issue.
> 
> Please just provide what is asked for in Comment #5.
> 

(In reply to comment #11)
> - You can use a Modes section only once. So you would have to duplicate it for
> the two monitors.
> * why? That would be very conterintuitive and hulking.

Yes, it's counterintuitive, but that's the way it's coded :-(

> As said if the X-server starts everything is all right (likely not an error of
> xorg.conf).
> The clone mode is then set by accident during startkde.

Ah, yes. The "intelligent" desktop setup :-(
Nevertheless, this should work.

I cannot reproduce your issues here - and without reproducing this is difficult (read: close to impossible) to debug.

One little idea would be to update your xserver to 1.6.3 - 1.6.1 still had a number of issues regarding randr AFAIR.
Also, for validation, please post your current xorg.conf again. Bad section references can have all kinds of weird runtime effects. The Xserver isn't exactly well designed with that respect.

Does this issue occur with the preferred ati driver (xf86-vide-ati)?  If so, please move this to the Driver/Radeon component.  

Development of radeonhd has pretty much halted and development focus is on the ati driver.  Please see http://www.x.org/wiki/radeonhd

If the issue does not exist in the ati driver (or if there is no response to this message), this bug will be closed as WONTFIX unless someone contributes a patch.

Closing due to lack of response.  Please reopen and move to the Driver/Radeon 
component if this issue persists with xf86-video-ati