[g45] Wishlist: Use native resolution of both monitors by default for login screen in dual-head setup

[Kai Jauch]

Binary package hint: xorg

I'm using a Dell Latitude E6400 (Intel 4500MHD) with a docking station. When booting up while docked, the external monitor is enabled but using the wrong resolution. When booting undocked and then docking the laptop, the correct resolution for the external monitor cannot be set.
LVDS is the internal display, HDMI-1 is the dvi-output of the docking station.

Using Ubuntu 8.10 beta (updated it today) with xorg 1:7.4~5ubuntu1.

Expected behaviour:
- Boot the laptop while docked, lid is closed
- External monitor is enabled using its native resolution (1600x1200)
- Internal display is disabled

Actual behaviour:
- Boot the laptop while docked, lid is closed
- External monitor is enabled using the internal display's native resolution (1440x900)
- Internal display is enabled

Expected behaviour:
- Boot the laptop while not docked, lid open
- Internal display is enabled
- Close lid, dock the laptop
- External monitor is enabled using its native resolution (1600x1200), internal display is disabled

Actual behaviour:
- Boot the laptop while not docked, lid open
- Internal display is enabled
- Close lid, dock the laptop
- External monitor is not being enabled

So there are two problems:
- When docking/undocking the monitors are not automatically enabled/disabled
- The wrong resolution is set for the external monitor when booting docked

[Kai Jauch (kaijauch)]

