Bug 766545 - Setting display size under hardware tab does not survive restart
Summary: Setting display size under hardware tab does not survive restart
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kde-workspace
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Daniel Vrátil
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 769028 825410 877174 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-12 10:21 UTC by George R. Goffe
Modified: 2015-11-02 01:36 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-01 00:02:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
KDE Software Compilation 183143 0 None None None 2012-06-20 11:20:48 UTC

Description George R. Goffe 2011-12-12 10:21:27 UTC
Description of problem:

System Settings -> Display and Monitor -> Size & Orientation does not survive a KDE restart.

Version-Release number of selected component (if applicable):

kdebase-4.7.3-1.fc16.x86_64

How reproducible:

always

Steps to Reproduce:
1.see above
2.
3.
  
Actual results:

Setting display values with and without "Save as Default" fails to permanently set values. Does not survive restart of KDE or system reboot.

Expected results:

Settings should survive a KDE restart.


Additional info:

Comment 1 Rex Dieter 2011-12-12 12:47:24 UTC
You need to click the "Save as Default" button for your changes there to be persistent.

Comment 2 Rex Dieter 2011-12-12 12:48:52 UTC
Could you give specifics on how you're configuring it?

And, please post the contents of your ~/.kde/share/config/krandrrc

Comment 3 George R. Goffe 2011-12-13 02:00:10 UTC
Rex,

I had already tried "save as default" with no effect. Next restart goes back to the default(?) settings (something x 900) as I recall. Do you need the exact settings? I select the top in the little pulldown menu.

Thanks!

George...

Comment 4 George R. Goffe 2011-12-13 03:30:58 UTC
Rex,

I'm trying to set VGA-0 to 1920x1200 and LVDS to 1680x1050.

And here's krandrrc:

[Display]
ApplyOnStartup=true
StartupCommands=xrandr --output VGA-0 --pos 0x0 --mode 1440x900 --refresh 76.0683\nxrandr --output LVDS --pos 0x0 --mode 1440x900 --refresh 59.8874\nxrandr --noprimary

[Screen_0]
OutputsUnified=false
UnifiedRect=0,0,0,0
UnifiedRotation=1

[Screen_0_Output_LVDS]
Active=true
Rect=0,0,1680,1050
RefreshRate=60.108470916748
Rotation=1

[Screen_0_Output_VGA-0]
Active=true
Rect=0,0,1920,1200
RefreshRate=70.3177108764648
Rotation=1

George...

Comment 5 Martin Bříza 2012-06-20 11:20:15 UTC
*** Bug 825410 has been marked as a duplicate of this bug. ***

Comment 6 Martin Bříza 2012-07-27 10:32:15 UTC
*** Bug 769028 has been marked as a duplicate of this bug. ***

