https://bugzilla.novell.com/show_bug.cgi?id=382784
User dkukawka@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=382784#c16
--- Comment #16 from Danny Kukawka
(In reply to comment #14 from Danny Kukawka) [...] No, the state won't always be wrong.
Oh, yes it wouldn't be always wrong ... only in 50% of the cases if you assume two possible states.
You assume a default saved state, which is exactly what NM would be doing anyway.
You can't assume some random default state if the device is diabled or enabled. That would only produce unreliable and possible wrong information.
NM isn't going to store the rfkill state, NM is going to start the radios powered up until the user or some other process tells NM to rfkill them.
I don't want NM to power up any device only to set it to a default state. If I disable WLAN under windows or an other Linux session I want to have it disabled also if I boot my actual Linux. The state should not change and it should be also the same over a reboot or shutdown/boot cycle. One example: I sit in a plane and disabled the WLAN in the airport, then I reboot in the airplane: I don't want NM or HAL to enable the WLAN again only to get a default state. Thats wrong behavior.
The _only_ way you know the state of the radio is if there is a toggle switch on the laptop that the user has switched to "off".
Then the state is possibly wrong until the user toggle the switch. Thats no option.
Btw. You are obviously wrong: The current rfkill interface/method don't tell the state of the button or switch, it tells you the state of the radio (from HAL SPEC: "This interface provides a mechanism for both querying whether a radio is on as well as turning it on and off.")
The spec does not reflect reality. Again, not every killswitch is directly related to a hardware radio, so how could the killswitch _possibly_ reflect the state of the radio???? It only reflects radio state for _some_ devices, those where the rfkill state is directly handled by the hardware device and driver.
It does not matter if the spec reflect the reality. It reflects what is described in the spec. And the description is clear. Also because this is for the already existing devices in HAL which all work the same AFAIK. GetPower() returns the state that is set in sysfs or the bios (in the case of the Dell machines) for the currently supported devices. There is nothing wrong in the specification of HAL. The SPEC is not wrong only because you want something different than the current situation.
IMO we have NM (and removed network stuff from HAL) because NM is the network abstraction layer. Because of this NM should also listen the input layer (and HAL) and handle all the network related stuff like the network related buttons. Only NM can know the correct state of the radio, HAL can't.
Wrong. The driver knows the correct radio state, whether it's on or off. And the kernel can/should know about hardware button state too. Sometimes that's tied to the radio state, sometimes its not tied to the radio state.
But this don't change the fact that NM is the abstraction layer for network.
If the radio state was tied to a specific device as you keep saying, why wouldn't it be a property on the actual wifi device itself instead of a property on the rfkill button object?
Because there is currently no state property for such devices! There is only a DBus method to get the current state of the radio.
They are rfkill _switch_ objects in the HAL GDL, _not_ radio objects.
Doesn't matter. What matters is actually what is written in the spec.
The way to clean this up is to:
1) Put radio state on the actual radio devices themselves; the WWAN/BT/WIFI/WIMAX device would have a 'rf.radio.state' parameter of 0 (on), 1 (softkill), or 2 (hardkill)
That's not possible for all keyboard buttons, because HAL don't know if the keyboard button has to handle WLAN or/and other radio devices. And adding a device to any radio make also no sense because you can have more than the internal radio devices (and you can detect if a internal UMTS USB card is internal or external) and keyboard button don't need to affect neccessarly the external (USB/PCMCIA/IR) devices (or the user want to differ between internal and external devices). What's if the system has more than one WLAN or bluetooth device? Adding the same keyboard botton to both? What if both devices are in different states? ...
2) Fix the spec to state that the rfkill button objects don't reflect radio state, but instead the button state
That would break the current behavior.
3) Remove the SetPower() method on the rfkill button objects
Why? Maybe an other application than NM wants to set the sysfs attributes also!
4) Add a SetState() call to the network device to set the state to 0 (on) or 1 (softkill); since 2 is a hardkill the radio obviously cannot be taken out of state 2 except by a physical user interaction over which the software has no control
Btw. It make no sense to continue the discussion. The current HAL is maybe not perfect, but what HAL currently do, as in the spec described, is correct. NM could simply listen to the input layer (this is no rocket science!) for now to fix the problem for the current product. If HAL get ever changed it would not be for the current product (openSUSE 11.0). Discuss this in the upstream bugzilla. The discussion ends for me here. -- 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.