Messages in this thread | | | Subject | Re: [PATCH 3/8] rfkill: handle KEY_RADIO and SW_RADIO events | Date | Sat, 12 Apr 2008 15:17:06 +0200 | From | Ivo van Doorn <> |
| |
On Saturday 12 April 2008, Henrique de Moraes Holschuh wrote: > On Sat, 12 Apr 2008, Ivo van Doorn wrote: > > On Saturday 12 April 2008, Henrique de Moraes Holschuh wrote: > > > On Sat, 12 Apr 2008, Ivo van Doorn wrote: > > > > On Friday 11 April 2008, Henrique de Moraes Holschuh wrote: > > > > > The *_RADIO input events are related to all radios in a system. There are > > > > > two: KEY_RADIO and SW_RADIO. > > > > > > > > > > Teach rfkill-input how to handle them. In particular, SW_RADIO is not a > > > > > toggle, but an absolute enable-or-disable command. > > > > > > > > Not sure what you are trying to achieve here, > > > > who triggers the SW_RADIO and why? > > > > > > Thinkpad-acpi issues EV_SW SW_RADIO when the user changes a phisical > > > switch in the unit. It is a switch, not a button: it has an ON > > > position, and an OFF position. > > > > Ok, and such a switch is always intended to control all radios? > > (in other words, it is the expected behavior it controls everything) > > In every device I have seen which had a non-type-specific radio switch? > Yes. > > If we need type-specific switches (and NOT buttons/hot keys) for, e.g., > Bluetooth, the correct thing to do is to add EV_SW SW_BLUETOOTH. The > same goes for WWAN, UWB, etc. But on laptops (which are the devices I > am dealing with), these switches (when they exist) are meant to block > *every* builtin radio and thus are not type-specific. > > I can easily see someone designing a gadget with type-specific switches, > but since nobody asked for such support yet, we don't have anything but > SW_RADIO defined in the input layer right now. > > So EV_SW SW_RADIO has "every radio" semanthics, just like KEY_RADIO.
Ok, thanks for the explanation. You can add this patch to my ACK list then. :)
Ivo
| |