https://bugzilla.novell.com/show_bug.cgi?id=382784
User dcbw@redhat.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=382784#c15
--- Comment #15 from Dan Williams
(In reply to comment #13 from Dan Williams)
(In reply to comment #12 from Danny Kukawka)
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.
If HAL can't find out the correct state on startup, the state will we ALLWAYS wrong, if the initial state isn't correct. Guessing the current state is a no-go. And that's why the whole discussion make no sense because HAL shouldn't provide any unreliable information.
No, the state won't always be wrong. You assume a default saved state, which is exactly what NM would be doing anyway. 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. 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".
And if you use SIOCSIWTXPOW to control the state of WLAN HAL also can't know the correct state.
Wrong; current ipw drivers set the rfkill state to "softkill" (1) when you set txpower off. When the user flips the hardkill switch, it sets the state to "hardkill" (2). Read the rfkill sysfs file to get the current state. But HAL doesn't distinguish between soft and hard kill, which is a bug in HAL that we need to fix anyway. If the driver is softkilled via WEXT, it needs to notify userspace that it has been softkilled. There are really 3 states: RF On, RF Softkilled, RF hardkilled. Drivers need to handle all 3.
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.
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. 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? They are rfkill _switch_ objects in the HAL GDL, _not_ radio objects. 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) 2) Fix the spec to state that the rfkill button objects don't reflect radio state, but instead the button state 3) Remove the SetPower() method on the rfkill button objects 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 -- 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.