Bug 27622 - [ILK] no OpRegion lid status detection for eDP panels
Summary: [ILK] no OpRegion lid status detection for eDP panels
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri-intel@kernel-bugs.osdl.org
Depends on:
Reported: 2011-01-26 09:07 UTC by Matthieu Imbert
Modified: 2013-02-10 17:23 UTC (History)
7 users (show)

See Also:
Kernel Version: 3.2
Tree: Mainline
Regression: No

kernel log with drm.debug=0x6 (250.45 KB, text/plain)
2011-02-11 14:52 UTC, Matthieu Imbert
patch to get lid status from OpRegion for eDP display (1.21 KB, patch)
2011-02-13 22:17 UTC, Matthieu Imbert
Details | Diff
revert for correct external display mode (766 bytes, patch)
2011-06-04 07:40 UTC, Andreas Sturmlechner
Details | Diff
revert-disable-opregion-lid-detection.patch (1.43 KB, patch)
2012-03-04 14:05 UTC, Andreas Sturmlechner
Details | Diff
resurrect panel lid status (3.35 KB, patch)
2012-11-13 11:25 UTC, Daniel Vetter
Details | Diff
resurrect panel lid status v2 (3.70 KB, patch)
2012-11-16 13:50 UTC, Daniel Vetter
Details | Diff

Description Matthieu Imbert 2011-01-26 09:07:26 UTC
hardware: dell e4310 laptop with arrandale dual-core i5-540m,
integrated graphics.  driver: i915. operating system: debian
testing. kernel: vanilla 2.6.37 + patch for touchpad. KMS activated.

Since 2.6.37 i noticed two bugs:

1 - when using my laptop standalone, sometimes at boot time, just
    after the grub screen, the screen becomes blank (no console
    output, no x output, backlight is on). OS boots correctly. Trying
    to switch consoles (ctrl-alt-F1 / ctrl-F7) or SysRq-V (force-fb)
    has not effect. SysRq-B allows me to reboot.

2 - when using my laptop on two docking station connected via HDMI to
    a 1600x1200 panel for one of the docking stations, or to a
    1680x1050 for the other docking station, with the laptop lid
    closed, after grub screen, the console appears correctly on the
    external monitor, with the right resolution (it seems), but it is
    limited in size to the size of the laptop screen. Then, when
    switching to X, the resolution is wrong, because the selected mode
    is duplicate screens in 1024x768.

    I can force the right resolution (and deactivate the laptop
    screen) with the following command:

    $ xrandr --output eDP1 --off --output HDMI1 --auto --output eDP1 --off

    note that setting output eDP1 to off both at the start and the end
    of the command seems mandatory to be effective.

    Later, in the same working session, as soon as the Desktop is
    redisplayed after leaving the screensaver, the screen layout is
    messed up again in various ways:

    - laptop monitor reactivated and becoming primary display, (so all
      windows and Destkop panels are moved from external monitor to
      laptop monitor) -> running the above command again fixes the

    - external monitor and laptop monitor are both off (but laptop
      backlight is on) -> running the above command is not sufficient,
      i have to switch to text console with ctrl-alt-f1 then back to X
      with ctrl-f7 then run the xrandr command to fix this.

    Also, sometimes (not very often), even without the screensaver,
    the external monitor can flicker and the screen layout is messed
    up in the above described ways. I call a flicker when the screen
    goes black for a very short while (less than 1/10 s).

    I can also mess up the screen configuration just by running:

    $ xrandr

I report these bugs together because i think they are related in a way
or another (something to do with display detection/initialization in
KMS is guess).

I checked the bugzilla and found a lot of bugs similar to these but
none are the same. Most of the other bugs describe:

- crashes: i never get crashes

- systematic blank screens: in my case it is only intermitent, when
  not using a docking station

- issues with suspend/resume: in my case, suspend/resume seems to work

I think it is a regression because with previous kernel versions (i
experimented various flavors of 2.6.32, 2.6.33, 2.6.35), i
experimented various issues. (1) was sometimes present, but (2) is
Comment 1 Chris Wilson 2011-01-26 09:37:23 UTC
1: commit 858bc21f0637c407601a05626854ae58b242f75d
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue Jan 4 10:46:49 2011 -0800

    drm/i915: check eDP encoder correctly when setting modes
    We were using a stale pointer in the check which caused us to use CPU
    attached DP params when we should have been using PCH attached params.
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31988
    Tested-by: Jan-Hendrik Zab <jan@jhz.name>
    Tested-by: Christoph Lukas <christoph.lukas@gmx.net>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: stable@kernel.org

