Bug 831020 - Screen resolution not applied
Summary: Screen resolution not applied
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: control-center
Version: 17
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Control Center Maintainer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-12 01:23 UTC by malak
Modified: 2013-07-31 22:22 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-31 22:22:41 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
screenshot of screen settings before the desired resolution disappears (43.04 KB, image/png)
2012-06-21 22:28 UTC, malak
no flags Details
screenshot of screen settings after the desired resolution disappears (36.24 KB, image/png)
2012-06-22 01:44 UTC, malak
no flags Details
picture of error on screen described in entry of July 3 2012 (3.87 MB, image/jpeg)
2012-07-03 11:23 UTC, malak
no flags Details
Xorg.0 log part during screen lock and unlock (2.65 KB, text/plain)
2012-08-19 23:21 UTC, Ian Shields
no flags Details

Description malak 2012-06-12 01:23:02 UTC
Description of problem:

I have set a screen resolution of 1280x1024 (5x4) on my Samsung SyncMaster 750s (circa year 2000).  Fedora 17 x86_64 Gnome 3.4.  When the screen saver and screen lock engage, after I enter my password to unlock the screen the 1280x1024 (5x4) resolution is no longer available and the screen defaults to 1024x768 (4x3).  Should the machine reboot, the first login will come up again with the desired 1280x1024 (5x4) resolution.

Previously, this was (curiously) "corrected" by (each time after unlocking the screen) going into the Applications / System Tools / System Settings / Displays in order to manually correct the problem; however, besides this being undesirable, the system would automatically correct the screen resolution before I could click the "apply" button.

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

17 x64

How reproducible:

always

Steps to Reproduce:
1. boot machine -- correct screen resolution is applied
2. allow screensaver to engage
3. enter password to unlock screen
  
Actual results:

higher resolutions are not available and screen defaults to 1024 x 768

Expected results:

1280x1024 (5x4) resolution would remain.

Additional info:

Comment 1 malak 2012-06-13 00:16:45 UTC
Inexplicably and despite the lack of any updates, I now can't reproduce this bug since the "expected result" of keeping the 5:4 resolution is occuring.

Comment 2 malak 2012-06-13 11:40:12 UTC
... and now overnight it has reproduced itself.

Comment 3 malak 2012-06-18 11:13:47 UTC
just upgraded to kernel 3.4.2-4.fc17.x86_64 and rebooted

As described, the desired screen size of 5:4 has returned on its own.  I have tried to do a screen lock via the menu in the upper right hand corner, and this does not cause the system to "forget" the screen resolution settings, as mentionned above.  I will see if allowing the system to do its own automatic screen lock will reproduce it again, which I expect will be the case.

Comment 4 malak 2012-06-18 15:48:43 UTC
just did as previously stated (about 4.5 hours screen lock after screen saver / screen lock timed out on its own) and screen came back with desired screen resolution.

Will follow through again this evening when I get home again.

... and I spoke too soon.  Out of curiosity, I went into Activities / Applications / System Tools / System Settings / Displays and whaddya know, the system decides "whoops, for whatever reason the hightest resolution available is 4:3 1024 x 768" and the screen automatically kicked down the resolution to 4:3 1024 x 768.

Comment 5 malak 2012-06-21 22:28:07 UTC
Created attachment 593613 [details]
screenshot of screen settings before the desired resolution disappears

Comment 6 malak 2012-06-21 22:34:24 UTC
Comment on attachment 593613 [details]
screenshot of screen settings before the desired resolution disappears

... another screenshot will follow if/when the 5:4 resolution is lost.

Comment 7 malak 2012-06-22 01:44:40 UTC
Created attachment 593639 [details]
screenshot of screen settings after the desired resolution disappears

about 3 hours had elapsed between the two screenshots.  The first was after a reboot, and this one was after about two hours of the screensaver being active, having timed out on its own.  This time, the screen resolution changed on its own.

So:

- proper resolution comes back after a reboot

But:

- the system forgets during a screensaver timeout all of the resolutions it can use, but:
- sometimes after short periods things don't change, but after somewhat extended periods (as little as two hours so far) it occurs, but not always (as long as 4.5 hours);
- sometimes it "auto corrects" during the locked screen before I log back in;
- sometimes it "corrects" itself only after entering into the system settings menu;
- sometimes (but not lately) it "auto corrects" during the locked screen, but when I go into the system settings it goes back to the desired resolution;
- so far manually locking the screen and immediately unlocking it doesn't create the problemè

