[Bug 100923] New: ACPI _LID usage model change

[bugzilla-daemon at freedesktop.org]

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

            Bug ID: 100923
           Summary: ACPI _LID usage model change
           Product: DRI
           Version: XOrg git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: lv.zheng at intel.com
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20170504/c5b135c4/attachment.html>