responsibility for enabling/disabling bluetooth?
liblit at cs.wisc.edu
Fri Jan 4 12:37:36 PST 2008
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
> 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?
More information about the hal