The same thing that happens if userspace is in charge and doesn't
cooperate or if rfkill-input is not loaded: the rfkill driver state is
never updated (remember, it is about the radio controller, not the input
device).
The input layer does not provide a way for userspace to get access to
the current state of any switches easily (or at all?). It just exports
events reporting these states sometimes.
We could fix it in the input subsystem, instead. How difficult (and
welcome a change?) would it be for the input device infrastructure to
provide pollable (for good measure!) "state" attributes for every EV_SW
event an input device registers in evbits+swbits ?
If the input subsystem exports that information, we can define that
slave read-only radio controllers must NOT be registered as rfkill
devices, and drop support for read-only rfkill devices, as all master
rfkill devices (which are input devices by definition) would get their
state exported to userspace through the input layer.
However, that DOES mean userspace would need to look for rfkill state in
two places. Input layer, to get the current state of the rfkill input
devices, and rfkill class to get the current state of the rfkill
radio controllers.
Yes. And that's the plan, actually. But it DOES NOT work at all with
the current mess, which used input events to keep the internal
rfkill->state state in sync with the hardware.
Let's decide this NOW, then. But if we decide to not do it in rfkill,
you will have to add attributes to every input device which has
registered itself as a source of EV_SW events.
We always had read/write rfkill controllers, they were just not properly
supported at all, and that is the root cause of the mess.
Anyway, do we fix read-only rfkill input device support in the input
layer (add access to their state using sysfs and make it clear they are
NOT to be registered with rfkill class) or in the rfkill class (add
read-only rfkill controller support)?
I better make it clear that I have NO idea how to properly implement the
required changes in the input layer if we go that way so if it is left
for me to do that work, it won't be ready anytime soon and it might be
supbar, so I'd appreciate lots of help in that case.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
