Version: 4.6 (using KDE 4.6.0) OS: Linux There is a bug reported https://bugs.kde.org/show_bug.cgi?id=183143 It is said to be fixed in kde 4.6 but looks like fix is not complete. The visible symptoms are the same - dualhead settings not restored at startup despite krandtray being loaded and run at startup. But after some investigation I found that "Configure Display" does not write down ~/.kde/share/config/krandrrc correctly. In my case the setting for the CRT2 is always set to the "false", effectively disabling the second display at startup and at calling "Configure Display" application (e.g. by clicking on krandrtray icon). However, the actual StartupCommands setting may be saved correctly! Saving this file manually (and not touching Configure Display anymore) makes thing work. At least, clicking on krandtray and therefore activating "Configure Display" does not automatically disable the second display. But after playing with "Configure Display" (e.g., activating second display on top or on the left of the first, and later to the right) and saving the configuration as default the resulting setting for CRT2 will be Active=false. Maybe it is triggered only when position of CRT2 is to the right to DFP2, I do not know. That's why I think that this is a separate bug from already described bug https://bugs.kde.org/show_bug.cgi?id=183143. I am sorry if the bug description is messy and cryptic. Here is my file ~/.kde/share/config/krandrrc for illustration, with the line that erroneously flips back to false. [Display] ApplyOnStartup=true StartupCommands=xrandr --output "DFP2" --pos 0x0 --mode 1280x1024 --refresh 60.0197\nxrandr --output "CRT2" --pos 1280x0 --mode 1024x768 --refresh 60.0038\nxrandr --output DFP2 --primary [Screen_0] OutputsUnified=false UnifiedRect=0,0,0,0 UnifiedRotation=1 [Screen_0_Output_CRT2] Active=true --------------------------------> mostly gets saved as false!!! Rect=1280,0,-1,-1 RefreshRate=0 Rotation=1 [Screen_0_Output_DFP2] Active=true Rect=0,0,1280,1024 RefreshRate=60.0197410583496 Rotation=1 Reproducible: Always Steps to Reproduce: see the bug details.
I should say that after rebooting my settings were picked up correctly. So, this is really a matter of ~/.kde/share/config/krandrrc being write correctly. However, I am not able to reproduce now a bug. The last three comments (#47-49) from https://bugs.kde.org/show_bug.cgi?id=183143 also mention that this had magically worked after some time.
So did I get it right that the bug is something like that: 1. You open krandr configuration, make the necessary settings on monitor layout 2. You apply them clicking Apply button and they are applied correctly. 3. You save them as default clicking Save as default. 4. But in spite of that it's written to ~/.kde/share/config/krandrrc that CRT2 is disabled (Active=false) but StartupCommands are stored correctly. 5. The behaviour above take place when there's some kind of previously stored config. If you remove it out and configure everything once again the bug isn't reproducible. Is everything right?
Yes, the behavior depends on what was saved before in the config. Once saved correctly, bug then disappears. For me it looks like that some part of the picked up previous (or default) configuration gets directly transferred to a new config, despite that it was actually changed in GUI and applied. Depending on the what was changed in GUI (and how) it may get overwritten correctly. Therefore, later it may be not reproducible. I mean that e.g. if it was "Active=False", than it will mostly remain as inactive. But once written as "Active=True" it will subsequently remain active and look like working. Another problem is that krandr seems not to execute saved StartupCommand but rather construct a new command, based on the saved configuration and execute it.
Hmm.. could you please make the experiment: save the correct config, then change "Active=True" to "Active=False" and test if the further settings made are saved correctly? The question is whether krandr can't work with some old config (it changes from time to time) or it just reads and writes the config incorrectly (even new one). If you could try it it will be very helpful. And I also have a look at load/save code in krandr. As to StartupCommand, it is executed not by krandr but in startkde script, it's written directly from config and executed immediately. So you should see the proper display layout just at the beginning of KDE log in. Krandr just saves the StartupCommand item in the config according to the settings you provide. But when you press apply, afaik it really don't execute StartupCommand but apply settings another way.
Hi, I am experiencing the same problem on KDE version 4.6 with latest patches applied today on Fedora 15. Issue can be reproduced using the following steps: 1) Attach two displays with your machine 2) Open the System Settings > Display and Monitor and change the Dual Display settings to other than default and Save. 3) Log off and Log in and open the Display and Monitor settings again, you will notice that default values are set. I also attached screenshots
Created attachment 62011 [details] Dual Monitor
Hi! It really turns out that krandr does not execute StartupCommand. That is executed by startkde script which in turn calls krandrstartup script. The problem lies in this script - it executes startup commands excluding the first one! I appended a few echo's to see what this script does: if test "$krandrrc_display_applyonstartup" = "true"; then if test -n "$krandrrc_display_startupcommands"; then echo "$krandrrc_display_startupcommands" >> /home/shawkat/testkrandr echo "executing" >> /home/shawkat/testkrandr # new way of simply storing the commands echo -e "$krandrrc_display_startupcommands" | \ while read command; do eval "$command" echo "Run: $command" >> /home/shawkat/testkrandr done The result is xrandr --output "DVI-0" --pos 0x0 --mode 1280x1024 --refresh 60 xrandr --output "VGA-0" --pos 1280x256 --mode 1024x768 --refresh 60 xrandr --output "DVI-0" --primary executing Run: -e xrandr --output "DVI-0" --pos 0x0 --mode 1280x1024 --refresh 60 Run: xrandr --output "VGA-0" --pos 1280x256 --mode 1024x768 --refresh 60 Run: xrandr --output "DVI-0" --primary Look at that "-e". It means that not the "xrandr ..." is being called, rather "-e xrandr" which is obviously a no-go. Therefore this command is actually ignored. This "-e" comes as an argument to "echo" which turns on backslash interpretation required to separate single line StartupCommand to several lines. I do not understand why this parameter for echo is being actually echoed, but this is a real source of a problem. As a workaround I added an additional first command in StartupCommand (actually I copied the first command twice in this line) and now at least the saved startup command correctly executes at startup. The first xrandr call is ignored due to starting "-e", but this command is also repeated second time and then everything works fine. Hope it helps.
It is a real fun. The problem is in command interpreter specified in krandrstartup! When it is a /bin/sh that spurious "-e" appends and first xrandr command fails. When it is a /bin/bash - everything is Ok.
And here it is: https://bugs.kde.org/show_bug.cgi?id=275360 Fixed in 4.6.5 So this is at least partly a duplicate of https://bugs.kde.org/show_bug.cgi?id=275360. It is still a question if krandr correctly handles the config file.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Should this be closed as either WORKSFORME or UNSUPPORTED?
Bug was reported against KDE4, which is no longer supported.