Bug 1430259

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.

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.

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!

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

I see the following reference in the commit log

https://bugzilla.kernel.org/show_bug.cgi?id=187271

Since the recent 4.10.10 kernel, this issue affects Fedora 25, too.

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

*** Bug 1444229 has been marked as a duplicate of this bug. ***

*** Bug 1444727 has been marked as a duplicate of this bug. ***

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

I see a couple more external bug tracker urls - so adding them here

https://bugzilla.kernel.org/show_bug.cgi?id=195455
https://bugs.freedesktop.org/show_bug.cgi?id=100923

*** Bug 1446097 has been marked as a duplicate of this bug. ***

https://kernel.googlesource.com/pub/scm/linux/kernel/git/rafael/linux-pm/+/acpi-4.11-rc1%5E2..acpi-4.11-rc1/

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

Great.

Looks like it was a mistake and cmdline workaround should be back in next release:

https://patchwork.kernel.org/patch/9713013/

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

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.

(FYI)

Yeah, confirmed not working on Lenovo X260 here and hopefully it will get included in next 4.11 F25 kernel!

I see the above 2 patches are reverted in 4.11.4 

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.11.4&id=4c5681afdf984b5eec41b280d43b9934af0f3144
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.11.4&id=8f8dca3c86b3b7748968c38ec5b2bc40f85b018b

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]

Cool, hope this hits stable for affected versions and gets released! :) After that we can mark this as resolved.

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?

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.

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!

(In reply to Marko Bevc from comment #22)
This seems to be a different issue for which you should file a new bug then.

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

https://bugzilla.redhat.com/show_bug.cgi?id=1461926

This is back in Fedora 27. Running Thinkpad x230.

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.

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.

Yes, this has been fixed somewhere along the way. Closing this one. Axel there is already issue opened for that one.

Oh, cannot close this one - I think this can be safely be closed now. I had a similar one about same issue. Thanks.

Thanks for letting us know.