automatic xrandr module misconfigures monitors

Ok, so this seems to have been triggered by the change in defaults in version 2.31.91-0ubuntu3 (turn on ext. monitors).

Setting 'apps/gnome_settings_daemon/xrandr/turn_on_external_monitors_at_startup' to false for the user gdm made this bug go away in the current version. That key has been introduced with version 2.31.91-0ubuntu1: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/gnome-settings-daemon/maverick/revision/109/plugins/xrandr/gsd-xrandr-manager.c#plugins/xrandr/gsd-xrandr-manager.c

From the ways to get the value for 'config' in the method 'apply_default_boot_configuration', only 'config = make_laptop_setup (screen);' seems to work (= as soon as enabling turn_on_external_monitors_at_startup, I see the 60 Hz). 'make_clone_setup' and 'make_other_setup' will call 'gnome_rr_mode_get_freq' at some point, which will return bogus because my monitor's EDID is invalid.

$ xrandr -q
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 320 x 175, current 1280 x 1024, maximum 1280 x 1024
default connected 1280x1024+0+0 0mm x 0mm
   1280x1024 50.0* 51.0 53.0

---

Due to all the patches I'm not sure if that's an upstream bug. This should affect all users that have a monitor without EDID (got to be an old one) or invalid EDID (have seen a couple of models on the video driver section of the freedesktop bug tracker).

I'm also effected by this bug, but with quite different symptoms. I also know this is quite long so I'll try to break things up very well.

First of all the hardware involved is Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) with a Hanns-G 22" LCD. That same hardware has worked properly with all versions of Ubuntu from Hardy up through Maverick Beta. The default will normally be 1680x1050@61Hz.

I've been monitoring the daily builds more closely than usual following changes to the new ubiquity and beginning about September 16th the Live CD would result in the monitor spitting the error message "Input signal out of range". Oddly I have a fully updated Maverick installed that began with the toolchain upload May 22nd and I've not been able to reproduce this bug on it.

However I do have two additional Mavericks on this machine leftover from Beta upgrade and iso-testing, so over the weekend I booted into the one installed for iso-testing, fully updated it, and was presented with the "out-of-range" error on reboot. That's a good thing as it's much easier to fiddle with an installed OS than a Live CD or USB.

I have tried a number of things:

1) Creating a known good xorg.conf w/a default resolution of 1440x900@60Hz.

2) Editing "/etc/gdm/Init/Default" and/or "/etc/gdm/PreSession/Default" to default to 1440x900@60Hz.

Note: both 1 & 2 are options I've used for some time due to poor vision.

3) Suspecting it may be KMS related I tried two different mainline kernels - 2.6.35-02063504 & 2.6.35-02063506.

None of the above worked, but the installed "non-working" Maverick will boot if I choose Recovery Mode from the grub menu and then choose FailsafeX, however I've tried the Live CD with many options including "nomodeset" and "i915.modeset=1" which both result in the "out-of-range" error, and also "i915.modeset=1" which drops me to a TTY, and if I try startx I just get the error "Fatal server error: no screens found".

I should also mention that this i945 works OK with my old 17" CRT, and an old machine w/VIA P4M800 graphics still works OK with the 22" LCD.

Finally this AM MacUntu from the forums pointed me to this bug and sure as heck if I uncheck "turn_on_external_monitors_at_startup" in gconf booting works normally and defaults to my custom resolution of 1440x900@60Hz either upon reboot or if I restart gdm.

Oddly the working Maverick that began with the toolchain upload has "turn_on_external_monitors_at_startup" checked in gconf and it's working OK. Odd, eh?

I think I'll leave the working Maverick alone rather than try to break it, but I am going to try and get a TTY in the current daily live i386 and see if editing gconf will allow it to boot w/startx.

I'll be glad to do any testing requested or to attach any requested info, but I'm beyond clueless so please be as complete as possible in your requests.

I'd expect iso-testing for the RC to begin very soon and I'd think we need to at least address this in the release notes.

Oops, This:

