So, we don't mess with the global state when we register the first
device for a type at all, which is how I thought the code worked indeed.
I don't understand what you mean with "So when there already is a switch
of that type present, then the value will be set to the state of the
first registered switch", then.
Err, where in sysfs can I set the global state of all bluetooth
switches, for example? I *can* loop all over the switches, find the
ones with a type of bluetooth, and change them. But that's NOT the same
thing.
Right now one needs rfkill-input loaded, and one has to send an
KEY_BLUETOOTH event from userspace. In the dark, I should say, because
one can't ask the kernel what the global state is, and any rfkill switch
could have its state different from the global state if someone
interacted with it directly over sysfs.
I will address this in a patch, I think. It will add a much cleaner way
for userspace to interact with the global states, and it will let the
used chose rfkill-input as an optional lightweight policy for the rfkill
switches and input events, OR to implement a heavy-weight one in
userspace.
Ok. So we assume the read-only ones are more important, and for the
*first* read-only rfkill switch registered for a type, we change the
global state for that type to match the switch state.
For read-only switches of type "any", we do that for all types that have
NO read-only switches registered, I suppose.
Let's call that behaviour a "master" rfkill switch. Its initial state
is forced on the global state when it is registered, and when it toggles
state, the global state is ALSO toggled.
We better ask the b43 maintainer about it, then.
Ah, ok.
So, it is better to make the initial state something drivers have to
provide in the rfkill_register call, IMHO. Otherwise, people will
forget to initialize that field, and we can't find that out unless we
manually inspect every code that calls rfkill_register.
Can we just have a bitfield flags field for rfkill devices, and use it
to host such information? Could be useful to define a read/write switch
as a "master" switch (i.e. one that behaves like the read-only switches
shall in the next round of these patches, and toggle the global state)
for example.
I really have some good uses for such a field, and it has to do with the
global states. You'll see it in the new patchset, when I finish it.
Drat, I wonder why I didn't find it when I searched for it in latest
mainline. I will read it now, and update it in any patches I write.
--
"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
--
