We are talking about different things. Please re-read the last three or
four messages before this one, thread-wise.
Ok, then we DO agree. Let's drop this point and go to the next one...
Actually, I am talking about ANY scenario where the kernel did not get a
chance to interfere with the RF toggle.
We must only broadcast master events, these switches are often tied to
each other in a tree, you can't report events on the leaves, just the
root. In a ThinkPad T60, you get an rfkill input device (that can be
read), which is hardwired into the WLAN card's rfkill input pin (that
can ALSO be read, and could potentially be registered as a rfkill
controller). The WLAN card has also a second rfkill controller, which
is in a config register.
I kept that in mind, that's why I started talking about master and slave
rfkill switches. Only the master ones can also be used as rfkill input
devices.
So yes, if there is a button involved, it must issue one (and only one)
input event. We agree on this.
As far as I can see, we actually agree in most issues related to rfkill,
maybe even in everything... but our terminology is NOT in sync, so it is
not immediately obvious that we do.
WHEN the kernel is the ONLY possible source of a radio controller state
change, it is not needed. For all other cases, we are either ignoring
the status changes (i.e. the kernel's idea of the current controller
state can be wrong), or using the input layer to resync (b43 tries to do
this).
It is a rare application that needs to know if a key is currently
pressed or not. And usually, it is assumed by the user that he should
not expect an application to know a key was depressed before it started,
nor are such applications usually written using shell script :-)
For switches, that's not rare at all.
It is not so different. But you could make the handling of that
information more generic if you could get it using just the rfkill
interface.
And it doesn't have much of an existence outside of when it generates an
input event. You don't ask a button where it is ON or OFF, that's a
switch property.
But that's not true for a real switch. You can ask it whether it is in
the ON or OFF state (for two-state switches, they can have a lot more
than just two states, but that's not relevant for rfkill).
I can see why we'd not want to export that through rfkill now that you
brought external keyboards into the picture. If I have an external
keyboard with a radio kill SWITCH (not key), I want it to work just like
if it were built-in the platform.
Which means it needs to be done in the input layer. Well, that gives me
my answer, in a rather definitive way too.
Actually, no, we don't.
AFAIK, input layer LEDs should go away, they belong in the LED class.
Keys have usage patterns that make it not necessary to export the
information of whether they are currently pressed or not through sysfs.
Utilities to query keyboard state are around for a long time as well.
Stuff that needs an axis position usually needs to track the axis (i.e.
they need a stream of data), so we are doing everyone a big favour if we
never ever let big bad stupid mistakes like that hdaps "position"
attribute's existence happen again.
As for writing the ioctl utility, it looks that it will be needed
without the sysfs attributes. But who will write it? Who will give it
a home? Maybe util-linux would take it in, if we're very lucky...
Agreed.
--
"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
--