Comment 7 Kyle Liddell 2012-09-14 05:21:05 UTC
I'm having this problem too, in Fedora 17 - I hope it's correct to post a little more detail under this bug.  This also happened in Fedora 16.
(In my situation, KDE always starts up with my two monitors cloning each other, which I don't want.)

My krandrrc:
[Display]
ApplyOnStartup=true
StartupCommands=xrandr --output DVI-0 --pos 1280x0 --mode 1680x1050 --refresh 59.8833 >>~/xrlog\nxrandr --output DVI-1 --pos 0x0 --mode 1280x1024 --refresh 60.0197 >>~/xrlog\nxrandr --output DVI-0 --primary >>~/xrlog\ntouch ~/ran_xrandr

[Screen_0]
OutputsUnified=false
UnifiedRect=0,0,0,0
UnifiedRotation=1

[Screen_0_Output_DVI-0]
Active=true
Rect=1280,0,1680,1050
RefreshRate=59.8832511901855
Rotation=1

[Screen_0_Output_DVI-1]
Active=true
Rect=0,0,1280,1024
RefreshRate=60.0197410583496
Rotation=1


As you can see, I've modified the StartupCommands to do some logging, so I know that these commands are being run - I have empty files named xrlog and ran_xrandr.

(If I run the xrandr commands by hand after KDE launches, my desktops have the proper config.)

I tried using kdebugdialog to turn on debugging, and then started kde by doing a Failsafe session and then running startkde.  I didn't see anything in the logfile about krandrrc/xrandr, but I did see a couple mentions of the resolutions of each display, like this:

plasma-desktop(9737)/plasma PlasmaApp::createView: Containment name: "Desktop" | type 0 | screen: 1 | desktop: -1 | geometry: QRectF(1686,0 1280x1024) | zValue: 0
plasma-desktop(9737)/plasma PlasmaApp::createView: Containment name: "Desktop" | type 0 | screen: 0 | desktop: -1 | geometry: QRectF(0,0 1680x1050) | zValue: 0

Another thing is that the Failsafe session almost did the right thing with the display layout - the displays were not cloned and they were at the proper resolution; the only problem was that DVI-0 was "LeftOf" DVI-1, instead of "RightOf".

I'd like to see a little more debugging detail, like exactly when the xrandr commands are run, but I don't know how to get it.  If somebody can tell me, I'd be happy to collect the information.

Comment 8 Martin Bříza 2012-09-17 12:27:43 UTC
Hello,

Kyle, thank you for the information, it helped me a lot and I think I'm near to solving this problem.
It seems xrandr fills empty gaps in screen when the displays are added, so (in your case) if you want to add a 1680x1050 display to position 1280x0, it will move it to 0x0 as there is nothing there yet.
So, to temporarily solve your problem, you can edit the configuration file and switch the two displays in the startup line. This:
StartupCommands=xrandr --output DVI-1 --pos 0x0 --mode 1280x1024 --refresh 60.0197 \nxrandr --output DVI-0 --pos 1280x0 --mode 1680x1050 --refresh 59.8833 \nxrandr --output DVI-0 --primary
should in my opinion run just fine.

George, are you sure you set the display as default? Your settings look very strange. Please, try to set it again and send us what appears in your ~/.kde/share/config/krandrrc . 

Thank you

Comment 9 Kyle Liddell 2012-09-18 04:26:55 UTC
Martin,                                                                     
                                                                            
Thanks for looking into this.  Your recommended xrandr commands do work.    
I also tried switching the monitor cables around, and when the 1680x1050 display is on DVI-1, KDE can restore the correct settings from the config file it generates.  (But then kdm places the login dialog box on the smaller display...)

I'm having another issue with display layout on KDE startup.  It may need to be filed as a seperate bug, but it seems to be related to this problem:
The KDE panel's position doesn't persist across sessions, if it's placed on the left edge of the 1280x1024 display.  If I place the panel on any other screen edge, it will be in the same position when I restart KDE.  But if I move it to the left edge (of the 1280x1024 display), then when I restart KDE it will appear on the left edge of the 1680x1050 display.  However, the panel will be 1024 pixels tall, instead of stretching all the way down.

(While trying out different cable configurations, I did end up in a default state where the two displays were at the correct resolution, but with the 1280x1024 display configured to be "right of" the higher res display, and in this case, the panel would start up on the left edge of the 1280x1024 display.)

It seems like ~/.kde/share/config/plasma-desktop-applets might be the correct config file to control this, but the panel geometry doesn't ever change when I move the panel around.

Thanks again!

Comment 10 Martin Bříza 2012-09-19 07:41:13 UTC
Kyle,

I looked into the desktop applet configuration file (i think it's not changing because it's saved on logout) and the issue here is that it's not exactly prepared to be used with multiple desktop configurations so it's breaking up when they are being switched. This definitely needs to be changed too when profiles for multi-head systems are added.

Comment 11 George R. Goffe 2012-09-19 08:15:12 UTC
Howdy,

The display settings have been working for me for some time now. Here's what krandrrc contains:

cat ~/.kde/share/config/krandrrc
[Display]
ApplyOnStartup=true
StartupCommands=xrandr --output default --pos 0x0 --mode 1920x1080 --refresh 0\nxrandr --noprimary

Need more info?

George...

Comment 12 Kyle Liddell 2012-09-26 05:20:37 UTC
I just logged into KDE with the recent update of most packages to version 4.9.1.  My bug with the panel not starting in the correct position (comment 9) is now gone - the panel stays where I left it when I log out.  I do continue to have the issue where KDE can't generate a correct krandrrc file.  Martin's xrandr commands still work.

Comment 13 Martin Bříza 2012-09-26 09:39:45 UTC
Hello,
thank you both for your information and I'm glad these issues are now fixed.
As far as I'm informed, there is work going on the whole display management (and it seems it's going to be awesome) in KDE so hopefully we will see some results soon.

Comment 14 Martin Bříza 2012-11-16 08:21:58 UTC
*** Bug 877174 has been marked as a duplicate of this bug. ***

Comment 15 Fedora End Of Life 2013-07-03 22:16:55 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 16 Fedora End Of Life 2013-08-01 00:02:30 UTC
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.