Comment 8 malak 2012-06-22 01:48:30 UTC
Also, adding a Xorg.conf file in /etc/X11/ with a desired screen resolution causes the computer to hang during a reboot.  I must go into the special booting options for Fedora to get a root terminal in order to remove the file so that the system will boot properly.

Comment 9 malak 2012-06-22 13:10:44 UTC
malak said:

"- sometimes after short periods things don't change, but after somewhat extended periods (as little as two hours so far) it occurs, but not always (as long as 4.5 hours);"

Now it's as little as about 20 minutes.  I did a hard reboot this morning ...

Comment 10 Charles R. Kiss 2012-06-22 16:34:10 UTC
Just have to say I'm also having a problem with screen resolution settings.  Which is why I'm here. I'm running Fedora 17 through VirtualBox 4.0 on a Debian 4.0 Squeeze host.

I've edited the Fedora 17 Xorg.conf files multiple times, multiple ways, and in multiple locations... ie. /root /etc/X11/xorg.conf.d. setting Modes, in multiple screens and monitors, including adding results from cvt into Modelines, but the resolution could actually get kicked down to 800x768 under certain circumstances, even though there is a "larger screen size" in the VM, but with no options to increase resolution even to 1024, the previous default.

Comment 11 malak 2012-06-22 19:18:48 UTC
I have been ruminating this morning about the problem ... this morning, after a reboot and using the computer at the correct 5:4 resolution, I physically turned off the power to the SyncMaster screen, and after 5-10 minutes came back.  The screensaver hadn't yet kicked in, but the resolution had gone down to the 4:3.

Which makes me wonder if some of the difficulties lay in interpreting the signals between the screen and the OS.

Don't know yet.

After the weekend I will try switching screens.

Comment 12 malak 2012-06-27 01:23:01 UTC
I have just switched out my samsung screen and switched in a Dell 17" screen of roughly the same vintage.

Besides initially having only three resolution choices instead of four, I was initially able to switch to the desired resolution after a reboot that did not reset the resolution.

I was immediately able to reproduce the bug by doing the following:

1) ensure that desired resolution (5:4) is present and available as an option, and chosen as the desired screen resolution;
2) force a screen lock in the notifications section;
3) physically turn off the screen by pressing the power button;
4) physically turn on the screen by pressing the power button;
5) (although the change was immediately visible at this point) engage the login and enter my password;
6) voilà, the screen resolution is back to 4:3 1024 x 768, and the higher resolution of 5:4 1280x1024 is NOT available in the screen settings.

Comment 13 malak 2012-06-27 01:41:59 UTC
I just did a yum update and an updated xorg-x11-server-Xorg-1.12.2-1.fc17.x86_64 was installed.

