Bug 27622

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.

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

cheers,

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.

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?

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.

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.

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

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 :)

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...

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.

Created attachment 72536 [details]
revert-disable-opregion-lid-detection.patch

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

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

Fixes:
- 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?

Lemme test with mine...

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.

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'.

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.

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'.

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?

There already is i915.panel_ignore_lid for that purpose of forcibly marking the panel as present or absent during modeset.

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.

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.

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.

I'm using latest drm-intel-next-queued branch, at least for me problem #2 is not yet fixed.

Yeah, I know that #2 isn't fixed yet ...

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.

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

i915.panel_ignore_lid=0

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.

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.

Can you check with a printk that we still execute the opregion lid detect code? Just to rule out me being dumb ...

I guess the line

+	else if (i915_panel_ignore_lid = 1)

is wrong? Because after changing it to == it works for me.

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.

Boots and greets me with 1920x1200 pixel glory. :)

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

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.