"however I've tried the Live CD with many options including "nomodeset" and "i915.modeset=1" which both result in the "out-of-range" error, and also "i915.modeset=1" which drops me to a TTY, and if I try startx I just get the error "Fatal server error: no screens found"."

Should say:

however I've tried the Live CD with many options including "nomodeset" and "i915.modeset=1" which both result in the "out-of-range" error, and also "i915.modeset=0" which drops me to a TTY, and if I try startx I just get the error "Fatal server error: no screens found".

One digit could make a huge difference.

I have tried several times with todays and 9-24's Live CD's removing "quiet splash" which then drops me in a TTY, and then very carefully typing "sudo -u gdm gconftool-2 --type bool -s "/apps/gnome_settings_daemon/xrandr/turn_on_external_monitors_at_startup" false" followed by "sudo restart gdm" and/or "startx".

I always end up with "Fatal server error: no screens found". So the Live CD is just a no-go ATM for me.

I forgot, you also need to disable this option for the user ('sudo -u gdm' will only deal with the gdm login screen):

gconftool-2 --type bool -s "/apps/gnome_settings_daemon/xrandr/turn_on_external_monitors_at_startup" false

I guess the easiest way to find out if you are affected by this bug is, to install the x11-xserver-utils package and run 'xrandr -q' - normally this should list a proper mode - it doesn't in my case. You can also run 'sudo get-edid' from the read-edid package - if it fails, you'll likely hit this bug.

without that option turned on some configurations have no active screens (ie docked laptop with lid closed for example), the configuration g-s-d applies should be valid, it seems rather an xorg or xrandr bug

you can run "sudo touch /var/lib/gdm/gsd-debug-randr" and restart gdm and you will get a debug log /var/lib/gdm/gsd-debug-randr.log with details on what g-s-d is doing

Nothing new in the log. I too think that g-s-d isn't the problem but rather triggering the behavior.

Thing is, without a xorg.conf I only can chose between low/safe resolutions. With Nvidia's BLOB it's enough to add horizontal and vertical refresh rates, with Nouveau I also need to provide a modeline. Xrandr/X (or however 'gnome_rr_mode_get_freq' from gnome-desktop gets the info) seems to only rely on the monitor's EDID.

Sorry to be slow but after trying the RC iso-testing i386 Live CD and seeing the "out-of-range" error I decided to jump into upgrade testing. I had been going to upgrade a highly modified Lucid, but due to this bug I decided to spend the extra time to install and update a fresh 10.04.1, and then perform the upgrade test.

As expected upon reboot I get the same error. Before reboot I gathered this info:

lance@lance-desktop:~$ xrandr -q
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 4096 x 4096
VGA1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 297mm
   1680x1050 60.6*+ 74.9
   1600x1200 75.0 60.0
   1400x1050 74.9 60.0
   1280x1024 75.0 60.0
   1280x960 60.0
   1152x864 75.0
   1024x768 75.1 70.1 60.0
   832x624 74.6
   800x600 72.2 75.0 60.3 56.2
   640x480 72.8 75.0 66.7 60.0
   720x400 70.1
lance@lance-desktop:~$ sudo get-edid
[sudo] password for lance:
sudo: get-edid: command not found

I'm loathe to modify that OS ATM because I might be able to provide some info for the appropriate devs. Just to recap a bit:

My effected hardware is Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) with a Hanns-G 22" LCD.

I currently have a fully updated (thru yesterday) Maverick on sda1 that began with the the toolchain upload that works, another that was effected by this bug on sdb1 but it now works with the edit to gconf, and I now have a third on sda16 that's a fresh upgrade from 10.04.1 that fails.

I'll not make any modifications to the latter as it may be the best suitable to gather info from. But if requesting info please realize that you're working with a simple minded end user :^)

Just thought I should add that I currently have no router so I can't ssh the sick "box" but I should be able to access the sick OS using a chroot from the same box if that's helpful.

happens to me ion the latest .run file from Nvidia
always resets to 60 on the refresh

