> I am still not sure that tight coupling of input device with rfkill
> structure is such a good idea. Quite often the button is separated
> from the device itself and radio control is done via BIOS SMM (see
> wistron driver) or there is no special button at all and users might
> want to assign one of their standard keyboard buttons to be an RF
> switch.
Making sure rfkill supports keys that are not handled by the driver
is a bit hard. Just as drivers that can only check if the button is
toggled and not what the current state is.
The problem is that it is hard to make a clean split between the
2 different button controls. Not all drivers allow the radio to be
enabled while the button status are indicating the radio should
be off.
The buttons that are already integrated into the keyboard,
by example by using a Fn key combo don't control the device
directly. So the driver cannot offer anything to the rfkill driver.
Such buttons should be mapped in userspace without the help of rfkill,
since the kernel cannot detect if that key belonged to a radio
control key or not.
> I think it would be better if there was an rfkill class listing all
> controlled devices (preferrably grouped by their type - WiFi, BT,
> IRDA, etc) and if every group would provide an attribute allowing to
> control state of the whole group (do we realistically need to kill
> just one interface? Wouldn't ifconfig be suitable for that?). The
There have been mixed feelings on the netdev list about what should
exactly happen when the button is pressed. The possible options are:
1 - rfkill will kill all interfaces
2 - rfkill will kill all interfaces of the same type (wifi, bt, irda)
3 - rfkill will kill the interface it belongs to
Personally I would favour the second option, but used the third after hearing
objections to the second method. So since there are also fans of
the third option I think there should be a decision made about what the
correct option is, so rfkill can follow that method.
> attribute should be a tri-state on/off/auto, "auto" meaning the driver
> itself manages radio state. This would avoid another tacky IMHO point
> that in your implementation mere opening of an input device takes over
> RF driver. Explicit control allow applications "snoop" RF state
> without disturbing it.
Currently userspace can always check the state of the button whenever
they like by checking the sysfs entry.