Bug 1430259 - [kernel] internal display not disabled for a docked Lenovo ThinkPad T400 with closed lid and external monitor attached
Summary: [kernel] internal display not disabled for a docked Lenovo ThinkPad T400 with...
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 26
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
: 1444229 1444727 1446097 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2017-03-08 08:35 UTC by Joachim Frieben
Modified: 2018-02-28 16:09 UTC (History)
24 users (show)

Fixed In Version: kernel-4.11.4-300.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-02-28 16:09:02 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Linux Kernel 187271 0 None None None 2019-01-22 18:50:10 UTC

Description Joachim Frieben 2017-03-08 08:35:59 UTC
Description of problem:
For current Fedora 26, only a grey background appears on the external monitor attached to the docking station of a (docked) Lenovo ThinkPad T400 after booting up the system even when the lid is closed. After opening the lid it turns out that the login manager is actually shown on the internal display which should have been turned off altogether.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Boot Lenovo T400 which is docked with an external monitor attached and lid closed.

Actual results:
Only a grey background is shown on the external monitor after the system has entered graphical mode. The login manager turns out to be displayed on the internal display although the lid is closed.

Expected results:
The login manager should appear on the external monitor attached to the docking station and not on the internal display when the lid is closed.

Additional info:
- This is working correctly for Fedora 25.
- The external monitor is connected to the DVI connector of the docking station.

Comment 1 Joachim Frieben 2017-03-23 10:21:29 UTC
For Fedora 26 Alpha 1.2, this issue also affects the live CD: the internal display is powered on and is the primary display even though the notebook is docked, the lid is closed, and an external monitor is attached and powered on. The external monitor is configured as a secondary display and only shows the empty background. However, it is possible to modify the display settings in order to switch off the internal display.

Comment 2 Satish Balay 2017-04-05 18:28:56 UTC
I see the same issue. [with a Thinkpad T430s attached to a dock - and connected to external LCD with DVI cable]

My workaround is:
- on reboot: 'open', 'login' and 'close' the lid.
- on suspend/resume: 'open' and 'close' the lid.

Comment 3 Joachim Frieben 2017-04-18 15:33:46 UTC
This issue now not only affects Fedora 26 but Fedora 25, too, namely after upgrading from package kernel-4.10.9-200.fc25 to kernel-4.10.10-200.fc25.
This undesirable behaviour appears to be caused by the following upstream kernel commit listed in the changelog of kernel release 4.10.10:

commit 8d5dd97f55563634ad830ea47c709bc96606ad65
Author: Lv Zheng <lv.zheng intel com>
Date:   Tue Apr 4 19:32:27 2017 +0000

    ACPI / button: Change default behavior to lid_init_state=open
    [ Upstream commit 77e9a4aa9de10cc1418bf9a892366988802a8025 ]
    More and more platforms need the button.lid_init_state=open quirk. This
    patch sets it the default behavior.
    If a platform doesn't send lid open event or lid open event is lost due to
    the underlying system problems, then we can compare various combinations:
    1. systemd/acpid is used to suspend system or not, systemd has a special
       logic forcing open event after resuming;
    2. _LID returns a cached value or not.

It seems that the new policy is not appropriate for the common use case reported above. Please consider reverting this change, thanks!