in var.log.xorg.o.log note last line
37888.571] (II) NVIDIA(0): Setting mode "1600x1200_60"
[ 37945.013] (II) NVIDIA(0): Setting mode "1600x1200_85+0+0"

which one is which one, I see a 60 and I see an 85??

[ 37887.802]
X.Org X Server 1.9.0
Release Date: 2010-08-20
[ 37887.802] X Protocol Version 11, Revision 0
[ 37887.802] Build Operating System: Linux 2.6.24-27-server i686 Ubuntu
[ 37887.802] Current Operating System: Linux scott-desktop 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010 i686
[ 37887.802] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.35-22-generic root=UUID=4923760a-6e34-4678-b0ab-d06b151a2998 ro quiet splash
[ 37887.802] Build Date: 16 September 2010 05:39:22PM
[ 37887.802] xorg-server 2:1.9.0-0ubuntu7 (For technical support please see http://www.ubuntu.com/support)
[ 37887.802] Current version of pixman: 0.18.4
[ 37887.802] Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.
[ 37887.802] Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 37887.803] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Sep 28 17:33:53 2010
[ 37887.803] (==) Using config file: "/etc/X11/xorg.conf"
[ 37887.803] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 37887.803] (==) ServerLayout "Layout0"
[ 37887.803] (**) |-->Screen "Screen0" (0)
[ 37887.803] (**) | |-->Monitor "Monitor0"
[ 37887.803] (**) | |-->Device "Device0"
[ 37887.803] (**) |-->Input Device "Keyboard0"
[ 37887.803] (**) |-->Input Device "Mouse0"
[ 37887.803] (**) Option "Xinerama" "0"
[ 37887.803] (==) Automatically adding devices
[ 37887.803] (==) Automatically enabling devices
[ 37887.803] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 37887.803] Entry deleted from font path.
[ 37887.803] (==) FontPath set to:
 /usr/share/fonts/X11/misc,
 /usr/share/fonts/X11/100dpi/:unscaled,
 /usr/share/fonts/X11/75dpi/:unscaled,
 /usr/share/fonts/X11/Type1,
 /usr/share/fonts/X11/100dpi,
 /usr/share/fonts/X11/75dpi,
 /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
 built-ins