I did a reboot to be certain (I know, normally it's not required except for kernel updates).  At first I couldn't reporduce the bug as mentionned a few minutes ago, however on the third screen lock (which also did not include a power down of the screen), the bug came back.

Comment 14 malak 2012-06-28 19:32:31 UTC
I just did another yum update.  A couple of screen drivers were updated (such as the nouveau driver, although I don't have an Nvidia card) and another (don't recall which, and I unfortunately closed the terminal ... I don't know how to dig up the logs on what was recently updated).

I went into the usual gnome screen settings, and at first the usual 4:3 1024 x 768 resolution was the highest available.  In a fit of mild frustration, I repeatedly clicked (5-10) on "detect display" (fully expecting it to have no effect) and whaddya know, suddenly the 5:4 1280 x 1024 resolution appears, and automatically applies.

I am crossing my fingers for the moment.

Comment 15 malak 2012-06-28 19:49:22 UTC
... and I sort of spoke too soon, BUT, I have found out something, and it's not all bad.

I walked away for about 10-15 minutes, and the screensaver kicked in, but not the screen lock.  I came back to a familiar sight:  4:3 resolution again.  So I went into the screen settings again as above, and slowly clicked the "detect display" button again (without saying "there's no place like home" ...) and the 5:3 resolution came back.

Curiouser and Curiouser ...

Comment 16 malak 2012-06-28 20:38:17 UTC
How do I change the priority of this bug to a higher level?  Although in the "grand scheme of things" this appears to be a low priority bug, I am getting another problem which is possibly related to this one, involving the upper panel of the screen disappearing, making the "activities" menus unavailable.  Ultimately the only solution appears to be a reboot.

Comment 17 malak 2012-06-30 14:27:08 UTC
Currently I'm able to use the system under two conditions:

- every time I unlock the screen, I go into the screen settings and do a "detect display" which brings back the desired resolution;
- (in allusion to my previous comment) I avoid loading lots of documents simultaneously, which seems to cause a partial G3 shell crash, causing the disappearance of the upper pannel of the screen, and I'm not able to reboot G3.  Essentially, while I can use any of the open applications, the only way to access them is to close the windows tiled "above" it.

Comment 18 malak 2012-06-30 17:09:36 UTC
reestablishing the "need more info" request since I put in the "anyone" tag.

*****

How do I change the priority of this bug to a higher level?  Although in the "grand scheme of things" this appears to be a low priority bug, I am getting another problem which is possibly related to this one, involving the upper panel of the screen disappearing, making the "activities" menus unavailable.  Ultimately the only solution appears to be a reboot.

Comment 19 malak 2012-07-01 13:37:00 UTC
"yum remove Gnome-desktop" and a "yum install gnome-desktop" does not correct the issue.

Comment 20 malak 2012-07-03 11:18:51 UTC
after the gnome desktop replacement above, I rebooted and got the error messages below, then logging in only after not initially logging in for several hours:

- reboot
- do not log in
- turn off screen power
- wait about 8 hours
- turn on screen power
- try to log in
- screen error as follows occurs:

none of the selected modes were compatible with the possible modes:
Trying modes for CRTC 63
CRTC 63: trying mode 1024x768@60Hz with output at 1280x1024@60Hz (pass 0)
CRTC 63: trying mode 800x600@60Hz with output at 1280x1024@60Hz (pass 0)
CRTC 63: trying mode 800x600@56Hz with output at 1280x1024@60Hz (pass 0)
CRTC 63: trying mode 848x480@60Hz with output at 1280x1024@60Hz (pass 0)
CRTC 63: trying mode 640x480@60Hz with output at 1280x1024@60Hz (pass 0)
CRTC 63: trying mode 1024x768@60Hz with output at 1280x1024@60Hz (pass 1)
CRTC 63: trying mode 800x600@60Hz with output at 1280x1024@60Hz (pass 1)
CRTC 63: trying mode 800x600@56Hz with output at 1280x1024@60Hz (pass 1)
CRTC 63: trying mode 848x480@60Hz with output at 1280x1024@60Hz (pass 1)
CRTC 63: trying mode 640x480@60Hz with output at 1280x1024@60Hz (pass 1)
Trying modes for CRTC 64
CRTC 64: trying mode 1024x768@60Hz with output at 1280x1024@60Hz (pass 0)
CRTC 64: trying mode 800x600@60Hz with output at 1280x1024@60Hz (pass 0)
CRTC 64: trying mode 800x600@56Hz with output at 1280x1024@60Hz (pass 0)
CRTC 64: trying mode 848x480@60Hz with output at 1280x1024@60Hz (pass 0)
CRTC 64: trying mode 640x480@60Hz with output at 1280x1024@60Hz (pass 0)
CRTC 64: trying mode 1024x768@60Hz with output at 1280x1024@60Hz (pass 1)
CRTC 64: trying mode 800x600@60Hz with output at 1280x1024@60Hz (pass 1)
CRTC 64: trying mode 800x600@56Hz with output at 1280x1024@60Hz (pass 1)
CRTC 64: trying mode 848x480@60Hz with output at 1280x1024@60Hz (pass 1)
CRTC 64: trying mode 640x480@60Hz with output at 1280x1024@60Hz (pass 1)

Comment 21 malak 2012-07-03 11:23:46 UTC
Created attachment 595931 [details]
picture of error on screen described in entry of July 3 2012

Comment 22 Ian Shields 2012-08-17 15:36:57 UTC
I am seeing similar problems. I have a Samsung VA2323wm connected via an IOGear KVM switch. If the screensaver engages while the screen is switched to the Fedora 17 box and it is left there, then the screen restores to 1920x1080 after I enter the password and unlock the screen. If the screen is left switched to a different system, then the screen will be at 1024x768 when I unlock. I have found that simply running xrandr is sufficient to automatically reset the screen to 1920x768. xrandr output is:
$ xrandr
Screen 0: minimum 8 x 8, current 1024 x 768, maximum 8192 x 8192
DVI-I-0 disconnected (normal left inverted right x axis y axis)
VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 509mm x 286mm
   1920x1080      60.0*+
   1680x1050      60.0  
   1600x1200      60.0  
   1440x900       59.9  
   1400x1050      60.0  
   1280x1024      75.0     60.0  
   1280x960       60.0  
   1152x864       75.0  
   1024x768       75.0     70.1     60.0  
   800x600        75.0     72.2     60.3     56.2  
   640x480        75.0     72.8     59.9  
DVI-I-1 disconnected (normal left inverted right x axis y axis)
$ uname -a
Linux attic4 3.5.1-1.fc17.x86_64 #1 SMP Thu Aug 9 17:50:43 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
$ rpm -qa | grep nvid
kmod-nvidia-3.4.6-2.fc17.x86_64-304.30-1.fc17.x86_64
nvidia-settings-1.0-19.fc17.x86_64
xorg-x11-drv-nvidia-304.32-1.fc17.x86_64
nvidia-xconfig-1.0-17.fc17.x86_64
akmod-nvidia-304.32-1.fc17.x86_64
xorg-x11-drv-nvidia-libs-304.32-1.fc17.x86_64
kmod-nvidia-3.5.0-2.fc17.x86_64-304.32-1.fc17.x86_64
kmod-nvidia-3.5.1-1.fc17.x86_64-304.32-1.fc17.1.x86_64

System is AMD 64-bit with 
$ lspci |grep VGA
01:00.0 VGA compatible controller: nVidia Corporation G98 [GeForce 8400 GS] (rev a1)

Ian.

Comment 23 Ian Shields 2012-08-18 01:48:11 UTC
What else is needed to advance this bug report?

Comment 24 malak 2012-08-18 14:33:00 UTC
Thank you for responding Ian.  It constitutes what I had been hoping for.

At this point the only solution I have for this problem, besides replacing my monitor with a new(er) unit, and/or possibly the video card, and/or trying other distros (not interested), has been to not turn the monitor off.

Since exhausting everything I could think of, I have merely kept the monitor on all the time.  As long as it isn't turned off and allow the screensaver and any energy saver to turn on automatically, the screen resolution problem has not presented itself.

The problem of the screen resolution kicking down, requiring going through the screen settings screen, still exists IF both the screenlock engages and the screen is physically turned off, at "the same time".

I suspect that this issue *could* be a symptom of the difficulty of keeping backwards compatibility with increasingly ageing technology while advancing with newer technologies, although obviously I'm not certain.

Comment 25 malak 2012-08-19 00:21:27 UTC
(In reply to comment #23)
> What else is needed to advance this bug report?

I was also wondering if the bug is, as I originally filed it, of relatively low importance in the grand scheme of things (such as I mention in #24, a symptom that my screen is getting too old and the code to support it should be depracated because of difficulties or impracticalities in doing so) or if it is symptomatic of a mildly larger issue independant of the specific screen / technology in question (ie. a change in code somewhere that should not have caused this).

Comment 26 malak 2012-08-19 00:24:19 UTC
(In reply to comment #25)
> (In reply to comment #23)
> > What else is needed to advance this bug report?
> 
> I was also wondering if the bug is, as I originally filed it, of relatively
> low importance in the grand scheme of things (such as I mention in #24, a
> symptom that my screen is getting too old and the code to support it should
> be depracated because of difficulties or impracticalities in doing so) or if
> it is symptomatic of a mildly larger issue independant of the specific
> screen / technology in question (ie. a change in code somewhere that should
> not have caused this).

... or now that I think of it, whether my screen is so old that an electronic switch somewhere has worn out that causes the problem.

Comment 27 Ian Shields 2012-08-19 19:27:44 UTC
It's a bug in some component. I've only seen it over the last few weeks. According to the man page for xrandr 
If invoked without any option, it will dump the state of the  outputs, showing  the existing modes for each of them, with a '+' after the preferred mode and a '*' after the current mode.
When I run it after unlockign the screen it first switches the screen to my preferred value, then dumps the values. OTOH, if I do a screen capture fo the whole screen via Print Screen, I get a 1024x768 image. After running xrandr with no arguments it has magically switched to 1920x1080. None of this is how things are supposed to work.

Comment 28 malak 2012-08-19 20:14:00 UTC
(In reply to comment #27)
> It's a bug in some component. I've only seen it over the last few weeks.
> According to the man page for xrandr 
> If invoked without any option, it will dump the state of the  outputs,
> showing  the existing modes for each of them, with a '+' after the preferred
> mode and a '*' after the current mode.
> When I run it after unlockign the screen it first switches the screen to my
> preferred value, then dumps the values. OTOH, if I do a screen capture fo
> the whole screen via Print Screen, I get a 1024x768 image. After running
> xrandr with no arguments it has magically switched to 1920x1080. None of
> this is how things are supposed to work.

Thank you.

Previous to the current F17 install, I've used this screen with (in this order) Win98, dual boot Win2000 and Red Hat 6.1, WinXP, Fedora 5, CentOS 4.x, CentOS 5.x, Ubuntu 8.04, F9, F10, F11, F12, F14, briefly F15, and F16, continuously since I purchased the screen in June 2000.  Until F17, I've never had any screen problems.  While this clearly came across to me as a bug, I suggested the hypothetical code depracation and mythical "electronic switch" scenaries merely to be open to the possibility that I concede that the hardware is becoming physically old and could either be becoming an anachronism or actually be physically wearing out somewhere. :)

If there are any more things I can test out beyond what I was doing a month ago, please let me know.  At this point I'd be curious mostly on a level technical curiosity, since I have changed my habits to not turn the screen off, which so far seems to have averted (though not actually solved) the "problem".

Comment 29 Ian Shields 2012-08-19 23:21:51 UTC
Created attachment 605548 [details]
Xorg.0 log part during screen lock and unlock

This is the part of my Xorg.0.log that was logged during locking of the screen (timestamp 12544) and unlock (timestamp 14733). Note particularly the last line of the lock part
[ 12544.001] (II) NVIDIA(0): Setting mode "VGA-0: nvidia-auto-select @1024x768 +0+0"
This file is actually a diff between the log as recorded before I switched away from the Fedora 17 screen adn the log when I returned later and unlocked the screen.

Comment 30 Ian Shields 2012-08-19 23:29:23 UTC
I've captured the difference between an initial Xorg.0.log and the changes made durign screen lock and unlock. I've uploaded this as an attachment. Note particularly the last line of what happens at lock time.
[ 12544.001] (II) NVIDIA(0): Setting mode "VGA-0: nvidia-auto-select @1024x768 +0+0"
I suspect this decision was made while the screen was not connected (i.e. switched away by KVM). Seems like the resolution should not be changed until the screen is reconnected. Something in this processing changed in the last several weeks because the behavior I see with the wrong resolution on both the passwordk prompt and the ensuing distorted screen is relatively recent.

If you're about to shut down the screen it hardly seems to make sense to probe the resolution at shutdown time, particularly if the user has either physically shut it off already, unplugged it, or logically done so usign a KVM switch to move it to another device. You need to do that wehn the screen is re-enabled.

Comment 31 malak 2012-09-17 13:38:06 UTC
I'm wondering if anyone at Fedora will actually be looking at this bug report?

Comment 32 pugs 2012-09-24 03:12:32 UTC
I am hoping that someone will bump up the severity on this issue. It is more than just annoying, I've lost work when the screen has goofy on me.

I have four boxes on a KVM switch and the two Fedora 17 Gnome boxes will reduce resolution and sometimes I'll loose the gnome panel on top or both screens will be mirrored. Once or twice the screens have gone black and won't respond at all. The two Fedora 17 boxes have different video cards. 

The resolution only seems to change after a couple of minutes. If I switch quickly back and forth the screen is fine, but if a wait a couple of minutes the resolution has dropped.

Comment 33 pugs 2012-10-09 06:52:19 UTC
(In reply to comment #32)
Solved my issue by adding 

Option "PreferredMode" "1280x1024" 
to the /etc/X11/xorg.conf file.

Thank you Sith!!!!

Comment 34 malak 2012-10-09 11:29:54 UTC
(In reply to comment #33)
> (In reply to comment #32)
> Solved my issue by adding 
> 
> Option "PreferredMode" "1280x1024" 
> to the /etc/X11/xorg.conf file.
> 
> Thank you Sith!!!!

as mentioned in Comment 8 https://bugzilla.redhat.com/show_bug.cgi?id=831020#c8 this doesn't work for me; the system hangs during reboot.  Nonetheless I tried again by adding a /etc/X11/xorg.conf file with the line "Option "PreferredMode" "1280x1024"" but this still causes the computer to hang; since it hangs after the screen where you see the Fedora Infinity logo develop and appear, this time I had to ssh in from another machine to remove the file in order to make the machine bootable.

Comment 35 malak 2013-02-10 14:11:45 UTC
As an update, on the same F17 system, I installed the MATE desktop a couple of weeks ago, and, as completely as a 'yum groupremove "GNOME Desktop Environment"' will allow (in some cases, too much for my tastes! :) ) I removed Gnome 3.

Interestingly, this problem does not reproduce itself, and I have been happily turning off my monitor regularly and saving the otherwise trivial amount of electricity that this represents.

Comment 36 malak 2013-03-09 20:13:32 UTC
I have reverted to Gnome 3 on the same system, and the issue still exists.

Comment 37 Fedora End Of Life 2013-07-03 21:21:40 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 38 Fedora End Of Life 2013-07-31 22:22:46 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.