Comment 4 Satish Balay 2017-04-20 14:01:47 UTC
(In reply to Joachim Frieben from comment #3)

>     [ Upstream commit 77e9a4aa9de10cc1418bf9a892366988802a8025 ]

Thanks! I can confirm this is indeed the cause.

Reverting this patch [and ecb10b694b72ca5ea51b3c90a71ff2a11963425a - a dependent change] and rebuilding kernel-4.11.0-0.rc7.git0.1.fc26 fixes the problem for me.

Comment 5 Satish Balay 2017-04-20 14:37:15 UTC
I see the following reference in the commit log


Comment 6 Joachim Frieben 2017-04-25 09:16:48 UTC
Since the recent 4.10.10 kernel, this issue affects Fedora 25, too.

Comment 7 Gijs Roeffen 2017-04-25 09:31:54 UTC
Can confirm, this also affects;

HP Elitebook 850/840 series with HP Ultraslim Docking station (powered on while docked)
Dell XPS 15 / XPS 13 with Dell WD15 / TB16 dock (powered on while docked)

Since Fedora 25, Kernel 4.10.10 update

Comment 8 Gijs Roeffen 2017-04-25 09:33:34 UTC
*** Bug 1444229 has been marked as a duplicate of this bug. ***

Comment 9 Justin M. Forbes 2017-04-26 12:16:29 UTC
*** Bug 1444727 has been marked as a duplicate of this bug. ***

Comment 10 Axel Sommerfeldt 2017-05-02 17:08:48 UTC
I can also confirm the problem and the behaviour described above. (Fedora 25, using Wayland, since Kernel 4.10.10 update, and still bad with current 4.10.13)

My setup:

Dell Latitude E7270 (Intel Corporation HD Graphics 520)
Dell Docking Station (E-Port Plus II)

BTW: If I use auto-login (avoiding the login process and therefore the main problem) the Gnome display settings show three available monitors: The two connected to the dock and the internal one. I need to open and close the lid to change the internal one to "lid close" and being disabled (greyed out) on Gnome display settings.

So it seems that the main problem is indeed that the internal display will not be recognized as "closed" and therefore not available on startup.

(Please ask for further details if needed.)

Comment 11 Satish Balay 2017-05-21 22:50:32 UTC
I see a couple more external bug tracker urls - so adding them here


Comment 12 Joachim Frieben 2017-05-28 15:32:11 UTC
*** Bug 1446097 has been marked as a duplicate of this bug. ***

Comment 13 Gijs Roeffen 2017-06-05 14:58:26 UTC

Seems like the 'button.lid_init_state=method' in the grub cmdline workaround is no longer working as of kernel 4.11 since they bluntly removed the function...


Comment 14 Marko Bevc 2017-06-05 15:26:14 UTC
Looks like it was a mistake and cmdline workaround should be back in next release:


Comment 15 Joachim Frieben 2017-06-05 16:19:53 UTC
Indeed, latest news by Greg Kroah-Hartman:
Patch "Revert "ACPI / button: Remove lid_init_state=method mode"" has been added to the 4.11-stable tree

Comment 16 Gijs Roeffen 2017-06-05 16:21:55 UTC
Thanks for the heads-up. Thing is that the "new" kernel provided by Fedora 25 Updates (4.11.3-200.fc25) does not contain the patch mentioned and thus breaks setups with Thinkpad / Dell docks.

So if applicable to you its better to avoid kernel 4.11.3-200.fc25 on Fedora 25.


Comment 17 Marko Bevc 2017-06-05 16:26:38 UTC
Yeah, confirmed not working on Lenovo X260 here and hopefully it will get included in next 4.11 F25 kernel!

Comment 18 Satish Balay 2017-06-07 22:25:42 UTC
I see the above 2 patches are reverted in 4.11.4 


I've installed 4.11.4-300.fc26.x86_64 from koji - and it works for me [without requiring 'button.lid_init_state=method' option]

Comment 19 Marko Bevc 2017-06-08 08:53:36 UTC
Cool, hope this hits stable for affected versions and gets released! :) After that we can mark this as resolved.

Comment 20 Marko Bevc 2017-06-09 18:47:03 UTC
Looks good now and 4.11.4 on FC25 works good on X260. Another note, from kernels 4.11 FB device limits resolution on 1920x1080 and not to maximum possible of my monitor: 2560x1440?

Comment 21 Bram Veenboer 2017-06-15 06:34:38 UTC
I just updated my FC25 installation and got kernel 4.11.4-200.fc25.x86_64, this resolved the issue for me (E7240).

No additional configuration (like the 'button.lid_init_state' parameter) was needed.

Comment 22 Marko Bevc 2017-06-15 09:00:22 UTC
Yeah, this was fixed in upstream 4.11.4 kernel and is working fine now. But on X260 I've got new issue now with frambuffer, when switching from UEFIfb to intel FB upon booting it switches from 2560x1440 to 1920x1080 when using external monitor on docking... It was working fine until 4.11 versions!

Comment 23 Joachim Frieben 2017-06-15 15:46:02 UTC
(In reply to Marko Bevc from comment #22)
This seems to be a different issue for which you should file a new bug then.

Comment 24 Marko Bevc 2017-06-15 15:55:59 UTC
(In reply to Joachim Frieben from comment #23)
> (In reply to Marko Bevc from comment #22)
> This seems to be a different issue for which you should file a new bug then.


Comment 25 Akshat Sikarwar 2017-11-15 22:11:44 UTC
This is back in Fedora 27. Running Thinkpad x230.

Comment 26 Laura Abbott 2018-02-28 03:57:31 UTC
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale. The kernel moves very fast so bugs may get fixed as part of a kernel update. Due to this, we are doing a mass bug update across all of the Fedora 26 kernel bugs.
Fedora 26 has now been rebased to 4.15.4-200.fc26.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
If you have moved on to Fedora 27, and are still experiencing this issue, please change the version to Fedora 27.
If you experience different issues, please open a new bug report for those.

Comment 27 Axel Sommerfeldt 2018-02-28 08:12:29 UTC
AFAIR this was fixed with 4.11.something.

With 4.15.3 and 4.15.4 there is a new and ifferent issue regarding booting the laptop in the docking station, but I'll better file a new bug report for this.

Comment 28 Marko Bevc 2018-02-28 09:28:25 UTC
Yes, this has been fixed somewhere along the way. Closing this one. Axel there is already issue opened for that one.

Comment 29 Marko Bevc 2018-02-28 09:30:50 UTC
Oh, cannot close this one - I think this can be safely be closed now. I had a similar one about same issue. Thanks.

Comment 30 Laura Abbott 2018-02-28 16:09:02 UTC
Thanks for letting us know.

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