https://bugzilla.novell.com/show_bug.cgi?id=382784
User dcbw@redhat.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=382784#c8
--- Comment #8 from Dan Williams
HAL needs to harvest rfkill input events that are simply input layer buttons and create an rfkill switch object in the device list for them
I don't see why HAL should track input events to disable/enable the killswitch. HAL already provide a killswitch object if available in the sysfs.
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.
NM (or maybe a desktop application) has to listen to the input events and has to react on them. I don't see a reason why hal should start to listen and handle input events. NM already handle the real killswitch objects (via HAL interfaces), why should hal now start to handle the other input events?
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. 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.
NM would enforce the _policy_ such that if that rfkill object's GetPower() method returned TRUE, NM would kill radios.
Why that? if GetPower() returns TRUE WLAN (or WWAN/Bluetooth) is already disabled. NM should IMO react on the already existing input events, disable the related interface and then call SetPower() if needed.
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.
What I really, really don't want to have is that some rfkill devices go through HAL, but other rfkill devices go through NM.
There are AFAIK _no_ rfkill devices that go through HAL and other that go through NM. HAL provides only an interface to get/set the current state (which is maybe set by the machine itself if you use the rfkill switch). HAL never set the state without someone that called the interface.
They either need to _all_ go through HAL or all go through NM, and right now HAL is the place for all rfkill state, not NM.
They have to go through NM. No, right now HAL isn't the place for the state, HAL provide only an interface to get/set the state from sysfs and other places.
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.
Btw. if you want HAL to do this, provide a patch and discuss it upstream. ATM IMO NM should do the handling of the input events and should call HAL to set it to sysfs (or the other tools).
Yes, that's the path forward. Until rfkill methods are standardized with a consistent interface, NetworkManager is not going to talk to them directly. We're NOT going to have 3 different codepaths to handle rfkill in NetworkManager. I see no reason why input event rfkill keys are any different than toggle rfkill keys. How the event gets delivered from the kernel is completely irrelevant; whether it's a sysfs file or an input event does not matter. What matters is having a consistent API for clients of rfkill state (ie, NetworkManager, others). -- 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.