[2.6.32-19 regression] Does not check lid status any more, external screen powered off

Bug #556253 reported by Martin Pitt on 2010-04-06
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
High
Unassigned
xorg-server (Ubuntu)
Undecided
Unassigned

Bug Description

I run my laptop docked with an external DVI monitor. This configuration has worked fine until 2.6.30-18, linux saw that the lid was closed, disabled the internal 1280x800 LVDS, and ran the external DVI with the full 1280x1024 resolution.

With the upgrade to 2.6.30-19, the external DVI now gets powered off during boot, and X/gdm start into an 1280x800 framebuffer which is only displayed on the internal LVDS (which is pretty pointless with the lid being closed). I have to blindly type my password to get into my session, and use xrandr to reenable the external DVI and disable LVDS.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: linux-image-2.6.32-19-generic 2.6.32-19.28
Regression: Yes
Reproducible: Yes
ProcVersionSignature: Ubuntu 2.6.32-19.28-generic 2.6.32.10+drm33.1
Uname: Linux 2.6.32-19-generic x86_64
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.21.
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: martin 1708 F.... pulseaudio
 /dev/snd/controlC0: martin 1708 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xefebc000 irq 21'
   Mixer name : 'SigmaTel STAC9200'
   Components : 'HDA:83847690,10280201,00102201'
   Controls : 7
   Simple ctrls : 5
Card1.Amixer.info:
 Card hw:1 'Headset'/'Logitech Logitech USB Headset at usb-0000:00:1d.7-8.3.4, full speed'
   Mixer name : 'USB Mixer'
   Components : 'USB046d:0a01'
   Controls : 6
   Simple ctrls : 2
Date: Tue Apr 6 09:04:36 2010
EcryptfsInUse: Yes
HibernationDevice: RESUME=UUID=5c285fda-1bff-4440-84ab-35ad7eadc72c
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta amd64 (20100316)
MachineType: Dell Inc. Latitude D430
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-19-generic root=UUID=5ec6a222-a4c1-426d-994b-340d9cac670a ro quiet splash drm.debug=0x04
ProcEnviron:
 PATH=(custom, user)
 LANG=de_DE.utf8
 SHELL=/bin/bash
RelatedPackageVersions: linux-firmware 1.33
SourcePackage: linux
dmi.bios.date: 05/21/2007
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A00
dmi.board.name: 0HU754
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA00:bd05/21/2007:svnDellInc.:pnLatitudeD430:pvr:rvnDellInc.:rn0HU754:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: Latitude D430
dmi.sys.vendor: Dell Inc.

Martin Pitt (pitti) wrote :
Martin Pitt (pitti) wrote :

This is the dmesg on 2.6.32-18 with drm.debug=0x04, where things work fine.

Martin Pitt (pitti) wrote :

This is dmesg with 2.6.32-19, with the regression.

The first interesting part of the diff:

 [drm] initialized overlay support
 [drm:intel_sdvo_debug_write], SDVOB: W: 05 00 00 (SDVO_CMD_SET_ACTIVE_OUTPUTS)
 [drm:intel_sdvo_debug_response], SDVOB: R: (Success)
+[drm:drm_helper_probe_single_connector_modes], VGA-1
 usb 2-2: configuration #1 chosen from 1 choice
 hub 2-2:1.0: USB hub found
-hub 2-2:1.0: 4 ports detected
-[drm:i8xx_disable_fbc], disabled FBC
-[drm:drm_helper_probe_single_connector_modes], VGA-1
 [drm:drm_helper_probe_single_connector_modes], VGA-1 is disconnected
 [drm:drm_helper_probe_single_connector_modes], LVDS-1
-[drm:drm_helper_probe_single_connector_modes], LVDS-1 is disconnected
+hub 2-2:1.0: 4 ports detected
+[drm:drm_helper_probe_single_connector_modes], Probed modes for LVDS-1
+[drm:drm_mode_debug_printmodeline], Modeline 30:"1280x800" 60 69300 1280 1328 1360 1419 800 803 809 816 0x48 0xa

Martin Pitt (pitti) wrote :

Ah, I bet this regression is due to

  * drm/i915: Stop trying to use ACPI lid status to determine LVDS
    connection.
    - LP: #515246

This was explicitly added to be able to support external monitors, and has worked fine until now. Why was it ripped out wholesale? Wouldn't it be a better solution to only ignore the ACPI status if there is only one monitor?

Changed in linux (Ubuntu):
assignee: nobody → Canonical Kernel Team (canonical-kernel-team)
importance: Undecided → High
status: New → Triaged
Martin Pitt (pitti) wrote :

FYI, the ACPI check was originally done for https://bugs.freedesktop.org/show_bug.cgi?id=11455

Martin Pitt (pitti) wrote :