2: commit 01fe9dbde19a1a27b8ee63e2d964562962e1eb78
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Jan 16 19:37:30 2011 +0000

    drm/i915: Use ACPI OpRegion to determine lid status
    Admittedly, trusting ACPI or the BIOS at all to be correct is littered
    with numerous examples where it is wrong. Maybe, just maybe, we will
    have better luck using the ACPI OpRegion lid status...
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

One is already in linus/master, the second is being evaluated in drm-intel-next because history says there's going to be something it breaks.
Comment 2 Matthieu Imbert 2011-01-27 09:21:16 UTC
Hi Chris, and thanks for the patches.

I applied both on 2.6.37.

I don't know yet for issue (1) since i haven't rebooted enough times to be sure that the intermittent bug is completely gone (though i'm confident)

Issue (2) is still there

Comment 3 Chris Wilson 2011-01-27 09:57:27 UTC
Then you appear to be out of luck for (2). We can't trust the lid status because history shows that manufacturers often shipped with broken hardware, and your machine doesn't seem to supply the value through the ACPI OpRegion, which has been the specification on Intel machines for the last few years. We can't win.

There are further patches for resuming with eDP which are being tested on drm-intel-next, which hopefully aren't required for the issue at hand.
Comment 4 Matthieu Imbert 2011-01-27 10:01:15 UTC
But then why didn't issue 2 occur with previous kernels (2.6.32, 33 , 35) ? How was the detection of lid status done in these versions?
Comment 5 Matthieu Imbert 2011-02-11 14:48:28 UTC
About issue (2): the second patch provided has no effect simply because the code in intel_lvds_detect() is never executed (i'm sure since i added some DRM_DEBUG_DRIVER logs in it).
Actually, no LVDS is detected in intel_lvds_init() (debug message: "LVDS is not present in VBT").

The closing / opening of the lid is accurately detected somewhere else in the code since when i close the lid, gnome locks the screen.

I attach kern.log with drm.debug=0x6 and i reopen the bug.
Comment 6 Matthieu Imbert 2011-02-11 14:52:37 UTC
Created attachment 47312 [details]
kernel log with drm.debug=0x6

this log was generated when booting an e4310 on a docking station. e4310 panel is closed, and docking station connected to a VGA 22' cathodic monitor.
log corresponds to full boot, starting from grub, then gdm3 login, and stops just after entering the x-window user session.
Comment 7 Matthieu Imbert 2011-02-13 22:17:13 UTC
Created attachment 47662 [details]
patch to get lid status from OpRegion for eDP display

duplicate what is done for lvds in patch 01fe9dbde19a1a27b8ee63e2d964562962e1eb78 for eDP display type.

Works for me. Tested on my dell e4310:
- boot standalone with lid open
- boot on dock connected to a 1600x1200 vga crt, lid closed. Then open and close the lid. Screen resolution is correct at boot, and adapts when opening / closing the lid
Comment 8 Andreas Sturmlechner 2011-03-16 20:21:45 UTC
BRILLIANT! I've been waiting for 01fe9dbde19a1a27b8ee63e2d964562962e1eb78 since 2.6.33 and this finally solves that nasty "be greeted with huge 1024x768 at an external 1920x1200 screen" issue for me.

Patch applies cleanly against 2.6.38.
Tested with: Lenovo Thinkpad X200s (GMA4500MHD), lid closed and sitting on its Ultrabase docking station, connected via Displayport to the external display.

Matthieu, thanks for opening this post thus pointing me to Chris' patch :)
Comment 9 Andreas Sturmlechner 2011-06-04 07:40:33 UTC
Created attachment 60742 [details]
revert for correct external display mode

These code lines found their way into the 2.6.39 merge window but were removed again with 2.6.39_rc1-r5. I'm applying all my kernels with this patch to get my external display resolution right from the start...
Comment 10 Andreas Sturmlechner 2012-03-04 11:58:10 UTC
linux-3.3_rc6 and this is still bugging me.

I've got two stationary setups for my ThinkPad X200s (LVDS native 1440x900):

 -) X200s closed-lid startup @ Ultrabase [DP] -> [DP] Eizo (native 1920x1200)
 Resolution ALWAYS wrong* without patch, Detection works (mostly)

 -) X200s closed-lid startup @ Ultrabase [DP] -> [DP]->[DVI-D] -> [DVI-D] Lenovo ThinkVision (native 1920x1200)
 Resolution ALWAYS wrong* without patch
 Ext. display detection completely non-functional, only BIOS-detection immediately at startup works. If I miss that fraction of a second, I can reboot all over again, and the Lenovo BIOS is really, really fast. I've become really good at this, but it's still about a 40 : 60 chance to fail at first boot.

