Re: Wireless hotkey support

[Dan Williams <dcbw redhat com>]

On Wed, 2007-01-31 at 16:30 +0000, Matthew Garrett wrote:
> 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?

Well, if we do actually want the "one key to rule them all" model, then
wouldn't it be simpler to have a global wireless rf-enabled state in
hal?  I think that's what you initially proposed before I misunderstood
and asked for a signal-per-device.  NM would then bring down the devices
if they weren't already hardware-disabled by some other mechanism.  But
I don't think this model is decided yet.  We keep going back and forth
on netdev about it.

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

Oh man.  WHY? WHY? WHY?  I seriously don't get it; because nobody has
actually explained to me before what the reason would be to disable one
and not the other.  Not that I'm opposed to it, but it seriously
complicates the interaction for everybody else for apparently little
reason.  I personally think it's acceptable that if you want to disable
bluetooth but not wireless, right-click on your DE's panel and tell
bluetooth to turn off.  But the interaction model should not be popping
up a dialog or stepping between all 4 combinations (which requires you
to look at all your status icons 4 times to ensure you really have done
what you want).

It comes down to a question of whether that button is really an rfkill
button, or just a really quick and easy way to turn off your wireless.
If people are using it to save battery life, then that's _not_ the right
way to go about saving battery life.  Maybe I have some outdated notion
that you only really want to use it when you're on a plane or in a blast
zone.

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

Yeah, thankfully most of these tend to be USB devices which would just
magically work.  Too bad the 802.11 stuff doesn't use PCI hotplug or
something.

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

What do you mean by "place"?  Does HAL actually talk to the driver or
hardware and do the radio disable?  Or does it just modify it's internal
per-device disabled 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.

I don't think the alternative is appropriate; hal doesn't touch network
device operation yet and probably shouldn't yet.  DavidZ and I have
talked about splitting pieces of NM out into hal addins, but that's a
ways off if it happens.

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

We need that too.  I had assumed that the _driver_ would be able to
present that information via sysfs or something, which means HAL could
pick it up or a script could poke /sys/class/net/wifi0/radio_state.

Basically, we really need to figure out whether it's rfkill-a-la-carte,
or global disable before making more of these types of decisions.

dan