Version: (using KDE 4.2.2) OS: Linux Installed from: Ubuntu Packages I have 2 monitors connected to an ATI graphics board using the radeon driver. I can switch between single and dual monitor mode with xrandr. Observation 1: If I am running single monitor (left monitor on, right monitor off), I see the "desktop" (panel, icons etc.) on the left monitor (Correct) If I enable the right monitor, the "desktop" jumps to the right monitor (Incorrect). Observation 2: In a static xinerama configuration set up via xorg.conf, the "desktop" is also created on the right monitor (Incorrect). KDM is showing its login mask on the left monitor (Correct).
Created attachment 32587 [details] xorg.conf with xinerama setup used for testing
Created attachment 32588 [details] Shell script for video mode switching used for testing
New observation: 1. Create a new user account 2. Log in to this user the first time while dual monitor Xinerama active: Desktop elements are created on the left monitor. Right monitor is empty (correct). 3. Disable right monitor: Content of right monitor is moved to the left monitor (incorrect) 4. Activate right monitor again: Original content of left monitor is shown again (with panel etc.) So to be able to see the panel etc. in dual and single monitor mode, you have to move it to the right monitor, so that it's visible on the left if the right monitor is disabled - you are in the same situation as written in the bug description.
Version: KDE 4.2.2 OS: Linux Installed from: Debian Sid packages I'm also experiencing this painful "feature" when using radeon with the following command: xrandr --output DVI-0 --right-of VGA-0 --auto .xsession-errors tells me that kde(?) decides that screen0 should move after the new output is enabled: [CRTC 75 ] Event... mode: 104 (current 0 ) pos: ( 1600 , 0 ) size: 1152 x 864 rotation: 1 Changed mode - old 0 - new 104 Changed size: QSize(1152, 864) RandRDisplay::handleEvent - RRNotify win: 170 RandRScreen::handleRandREvent - OutputChange [OUTPUT 77 ] Got event for "DVI-0" crtc: 75 (current 0 ) mode: 104 (current 0 ) rotation: 1 connection: 0 Setting CRTC 75 on output "DVI-0" (previous 0 ) possible: (76, 77) CRTC outputs: (77) XRandROutput::outputChanged true true QRect(1600,0 1152x864) OutputScreens::outputActivated OutputScreens::triggerRebuildScreens() OutputScreens::rebuildScreens() rebuild: emitted screenMoved 0 - old QRect(0,0 1600x1200) - new QRect(1600,0 1152x864) rebuild: emitted screenResized 0 - old QRect(0,0 1600x1200) - new QRect(1600,0 1152x864) rebuild: emitted screenAdded 1 And of course, "xrandr --output DVI-0 --off" produces the move back: rebuild: emitted screenMoved 0 - old QRect(1600,0 1152x864) - new QRect(0,0 1600x1200) rebuild: emitted screenResized 0 - old QRect(1600,0 1152x864) - new QRect(0,0 1600x1200) rebuild: emitted screenRemoved 1
Same problem with my setup: Laptop with external display connected. I would love to have my "0" screen on my laptop LCD. The external display should only extend the desktop, but not take over. At first I thought this could be controlled with xrandr by using the "--primary" option for one output. But that does not work.
I have done some tests with several distributions (all latest versions): Kubuntu 9.10 (kde 4.3.2, xorg 1.6) Bug still present SuSE 11.2 (kde 4.3, xorg 1.6) Bug present Mandriva (kde 4.3.2, xorg 1.6) Bug present Sidux (kde 4.3.2, xorg 1.6) Bug present Fedora 12 (kde 4.3.2 and 4.3.3, xorg 1.7): Bug NOT present. Tested with and without kernel mode setting. krandrtray is still unusable.
so after those tests, could it be that this is a xorg issue (that has been fixe)?
For the record, I also can't reproduce with xorg 1.7 (KDE 4.4 RC)
this is probably fixed, closing for now. please reopen if somebody can reproduce.
I'm getting this problem too. Debian testing/sid mix on amd64 kde 4.3.4-1 xorg 1.7.4-2 radeon 6.12.4-3 If I use radeonhd 1.3.0-2 this problem goes away, but I get other problems. Wolfgang, did your Fedora 12 test use radeonhd instead of radeon driver? The difference is that radeon and radeonhd drivers use different names for the screens. The other possibility I see is Fedora has a patch that hasn't been accepted upstream. ======================================= On my setup: radeon DVI-1 (physical port 0, my default monitor) DVI-0 (physical port 1) radeonhd DVI-I_1/digital (port 0 again) DVI-I_2/analog (port 1 again) xrandr lists them in the correct order in each case (primary first), but with the radeon driver this is not in alphabetical order. ======================================= xrandr -q with radeon driver Screen 0: minimum 320 x 200, current 2624 x 900, maximum 2624 x 900 DVI-1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 443mm x 250mm 1600x900 60.0*+ 60.0 1024x768 60.0 800x600 60.3 640x480 59.9 720x400 70.1 DVI-0 connected 1024x768+1600+0 (normal left inverted right x axis y axis) 300mm x 230mm 1024x768 85.0*+ 75.0 800x600 85.1 75.0 640x480 85.0 75.0 59.9 720x400 70.1 ======================================= relevant part of Xorg.0.log with radeon driver (II) RADEON(0): Port0: XRANDR name: DVI-1 Connector: DVI-I CRT2: INTERNAL_KLDSCP_DAC2 DFP1: INTERNAL_UNIPHY DDC reg: 0x7e60 (II) RADEON(0): Port1: XRANDR name: DVI-0 Connector: DVI-I CRT1: INTERNAL_KLDSCP_DAC1 DFP2: INTERNAL_KLDSCP_LVTMA DDC reg: 0x7e20 ======================================= xorg.conf for radeon Section "Module" Load "extmod" Load "dri" Load "drm" Load "glx" EndSection Section "Monitor" Identifier "monitor0" Option "PreferredMode" "1600x900" Option "Primary" "True" EndSection Section "Monitor" Identifier "monitor1" Option "RightOf" "monitor0" Option "PreferredMode" "1024x768" EndSection Section "Device" Identifier "hd4870" Driver "radeon" Option "AccelMethod" "EXA" BusID "PCI:1:0:0" Option "monitor-DVI-1" "monitor0" Option "monitor-DVI-0" "monitor1" EndSection Section "Screen" Identifier "screen0" Device "hd4870" DefaultDepth 24 SubSection "Display" Depth 24 Virtual 2624 900 EndSubSection EndSection Section "ServerLayout" Identifier "dual head" Screen 0 "screen0" EndSection Section "DRI" Group "video" Mode 0660 EndSection ======================================= Does KDE sort screens by name to decide which is the primary instead of using the xrandr reported order? If so, that would be the problem, as there are 3 possibilities: primary is first in sort order, so sorting is a NOP user doesn't care which is primary, so sorting is irrelevant primary is NOT first in sort order, so sorting is wrong