responsibility for enabling/disabling bluetooth?

[Dan Williams]

On Sat, 2008-01-05 at 14:37 +0000, Bastien Nocera wrote:
> On Fri, 2008-01-04 at 12:37 -0800, Ben Liblit wrote:
> > Bastien Nocera wrote:
> > > That key doesn't seem to say "disable bluetooth" but "disable wifi
> > > power", which means that policy should be implemented in user-space for
> > > it (making it a bit complicated to handle in just the one place).
> > 
> > I agree that the intended behavior of that key is unclear.  With 
> > previous ThinkPads I've owned, it toggled bluetooth only, not all 
> > radios.  When running Windows, this key brings up a networking control 
> > panel that allows one to connect to wireless networks and turn various 
> > radios (bluetooth, 802.11 WIFI) on and off individually or as a group.
> > 
> > That said, the current behavior on my current laptop under Linux is to 
> > do nothing at all.  *Anything* else would be preferable to this.  Even 
> > if there's one default treatment of the button which some users will 
> > accept and other user will modify, isn't it better to do something 
> > out-of-the-box instead of nothing at all?
> 
> Of course it's better, but catching the keypresses and acting upon them
> needs to be implemented somewhere. Currently, the best place to do this
> would be in NetworkManager, in my opinion, as all those radios are
> network enablers. If somebody wanted to implement a separate application
> to handle this (because they don't like the UI, or whatever), it would
> be trivial as we already have the input mechanism (via HAL), and the
> KillSwitch methods in HAL as well.
> 
> > > There's already a killswitch mechanism in HAL, which will correctly
> > > enable/disable Bluetooth on Dell and Sony (sonypi-supported) laptops.
> > > 
> > > You'd need to implement the same thing for IBM laptops, which would be a
> > > matter of a couple of lines of fdi file and shell scripting.
> > 
> > My ThinkPad X61 has a kill switch as well, which is *distinct* from the 
> > Fn+F5 button I was discussing when this thread started.  The kill switch 
> > works perfectly.  Putting it into the kill position disables all radios; 
> > I believe this happens at the hardware or BIOS level.  HAL detects that 
> > the radios have gone away, and other daemons like NetworkManager and 
> > bluez-utils' hcid also respond appropriately.  It works like a charm.
> > 
> > That's not the input element I'm interested in here.  I'm talking about 
> > the Fn+F5 key, which causes HAL to emit a "wifi-power" ButtonPressed 
> > signal that nobody else is listening for.  I've already figured out how 
> > to write a small Python script that catches and responds to this signal, 
> > but I think it's a shame that this didn't do something useful 
> > (*anything* useful) right out of the box.
> 
> The input element already works, we agree. What you don't understand is
> that we're not going to reimplement the "Do something" part of the
> equation for each piece of hardware.
> 
> Implement the KillSwitch (think "Software Killswitch") for IBM laptops
> in HAL, and the application that handles the action on button press will
> know how to deactivate Bluetooth, Wi-Fi or EVDO/HSDPA depending on your
> preferences, and whatever the model of laptop.
> 
> > Meanwhile, I raised this issue on the <bluez-users> mailing list.  Bluez 
> > developer Marcel Holtmann disagrees with Rui Tiago Matos's suggestion 
> > that this is bluez-util's responsibility.  Marcel writes:
> > > we discussed this some time ago at one of the BlueZ developer meetings.
> > > The overall agreement was that this should be handled via rfkill and/or
> > > HAL.
> > > 
> > > The reason for this is that the Bluetooth on/off switches are all
> > > different and HAL and rfkill is the way to abstract it into a common
> > > interface. It is not the job of hcid to abstract this.
> > > 
> > > Also when it comes to handle these events from HAL/rfkill, then we can
> > > discuss handling this inside bluez-gnome. Putting that code into hcid
> > > would be wrong.
> > 
> > However, Marcel does agree with Rui that the bluez daemons should start 
> > and stop automatically:
> > > The discussion about starting hcid from within HAL has been discussed
> > > and yes, eventually it will happen.
> 
> It seems that we're moving towards using D-Bus activation for that,
> rather than HAL singletons. It's not required to make the feature you're
> talking about work though.
> 
> > But that's a secondary issue.  We're still left with a situation in 
> > which the Fn+F5 key on this laptop does nothing useful out-of-the-box 
> > and the end user has to write their own custom scripts, possibly 
> > involving D-BUS and other nontrivial technologies, to make this key 
> > useful.  That's something I'm capable of, but many users won't be.
> 
> 1) Write support for KillSwitch for IBM laptops

