https://bugzilla.novell.com/show_bug.cgi?id=382784
User dkukawka@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=382784#c7
Danny Kukawka
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. 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?
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.
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. 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). -- 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.