Update: Now the internal display is correctly disabled and the external display is set to its correct native resolution when gnome has started up (docked boot, haven't tried an undocked boot). The login screen still exhibits the original wrong behaviour, but this is far better than before.

[Bryce Harrington (bryce)]

[This is an automatic notice.]

We'd like to forward your bug upstream, however upstream requires
that you first test it against their newer driver code.

To save you the effort of building the driver from source, we've built
packages for the driver and its new dependencies.

So you have a couple options:

 1. Download and test .debs for intrepid, from:
     https://edge.launchpad.net/~intel-gfx-testing/+archive

 -or-

 2. Download and test the Jaunty alpha-2 (or newer) Live CD,
     (which includes a beta of the new xserver 1.6 as well).
     See http://cdimage.ubuntu.com/releases/9.04/ for ISOs

Thanks ahead of time! You can simply reply to this email to report your
findings.

P.S., if you wish to forward your bug upstream yourself, please follow
these directions to do so:
  http://intellinuxgraphics.org/how_to_report_bug.html

[Craig Holyoak (craigholyoak)]

Preface:
I have a Latitude E4300, and the resolution of the built-in screen is 1280x800. I have attached my xorg.conf, as I have found manually setting the virtual screen size to help, otherwise docking after booting undocked, I could not set the screen size greater than 1280x800.

Following are the my experiences of Kai's scenarios with the latest test .debs for intrepid (xserver-xorg-video-intel - 2:2.5.1-1ubuntu5~intrepid):

Expected behaviour:
- Boot the laptop while docked, lid is closed
- External monitor is enabled using its native resolution (1680x1050)
- Internal display is disabled

Actual behaviour:
- Boot the laptop while docked, lid is closed
- External monitor is enabled, resolution 1024x768
- Internal display is enabled, resolution 1024x768
- Run `xrandr --output LVDS --auto --output HDMI-1 --auto`
- External monitor is enabled, resolution 1680x1050
- Internal display is enabled, resolution 1280x800

Expected behaviour:
- Boot the laptop while not docked, lid open
- Internal display is enabled, resolution 1280x800
- Close lid, dock the laptop
- External monitor is enabled using its native resolution (1680x1050), internal display is disabled

Actual behaviour:
- Boot the laptop while not docked, lid open
- Internal display is enabled, resolution 1280x800
- Close lid, dock the laptop
- External monitor is not being enabled, its native resolution is not listed by xrandr
- Run `xrandr --output LVDS --auto --output HDMI-1 --auto`
- External monitor is enabled, resolution 1680x1050
- Internal display is enabled, resolution 1280x800

So there are three problems:
- When docking/undocking the monitors are not automatically enabled/disabled
- The native resolution of the external monitor is not being listed when docking after an undocked boot
- The wrong resolution is set for both monitors when booting docked, however, running `xrandr --output LVDS --auto --output HDMI-1 --auto` sets both resolutions correctly, although LVDS is still 'enabled' when it is closed.

[Bryce Harrington (bryce)]

Kai, since you're the original reporter, do you confirm Craig's findings?
If so, this should probably go upstream.

[Kai Jauch (kaijauch)]

I just installed xserver-xorg-video-intel 2:2.5.1-1ubuntu5~intrepid and can confirm Craig's findings. Attaching logs for docked/undocked boot.
One thing changed though: After an undocked boot, the correct resolutions for the external monitor are now being detected and listed by xrandr after docking. The external monitor isn't being enabled in the GDM login, but gnome-settings-manager or whatever sets the resolutions in gnome after login can now disable the internal display and enable the external monitor with the right resolution.

[Bryce Harrington (bryce)]

Hmm, next I'd like to forward this issue upstream, but first it must be retested on latest Jaunty to make sure the issue still happens there with the latest code. ISO images are available at http://cdimages.ubuntu.com/releases/jaunty/. If you can reproduce it in the LiveCD environment, you shouldn't need to modify your installed system. Also please attach a fresh Xorg.0.log from this testing.

[Kai Jauch (kaijauch)]

I just tried the Alpha 5 LiveCD.

- Booted docked with closed lid
- Internal and external display are enabled when X comes up (and although the lid is closed, the backlight of the internal display stays on, but I guess that's another bug)
- Both are automatically configured to run at 1152x864 (that's not right for either of the displays)

Changing the resolution via System -> Preferences -> Screen Resolution does not work correctly. I can set the right resolution for the external display and disable the internal one, but that's not how it should look.. (see screenshot)

Doing it via xrandr works:
xrandr --output LVDS --auto
xrandr --output HDMI-1 --off
xrandr --output HDMI-1 --auto
xrandr --output LVDS --off

Attaching Xorg.0.log and output of xrandr from after boot, after setting the resolution using the GUI and after setting it via xrandr.

[Bryce Harrington (bryce)]

[This is an automatic notification.]

A new major version of the -intel driver is now available in Karmic.

This version includes a major reworking of the acceleration
architecture, which resolves a huge number of issues. We do not know
whether it resolves the issue you reported.

Would you mind testing Karmic Alpha-2 and seeing if it is still a
problem? CD ISO images are available here:

  http://cdimages.ubuntu.com/releases/karmic/

If the issue can still be reproduced on karmic, please report here with
your findings, and attach a fresh Xorg.0.log from your test, and we will
be able to forward the bug upstream.

Otherwise, if the bug no longer exists in Karmic, let us know that as
well.

In the off chance you encounter different bugs while attempting to test
Karmic, please report those as new bug reports.

[Bryce Harrington (bryce)]

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

It seems likely to me this bug is gone; the -intel driver has improved immensely in Karmic and a lot of bugs are being reported as no longer present. So hopefully that's the case here too.

[Kai Jauch (kaijauch)]

Sorry that it took so long for me to respond.
I tested it with xserver-xorg-video-intel 2:2.8.0-0ubuntu1 and linux-image-2.6.31-4-generic 2.6.31-4.23 and observed the following behaviour:

Booting docked with DVI1 attached, lid closed/open (doesn't make a difference):
- If lid is closed, only DVI1 is enabled by BIOS, LVDS1 disabled
- KMS enables both outputs, DVI1 at 1600x1200, LVDS1 at 1440x900 (both are the native resolutions for the respective displays). Usplash centered on LVDS1, top left corner on DVI1 (that's fine)
- GDM starts, LVDS1 and DVI1 are set to 1152x864

Booting undocked with nothing attached:
- KMS sets LVDS1 to 1440x900
- GDM uses the resolution set via KMS

To summarize:
The resolutions set by KMS are right in all cases, GDM sets a common resolution for all connected displays (1152x864).

[Bryce Harrington (bryce)]

> The resolutions set by KMS are right in all cases, GDM sets a common resolution for all connected displays (1152x864).

Am I understanding your response correctly that the original problem (incorrect resolution when docked) is now being set right? If I've misunderstood, feel free to reopen the bug and explain the remaining problem more clearly.

[Kai Jauch (kaijauch)]

No, the problem still remains.

KMS detects and sets the "preferred" resolutions for each device correctly (1600x1200 on DVI1, 1440x900 on LVDS1). When X starts up, the resolutions set by KMS IMHO should be kept, but aren't. X sets both displays to the highest common resolution, which is 1152x864.
Though you can see what you're doing on both displays this way, it defeats the purpose of KMS (set resolutions as early as possible and use them when X is starting) and adds unnecessary flickering and delay to the boot process (when X resets both displays to a common resolution). Using another resolution than the preferred one doesn't look that good on a TFT, either. If the lid is closed, there isn't even a point in limiting the resolution to 1152x864 as LVDS1 should then simply be disabled. The only enabled output should then be DVI1 at 1600x1200, which could be fully used.

In my opinion it would be best if the resolutions set by KMS are kept by X and the usable area on both displays should be determined by the display with the lower resolution (1440x900 fits into 1600x1200), much like it is already happening during boot with usplash. If the lid is closed during startup, there is no point in enabling LVDS1 and limiting the usable area as I can't see anything on there as long as the lid is closed.

Those are the scenarios as I think they should be (but aren't):

1. Booting with LVDS1 and DVI1 attached, lid open:
- KMS sets LVDS1 to 1440x900, DVI1 to 1600x1200
- X starts up and restricts the usable area to 1440x900, but doesn't reset the resolutions

2a. Booting with LVDS1 and DVI1 attached, lid closed:
- KMS sets LVDS1 to 1440x900, DVI1 to 1600x1200
- X starts up and disables LVDS1, leaving DVI1 fully usable

  OR (better):

2b. Booting with LVDS1 and DVI1 attached, lid closed:
- KMS sets DVI1 to 1600x1200, LVDS1 disabled
- X starts up and uses the only enabled output: DVI1

I attached a little ASCII drawing which hopefully explains what I mean by "restricting the usable area".

If you need any more information, please let me know.

[Geir Ove Myhr (gomyhr)]

Thank you for explaining in detail how you expect the display to behave when using dual head. I agree that the behaviour you describe with using native resolution and limiting the usable area is preferable to the current one. Actually this is more or less what happened for Hardy (you may fire up a LiveCD with that to see how it works on your system). It changed to the current behaviour for Intrepid. I don't know which part of xorg is responsible for this or what the rationale for the change was. See http://launchpadlibrarian.net/17844487/importdump.jpg (from bug 273306) for a screenshot of how the login screen looked back then. The desktop would look like this in mirror mode: http://launchpadlibrarian.net/12354400/screen.png .

That the lid status is not taken into account is a separate issue, and is one of the known issues listed at http://intellinuxgraphics.org/2009Q2.html

[Geir Ove Myhr (gomyhr)]

The upstream bug report for the lid issue is https://bugs.freedesktop.org/show_bug.cgi?id=11455 . From what I remember the reason that this is not trivial to fix is that the methods they have used to detect the lid status is unreliable on some computers. This could result in the internal LVDS display being disabled even when it shouldn't be.

Since the lid issue is being worked on upstream already, I suggest we focus on the issue that the resolution is set to the lowest common denominator (and sometimes even lower, see bug 404919) here. That is why I have changed the title of this bug report and set the priority to Wishlist; this is more likely a feature that we want to change than a real bug.

[Geir Ove Myhr (gomyhr)]

I have posted to the ubuntu-x mailing list about this: https://lists.ubuntu.com/archives/ubuntu-x/2009-August/000608.html

Feel free to join the mailing list and correct me if I have misrepresented you or am wrong in any other way.

[Luka Renko (lure)]

I have the same problem on ThinkPad X200s with Intel 4500MHD using HP L2045w (1680x1050) connected with DisplayPort->DVI adapter. LVDS native is 1440x900. When I am booting my system docked, I get lower (common) resolution on both displays. I use the following xrandr command to workaround the issue:

xrandr --verbose --output LVDS1 --mode 1440x900 --output DVI2 --mode 1680x1050 --left-of LVDS1

[Jeremy Foshee (jeremyfoshee)]

Kai,
   As you may be aware, modesetting has moved into the kernel. As such, I'd appreciate a test against the latest build of Lucid. Should you encounter the issue there, please also test against the latest vanilla mainline kernel build so that we can verify the behavior there.

I'll be adding a kernel task to this bug and marking the xorg task invalid.

Thanks!

-JFo