Bug 20361

Created attachment 23376 [details]
dmesg output

Created attachment 23377 [details]
X configuration

Is the monitor attached at X startup?

Yes, it is. I'm not trying to hotplug anything yet.

My guess is that the arbitrary choice is made that your lvds size is the
starting size. Which results in a framebuffer which cannot support larger
resolutions.

You'll have to add a virtual line (grep
http://www.thinkwiki.org/wiki/Xorg_RandR_1.2).

Adding virtual did not help. I'll attach the new xorg.conf in case I did it wrong.

Created attachment 23378 [details]
X configuration with virtual keyword

Tried manually setting the desired resolution (if it isn't doing it automatically in the first place it won't start magically doing something else)?

Yep, works great after
[ak@localhost SPECS]$ xrandr --output DVI-I-0 --mode 1920x1200

except I'm seeing slight pixel corruption, but that'd be a separate bug.

Anyway, this doesn't explain the non-sensible default choices - I'm no xrandr guru, but it's supposed to just work, no?

Default choices became better at some point, not sure if xserver 1.5.3 already had them. Dynamic resizing of framebuffer will happen when we have a good memory manager.

As Maarten says, this is an xserver feature.  See http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/modes/xf86Crtc.c?h=server-1.5-branch and search for "Using exact sizes for initial modes" as appears in your log just before it picks 1024x768 for both heads.

Looking at the xf86TargetPreferred function (in the same file) that selects this behaviour, it tries to pick the largest preferred mode (an attribute specified in the screen's EDID) where the mode is available on all screens, hence you get 1024x768 as the laptop screen's preferred mode.  This behaviour appears mostly unchanged in master ( http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/modes/xf86Crtc.c ), so if you want it fixed you'll have to file an xserver bug, but I suspect they'd argue it's reasonable and intended behaviour.

Alternatively, before using this method of mode selection, the xserver allows consideration of user-specified preferences, so you could configure it in your xorg.conf (see http://wiki.debian.org/XStrikeForce/HowToRandR12 for details).  Also any DM you use may have a control panel to set this up for you when X starts.

I didn't mention this (thought it'd be obvious) but the notebook lid is closed. I think it's reasonable to detect this and not take the internal screen into consideration at all, and just set the external screen to its native resolution. Could it be that the driver somehow incorrectly assumes the internal screen is visible/enabled?

As far as i'm aware we don't know when a lid is open or closed, so we assume it's always on.

The lid status is very easy to find out though, for example from hal:

udi = '/org/freedesktop/Hal/devices/pmu_lid'
  button.has_state = true  (bool)
  button.state.value = true  (bool)
  button.type = 'lid'  (string)
  info.addons = {'hald-addon-pmu'} (string list)
  info.capabilities = {'button'} (string list)
  info.category = 'button'  (string)
  info.parent = '/org/freedesktop/Hal/devices/computer'  (string)
  info.product = 'Lid Switch'  (string)
  info.udi = '/org/freedesktop/Hal/devices/pmu_lid'  (string)
  linux.hotplug_type = 6  (0x6)  (int)
  linux.pmu_path = '/proc/pmu/info'  (string)
  linux.pmu_type = 2  (0x2)  (int)

Does X track the lid in any way?

(In reply to comment #14)
> Does X track the lid in any way?

I don't believe so.

So seems like correctly supporting all scenarios is a distribution's job?

Nouveau is the default driver in upcoming Fedora, so I should probably file this issue with them, if they haven't made the correct tweaks yet. 

It appears that this bug report has laid dormant for quite a while. Sorry we haven't gotten to it. Since we fix bugs all the time, chances are pretty good that your issue has been fixed with the latest software. Please give it a shot. (Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git versions.) If upgrading to the latest isn't an option for you, your distro's bugzilla is probably the right destination for your bug report.

In an effort to clean up our bug list, we're pre-emptively closing all bugs that haven't seen updates since 2011. If the original issue remains, please make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/ for what we need to see, and re-open this one.

Thanks,

The Nouveau Team