x61: Clonemode active while in docking station with closed lid

[Torsten Spindler]

Binary package hint: xserver-xorg-video-intel

While residing with closed lid in a docking station the x61 graphics are operating in clone mode, making higher resolutions on external displays hard to use.

[Torsten Spindler (tspindler)]

xrandr output of x61 with closed lid.

[Torsten Spindler (tspindler)]

/proc/acpi/ibm/video output of x61 with closed lid.

[Bryce Harrington (bryce)]

Please also include the Xorg.0.log, xorg.conf, and run `lspci -vvnn > lspci-vvnn.txt` and attach that file to this bug report?

[Bryce Harrington (bryce)]

Torsten, I recall some quirks and lid behavior changes that went into the -intel driver subsequent to 8.04, so there could well be a patch out there that could resolve this.

Be aware though that hardy uses UMS for modesetting, so the issue probably doesn't exist for Karmic/Lucid since that whole code path is rewritten and now lives in the kernel.

[Torsten Spindler (tspindler)]

Bryce, the bug occurs in Lucid, not Hardy.

[Bryce Harrington (bryce)]

Torsten, that is not what you said previously:

>The x61 seems to operate in clonemode
>with lid closed and external monitor attached. I filed bug
>https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/564463
>about this.
>
>Is there any chance that you can target this for 8.04.1?
>Bye,
>Torsten

Please clarify.

Also, be aware that in Lucid, output modesetting is done by the kernel now, not X, so if it's true that this is a 10.04 issue, you'll need to bring this issue to the kernel team, as the X.org intel driver no longer handles this.

[Torsten Spindler (tspindler)]

On Sat, 2010-04-17 at 11:27 +0000, Bryce Harrington wrote:
> Torsten, that is not what you said previously:
...
> >Is there any chance that you can target this for 8.04.1?

Correct, this was my mistake. I meant 10.04.1.

> Please clarify.
>
> Also, be aware that in Lucid, output modesetting is done by the kernel
> now, not X, so if it's true that this is a 10.04 issue, you'll need to
> bring this issue to the kernel team, as the X.org intel driver no longer
> handles this.

Thanks for the pointer, let me re-assign the bug to the kernel.

Thanks,
Torsten

[Torsten Spindler (tspindler)]

Changed affects status according to conversation with Bryce above.

[Jeremy Foshee (jeremyfoshee)]

[This is an automated message. Apologies if it has reached you inappropriately.]

This bug was reported against the linux-meta package when it likely should have been reported against the linux package instead. We are automatically transitioning this to the linux kernel package so that the appropriate teams are notified and made aware of this issue.

If this bug really is a bug in the linux-meta package you can move it back to linux-meta and tag it kj-linux-meta, or contact us on the #ubuntu-kernel channel on the FreeNode IRC server. Thanks.

[Torsten Spindler (tspindler)]

The problem could be either of
1) The X-Server takes disabled outputs into account
2) The laptop lid closed does not disable the LVDS1 output

[Chris Halse Rogers (raof)]

It is the latter: the Intel kernel module no longer takes the lid switch into account when determining whether or not to light up an LVDS connector (at least on boot). The lid switch was simply wrong too often, resulting in laptops booting with no displays active.

There is a possible workaround here - the nouveau kernel module reports the status of LVDS connectors as unknown when the lid switch indicates a closed laptop. This causes X to ignore the LVDS when doing the initial mode probe unless there are no other outputs connected.

This would be an easy patch if I had any external VGA monitors with which to test it!

[Chris Halse Rogers (raof)]

So, this should have an easy workaround, in two parts:
1) Revert git commit 6e6c822868f113dabe3c33bdd91e883cc28fa11b
Author: Eric Anholt <email address hidden>
Date: Wed Mar 17 13:48:06 2010 -0700

    drm/i915: Stop trying to use ACPI lid status to determine LVDS connection.

    I've been getting more and more quirk reports about this. It seems
    clear at this point that other OSes are not using this for determining
    whether the integrated panel should be turned on, and it is not
    reliable for doing so. Better to light up an unintended panel than to
    not light up the only usable output on the system.

2) Change the final hunk of that reversion to set status to connector_status_unknown rather than connecton_status_disconnected here:

- if (!dmi_check_system(bad_lid_status) && !acpi_lid_open())
- status = connector_status_disconnected;
-

The system should now (a) not bring up the LVDS panel if the lid is not detected as up *and* there's an external display connected, and (b) bring up the LVDS panel in all other cases.

(b) will only kick in once X has done it's mode probing, though. I expect that users with broken lid-switch detection will get a blank screen from i915 module load to X.

[Chris Halse Rogers (raof)]

I guess that for added bonus points drm could grow a second probe phase if there were no outputs with status connector_status_connected, where all outputs with status connector_status_unknown were attempted to be lit up.

[Steve Conklin (sconklin)]

The solution that Chris mentions above has a high chance of causing regressions for some Intel graphics hardware, and therefore isn't a viable solution. After some Discussion with Chris, there is a possible way to fix it that would require changes in the way the driver does probing, These changes would have to be done with the cooperation of the upstream driver maintainers, and while they are probably worth pursuing, they won't be implemented soon.