* Resolution always wrong basically means that console output is aligned at the upper left corner and limited to the size of LVDS-native, while in X the LVDS-native resolution is blown up to the full size of the external display, looking gross.

I am still using the same patch.
Comment 11 Andreas Sturmlechner 2012-03-04 14:05:46 UTC
Created attachment 72536 [details]

Ok, I've taken another look at the problem. This reverts the following patch:

drm/i915: disable opregion lid detection for now.
commit 40c7f2112ce18fa5eb6dc209c50dd0f046790191

- Tiny LVDS resolution @ huge external display

Seems to fix:
- External display detection (needs a few more reboots to confirm)

Can't we put this into some CONFIG_KMS_TRUST_OPREGION (EXPERIMENTAL) option?
Comment 12 Jesse Barnes 2012-04-18 20:22:19 UTC
Lemme test with mine...
Comment 13 Jesse Barnes 2012-04-18 21:01:51 UTC
There was a fix for LVDS configuration in the case where the lid was closed and the BIOS hadn't programmed anything, so hopefully this isn't an issue for you anymore.

I verified that my x200s works ok with a 1920x1200 monitor attached and the laptop running at 640x480, can you re-test?  I was just using Daniel's drm-intel-next-queued branch from git://people.freedesktop.org/~danvet/drm-intel with no other patches applied.
Comment 14 Andreas Sturmlechner 2012-04-20 20:57:20 UTC
Unfortunately there's no change for me in the Ultrabase/DisplayPort/Eizo scenario. But I'll do some further testing with/without closed lid and dock (how do you connect with your external display?).

Just to make sure I didn't screw up: I git fetched your link into my existing copy of Linus' kernel and then 'git merge danvet/drm-intel-next-queued'.
Comment 15 Andreas Sturmlechner 2012-04-20 21:24:40 UTC
I also checked startup with the same monitor connected via D-SUB (without the dock), with the same result, regardless of lid status. LVDS and ext.display both come up with 1024x768 at X, while terminal on the ext.display is OK in resolution but only the upper left - what seems to would be 1440x900 - gets used.
Comment 16 Andreas Sturmlechner 2012-04-21 14:47:18 UTC
Back at my weekend setup, things are the same, although I have noticed a difference not mentioned here before: The [DP]->[DVI] adapter makes the external display turn into an HDMI port in xrandr, and instead of 1024x768 as with D-SUB or DP, X comes up at 1440x900 for both LVDS and 'HDMI'.
Comment 17 Matthieu Imbert 2012-04-23 09:31:12 UTC
Hi. I don't know if it's relevant, but:

I tried kernel 3.2.0 (default kernel shipped with debian testing) on a Dell E4310 (internal screen is 1440x900) and the issue is still there: When booting the laptop on a docking station, with the lid closed, and an external 1600x1200 monitor attached, after KMS, the screen resolution is set to 1600x1200 but then console only uses 1440x900. Then when X starts i get a login screen which seems to be something like 1024x768 or 1280x1024.

instead of a compile time config CONFIG_KMS_TRUST_OPREGION, why not adding a module parameter to module i915? If you think it's a good idea but don't have the time to implement it, I could try to do it and send a patch.

