Screennresolution applet no longer asks for confirmation of new resolution settings

[junior]

In Hardy you got asked if you wanted to keep new settings. So if all displays went black, you could hit escape and get back. This was very useful with the buggy xrandr, cause my displays often get black, and now killing x is the only solution

[James Westby (james-w)]

Hi,

Thanks for your bug report.

We should decide whether to resurrect that patch.

Thanks,

James

[Luke Faraone (lfaraone)]

James,

I think it would be a very good idea, I just experienced this problem.
(it might have been more than that, as the machine wouldn't restart X or respond to RSEIUB)

In general, it is a good idea IMHO.

Luke

[Jessie Lawrence (nightwolf177-deactivatedaccount)]

i confirm this bug.

of course it would be a good idea! it asked you before, and so does every other operating system.

[Miguel Diago (mdm)]

Please add a confirmation message or some mechanism to let the user revert a selected resolution. A few minutes ago I felt curious about how my desktop would look at 400*300 px and had a hard time to find out how to get back to 1440*900, because this configuration had rendered it unusable. Luckily, the "recovery mode" at the bootloader did the trick and restored my desktop :)

If there just had been a confirmation window nothing so stupid would have happened... :P

[Damian Melniczuk (quantumdamage)]

You need just to edit ~/.config/monitors.xml

[Eric Forgeot (eforgeot)]

it's a very stupid default behavior. I've experienced this on archlinux too, so it's probably a gnome upstream modification.
My screen doesn't support some default resolution in 800x600, so switching to it will make the screen black, without confirmation.

[Adam Buchbinder (adam-buchbinder)]

Damian, yes, you can delete ~/.config/monitors.xml, but that's not easily discoverable. A change made by one interface (the Screen Resolution app) is not revertible via that same interface--not even by logging in in failsafe mode (see bug 305604). By any definition, the user interface is broken. There is no conceivable reason for this kind of configuration tool to allow you to easily and accidentally make your session unusable.

Furthermore, if users seem to keep running into the same problem, the fault most likely doesn't lie with the users, but with the system that makes the failure-path the most simple and obvious one. See "forcing functions" for some user-interface research on the concept.

Also, there are some possibly-relevant patches in bug 197673; are those helpful?

[Adam Buchbinder (adam-buchbinder)]

Also, please note that bug 197673 was triaged as "High"-priority. Unless there's some reason that this iteration of the same problem is different, perhaps the priority should be bumped up on this bug?

[Luke Faraone (lfaraone)]

The fix was first available in 1:2.22.0-0ubuntu4 in file debian/patches/110_cc-randr12-revert-dialog.patch, subscribing Bryce Harrington, the author of the patch.

[Bryce Harrington (bryce)]

Sorry, I don't know what the reasoning was for dropping the patch for Intrepid.

[Jim (JR) Harris (jimrh)]

Ref: Bug 316961 (duplicate of this)

I experienced the exact same issue, and (not finding THIS bug), wrote it up yet again.

Essentially my steps to reproduce involved selecting an invalid display resolution and accepting it.

The result (as of 8.10) is a functionally "bricked" box. Even though I am not a raw newbie, I researched and jumped through hoops for several hours before I returned my system to a usable state. I eventually got it back by passing " -- bestResolution" as a kernel parameter through GRUB. (the recovery menu was ZERO help to me) and even with that, it originally got stuck in the unusable resolution first - then when I tried to kill via CTL-ALT-DEL, it then (eventually) reverted to a 800x600 - 60hz resolution that I could save and then reboot into to put it back the way it was before.

And yes, I agree, a bug like this that has the potential for "bricking" (rendering un-usable), a customer's system without a clear path to recovery should be ranked as something higher than a snooze-fest. :-) (I'd be tempted to call it release-critical)

I made some recommendations within my own bug report which I will transcribe here for everyone's benefit:

Suggested changes to solve the bug's problem:

