Re: Wireless hotkey support

[Dan Williams <dcbw redhat com>]

On Wed, 2007-01-31 at 15:24 +0000, Matthew Garrett wrote:
> On Wed, Jan 31, 2007 at 10:11:56AM -0500, Dan Williams wrote:
> > On Wed, 2007-01-31 at 08:32 +0000, Matthew Garrett wrote:
> > > I've just submitted a patch to hal that should result in hitting a 
> > > wireless hotkey sending an event over dbus. The obvious next step is 
> > 
> > How does this jive with Ivo van Doorn's rfkill infrastructure that's
> > just been updated on netdev?  Or is this the HAL -> client part, which
> > will simply be triggered by whatever Ivo comes up with?
> 
> rfkill works in two ways, depending on whether or not an application has 
> opened the input device it provides. In the "default" mode, hitting the 
> rfkill switch will toggle the radio state directly, whereas if the input 
> device is open (which is what I'd imagine to be the default in a 
> hal-based system) it'll send a signal out to userspace instead. In some 
> cases, the radio will already have been brought down, but otherwise we 
> can then leave it to the policy daemon (n-m in this case). 

Ok, I think I know what you mean here.  I guess I'd rather have this
sort of thing in HAL.  If it's going to be a global "kill everything"
switch, having that in HAL makes sense.  David?  It doesn't quite feel
right to put this into NM, because NM isn't really that close to the
hardware, and NM isn't a standard tool that everyone ships, but I think
we view HAL in that light.

Seriously, what other possible reason than "kill my radio" could pushing
the "kill my radio" button mean? :)

> > > that n-m should catch this and toggle the wireless state. However, I'm 
> > > not entirely clear what level this should be done at - the daemon or the 
> > > applet? I'm leaning towards the daemon, since it's a system-wide event 
> > > and should ideally work even if there's no user logged in. Any other 
> > > opinions?
> > 
> > Definitely the daemon.  If the radio is dead, there's absolutely no
> > reason that NM shouldn't know about it _now_, so that it can clean up.
> 
> Makes sense.
> 
> > Furthermore, is this a per-device signal?  Because if it's not, it
> > should be; the rfkill infrastructure may or may not make the rfkill
> > signals be per-device, but HAL should certainly send out one signal for
> > each device whos radio is now dead.
> 
> In some cases, the wireless key is simply a key on the keyboard. 

It's a lot uglier than that:

1) ACPI key
2) BIOS handled, need to poll BIOS in vendor-dependent manner
3) normal keyboard key or input layer key
4) Key toggles GPIO pin on wireless card, card disables radio
5) Key just cuts radio, doesn't tell wireless card, but does 1, 2, or 3

All these cases are in the wild and were brought up at the wireless
summit.  You can't even tell with specific cards since it's all OEM
dependent.  HP may do something completely different than Dell even if
they both use the same ipw3945 card.

> Logically I guess we should tie that to any minipci card, but telling 
> the difference between an internal minipci card and a cardbus one (which 
> may have the same chipset) isn't going to be trivial. My instinct was 
> that the wireless key would be considered to be a global thing ("I don't 
> want wireless") rather than controlling an individual device, regardless 
> of how it's wired internally.

This is true; and I don't really care either way I guess.  To _me_
logically if I say "kill wireless" that means all of bluetooth,
GPRS/CDMA, and 802.11.  The corner case is if you have more than one
button on a laptop (does this happen?  ISTR it has) and if you slide the
bluetooth toggle button to off, but the 802.11 toggle is still "on",
what does that mean?  There's a ton of variability here; but I think the
corner case I brought up is exceedingly rare and I guess we shouldn't
care about it.

In the end, I think we just have to pick a policy and stick to it,
regardless of what kernel no-policy police say.  In our case, the policy
isn't really ambiguous, otherwise why did you hit the button in the
first place.

> > > Secondly, there needs to be some mechanism for keeping track of the 
> > > hardware state. While some buttons are implemented in software, others 
> > > are in hardware. It's important that we not get into a state where 
> > > hitting the hotkey disables the radio while causing nm to bring up the 
> > > interface, or vice-versa. Right now, different drivers seem to expose 
> > > this information in different ways, so presumably we want to look at 
> > > implementing this in hal as well?
> > 
> > No, this needs to be left to the rfkill patches.  The _driver_ needs to
> > maintain the rfkill state if the button is just another one-state
> > keyboard button and does not actually have two states.  The driver must
> > know when the radio is disabled, and that should be the source of the
> > information that HAL (eventually) uses to send out the signals for
> > rfkill to the HAL clients.  The driver needs to the be the _one_ stop
> > shop for device state.
> 
> No, that doesn't work for all cases. On my machine, for example, the 
> wireless key doesn't alter the radio state at all. In that situation, 
> it's network-manager that's going to get to decide what state to put the 
> hardware in.

Right.  The problem I have with all of this is that it will be pretty
hard to make sure that all the different variations of rfkill are
synchronized between the state keeper (HAL?) and the driver in the case
where the rfkill switch and the hardware are more tightly integrated
than your machine.

Dan