Mailinglist Archive: opensuse-bugs (19584 mails)
| < Previous | Next > |
[Bug 382784] NM don't react on WLAN button and don' t set kill switch status correctly
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Tue, 13 May 2008 10:10:00 -0600 (MDT)
- Message-id: <20080513161000.E20F4CC7B1@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=382784
User dcbw@xxxxxxxxxx added comment
https://bugzilla.novell.com/show_bug.cgi?id=382784#c10
--- Comment #10 from Dan Williams <dcbw@xxxxxxxxxx> 2008-05-13 10:10:00 MST ---
(In reply to comment #9 from Danny Kukawka)
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.
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.
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.
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.
I completely understand what happens.
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).
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.
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.
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.
User dcbw@xxxxxxxxxx added comment
https://bugzilla.novell.com/show_bug.cgi?id=382784#c10
--- Comment #10 from Dan Williams <dcbw@xxxxxxxxxx> 2008-05-13 10:10:00 MST ---
(In reply to comment #9 from Danny Kukawka)
(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.
| < Previous | Next > |