[ 37887.803] (==) ModulePath set to "/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"
[ 37887.803] (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[ 37887.803] (WW) Disabling Keyboard0
[ 37887.803] (WW) Disabling Mouse0
[ 37887.803] (II) Loader magic: 0x81f8e00
[ 37887.803] (II) Module ABI versions:
[ 37887.803] X.Org ANSI C Emulation: 0.4
[ 37887.803] X.Org Video Driver: 8.0
[ 37887.803] X.Org XInput driver : 11.0
[ 37887.803] X.Org Server Extension : 4.0
[ 37887.804] (--) PCI:*(0:1:0:0) 10de:06e4:196e:05cc rev 161, Mem @ 0xfd000000/16777216, 0xd0000000/268435456, 0xfa000000/33554432, I/O @ 0x0000bc00/128, BIOS @ 0x????????/131072
[ 37887.804] (--) PCI: (0:5:1:0) 4444:0016:9005:0092 rev 1, Mem @ 0xf4000000/67108864
[ 37887.804] (II) Open ACPI successful (/var/run/acpid.socket)
[ 37887.804] (II) LoadModule: "extmod"
[ 37887.805] (II) Loa...

Is there anyway I could determine what the default settings are once I've hit the "wall" in the live CD?

I fiddled around in that "working" Maverick and rolled back all old kernels:

Start-Date: 2010-09-28 15:55:18
Commandline: /usr/sbin/synaptic
Remove: linux-headers-2.6.35-14:i386 (2.6.35-14.20), linux-headers-2.6.35-14-generic:i386 (2.6.35-14.20), linux-image-2.6.35-14-generic:i386 (2.6.35-14.20)
End-Date: 2010-09-28 15:56:21

Start-Date: 2010-09-28 16:19:17
Commandline: apt-get autoremove
Remove: linux-headers-2.6.35-21-generic:i386 (2.6.35-21.31), linux-headers-2.6.35-16-generic:i386 (2.6.35-16.22), openoffice.org-java-common:i386 (3.2.1-6ubuntu2), linux-headers-2.6.35-15:i386 (2.6.35-15.21), linux-headers-2.6.35-20:i386 (2.6.35-20.29), linux-headers-2.6.35-21:i386 (2.6.35-21.31), linux-headers-2.6.35-16:i386 (2.6.35-16.22), libx264-85:i386 (0.85.1448+git1a6d32-4), ufraw-batch:i386 (0.16-3), libmythes-1.2-0:i386 (1.2.0-4), libpoppler6:i386 (0.14.2.is.0.14.1-0ubuntu1), libappindicator0.1-cil:i386 (0.2.9-0ubuntu1), libtextcat-data-utf8:i386 (2.2-4), linux-headers-2.6.35-15-generic:i386 (2.6.35-15.21), linux-headers-2.6.35-20-generic:i386 (2.6.35-20.29), libmodplug0c2:i386 (0.8.8-2)
End-Date: 2010-09-28 16:19:56

Start-Date: 2010-09-28 16:28:49
Commandline: /usr/sbin/synaptic
Remove: linux-image-2.6.35-15-generic:i386 (2.6.35-15.21)
End-Date: 2010-09-28 16:29:33

Start-Date: 2010-09-28 16:30:23
Commandline: /usr/sbin/synaptic
Remove: linux-image-2.6.35-16-generic:i386 (2.6.35-16.22)
End-Date: 2010-09-28 16:31:05

Start-Date: 2010-09-28 16:34:04
Commandline: /usr/sbin/synaptic
Remove: linux-headers-2.6.35-19-generic:i386 (2.6.35-19.28), linux-headers-2.6.35-17:i386 (2.6.35-17.23), linux-headers-2.6.35-19:i386 (2.6.35-19.28), linux-headers-2.6.35-17-generic:i386 (2.6.35-17.23), linux-image-2.6.35-19-generic:i386 (2.6.35-19.28), linux-image-2.6.35-17-generic:i386 (2.6.35-17.23)
End-Date: 2010-09-28 16:35:46

Start-Date: 2010-09-28 16:51:59
Commandline: /usr/sbin/synaptic
Remove: linux-image-2.6.35-20-generic:i386 (2.6.35-20.29)
End-Date: 2010-09-28 16:52:42

Start-Date: 2010-09-28 16:58:34
Commandline: /usr/sbin/synaptic
Remove: linux-image-2.6.35-21-generic:i386 (2.6.35-21.31)
End-Date: 2010-09-28 16:59:21

And it still works just fine, so something that "stuck" from that original toolchain upload and the newer installs/upgrades has absolutely changed.

I'm just stuck and can't really test the new changes to ubiquity until we get past this.

In bug 643118 the consequences are more serious, because g-s-d picks an unsupported mode instead of the preferred one, and the display is messed up. I understand the driver should not suggest broken modes, but what is g-s-d trying to do anyway? Should it not just keep the preferred mode that the X server set up?

First of all, apologies in advance for subscribing Steve Langasek w/o permission but I have concerns regarding this NOT being included in the release notes for the RC. Is it ever allowable to edit the release notes?

You'll notice that I also marked both #643118 and #649534 as duplicates of this bug. I'm reasonably sure that's correct, but maybe this bug should be renamed something like, "Improper monitor settings result from ..................".

I dunno???????????????

Remember we're talking first impressions here ;^)

We had a discussion on IRC #ubuntu-x right now, and the consensus was that by default, g-s-d should not turn external screens on or off, but leave it the way the X server has set it up. If the user later configures things on/off these settings will be applied next time.

The issues in this bug reports reveal some bugs in g-s-d and xorg/drm, but they should be fixed independently of this turn_on_external_monitors_at_startup question.

Note also that before bug 646076 gets fixed, the user can not make any system-wide screen settings.

The recent g-s-d change also made bug 641525, bug 645377 and bug 646474 appear, but I am not marking them as duplicates since I believe xorg is generating wrong modes in these cases which should be fixed separately. g-s-d is only at fault for overruling the X server and selecting the bad modes.

I filed a new one:

https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/654660

Not to be a pain in the rear but I didn't see an exact parallel to what I've experienced, and I thought it couldn't hurt to gather info.

I'm just trying to show that this effects a lot of different hardware and I do see this as a true "show-stopper"!

Are we going to release Maverick final this way?

If others are unable to even boot the Live image, as I was, how many will decide that Ubuntu just doesn't work for them?

While repeating what I said there I was able to finally boot the Live CD this way:

" pressing F6, then ESC, then typing "text" (w/o the quotes), and then typing:

gconftool-2 --type bool -s "/apps/gnome_settings_daemon/xrandr/turn_on_external_monitors_at_startup" false

Then just typing "startx" (again w/o the quotes) I got a desktop with the expected modes".

I just don't see how we can release like this :^(

IMHO Maverick is otherwise an exemplary release. I just want to know how we're going to handle this for the final release.

Subscribing ubuntu-release instead of myself; Erick, I'm no longer the Ubuntu release manager, so please use the role account instead for issues such as this.

> I'm just trying to show that this effects a lot of different hardware and I do see this as a true "show-stopper"!

How do you know that? How much hardware did you try? How do you know if doesn't do better job on some configurations and breaks some others?

What solution do you suggest? Changing the key value just workaround the issue on some setups to trade with other broken ones. The safe way would probably to go back to what lucid was doing though

the gsd-xrandr-manager.c code has

" if (!apply_stored_configuration_at_startup (manager, GDK_CURRENT_TIME)) /* we don't have a real timestamp at startup anyway */
                if (!apply_default_configuration_from_file (manager, GDK_CURRENT_TIME))
                        apply_default_boot_configuration (manager, GDK_CURRENT_TIME);"

the idea would be do an extra gconf key to only do the third call if the key is set

upstream comment from an IRC discussion about the issue

"<federico1> I'll happily include a patch that makes the boot-time configuration conditional
 <federico1> with some use_boot_time_configuration key or something reasonably-named
 <federico1> use_boot_time_configuration or use_xorg_configuration (the reverse)?
<federico1> I'd like it to be obvious from the key name that it's an either/or thing
<federico1> tormod: I'm leaning toward a do-not-touch kind of name now, with False by default - if you need to make it True, it means that you have a special case due to your X setup anyway"

one part of the issue could also be https://bugzilla.gnome.org/show_bug.cgi?id=572502
"gnome-display-properties should pick the preferred xrandr mode"

which is bug #314057 on launchpad

bug bug #638680 seems similar as well

Feel free to rename the bug title as it doesn't seem to fit anymore. :-)

No doubt there are many related bugs, some may be duplicates, others not. I'm certainly not sure.

But we're a few days from iso-testing, and one week from final. Do we actually plan to release with this bug?

Should we not at least have some coherent reference in the release notes?

If we release as-is I expect we'll regard the big bru-ha-ha over wallpaper as very minor in comparison.

Color me sad and confused.

Just confirming, for me the bug manifests differently: I have a 1280x1024 external monitor, and X starts in that mode (with a little help in xorg.conf). However, g-s-d tries to be too clever and switches it to 1024x768, presumably because xrandr thinks that this is the highest common resolution with my internal monitor (1280x800). So I now get two unnecessary modeswitches during boot (my desktop session of course switches it back to 1280x1024).

So this is indeed a regression.

We can't set turn_on_external_monitors_at_startup to True again. We already had that, and it causes external monitors to get powered off. This means that you can't use a docked laptop with an external monitor any more, since we don't have any cleverness to detect whether the lid is closed at startup and the internal screen should be powered off (this is because of too many buggy BIOSes, not because we couldn't implement it).

