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. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
