Version: unspecified (using KDE 4.5.0) OS: Linux I've just switched to KDE from GNOME and this is a very important feature for my that is missing in kde. GNOME handles multiple displays pretty well. It saves the screens layout for every monitor you use. That is, if I work on two external monitors at home and a single external one at work, GNOME will recover the last config for each layout (use both external screens at home and the laptop screen and the external monitor at work). This way I don't have to worry about setting them up any more. I would like to see this behaviour in KDE as well Reproducible: Always Steps to Reproduce: Set another screen layout different than default Actual Results: After logging out, these settings are lost Expected Results: Recover the previous configuration for that environment Just like GNOME does it would be great.
I confirm this behavior, and for me it's a "no go" for KDE :-(
I'm experiencing the same problem with KDE 4.4.2, Kubuntu Lucid packages. I set up my dual screens to display screen 2 to the right of screen 1 in System Settings, but when I restart, It switches back 2 as a clone of 1. The rest of my session (panels, running applications) are saved correctly. GNOME doesn't have the same problem. Also worth noting is that the 2 monitors are plugged in to 1 DVI port through a splitter with 2 VGA sockets, rather than directly into the graphics card, like this: DVI | / \ VGA VGA | | 1 2
I can confirm too, after upgrade KDE to 4.6 beta 2, I noticed after logging out these settings are saved but after a restart these settings are lost.
It's working fine for me on KDE 4.6 beta 2. Even after restart.
Current way of saving the default configuration with dual monitors does not work for me . This line in .kde/share/config/krandrrc fails at startup: StartupCommands=xrandr --output "DVI-0" --pos 1280x0 --mode 1920x1080 --refresh 60\nxrandr --output "VGA-0" --pos 0x0 --mode 1280x1024 --refresh 60.0197\nxrandr --noprimary This is what actually works for me: StartupCommands=xrandr --output "DVI-0" --pos 1280x0 --output "VGA-0" --left-of "DVI-0" --noprimary Several probable reason why the original line does not work: 1. xrandr confused by multiple calls and overwrites the earlier ones. 2. \n is a strange separator. try ';' intead? 3. incorrect order order of xrandr calls. The bottom line: Wrapping xrandr calls into one with multiple --output options helps a lot!
I think comment #5 deserves a separate report as the previous messages are about the 'save configuration' problem in general which was fixed in 4.6 using StartupCommands saving. As for problems mentioned in comment #5, they look like issues in xrandr itself as it's so sensitive to commands order and structure (one command / several commands) on certain devices and drivers. It seems that in your case xrandr can't set the mode for one of the head. Could you add --mode keys again in the command which works for you and try it? Unfortunately, compiling all the config into one xrandr command wouldn't solve the situation as one big command usually have even more problems than separate ones.
In the exampes on the xrandr man page, --output's are always (both times) combined. Multiple xrandr calls are only used to setup modes. Just saying.... How can I log my KDE startup to make sure that three separate commands actually happened?
The easiest way is to check the proper layout is set. You can also see the output of KDE startkde script which is printed to the console. As for xrandr, the combined one command and a sequence of commands with single --output key are completely equal. In theory. The fact is also that your very first StartupCommands string is either correct. But there're issues with xrandr. Sometimes it can't apply three commands in a row because it needs some delay between them. Sometimes it ignores commands with several outputs. And in most cases xrandr don't inform the environment about that - you can notice that something went wrong only seeing that the current layout is actually not what you want. The reason why compiling one command for StartupCommands is not good is that it actually don't solve problems for all configs while it is potentially more complex and buggy code. So I wanted to detect why the initial StartupCommands fails for you. It would be great if you could address to make the sequence work for you. It seems to me that it most likely because of --mode and --refresh keys or the order of 1st and 2nd string (--pos 0x0 perhaps should precede --pos 1280x0) Could you please test it in several variants?
Sure, I will play with the different arrangements and report what works. I see the point. On a side note, is it possible to switch to semicolon ";" as a perfectly shell-portable separator instead of very ugly "\n"? In 4.7, maybe?
Yes, I think, separator could be easily changed, before 4.7. That's not so major change, I believe :)
Right you are. It works with multiple xrandr's as long as you start with --pos 0x0. I also started from --pos 1280x0 and run it three times in a row with different outcomes: [apodtele@home ~]$ xrandr --verbose --output "DVI-0" --pos 1280x0 --mode 1920x1080 --refresh 60 crtc 1: disable screen 0: 1920x1080 506x285 mm 96.25dpi crtc 0: 1920x1080 60.0 +0+0 "DVI-0" crtc 1: 1280x1024 60.0 +640+0 "VGA-0" [apodtele@home ~]$ xrandr --verbose --output "DVI-0" --pos 1280x0 --mode 1920x1080 --refresh 60 screen 0: 2560x1080 675x285 mm 96.25dpi crtc 0: 1920x1080 60.0 +640+0 "DVI-0" crtc 1: 1280x1024 60.0 +0+0 "VGA-0" [apodtele@prosha ~]$ xrandr --verbose --output "DVI-0" --pos 1280x0 --mode 1920x1080 --refresh 60 screen 0: 3200x1080 844x285 mm 96.25dpi crtc 0: 1920x1080 60.0 +1280+0 "DVI-0" Finally worked! Just crazy. Why does it even touch crtc1?
I would still argue for a single xrandr with all --output options specified. This is the only way for xrandr to know the final layout and the total screen size. When you split --output options, xrandr considers the missing outputs as undefined and tries to optimize for the smallest screen possible even disregarding offsets. There is abolutely nothing wrong with that. There is only two solutions logically. 1) specify all --outputs at once 2) start xrandr's from --pos 0x0, the rest does not matter.
So sensible description, but again, that's not the correct behaviour it should demonstrate. AFAIK, at the end of the day there're just library function calls at the low end of xrandr. It obviously can manage the parameters some way but if you don't mention the output/crtc it shouldn't change. But there're some problems in video drivers, hardware etc. I think it could be reasonable to sort output by --pos to prevent some of those cases but I think it actually which should be fixed in video drivers to work correctly.
I'll leave it to you to discuss it with X.org or file a bug there. :) I'm using their radeon driver in case they what to know. Sorting multiple monitors is an overkill here. You just need to anchor the monitor at --pos 0x0 first. The rest can come in any random order. Once the origin is explicitly anchored, I doubt that xrandr will dare to alter it. But what if NO monitor is at the origin??? Hmmm. Respect the user's wishes? What's wrong with a single command? This way you let xrandr to sort this out. I do not think there is a driver issue here. The radeon driver just decided to do whatever it pleases until the position is explicitly set. This is reasonable. Other drivers may preset the positions. This is also reasonable. Undefined means that anything goes.
Well, thanks, but I have no point, my configuration is ok :) Single command is wrong just because it's possible that you update your video drivers tomorrow and say "Hey, this command don't work for me anymore but set of commands work flawlessly. Revert everything back!". The aim is to get it work correctly for all configs, not just for you. It's possible to take some measures to avoid some bugs but unfortunately it's impossible to workaround all upstream bugs completely. If you want to improve it, you can file a bug to radeon drivers yourself, I think it's correct to address the problem there. I'll consider to fix what we learned in krandr, that is separator sign and --pos sorting, it can also fix the situation for some configs. But as I said above, it's separate bug. This report is about general problem which is already resolved.
*** This bug has been marked as a duplicate of bug 275360 ***