Re: Wireless hotkey support

[Matthew Garrett <mjg59 srcf ucam org>]

On Wed, Jan 31, 2007 at 11:10:16AM -0500, Dan Williams wrote:

> 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.

Ok, just to make sure I understand your opinion on this - hal should 
recognise that the key has been hit (whether from the keyboard 
controller, rfkill or whatever), ensure that all the cards are set to 
one state or the other and then let n-m know to bring the interfaces up 
or down as appropriate?

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

You'd actually be surprised - I've had several bugs from people asking 
for support for toggling between the four different combinations of 
bluetooth and wireless.

> 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.

Some machines do have more than one button, but I guess we just flag 
those in fdi files and treat things differently there. Though, to be 
honest, in most cases we have little influence over bluetooth anyway - 
the hardware tends to simulate plugging/unplugging.

> 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.

Ok. So how about the following:

1) User hits wireless button
2) Hal notices this event (somehow). Depending on its understanding of 
events, it places all controllable radios into either the on or off 
state.
3) Hal notifies n-m of this (or alternatively n-m gets a netlink event, 
but I don't think we have the infrastructure for that yet?)
4) n-m either downs the interfaces (which ensures that the hardware is 
powered down in the new world order) or brings them up and attempts to 
connect to the world again

? The alternative would be that step 4 is done by hal itself.

Thinking about it, while rfkill provides a mechanism for tying together 
the interface between kill switches and hardware, does it provide a 
common interface for userspace to determine whether an interface has a 
working radio?

-- 
Matthew Garrett | mjg59 srcf ucam org