Hi, > > This patch is a resend of a patch I has been send to the linux kernel > > and netdev list earlier. The most recent version of a few weeks back > > didn't compile since I missed 1 line in my patch that changed > > include/linux/input.h. > > > > This patch will offer the handling of radiokeys on a laptop. > > Such keys often control the wireless devices on the radio > > like the wifi, bluetooth and irda. > > Ok, what was the conclusion on the following issues? > > 1) What about rfkill keys that aren't routed via software? There are > two modes here: (a) the key is not hardwired to the module and the > driver is responsible for disabling the radio, (b) the key is hardwired > to the module and firmware or some other mechanism disables the radio > without driver interaction. I thought I'd heard of some (b) hardware, > mostly on older laptops, but does anyone know how prevalent (b) hardware > is? If there isn't any, do we care about it for now?
On condition a) The driver is supposed to read the button status by the method provided by the device. (i.e. reading the register) the rfkill will periodically poll the driver (if the polling method has been provided by the driver) and the rfkill will do its work when the status of the register has changed. With the input device open, the user can listen to the events and switch off the radio manually (by using a tool like ifconfig or through the sysfs field) When the input device is not open, rfkill will use the driver provided callback functions to enable or disable the radio. b) In this case an interrupt is usually send to the driver about the event, or still the register will be possible. On both occassions the signal can still be caught by rfkill and handled further. If the event is send to userspace so the user can still perform tasks, the user can however not use the sysfs field to change the radio status since it is only allowed to switch the radio to the status that the button indicates. But the user can still perform tasks that should be handled (like stopping programs that need the network). I have heard that the broadcom chipsets toggle the radio state without intervention of the driver, and instead only send an interrupt event. > 2) Is there hardware that has separate keys for separate radios? i.e., > one key for Bluetooth, and one key for WiFi? I know Bastien has a > laptop where the same rfkill key handles _both_ ipw2200 and the BT > module, but in different ways: it actually removes the BT USB device > from the USB bus, but uses the normal ipw rfkill mechanism. Don't know about this hardware, my laptop has 2 seperate buttons for wifi and bluetooth. But it would be quite hard to caught such events cleanly, in this case the option would be to register 2 seperate rfkill_key structures. That way the key is represented twice to the user. But the enable_radio and disable _radio callback functions from the driver would make the callback for the wifi and bluetooth radio individually possibly. > 3) How does this interact with HAL? What's the userspace interface that > HAL will listen to to receive the signals? NetworkManager will need to > listen to HAL for these, as rfkill switches are one big thing that NM > does not handle now due to lack of a standard mechanism. In userspace there are 2 ways to listen, either regularly check the sysfs entry for the status. Or the prefered way listen to the input device that is created for each key. > In any case, any movement on rfkill interface/handling standardization > is quite welcome :) True, there are currently a lot of methods floating around. And a single way to notify the user would be a nice idea. :) Ivo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