1. Resolve the lack of confirmation issue noted above.

2. Provide a specific entry in the recovery menu that will reset the display resolution to something sane.

3. Provide a specific entry within the default entries created within GRUB that allows a reboot into a sane resolution. (Note that simply passing " -- bestResolution" may not be the best answer.)

I realize that this is "three things" - but to ensure the best possible user experience, I believe that all three of these things should be completed under the scope of this bug.

What say ye?

Jim

[Adam Buchbinder (adam-buchbinder)]

Jim: grub doesn't have any control over what X does; it doesn't make much sense to have options there for controlling X. Also, as of Gutsy, we're supposed to have an X configuration that will, at the very least, start up properly. ( https://blueprints.launchpad.net/ubuntu/+spec/bullet-proof-x ) As for a failsafe mode, there's a separate bug open for having X's failsafe session actually use a failsafe resolution instead of the possibly-broken one in ~/.config/monitors.xml; it's bug 305604.

Any changes to the way grub works need to be filed as bugs affecting grub; while it may look similar to the user, it affects a very different part of the system from the one this bug refers to.

[Luke Faraone (lfaraone)]

On Wed, Jan 14, 2009 at 8:03 PM, Jim (JR) Harris <email address hidden> wrote:

> 3. Provide a specific entry within the default entries created within
> GRUB that allows a reboot into a sane resolution. (Note that simply
> passing " -- bestResolution" may not be the best answer.)

Boot into "recovery mode" and choose "xfix". Problem solved.

--
Luke Faraone
http://luke.faraone.cc

[Jim (JR) Harris (jimrh)]

Luke,

I hate to break the bad news to you - but (at least in Intrepid), that's NOT true.

I set my screen resolution/refresh rate to something higher than my monitor could display - and I got a blank screen. I had to actually *KILL POWER* to get the beast to reboot, and when I booted into recovery mode and chose "xfix" - it did me absolutely 100% of zero good at all. When the system came up - still no (usable) display.

The ONLY thing that worked for me was to edit the "kernel=" line and add " -- bestResolution" to the end of the line. That restored me to a bogus - but viewable - resolution. I was then able to open the screen rez applet (which would ONLY allow me to "choose" the abysmal resolution I had), saved, and rebooted. I then had the same abysmal resolution and refresh rate, which I could then change (and save) into something more reasonable.

I don't know what "xfix" is *supposed* to do, but it darn sure didn't fix MY "x". . . . .

What say ye?

Jim

[Jim (JR) Harris (jimrh)]

p.s. . . . .

I actually tried "xfix" several times in a row to see if that would help. No cigar....

[Luke Faraone (lfaraone)]

On Tue, Jan 27, 2009 at 5:17 PM, Jim (JR) Harris <email address hidden> wrote:

> I don't know what "xfix" is *supposed* to do, but it darn sure didn't
> fix MY "x". . . . .
>
> What say ye?

File a separate bug against xfix.

--
Luke Faraone
http://luke.faraone.cc

[Sebastien Bacher (seb128)]

the bug has been fixed upstream now and the fix will be in jaunty

[Duncan Lithgow (duncan-lithgow)]

How can I add Jaunty to this bug to record that this is not fixed in Jaunty?

[Adam Buchbinder (adam-buchbinder)]

Duncan, the status is tracked in Jaunty; "Fix Committed" means that the fix will be in the next version of the package released for Jaunty. When the package is actually released, the status will be changed to "Fix Released".

[Sebastien Bacher (seb128)]

the bug is fixed in jaunty now

[nullrend (nullrend)]

Bitten by this bug just now. For all those who are still using 8.10, the easiest solution is to issue the following command from a terminal.

$ rm ~/.config/monitors.xml

This way GNOME will rebuild the file using Xorg defaults and the session should start up properly.

In my own case I had to issue the command from a failsafe X session, as the alternate terminals (ctrl+alt+F2, etc) did not work on my system.