So it seems that both settings cause problems. Can't we just entirely disable this xrandr messing by default? On normal single-screen settings, KMS and X should already care about the resolution, and any mode change that we introduce will not only be prone to misconfigure your screens, but also introduce major startup latencies and thus slow down boot.

Bumping to high, since this breaks a lot of people's monitor settings. The upstream change was introduced after feature freeze, so it appeared quite late.

Seb and I discussed this in #ubuntu-desktop. We will add a gconf key to enable the automatic xrandr configuration (if there are no configuration files), and set that to false in Ubuntu. That patch will be acceptable for upstream, and it's a very safe solution, in the sense that it is easy to test, relatively unintrusive, and will change back behaviour to what we had in all earlier releases and Maverick Beta. With my release team hat on, I think this is safe enough to push into maverick final still; this affects the live system, so an SRU would be a lot less useful.

http://bazaar.launchpad.net/~ubuntu-desktop/gnome-settings-daemon/ubuntu/revision/114 adds the patch for introducing the new gconf key. I also sent this patch upstream.

http://bazaar.launchpad.net/~ubuntu-desktop/gnome-settings-daemon/ubuntu/revision/115 sets this new gconf key to true to disable the new xrandr-auto-configuration behaviour. This gets us back to what we had in Maverick beta and all previous releases.

