ACPI 控制方法 Lid Device 的特殊使用模型

摘要

包含lids的平台使用控制方法lid设备将lid状态（打开/关闭）传递给OSPMs。为了实现这一点，AML 表发出 Notify(lid_device, 0x80) 以在lid状态发生变化时通知 OSPM。必须实现lid设备的 _LID 控制方法，以将lid的“当前”状态报告为“打开”或“关闭”。

对于大多数平台，_LID 方法和 lid 通知都是可靠的。但是，也有例外。为了与这些异常的有缺陷的平台一起工作，应该考虑特殊的限制和例外。本文档描述了 Linux ACPI lid设备驱动程序的限制和例外。

_LID 控制方法返回值的限制

_LID 控制方法被描述为返回“当前” lid 状态。然而“当前”一词具有歧义，一些有缺陷的 AML 表在最后一次 lid 通知时返回 lid 状态，而不是在最后一次 _LID 评估时返回 lid 状态。在运行时评估 _LID 控制方法时不会有差异，问题在于其初始返回值。当 AML 表使用缓存值实现此控制方法时，初始返回值可能不可靠。有些平台总是返回“关闭”作为初始 lid 状态。

lid 状态变化通知的限制

存在缺陷的 AML 表永远不会在 lid 设备状态更改为“打开”时发出通知。因此，无法保证“打开”通知。但可以保证，当 lid 状态更改为“关闭”时，AML 表始终会通知“关闭”。在 Windows 上，“关闭”通知通常用于触发某些系统省电操作。由于它经过了全面测试，因此从所有 AML 表中来看都是可靠的。

ACPI lid 设备驱动程序的用户空间用户的例外情况

ACPI 按钮驱动程序通过以下文件将 lid 状态导出到用户空间：

/proc/acpi/button/lid/LID0/state

此文件实际上调用了上面描述的 _LID 控制方法。根据前面的解释，它在某些平台上不够可靠。因此建议用户空间程序不要仅依赖此文件来确定实际的 lid 状态。

ACPI 按钮驱动程序向用户空间发出以下输入事件：

• SW_LID

ACPI lid 设备驱动程序的实现是为了尝试将平台触发的事件传递给用户空间。但是，鉴于存在问题的固件无法确保“打开”/“关闭”事件成对出现，ACPI 按钮驱动程序使用以下 3 种模式以避免触发问题。

如果用户空间尚未准备好忽略不可靠的“打开”事件和不可靠的初始状态通知，Linux 用户可以使用以下内核参数来处理可能出现的问题：

A. button.lid_init_state=method：指定此选项后，ACPI 按钮驱动程序将使用 _LID 控制方法的返回值报告初始 lid 状态，而“打开”/“关闭”事件是否配对完全取决于固件实现。

　　此选项可用于修复某些平台，其中 _LID 控制方法的返回值可靠，但缺少初始 lid 状态通知。

　　当用户空间尚未准备好处理有缺陷的 AML 表时，此选项是默认行为。

B. button.lid_init_state=open：指定此选项时，ACPI 按钮驱动程序始终将初始 lid 状态报告为“打开”，而“打开”/“关闭”事件是否配对完全取决于固件实现。

　　这可能会修复某些平台中 _LID 控制方法的返回值不可靠且缺少初始 lid 状态通知的问题。

如果用户空间已经准备忽略不可靠的“打开”事件和不可靠的初始状态通知，Linux 用户应该始终使用以下内核参数：

C. button.lid_init_state=ignore：指定此选项后，ACPI 按钮驱动程序将永远不会报告初始盖子状态，并且会实施补偿机制，以确保始终将“关闭”输入事件与补充“打开”输入事件配对，从而始终将可靠的“关闭”通知传递到用户空间。

　　但是，由于某些 AML 表无法可靠地发送“打开”通知，因此仍然无法保证在 lid 实际打开时可以将“打开”通知传递到用户空间。

　　在此模式下，如果平台固件正确实现了所有内容，则旧的用户空间程序仍应正常工作。否则，新的用户空间程序需要与 ACPI 按钮驱动程序配合使用。在用户空间准备好处理有缺陷的 AML 表后，此选项将成为默认行为。