https://bugzilla.novell.com/show_bug.cgi?id=382784
User dkukawka@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=382784#c9
--- Comment #9 from Danny Kukawka
Because the input events _are_ killswitch events. They are the same thing as the user flipping a switch on the laptop. To the user, it does not matter whether it's an input button Fn+F5, or whether it's a toggle switch somewhere. It's the same thing.
No, they are not the same (from the technical view). The keyboard input events are not the same as the real kill switch buttons. In the most cases of the real killswitch buttons go through the kernel and the hardware get disabled directly. The input events are different, because they need user interactions in many cases (e.g. if the input event isn't only for WLAN but also for bluetooth or WWAN. See for example ThinkPads and Fn+F5 where a tool from Lenovo ask the user what to diable WLAN or/and bluetooth).
And I don't see why there should be two places to handle the same thing: rfkill. There's still different driver interfaces in the kernel to handle rfkill, because some drivers (ipw2xxx and others) have custom rfkill handling and don't hook into the kernel's rfkill framework yet.
There are no different places currently. HAL never set the state of the rfkill. _NEVER_ without an other tool like NM that call hal to do so!
HAL is a Hardware Abstraction Layer. rfkill keys are hardware, irregardless of whether they are a toggle switch or a keyboard button. And since there are multiple methods of handling rfkill (kernel rfkill, ipw2x00, input event, vendor-specific module like tpbuttons, fujitsu-laptop, etc) there needs to be a hardware abstraction around them until they all use the same kernel interface.
This is what HAL already do. HAL provides an interface for e.g. NM to set the state back to sysfs/kernel. This is not the job of HAL, also because you need in several cases user interaction (see above).
If you create a machine-wide rfkill switch that just handles input events, then NM would already handle that killswitch automatically just like it handles toggle killswitches. No changes needed to NetworkManager at all. The cases we are talking about are _also_ machines without toggle killswitches, where the _only_ rfkill method is a keyboard key.
Looks as if you don't full understand what happens currently. Again: 1) HAL don't change the state of the rfkill. In some cases it's the kernel, in all other cases NM has to set the state via HAL if there is a event. 2) Why should HAL provide a machine-wide rfkill? There are different types of rfkill 'devices' (WLAN/WWAN/Bluetooth) and this is why HAL has more than one (if supported by the machine) rfkill device/interface. Also because you can have more than one WLAN/WWAN/Bluetooth card. In such cases you have to ask the user which of them (maybe all, maybe only WLAN or only Bluetooth) he would like to disable.
No, they WILL NOT go through NetworkManager until there's a standard kernel or HAL interface for ALL rfkill items. It's completely insane to put the hardware abstraction for rfkill stuff in to NetworkManager, when that's exactly what HAL is supposed to be doing right now. There's a standard rfkill interface in HAL: let's use it, not re-implement rfkill in two different places.
This all has nothing to do with hardware abstraction in NM. This all is _already_ abstracted in HAL. NM needs only to listen to the events and has to act on them. There is no need to abstract anything.
Yes, that's the path forward. Until rfkill methods are standardized with a consistent interface, NetworkManager is not going to talk to them directly.
AGAIN: THIS IS WHAT WE ALREADY HAVE! THERE IS ALREADY A standardized INTERFACE. READ THE HAL SPEC. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.