Those commits seem fine to me, thanks pitti for working on that!

Fixed package uploaded for release team consideration.

This bug was fixed in the package gnome-settings-daemon - 2.32.0-0ubuntu2

---------------
gnome-settings-daemon (2.32.0-0ubuntu2) maverick; urgency=low

  * Add 09_gconfify_default_xrandr.patch: In a lot of situations it is
    undesirable to have g-s-d change the XRandR settings, because it overrides
    X.org customizations, leads to unnecessary mode switches, or increases
    boot time. Add a gconf key "use_xorg_monitor_settings" to disable
    apply_default_boot_configuration(), in which case the XRandR configuration
    will not be touched unless there is a global or per-user configuration
    file.
  * debian/gnome-settings-daemon.gconf-defaults: Set use_xorg_monitor_settings
    to true. This disables g-s-d's rather new default XRandR configuration and
    reverts back to what we had up to Maverick beta. This avoids a lot of
    monitor misconfigurations. (LP: #640807)
 -- Martin Pitt <email address hidden> Tue, 05 Oct 2010 12:02:35 +0200

Hi

I have applied the above update to no effect i am still stuck with one screen resolution?

The system just tells me i have one (should be two) "UNKNOWN" monitor, both screens working at this res.
Worked on beta but not on RC?

Should i need to do anything to reset/configure X?

andy@ubuntu:~$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

andy@ubuntu:~$ xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1024 x 768, current 1024 x 768, maximum 1024 x 768
default connected 1024x768+0+0 0mm x 0mm
   1024x768 0.0*

Yes, thank you it is fixed.
Did and update
Rebooted and came up with refresh at 85

Just tested the October 6th i386 daily and I can verify that this is fixed, many thanks to all involved.

I've not been using the daily CDs, but I not sure whether this isn't fixed, or whether I'm afflicted by bug #654660 as well. So to confirm, using gconftool to set /apps/gnome_settings_daemon/xrandr/use_xorg_monitor_settings to true like so:

sudo -u gdm gconftool --type bool --set /apps/gnome_settings_daemon/xrandr/use_xorg_monitor_settings true

Will make g-s-d use xorg details to set up the screens rather than the newer methods employed by g-s-d?

Hello Darren,

Darren Adams [2010-10-06 23:37 -0000]:
> /apps/gnome_settings_daemon/xrandr/use_xorg_monitor_settings to true

(Which we do by default now)

> Will make g-s-d use xorg details to set up the screens rather than the
> newer methods employed by g-s-d?

Yes, unless you have a ~/.config/monitors.xml (i. e. manual settings).
If there is no config file, g-s-d now won't touch the xrandr settings
at all.
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)