responsibility for enabling/disabling bluetooth?

[Bastien Nocera]

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

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)

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.

1) and 3) are dead-easy on their own (possibly a couple of hours each,
more for 3) if you want a decent UI), 2) is a bit harder as it might
require fixing the ibm_acpi kernel driver. Richard might know more about
that, Richard?

Cheers