ACPI 控制方法 Lid 设备的特殊使用模型¶
- 版权:
© 2016，英特尔公司
- 作者:
Lv Zheng <lv.zheng@intel.com>
摘要¶
带有盖子的平台使用控制方法 lid 设备向 OSPM 传达盖子状态（打开/关闭）。为了实现这一点，AML 表会在盖子状态发生变化时发出 Notify(lid_device, 0x80) 来通知 OSPM。必须实现 lid 设备的 _LID 控制方法，以报告盖子的“当前”状态为“打开”或“关闭”。
对于大多数平台，_LID 方法和盖子通知都是可靠的。但是，也有例外。为了处理这些特殊的有缺陷的平台，应考虑特殊的限制和例外情况。本文档描述了 Linux ACPI lid 设备驱动程序的限制和例外情况。
_LID 控制方法的返回值限制¶
_LID 控制方法被描述为返回“当前”盖子状态。然而，“当前”一词具有歧义，一些有缺陷的 AML 表返回上次盖子通知时的盖子状态，而不是返回上次 _LID 评估时的盖子状态。当 _LID 控制方法在运行时进行评估时，不会有差异，问题在于其初始返回值。当 AML 表使用缓存值实现此控制方法时，初始返回值很可能不可靠。有些平台始终返回“关闭”作为初始盖子状态。
盖子状态更改通知的限制¶
有一些有缺陷的 AML 表，当盖子设备状态更改为“打开”时，永远不会发出通知。因此，不保证“打开”通知。但是，可以保证当盖子状态更改为“关闭”时，AML 表始终会通知“关闭”。“关闭”通知通常用于在 Windows 上触发一些系统节能操作。由于经过了充分的测试，它在所有 AML 表中都是可靠的。
ACPI lid 设备驱动程序用户空间用户的例外情况¶
ACPI 按钮驱动程序通过以下文件将盖子状态导出到用户空间
/proc/acpi/button/lid/LID0/state
该文件实际上调用了上面描述的 _LID 控制方法。鉴于之前的解释，它在某些平台上不够可靠。因此，建议用户空间程序不要仅仅依赖此文件来确定实际的盖子状态。
- ACPI 按钮驱动程序向用户空间发出以下输入事件
SW_LID
ACPI lid 设备驱动程序的实现是为了尝试将平台触发的事件传递到用户空间。但是，鉴于有缺陷的固件无法确保“打开”/“关闭”事件成对出现，ACPI 按钮驱动程序使用以下 3 种模式以避免触发问题。
如果用户空间尚未准备好忽略不可靠的“打开”事件和不可靠的初始状态通知，Linux 用户可以使用以下内核参数来处理可能的问题
button.lid_init_state=method: 指定此选项后，ACPI 按钮驱动程序使用 _LID 控制方法的返回值报告初始盖子状态，并且“打开”/“关闭”事件是否成对完全取决于固件的实现。
此选项可用于修复某些平台，这些平台的 _LID 控制方法的返回值可靠，但缺少初始盖子状态通知。
在用户空间未准备好处理有缺陷的 AML 表期间，此选项是默认行为。
button.lid_init_state=open: 指定此选项后，ACPI 按钮驱动程序始终将初始盖子状态报告为“打开”，并且“打开”/“关闭”事件是否成对完全取决于固件的实现。
这可能会修复某些平台，这些平台的 _LID 控制方法的返回值不可靠，并且缺少初始盖子状态通知。
如果用户空间已准备好忽略不可靠的“打开”事件和不可靠的初始状态通知，Linux 用户应始终使用以下内核参数
button.lid_init_state=ignore: 指定此选项后，ACPI 按钮驱动程序永远不会报告初始盖子状态，并且实现了一种补偿机制，以确保可靠的“关闭”通知始终可以传递到用户空间，方法是将“关闭”输入事件始终与补充的“打开”输入事件配对。但是，仍然无法保证在盖子实际打开时，可以将“打开”通知传递到用户空间，因为某些 AML 表不会可靠地发送“打开”通知。
在这种模式下，如果平台固件正确实现了所有内容，则旧的用户空间程序仍然应该可以工作。否则，新的用户空间程序需要与 ACPI 按钮驱动程序一起工作。在用户空间准备好处理有缺陷的 AML 表后，此选项将成为默认行为。