On Fri, 2020-04-17 at 16:18 +0200, Daniel Vetter wrote:
> > I suppose rf-kill is a bit similar.

RfKill is actually much more complicated, and I don't really see how it
is related. We may be in the situation where we cannot control the
hardware state, but RfKill has two entirely separate "block" states and
the real value is the logical OR of both.

Also, RfKill key handling is a mess as userspace needs to tell the
kernel it is handling the keys.

> > You'd have a userspace controlled property to state what the userspace
> > wants, and a kernel controlled property to show the hardware
> > state. Userspace can ask for one or the other, and usually this happens,
> > but the hardware hotkey bypasses the whole thing.
> >
> > It's not perfect. But I think just one property changed nilly-willy by
> > both the kernel and userspace (especially when it's really not in the
> > kernel's full control either) is going to be a PITA.
> 
> Yeah that's what we've done in other cases where both kernel and
> userspace can change stuff. These where just tri-states, but this here
> sounds like we need all for, so best to just have 2 properties.

As I see it, the requirements here are:
 * Userspace needs to be able to query the current state
   (possibly unavailable?)
 * Userspace needs to know whether it can set the property
 * Userspace needs to be notified about changes
   (by the firmware or possibly any other reason)

But, should never get into the situation that both the firmware and
software are trying to toggle the state in response to the same event.
In the case of the Fn-key, we'll either deliver a key-press to
userspace or just update the attribute because the firmware has already
handled it. Only one of these two possibilities may happen.

Benjamin