It gets more complicated; 2.6.23 and 2.6.24 kernels have an rfkill
module that formalizes more rfkill stuff, and that all _driver_-level
rfkill stuff should use.  If the switch is hooked into the hardware
(toggles a GPIO pin or whatnot) that the driver polls or gets interrupts
for, the driver should be doing the right thing in the rfkill layer.

That includes vendor specific rfkill stuff, like sony_acpi, dcdbas (ie,
dellWirelessCtl should eventually die), etc.

For rfkill buttons that are purely input buttons, like the Fn+F5 for
example, that needs to get trapped by whatever reads input events.

The core problem is that there are multiple ways for rfkill buttons to
get implemented, some coming from the drivers themselves, others coming
from X, others coming from BIOS.  There needs to be some switchboard to
handle all of these, and HAL may not be able to (or perhaps should not)
try to be that switchboard, depending on where the events get delivered.

> 2) Make sure that we handle "wifi-power", etc. keys on IBM laptops and
> others with a clear policy (ie. does "wifi-power" mean there's also a
> "bluetooth-power", or is it a generic "wireless-killswitch" button?)
> (Also, the event should go via the kernel's input layer rather than
> HAL/ACPI, so the ibm_acpi/thinkpad_acpi driver might need fixing)

Probably need an out-of-the-way capplet here that lets the user (if they
so desire) specify which classes of radio (WLAN, WWAN, Bluetooth, IRDA,
UWB, etc) get killed by each switch their machine supports.  Ideally, a
sane default is picked by tools like NM if there is no policy in place,
but when a policy shows up, NM respects it.

> 3) In nm-applet, we'll need to catch the killswitch events (ie. the
> button press events) and do something with them. This is fairly trivial
> and we could default to "ask what to do" when the button is pressed.

Well, I'd rather this happen in NetworkManager itself, in response to
events delivered via HAL's killswitch objects.

I envision rfkill working like so; there are 3 parts:

1) a userspace daemon that handles the policy and catches events that
may not be available to HAL (input events perhaps).  In the gnome world,
Bastien proposed a gnome-settings-daemon plugin.  Ideally this component
is available as close to boot-time as possible, at least before login,
so that toggling the rfkill switch at boot time still works as expected.
This daemon would push the user-set radio category preferences to HAL.
Some UI tool would allow the user to match up radio categories with
specific switches.

2) HAL.  Each rfkill switch should be represented by an object in HAL,
and each switch should have a state.  That object should send D-Bus
signals when it changes state, either in response to the a
kernel/netlink/driver/poll-of-sysfs event, or in response to some
process calling setPower() on the object.  This object should also store
the policy; note that I did not say determine policy, only store the
policy that's determined by #1.  The 'killswitch.type' key should be
re-purposed to become a string _list_ containing one or more of:

[ wlan, wwan, bt, uwb, irda, <etc> ]

There should no longer be separate killswitches for each type of device,
unless there _are_ really two physical killswitches on the machine (for
example, the physical one, and an additional Fn+F5 one).

3) The actor, for example NetworkManager.  Listens for signals on the
killswitches and acts upon them.  Sometimes the device will already be
rfkilled when the signal gets to NetworkManager, in the case of switches
tied into the card in hardware.  In any case, NetworkManager determines
the categories of radio that the killswitch should affect, then proceeds
to set any device that matches that category (that is not already down)
down, usually !IFF_UP.  The driver should then turn off the radio and
power down the card, like wlan and ethernet drivers are supposed to do.

Dan