For convenience, this is the complete diff between -18 and 19 (with the timestamps filtered out)

Andy Whitcroft (apw) wrote :

As I understand things this change was triggering a number of internal LDVS displays to not initialise due to broken lid detection leaving users with no display at all. The sheer number of negative quirks being applied to work around these cases lead to an upstream decision to revert the whole change as a bad approach to the issue. We are working on the assumption we would see a similar balance of bad initialisation, though the expected behaviour worse case was that some closed displays would be incorrectly enabled.

It is unclear why you get no output on your external display if it is connected on reboot.

Changed in linux (Ubuntu):
milestone: none → ubuntu-10.04
Surbhi Palande (csurbhi) wrote :

Martin Pitt, if it is possible for you, will you please upload a dmesg with DRM_DEBUG on with Karmic (maybe live cd), with the same setup? Thanks!

Surbhi Palande (csurbhi) wrote :

Forgot to add: The reverted patch was introduced post karmic, so with a dmesg from karmic, i could possibly try to find out what is missing in lucid. Thanks!

Martin Pitt (pitti) wrote :

Hmm, drm.debug=0x04 under Karmic gives

[ 0.000000] Unknown boot option `drm.debug=0x04': ignoring

I might need to add that after the --, I'll play around with this a bit. But even without this, the karmic kernel is already quite verbose:

[ 5.280551] [drm] TMDS-14: set mode 1280x1024 27
[ 5.545646] [drm] LVDS-8: set mode 1280x800 28
[...]
[ 98.874965] [drm] TMDS-14: set mode 1024x768 2a
[ 99.382981] [drm] LVDS-8: set mode 1024x768 2b

This still exhibited the broken behaviour which the mentioned lid checking patch was fixing, i. e. both monitors got the wrong mode.

I also noticed that with lucid's -19, the VTs/plymouth are in fact working on the DVI, just X switches them off.

As a summary, these are the behaviors:

Karmic (2.6.31):
 - LVDS: 1024x768 (non-native), switched on in both VT and X
 - DVI: 1024x768 (non-native), switched on in both VT and X

Lucid 2.6.32-18:
 - LVDS: switched off in both VT and X
 - DVI: 1280x1024 (native), switched on in both VT and X

Lucid 2.6.32-19:
 - LVDS: 1280x800 (native), switched on in both VT and X
 - DVI: 1280x800 (non-native), switched on in VT, switched off in X

Surbhi Palande (csurbhi) wrote :

@Martin Pitt, your dmesg is also showing that dvi display is getting probed appropriately even when the LVDS-1 is connected.

Martin Pitt (pitti) wrote :

For completeness, this is the X.org log (from a clean boot of a lucid beta-2 live system). It shows that it tries to settle for a 1024x768 resolution for both screens, but for some reason the external one stays blank. It might be because xrandr decides to only show the internal one by default, or the non-native resolution somehow conflicts with KMS/the plymouth transition patch, etc.

tags: added: iso-testing
Martin Pitt (pitti) wrote :

To eliminate this part, it's the same situation with plymouth uninstalled.

Hm, so xrandr seems to also think that both are running:

Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
VGA1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 261mm x 163mm
   1280x800 59.8 +
   1024x768 85.0* 75.0 70.1 60.0
   832x624 74.6
   800x600 85.1 72.2 75.0 60.3 56.2
   640x480 85.0 72.8 75.0 59.9
   720x400 85.0
   640x400 85.1
   640x350 85.1
DVI1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 340mm x 270mm
   1280x1024 75.0 + 60.0
   1280x960 60.0
   1152x864 75.0
   1024x768 85.0* 75.1 70.1 60.0
   832x624 74.6
   800x600 85.1 72.2 75.0 60.3 56.2
   640x480 85.0 72.8 75.0 66.7 60.0
   720x400 70.1
TV1 disconnected (normal left inverted right x axis y axis)

Interesting observation when I change the lid status (which X listens to):

When opening the lid, I quickly see gdm in 1024x768 mode (with the usual scaling distortion), but it quickly switches to 1280x800 (LVDS native). When I close the lid again (sudo killall gnome-power-manager before, to avoid suspend) the external DVI suddenly turns on, with the native 1280x1024, and LVDS goes off:

(II) PM Event received: Capability Changed
I830PMEvent: Capability change
(II) intel(0): EDID vendor "SEC", prod id 21569
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "1280x800"x0.0 69.30 1280 1328 1360 1419 800 803 809 816 -hsync -vsync (48.8 kHz)
(II) intel(0): Allocate new frame buffer 1280x800 stride 2048
(II) PM Event received: Capability Changed
I830PMEvent: Capability change
(II) intel(0): EDID vendor "SEC", prod id 21569
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "1280x800"x0.0 69.30 1280 1328 1360 1419 800 803 809 816 -hsync -vsync (48.8 kHz)
(II) intel(0): Allocate new frame buffer 1280x1024 stride 2048

So in summary, X does not get along with trying to run the DVI in 1024x768 mode with KMS.

So if this kernel change is meant to stick, this needs an X.org change to replicate the logic that was previously in the kernel (only enable external DVI when the lid is closed), to avoid those hideously blurry scaled graphics and the KMS resolution incompatibility. Or KMS needs to be fixed to alllow the mode swich on the DVI (which seemed to work in karmic). Or the kernel logic needs to be fine-tuned to not apply the lid check for single monitors only.

Bryce Harrington (bryce) on 2010-04-07
Changed in xorg-server (Ubuntu):
status: New → Confirmed
Martin Pitt (pitti) on 2010-04-07
summary: - [2.6.32-19 regression] Does not check lid status any more, blank screen
+ [2.6.32-19 regression] Does not check lid status any more, external
+ screen powered off
Martin Pitt (pitti) wrote :

As expected, booting with video=LVDS-1:d works, but with that I never get back the LVDS, not even after opening the lid.

Chase Douglas (chasedouglas) wrote :

@Martin:

This sounds like it could be partly gnome-settings-daemon misbehaving. g-s-d performs the xrandr configuration for the gnome desktop. I've been working on bug 484186 where g-s-d will fail to change the configuration settings of a CRTC output. You may be seeing the same bug from the DVI side. I've built a test package with my fix and uploaded it to ppa:chasedouglas/gnome-settings-daemon. Would you mind trying it out to see if it helps?

Martin Pitt (pitti) wrote :

Just to complete the data collection and followup to the IRC discussion with Andy:

 * Same result with VGA instead of DVI

 * When I force the resolution in xorg.conf, it works:

Section "Screen"
 Identifier "MyScreen"

 SubSection "Display"
  Modes "1280x1024"
 EndSubSection
EndSection

Martin Pitt (pitti) wrote :

Chase,

I tried the package, but no difference. The changelog speaks about fixing the "change resolution" Fn key, which is an unrelated problem. This one happens without any custom xrandr configuration.

Chase Douglas (chasedouglas) wrote :

@Martin:

That's too bad. g-s-d calculates its own configurations, and the fn-F7 handler sometimes gets called without the key actually being pressed (i.e. when my laptop lid is opened and it resumes). I was hoping this might be related to your issues. Oh well...

Robert Hooker (sarvatt) wrote :

Martin: The same issue you experience with video=LVDS-1:d was hitting a significant amount of people who's lid status was broken because of a crappy bios, so they could never get the LVDS working with KMS without adding a quirk to the kernel and installing the new kernel.

Out of curiosity, can you please try booting with video=SVIDEO-1:d and see if there is any difference? It seems to be a userspace problem to me. Alternatively, can you try booting with i915.fbpercrtc=1?

Bryce Harrington (bryce) wrote :

Seems my concerns about this were justified - https://lists.ubuntu.com/archives/kernel-team/2010-March/009613.html

The upstream change feels like one of those that makes sense "in theory" but doesn't take all hardware configurations into account.

Martin, to isolate g-s-d, remove your monitors.xml file (in .config somewhere). If that is not present, AFAIK g-s-d will not attempt to do any changes to your system. If that makes the problem go away, then this bug should focus on g-s-d.

Otherwise, perhaps reverse-quirks in the kernel are needed. I might even suggest backing out the upstream patch, and sticking with individual quirks. Quirking individual systems means a lot of work, but at least it's well understood how to recognize the problem and incorporate the quirk.

Bryce Harrington (bryce) wrote :

Can you explain in further detail how you think the kernel logic that handled this previously could be moved to the xserver?

Changed in xorg-server (Ubuntu):
status: Confirmed → Incomplete

Bryce Harrington [2010-04-07 23:46 -0000]:
> Martin, to isolate g-s-d, remove your monitors.xml file (in .config
> somewhere). If that is not present, AFAIK g-s-d will not attempt to do
> any changes to your system. If that makes the problem go away, then
> this bug should focus on g-s-d.

It's quite the other way around: The gdm account doesn't have a
monitors.xml, and thus X decides for a "compromise" resolution between
LVDS and DVI (1024x768) and enables both. This has been like that for
several releases, and while it looks ugly and distorted, it at least
works "good enough" for gdm. The regression is that DVI now gets
powered off (which the kernel DRM/X logs have no evidence off, they
claim that it's on) -- we haven't figured out yet why that happens.

Once I log into my user account (blindly type password), my custom
monitors.xml kicks in, and g-s-d disables LVDS and sets DVI to
1280x1024, and things work perfectly again.

> Otherwise, perhaps reverse-quirks in the kernel are needed. I might
> even suggest backing out the upstream patch, and sticking with
> individual quirks. Quirking individual systems means a lot of work, but
> at least it's well understood how to recognize the problem and
> incorporate the quirk.

Like a "known works" whitelist? This sounds like an interesting case.
I'd expect vendors like Dell to at least get this right on their
business laptops, where they sell good docking stations for, and have
trouble with paying support if it fails..

Bryce Harrington [2010-04-08 2:21 -0000]:
> Can you explain in further detail how you think the kernel logic that
> handled this previously could be moved to the xserver?

This was an initial idea, but we have to discard it. The reason for
removing it from the kernel wasn't something like "we do not want the
kernel to have policy and decide which port to favor", but "initial
lid status detection is just plain broken on too many BIOSes". Thus if
we'd move that logic into X, we'd get the exact same problems back.

Now, without the initial lid state I see use cases in both directions
when you have multiple monitors -- if you attach a beamer, you usually
want both on, if you attach an external monitor (with a higher
resolution), you usually want only the external monitor).

So the root problem here (apart from the "doesn't work as perfectly as
before in lucid") is why the DVI powers off. Getting back the better
behavior of previous lucid versions with driving DVI in native
resolution is certainly a bonus, but I don't see how to achieve that
easily at this point of the release.

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Martin Pitt (pitti) wrote :

> video=SVIDEO-1:d

No perceivable difference, DVI stays off and LVDS is on in non-native 1024x768 mode.

Martin Pitt (pitti) wrote :

> Alternatively, can you try booting with i915.fbpercrtc=1?

Again no perceivable difference. Unlike with the SVIDEO-1:d test, I also opened and closed the lid, to check that lid detection and resolution updates still work (they do). Thus this X.org log is slightly longer than the SVIDEO one.

Chris Halse Rogers (raof) wrote :

It's possible that the Intel driver could use the same trick the Nouveau module does. Nouveau also had lid-detect quirks, which they removed, and now the driver reports LVDS as “unknown” if the lid is detected as down. If there are no other outputs detected, the “unknown” status causes nouveau to try to bring up the LVDS anyway, and if there are other outputs connected the LVDS remains unactivated.

This seems like a better behaviour to me.

That still leaves the DVI powering off problem, though.

Manoj Iyer (manjo) on 2010-05-24
tags: added: kernel-power kernel-reviewed
Manoj Iyer (manjo) on 2010-06-04
tags: added: kernel-graphics
removed: kernel-power
Manoj Iyer (manjo) wrote :

@Manoj: The lid status is still ignored with your kernel.

Martin Pitt (pitti) wrote :

With your kernel I get a correct resolution on DVI, but it seems that LVDS is now entirely ignored. It stops appearing in Xorg.log and xrandr, and in dmesg I get

[ 1.431388] [drm:intel_no_lvds_dmi_callback], Skipping LVDS initialization for Dell Latitude

When I boot undocked, or undock while it's running, I get a black internal screen. When booting undocked, it does not even start X.

I attach dmesg and Xorg log with your kernel while it's docked.

Martin Pitt (pitti) wrote :
Changed in linux (Ubuntu):
assignee: Canonical Kernel Team (canonical-kernel-team) → nobody
mstfa cmly (mstfacmly) wrote :

This issue is present on kernel 2.6.32-24, which, as you know, is used by the LTS release.

I tested with a Dell Latitude E6410, as well as with an EEEPC. The EEEPC worked fine, but the Latitide does not show any display. I was able to install by using an alternate installer.

I attempted to use GRUB options such as video=LVDS-1:e, video=LVDS-1:d and acpi=off, with no success.

Here's the lspci -vvnn for the Intel Card:

00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 12)
        Subsystem: Dell Device [1028:040a]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at 90000000 (64-bit, non-prefetchable)
        Region 2: Memory at 80000000 (64-bit, prefetchable)
        Region 4: I/O ports at 70b0
        Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
                Address: fee0a00c Data: 4199
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a4] PCIe advanced features <?>

Brad Figg (brad-figg) wrote :

@Martin
   Does this issue still present itself in current, Lucid kernels ?

Changed in linux (Ubuntu):
status: Triaged → Incomplete
tags: added: regression-release
removed: regression-potential
Changed in linux (Ubuntu):
milestone: ubuntu-10.04 → lucid-updates
Stan Schymanski (schymans) wrote :

This is Ubuntu 11.04, with 2.6.38-11-generic on a Dell Latitude E6320 and I am still seeing this issue. My external monitor (DVI through a docking station) stays off during reboot or resume, sometimes with the login screen not visible so that I have to type in the password blindly. After login, it still stays off until I do System Settings - Monitors, set the external monitor to off, apply settings and then restore the original settings.

To post a comment you must log in.