https://bugzilla.novell.com/show_bug.cgi?id=382784
User dcbw@redhat.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=382784#c13
--- Comment #13 from Dan Williams
HAL don't need a "system-wide rfkill switch object" since there can be more than one rfkill (for different devices) and they can't and shouldn't go through one object. This make no sense.
I never said only _one_ killswitch object. There would be one for the toggle-switch if present, and one for input buttons. For example: my T41 doesn't have a toggle switch, but does have an ipw2200 which is perfectly capable of rfkill. I therefore have an "ipw" killswitch. But I also have Fn+F5, which should be represented as a _second_ killswitch that traps all input rfkill events. With this setup, NetworkManager can do the right thing.
And since the kernel send e.g. no events if you use a "real" rfkill switch HAL don't get any info if the state change. And for the other events you get
Right; you'll only get a button press. So HAL would store the power state for that button. When the button gets pressed, HAL toggles the power state and emits a signal for the power state change.
information from HAL (as e.g. IBM ACPI events which don't go through the input layer) or the input layer. NM needs only to listen to the input layer and HAL. And since NM already listen to HAL it shouldn't be rocket science to listen also to the input layer to get the other events.
But NM shouldn't have to listen to the input layer since that button state can also be handled by HAL transparently.
If there are rfkill types not supported by GetPower() (which returns the current state) you have to provide the information to add them to the existing HAL structure/script and they get supported.
Right; we should provide an input-layer rfkill button object for hal that works as I've described.
If there are rfkill-buttons which don't have a specific hardware device, how should HAL be able to get (and provide information) about the actual state of the button? Should HAL guess it? AFAIK the keyboard buttons have no state, you can't get information about the state.
HAL tracks the button presses of the item and toggles the power state accordingly. What the default state is when HAL starts, or whether that state gets save across reboots, I'm not sure.
The keyboard button event doesn't mean neccessary that the rfkill state change. Since a event don't neccessary mean that e.g. the state for WLAN rfkill change if you e.g. disable only WWAN/Bluetooth on the event (because of the user interaction). It make IMO no sense to do this in HAL since only NM can know the correct state in this case.
Remember; HAL isn't tracking _device_ state with this killswitch, it would only be tracking _button_ state. It's up to the consumer of the killswitch state in HAL to decide whether that on/off state applies to WWAN, BT, Wifi, or whatever. Obviously HAL shouldn't be in that business. But it should be in the business of reporting the _button_ state so that NM can disable the radios of the devices that NM has associated with the button.
(In reply to comment #11 from Dan Williams)
I should note that NM never has may never call SetPower(), for a few reasons:
If NM don't call SetPower() also GetPower() make no sense, since the state get never set back to the card or the sysfs. HAL can't tell you the correct state then.
No, GetPower() reports the _switch_ state for most items, and in the other cases NM will be disabling the radios via SIOCSIWTXPOW for wifi and otherwise for BT and WWAN. If the driver doesn't update it's rfkill state accordingly, then the driver needs to be fixed. Also, remember that not all devices are directly tied to the hardware. So calling SetPower() on a device with an ACPI-reported button doesn't do anything, because it's just a button and has no interface to the wireless device anyway. It's still up to NM to proxy that state back down to the wireless device. Even if you set up scripts in HAL to handle this, how would HAL know which device to take down? There's no sysfs mapping for the device and the rfkill thing because there _is_ no rfkill button for the device since it's an independent ACPI thing. Also, who knows what type of wifi card you have and therefore how to disable it in HAL? I could put an ipw card into the machine, and then you need to write values to the /sys/class/net/eth1/device/rfkill, or I could put a bcm43xx card into the box, and then you need to do something else. HAL + callouts just can't handle SetPower() in all cases. -- 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.