On Wed, May 18, 2016 at 2:57 PM, Bastien Nocera <hadess@xxxxxxxxxx> wrote: > On Tue, 2016-05-17 at 16:27 +0800, Lv Zheng wrote: >> (This patch hasn't been tested, it's sent for comments) >> [cut] > > As mentioned previously, I'd be much happier if either: > - a new system was put in place that matched the ACPI specs and the way > they are used by Windows > - an additional tag/property was added to show that the API offered by > the LID switch is different from the one that existing since ACPI > support was added to Linux. I'm sorry, but I'm not following either of the above. > And I'd really appreciate it if you stopped saying that it's systemd's > fault. > > The kernel has offered an API to user-space that included the state of > the LID switch. To be precise, this is not what the kernel has been providing. It really is the state of the lid switch as reported by the platform firmware. The "as reported by the platform firmware" part appears to be missing from your argumentation and it is quite relevant, because the firmware, being what it is, messes up things at least occasionally, so by using that interface you may end up having to deal with a value that has been messed up by the firmware. Now, the kernel is not entirely innocent here, because it sometimes reports input events that it has not received to user space. That happens during system initialization and during resume from system suspend and is generally problematic, so I'd prefer to get rid of that behavior. That, however, has nothing to do with the spec compliance and/or the Windows' behavior. > And the state of the LID switch has been correct for > the majority of systems and devices for the past decade or so. The fact > that this device means that the LID state isn't reliable anymore means > that the kernel needs to communicate that to user-space. The problem, though, is that the kernel has no idea about the value being incorrect. It just passes the value over to user space and has no way to validate it. > I'm volunteering to modify systemd and UPower to respect the fact that > the LID switch state isn't available on those devices. If you want to > find something to blame, blame the kernel for implementing an API that > doesn't reflect what the hardware makes available. The API works as I described: it passes the value reported by the firmware to user space. I has always worked this way. Whether or not that is a useful API is a good question. I guess, however, that the fake input events reported by the kernel are really problematic here, because had they not been reported, you wouldn't have seen an incorrect lid switch state, most likely. -- 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