I also have another issue with kernel 3.2.0 on this laptop: When i boot without a dock and external screen (and thus the lid is open), 50% of the time, KMS fails with message:
[drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting
then the screen is either black or contains some garbage.
Should I fill a specific bug for this other issue?
Comment 18 Chris Wilson 2012-04-26 12:13:45 UTC
There already is i915.panel_ignore_lid for that purpose of forcibly marking the panel as present or absent during modeset.
Comment 19 Matthieu Imbert 2012-04-26 12:29:12 UTC
For the module option I rather thought about something like i915.trust_opregion which would not forcibly mark the panel as present or not, but would trust opregion for lid state detection.
Comment 20 Andreas Sturmlechner 2012-05-06 17:07:23 UTC
So i915.panel_ignore_lid=-1 is another workaround for use with external displays exclusively, and it works, but it basically means having grub options for mobile and docking use each because LVDS won't come up at all. Having an opregion module parameter would really improve the situation.
Comment 21 Daniel Vetter 2012-06-06 12:57:49 UTC
Ok, I'm a bit confused about the status of this bug here. I guess we should restrict this bug here to the 2nd problem that we don't do OpRegion lid status detection for eDP panels. I'll adjust the subject accordingly. Also, this would not really be a regression any more because we never used to detect lid status for eDP.

Chris Wilson volunteered himself to resurrect a patch series, which would then allow us to easily enable OpRegion lid detection on eDP panels, too.

For the 1st issue, that hasn't been mentioned in comments in a long time. Mattheieu, is this gone for good and fixed? If so, I think we should create a new bug report (which then would be a regression) for that one.
Comment 22 Andreas Sturmlechner 2012-06-06 16:49:22 UTC
I'm using latest drm-intel-next-queued branch, at least for me problem #2 is not yet fixed.
Comment 23 Daniel Vetter 2012-06-06 17:00:23 UTC
Yeah, I know that #2 isn't fixed yet ...
Comment 24 Matthieu Imbert 2012-06-07 11:14:23 UTC
I understand your confusion because this bug gathers initially differents issues (my fault) which have evolved differently. I agree that we should rename/create new bugs:

- Issue 1 was indeed fixed but has now reappeared in a different form. I've opened bug #43348 (https://bugzilla.kernel.org/show_bug.cgi?id=43348) for this.

- Issue 2 is not fixed. I agree that we should change this bug's subject accordingly. If I understood correctly, display detection may be done with (A) OpRegion or (B) other ways, and current code chooses (B) because some hardware are buggy with (A). It seems that my hardware (dell E4310 laptop) is buggy with (B) but works with (A). I think being able to tell the driver wich way (A) or (B) to detect the display(s) would be nice. Moreover, I think that being able to do that with a module option would be preferable rather than a compile time define.
Comment 25 Daniel Vetter 2012-11-13 11:25:46 UTC
Created attachment 86291 [details]
resurrect panel lid status

Sorry for the long delay. The attached patch resurrects the panel lid handling, but still leaves it disabled by default. To enable lid-based panel detection, boot with


Due to buggy firmware I fear we'll never be able to enable this by default, but this should at least get your use-cases going. Tested-bys highly welcome.
Comment 26 Andreas Sturmlechner 2012-11-15 23:04:15 UTC
My first try with your patch was unsuccessful, I applied the patch over 3.6.6 and added i915.panel_ignore_lid=0, same behaviour as vanilla kernel.
Comment 27 Daniel Vetter 2012-11-15 23:09:05 UTC
Can you check with a printk that we still execute the opregion lid detect code? Just to rule out me being dumb ...
Comment 28 Andreas Sturmlechner 2012-11-15 23:12:26 UTC
I guess the line

+	else if (i915_panel_ignore_lid = 1)

is wrong? Because after changing it to == it works for me.
Comment 29 Daniel Vetter 2012-11-16 13:50:50 UTC
Created attachment 86521 [details]
resurrect panel lid status v2

Ok, my C programmer license has been revoked ... please check whether this version is correctly fixed up.
Comment 30 Andreas Sturmlechner 2012-11-16 19:24:51 UTC
Boots and greets me with 1920x1200 pixel glory. :)
Comment 31 Daniel Vetter 2012-11-23 09:30:51 UTC
Patch merged into drm-intel-next:

commit a726915cef1daab57aad4c5b5e4773822f0a4bf8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Nov 20 14:50:08 2012 +0100

    drm/i915: resurrect panel lid handling
Comment 32 Andreas Sturmlechner 2012-12-14 16:14:19 UTC
I'm happily using the patch with 3.6.10 right now, but some change in 3.7 makes all fonts look blurry with it. Correct resolution is still picked, but it looks like being non-native.

Note You need to log in before you can comment on or make changes to this bug.