responsibility for enabling/disabling bluetooth?

[Ben Liblit]

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?

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

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.

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.

Can't we do better?