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:
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
1: commit 858bc21f0637c407601a05626854ae58b242f75d
Author: Jesse Barnes <email@example.com>
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 <firstname.lastname@example.org>
Tested-by: Jan-Hendrik Zab <email@example.com>
Tested-by: Christoph Lukas <firstname.lastname@example.org>
Signed-off-by: Chris Wilson <email@example.com>
2: commit 01fe9dbde19a1a27b8ee63e2d964562962e1eb78
Author: Chris Wilson <firstname.lastname@example.org>
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 <email@example.com>
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
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]
Ok, I've taken another look at the problem. This reverts the following patch:
drm/i915: disable opregion lid detection for now.
- 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
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:
Author: Daniel Vetter <firstname.lastname@example.org>
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.