https://bugzilla.novell.com/show_bug.cgi?id=382784
User dcbw@redhat.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=382784#c10
--- Comment #10 from Dan Williams
(In reply to comment #8 from Dan Williams)
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
Direct hardware disable only happens in _some_ cases. In some cases it's a GPIO pin that the chip reads directly and notifies the driver. In other cases, the driver reads the value and disables rf. In other cases it's a laptop specific ACPI event. In yet other cases it's a straight input button. I know this.
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).
That's fine; you could still have a tool to do this if there was a system-wide killswitch in HAL. When the bit flips in HAL, you ask the user what they want to do.
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!
Since the input rfkill button is obviously not tied to a wireless device, there is nothing that SetPower() could or should do. It should simply return an exception when SetPower() is called. It should only report the state of the switch with GetPower(). And yes, there are different places for the rfkill events to come from. There's the kernel's rfkill framework, there's the ipw-specific rfkill stuff in the device's sysfs directory, there's ACPI events, and there's the input-layer buttons. That's 4 different places that rfkill information comes from. NetworkManager is NOT going to abstract these 4 different places. That's HAL's job.
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).
But it doesn't provide an abstraction for _all_ rfkill buttons. Again, HAL would provide the state of the button, but not the policy. The "user interaction" you talk about is the Policy, and that's fine to handle with NetworkManager. But NetworkManager is not going to provide the abstraction, since that's HAL's job. NM would certainly turn off the radios if the GetPower() call on this virtual killswitch was FALSE. NM would not call SetPower() on the device, because as you state, HAL has no idea how to handle that. Again, the _state_ should be handled in HAL. The _policy_ should be handled in NM. Whether the button is on or off is state, and what to do about that state when it changes is policy.
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:
I completely understand what happens.
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.
I don't expect HAL to turn the power on and off. I simply expect HAL to report the current power state of the rfkill button (either on or off).
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.
Again, I don't expect HAL to handle SetPower() for virtual rfkill buttons. I only expect HAL to report the GetPower() state for the virtual buttons. Obviously something like NetworkManager will handle the policy and user interaction once the user turns the switch off. But NM has to know that the switch got turned off in the _first_ place, and that's the job of the Hardware Abstraction Layer to report. Once NM knows the power state changed, NM can ask the user just what they want to turn off, and do it. HAL would not be involved in actually turning off anything.
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.
rfkill is not fully abstracted in HAL, because HAL doesn't handle all the different types of rfkill switches yet. Not all laptop-specific modules (like tpbuttons, fujitsu-laptop, toshiba-laptop, etc) have been converted to use the kernel's rfkill layer. HAL doesn't handle input-layer rfkill buttons. Some drivers like ipw2x00 don't use the in-kernel rfkill layer. Therefore it's not abstracted, since HAL doesn't completely abstract it.
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.
I have read the HAL spec. I understand it. And HAL doesn't abstract input-layer rfkill buttons that are not tied to a specific hardware device. Remember, just because there's a switch on the laptop _doesn't_ mean that it disables the device in hardware when the switch is flipped. That only happens on some latops. The rfkill devices exposed in HAL are already system-wide rfkill switches, because some laptops don't tie the killswitch to a specific device. Therefore, it's exactly the same sort of thing as an input-layer rfkill switch, which is also system wide. Remember: HAL rfkill button objects are _not_ tied to a specific hardware device; some just happen to be, but that was never the intention becuase it's just not possible. Again, the path forward is to create a virtual, system-wide rfkill switch object in HAL, that responds to GetPower() but returns an exception on SetPower(), and consumes input-layer rfkill events. It should toggle the GetPower() state of the object accordingly when the switch is pressed. Things like NM can then get the events, and act on them as necessary. HAL would not have to care about what specific devices get enabled/disabled. -- 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.