I believe that this can be solved by running xrandr so that the driver will use the probes resolution of the external monitor. For that reason, I think that the fix for this is to run xrandr.

[Torsten Spindler (tspindler)]

xrandr or rather gnome-display-properties is not an option for our customer here. From their perspective it's a regression as their now working Linux (different vendor) provides them with a non-cloned output on the external display. They do have their own repository, so creating a specialized version that works for their 10k systems is worth pursuing.

[Andy Whitcroft (apw)]

@Tosten -- can you test whether booting nomodeset fixes this for this machine type and report back here.

[Hans-Gerd van Schelve (van-schelve)]

I tested with the nomodeset option as mentioned but the problem is still the same.

[Kamal Mostafa (kamalmostafa)]

Following up on the suggestion by Steve and email with Torsten, lets see if we can make an xrandr-based solution work.

Using a rather different laptop (old Thinkpad T20 with S3 graphics) I find that if I have the external VGA output connected to a monitor while I'm booting up, then the LCD stays dark and the gdm GUI login screen comes up in a higher resolution (on the monitor) than is supported by the laptop LCD -- so in my case, it is not coming up in clone mode. However...

I can force the gdm login screen (and subsequent user X session) to come up in whatever resolution I wish by inserting an xrandr command near the top of /etc/gdm/Init/Default . I think that an xrandr line as shown here would be appropriate for the X61 based on your xrandr.out:

/etc/gdm/Init/Default
    ...
    xrandr --output VGA1 --mode 1280x1024 # <--- try inserting this before the /sbin/initctl line
    /sbin/initctl -q emit login-session-start DISPLAY_MANAGER=gdm
    ...

Hans-Gerd, please try that and let us know whether it works on the X61 to overcome the clone mode problem.

Also, this article describes additional resolution setting methods that may be relevant: https://wiki.ubuntu.com/X/Config/Resolution

[Hans-Gerd van Schelve (van-schelve)]

Hi, I polished a bit around the xrandr command you mentioned:

if [ -f /proc/acpi/ibm/video ]; then
        state=$(awk '/lcd:/ {print $2}' /proc/acpi/ibm/video)
        if [ "$state" = "disabled" ]; then
                /usr/bin/xrandr --output LVDS1 --off --output VGA1 --preferred
        fi
fi

This way it looks to be a valid work around for this issue. The external display comes up with it's native resolution while the internal is disabled. But everytime a gdm update comes out I have to check if there is any change in /etc/gdm/Init/Default. That is the bad side of this solution...

[Kamal Mostafa (kamalmostafa)]

Very good to hear that the problem can at least be addressed with an xrandr workaround, and nice polish as well. We can also use this to help further diagnose the underlying problem.

Hans-Gerd, can you please attach the Xorg.0.log (with the xrandr workaround in place). The modelines and other X startup information may be informative.

I would also like to know whether both of the sequences "--output LVDS1 --off" and "--output VGA1 --preferred" are actually required, or if just one or the other by itself resolves the problem.

You're right that manually inserting these lines into /etc/gdm/Init/Default is a non-optimal solution... I'm investigating the best way to deploy a long term fix.

[Hans-Gerd van Schelve (van-schelve)]

Kamal,

I need both of the sequences. Only --output LVDS1 --off does not change the resolution on the external display.

[Kamal Mostafa (kamalmostafa)]

I have constructed a pair of .deb packages which implement the xrandr-based fix. Hans-Gerd, pending your testing and approval, these can be deployed at your site:
  http://kernel.ubuntu.com/~kamal/lp564463-lvm-gdm/
        gdm_2.30.0-0ubuntu6~lvm1_amd64.deb
        lvm-gdm-customization_1.0.0_amd64.deb

The first package (a replacement version of 'gdm' for Lucid) decouples the X61-specific nature of the fix from gdm by enhancing the /etc/gdm/Init/Default script to run another script, "Default-local" in the same directory, if that script exists. The second package (a new one called 'lvm-gdm-customization') actually supplies that Default-local script which contains Hans-Gerd's xrandr fragment.

This version of lvm-gdm-customization requires exactly the version of gdm supplied with it. I will propose the Default-local enhancement to the gdm maintainers. Assuming I can get that enhancement (or a similar one) accepted, I will then supply you with a new version of lvm-gdm-customization which recognizes that (and of course you'll no longer need to carry the special version of gdm).

[Torsten Spindler (tspindler)]

@ Kamal: Thanks for the packages, but LVM used 32bit on the system. Can you supply i386 packages?
@ Hans-Gerd: Can you build the 32bit package yourself based on the .dsc and orig.tar.gz in Kamals webdirectory?

[Kamal Mostafa (kamalmostafa)]

I have just uploaded i386 builds of the two packages:

  http://kernel.ubuntu.com/~kamal/lp564463-lvm-gdm/
        gdm_2.30.0-0ubuntu6~lvm1_i386.deb
        lvm-gdm-customization_1.0.0_i386.deb

[Kamal Mostafa (kamalmostafa)]

I'm advised by Torsten that a custom gdm package will be maintained and deployed at the site (implementing the method described in comment #22). As we intend no further action at this time, I'm marking this bug report as "Won't Fix".