> > 2 - Hardware key that does not control the hardware radio and does not report anything to userspace
>
> Kind of uninteresting button ;)
And this is the button that rfkill was originally designed for.
Laptops with integrated WiFi cards from Ralink have a hardware button that don't send anything to
userspace (unless the ACPI event is read) and does not directly control the radio itself.
And this event should be reported by a generic approach right? So it should
be similar as with your point 2 below. But this would mean that the driver
should create the input device. Or can a driver send the KEY_WIFI event
over a main layer without the need of a personal input device?
I am not that familiar with the input device layer in the kernel, and this is
my first attempt on creating something for it, so I might have missed something. ;)
> 3. A device without transmitter but with a button - just register with
> input core. Userspace will have to manage state of other devices with
> transmitters in response to button presses.
This is clear too. Rfkill is only intended for drivers that control a device with
a transmitter (WiFi, Bluetooth, IRDA) that have a button that is intended to
do something with the radio/transmitter.
> Does this make sense?
Yes, this was what I intended to do with rfkill, so at that point we have
the same goal.
>
> I don't think a config option is a good idea unless by config option
> you mean a sysfs attribute.
I indeed meant a sysfs attribute. I should have been more clear on this. :)