Hi, I'm from Linux kernel ACPI community. We've been reported issues that: If a laptop connects an external monitor via its dock with its lid closed. 1. On some platforms, after resuming, the external monitor couldn't be lit on. https://bugzilla.kernel.org/show_bug.cgi?id=187271 https://bugzilla.redhat.com/show_bug.cgi?id=1430259 2. On some platforms, after resuming/booting, the internal display is lit on. https://bugzilla.kernel.org/show_bug.cgi?id=195455 It's bisected to an ACPI change to change acpi button driver's default mode from button.lid_init_state=method to button.lid_init_state=open. That's intentional as recently there have been more and more platforms: 1. some of them return a cached value from _LID control method and the value is not updated by the AML code, so after a resume, it might be remained "closed", causing _LID to return "closed"; 2. some of them never notify after a resume. Some proofs for why _LID and lid open event is not reliable: https://bugzilla.kernel.org/show_bug.cgi?id=89211 https://bugzilla.kernel.org/show_bug.cgi?id=106151 https://bugzilla.kernel.org/show_bug.cgi?id=106941 https://bugzilla.novell.com/show_bug.cgi?id=326814 You can also find explanations and conclusions in Documentation/acpi/acpi-lid.txt. So finally, it turns out to be: 1. the _LID returning value is not reliable unless an AML Notify(lid_device, 0x80) is received; 2. _LID open event is not ensured by many BIOS tables. _LID returning value is only reliable after OSPMs received a BIOS triggered LID notification. Though BIOS triggered lid notification is relible, BIOS could stop triggering "open" event and then OS generated post-boot/resume lid notificactions are not that reliable. Such os faked events could report user/kernel space with wrong lid states. And from the fact and Windows GUI, we also can conclude that the only BIOS ensured usage model of ACPI control method lid device is to "suspend upon receiving a LID close event" (in control panel, power options). Thus the ACPI button driver provides 3 operation modes: 1. button.lid_init_state=method, the old mode, after booting/resuming, it sends a LID notification to userspace/kernel drivers using the _LID control method returning value (this mode has been removed from kernel recently) 2. button.lid_init_state=open, systemd now requires kernel to notify LID open to userspace otherwise it may suspend the platform again, and if kernel doesn't send any notification, it may also suspend the platform again. That's why we changed to use this mode before systemd make changes 3. button.lid_init_state=ignore. This only generates LID notification when the underlying BIOS generates LID notification. "button.lid_init_state=ignore" in fact is the preferred behavior where OSPMs will stop generate unreliable lid events. But now we have 2 usage models dependent on the unreliable but sometimes working post-boot/resume lid faked events: 1. systemd 2. graphics lvds drivers All above userspace/kernel space wrong usage models should make changes accordingly. ACPI button driver cannot find a way to have all such unwanted usage models working. For the above i915 related issue, we can see code in drivers/gpu/drm/i915/intel_lvds.c trying to listen to lid notifications to make decision whether a modeset should be performed. I'm not an expert of graphics, after glancing at it, it looks like the code is relying on "post-boot/resume lid notifications" to make decisions. Maybe my reading is wrong, could someone here also tell me whether the piece of code is related to this issue and how it is supposed to function? Also we noticed that it looks nouveau developers have already been aware of this problem. In nouveau drivers, external monitor users should use nouveau_ignorelid module parameter. http://www.linuxquestions.org/questions/linux-newbie-8/blank-screen-on-lid-close-nomatter-what-i-do-4175445108/ So maybe it's time for i915 to change to be able to work without post-boot/resume ACPI lid notifications.
The kernel modification committed by Lv Zheng triggered https://bugzilla.redhat.com/show_bug.cgi?id=1430259 which affects a system with an AMD Radeon RV620 video device; thus, the issue goes beyond the Intel driver i915. Since kernel 4.10.10, the internal display is active and used as primary display after powering on the system even when it is docked and the lid is closed permanently.
It's not simply a regression. if you check the linked bugs. You'll see there are buggy AML tables (buggy from lid notifiers' point of view, but not from Windows compliance's point of view). For that platforms, user actually should specify "button.lid_init_state=open" to appeal systemd in order not to enter a suspend/resume cycle. And "button.lid_init_state=close" to appeal x.org to light on correct monitors. The 2 options are entirely mutual exclusive. So the unexpected usage models of lid control method device must make changes. And this report is meant to notify the desktop developers to change. Thanks Lv
Changed category due to suggestion from Benjamin Tissoires <benjamin.tissoires@redhat.com> Thanks Lv
Strictly from GNOME's point of view (i.e. I'm not talking for systemd) I'd be happy to drop all lid event/state checks if the drm drivers started reporting the lid display's connector as disconnected when the lid is closed. Is that possible?
Well, this issue is not related to libinput but to the use of acpi_lid_open() by the intel i915 driver (in drivers/gpu/drm/i915/intel_lvds.c). It has been shown that on some platforms the ACPI _LID call is not reliable and only the closed event is sent. drivers/gpu/drm/i915/intel_lvds.c ignores the value provided by the lid notifier (unsigned long val parameter), and does it's own call to acpi_lid_open(). IMO, we should either enforce i915 to use the provided value (as sent by Lv in https://patchwork.kernel.org/patch/9713021/), or make sure acpi_lid_open() returns the fixed value (so no change from the i915 driver would be required).
Hi, Benjamin I'm afraid this bug is not related to the use of ACPI lid APIs. That's just a small cleanup, and we won't file a bug here for that. It's talking about a possibility that if graphics can determine internal/external display status without using ACPI lid APIs.
I'm also having same question as "Rui Tiago Matos". On the other hand, is that possible for i915 to just save internal/external monitor status and restore saved status after being resumed? Or if i915 don't do anything, will BIOS do that for graphics driver? Knowing the answers to these 3 questions are the purpose of opening this bug.
Hello, I'm adding platforms reported on the mentioned bugs(In reply to Lv Zheng from comment #0) > Hi, I'm from Linux kernel ACPI community. > > We've been reported issues that: > > If a laptop connects an external monitor via its dock with its lid closed. > 1. On some platforms, after resuming, the external monitor couldn't be lit > on. > https://bugzilla.kernel.org/show_bug.cgi?id=187271 > https://bugzilla.redhat.com/show_bug.cgi?id=1430259 > 2. On some platforms, after resuming/booting, the internal display is lit on. > https://bugzilla.kernel.org/show_bug.cgi?id=195455 > ... ... > > Some proofs for why _LID and lid open event is not reliable: > https://bugzilla.kernel.org/show_bug.cgi?id=89211 > https://bugzilla.kernel.org/show_bug.cgi?id=106151 > https://bugzilla.kernel.org/show_bug.cgi?id=106941 > https://bugzilla.novell.com/show_bug.cgi?id=326814 > You can also find explanations and conclusions in > Documentation/acpi/acpi-lid.txt. > > Thank you.
(In reply to Lv Zheng from comment #7) > On the other hand, is that possible for i915 to just save internal/external > monitor status and restore saved status after being resumed? You can unplug/plug displays and close/open the lid while being suspended.
As Peter mentioned, DMs (desktop managers) can start at any time. While there are tables (mostly from microsoft) that BIOS won't notify lid state change to OS (there are even worse case that lid state is always "closed"). Thus OS driver/input layer cached lid state value is not reliable for such notebooks. For current kernel input ABI, input driver can only use a timer to timely refresh the cached value to provide reliable lid state to userspace. But the timer is not power friendly. We should find different solutions. Either input layer could provide a new callback for driver. When userspace reads the latest lid state from kernel, input layer may invoke "get_state()" callback to update the cached state. Or userspace GMs should stop using lid state to determine window layout and monitor status. That's reasonable as ACPI lid is not provided for this purpose. Thanks Lv
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
All bugs mentioned on comment 0 are closed, is this still valid? https://bugzilla.kernel.org/show_bug.cgi?id=187271 https://bugzilla.redhat.com/show_bug.cgi?id=1430259 https://bugzilla.kernel.org/show_bug.cgi?id=195455 https://bugzilla.kernel.org/show_bug.cgi?id=89211 https://bugzilla.kernel.org/show_bug.cgi?id=106151 https://bugzilla.kernel.org/show_bug.cgi?id=106941 https://bugzilla.novell.com/show_bug.cgi?id=326814
Closing, please re-open is issue still exists.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.