On Mon, 2016-02-22 at 07:24 +0000, Zheng, Lv wrote: > [Lv Zheng] > According to the knowledge of various BIOS _LID implementation, Linux > button driver doesn't seem to be working wrong. > It in fact works correctly and is able to handle all BIOS _LID > implementations. > > So this looks to me like a user space bug. I don't think it is one, given the kernel API for that functionality. If, instead of exposing the lid as an input switch, the kernel only ever sent an event saying "the lid is now closed" then we wouldn't have that problem, as we'd likely expect the lid to be opened when starting the machine (if present). > That the user space doesn't contain a proper mode to handle ACPI BIOS > _LID implementations. > > Why should kernel work this gap around? > The gap is: > The user space requires lid device to act in the way it wants. In the way that it's always worked up until now, rather. > While the ACPI BIOS only provides lid behavior that is working for > Windows power-saving settings. > IMO, > 1. Windows Only requires LID close notifications to trigger power- > save action and only evaluates _LID after receiving a LID > notification, > BIOSen only ensure _LID returning value is correct after a > notification. In which case, expecting the lid to always be opened on startup would probably be a fair assumption, no? > 2. But Linux user space requires all LID notifications to be > instantly/correctly reported and wants to know the exact LID states > whenever it reads the states from the sysfs. > It doesn't seem to be possible for the kernel to work between BIOSen > and the user space to fill such a gap. If you quirk the kernel lid handling to always be opened on startup, and we waited until the first event to correct it if necessary, seems like the easiest way to go. But that brings me the question of how Windows (and then Linux) behave when you've booted your laptop and closed the lid straight away, before any driver in the OS had the chance to be around to see the notification? It also brings the question of how Windows will know that the lid is still closed when coming out of suspend by pressing the power button, which can happen depending on the hardware design (it's certainly possible to press the power button with the lid closed on the Surface 3, and likely other Surfaces). I'm not happy about the "fix" for this problem either, but blaming user-space for this is harsh, given the API exported by the kernel and how pretty much every laptop worked. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
