Re: [PATCH v3 1/2] ACPI / button: Add KEY_LID_CLOSE for new usage model

On Mon, 2016-07-18 at 09:53 +0200, Benjamin Tissoires wrote:

<snip>

I don't think this is a good solution to have a kernel parameter. I
thought the final decision were to have userspace decide which event
was valid, and so we just need to export and emit both of events.

_If_ you export a kernel parameter, it makes sense to have a dmi
blacklist to have a good default experience, which is what you wanted
to avoid.
So if you just export and use both events at the same time, you will
have:
- correct ACPI machines will just have an extra KEY_LID_CLOSE event
emitted, which will not harm logind
- wrong ACPI machines will not have their SW_LID input event updated
because it will be kept closed. But given that logind will ignore it,
there is no harm either

As Dmitry said, we could also have a KEY_LID_OPEN emitted for
symmetrical purposes, but I am not entirely sure if this will confuse
userspace or not. On the other hand, there are few users of these
states, and we can teach them how to properly use them.

So in the end, I think you should just get rid of the kernel
parameter, export SW_LID, KEY_LID_CLOSE, KEY_LID_OPEN in the event
node, and only add the KEY_LID_CLOSE|OPEN events on an actual acpi
notification.

Then a small hwdb entry set will teach logind/powerd if they need to
ignore the SW_LID event or not.

So user-space would have its own blacklist (likely in udev through an
hwdb), instead of having it in the kernel? That seems like a fine idea
to me, and one of the first consumers, logind, would have all the
necessary data straight away.