dell-bluetooth - BT applet visible even without any adapter being present

[Martin Pitt]

Binary package hint: gnome-bluetooth

Since yesterday's update, I always have a BT applet in my panel; however, I do not have any BT adapters at the moment (I usually just plug it in when I need it). Before, it only showed the applet when an adapter actually was present, and I think we should keep it that way to avoid clutter.

[Martin Pitt (pitti)]

I suspect this was a regression in

gnome-bluetooth (2.28.1-0ubuntu1) karmic; urgency=low

  * new upstream release 2.28.1 - noteworthy changes:
    - bgo:595845 - The applet shows wrong connection information (LP: #440235)
    - bgo:595593 - Make sure pairing agents only bind to default adapter
    - bgo:593565 - Use "cell phone" instead of "mobile phone"
    - bgo:593170 - Minor string fixes
    - Move the pin handling code into a new library, libwizard
    - Fix invalid memory access in agent.c
    - Don't overwrite UUIDs when discovering known device (LP: #413053)

  * ship 61-gnome-bluetooth-rfkill.rules, which enables access to
    /dev/rfkill for users (LP: #436694, #441800); also see rh:514798
  * update libgnome-bluetooth7.symbols; add two new symbols

[Martin Pitt (pitti)]

This is even more confusing since the applet allows me to "Enable bluetooth", but there is no physical way to do so :-)

[Martin Pitt (pitti)]

Some discussion with Alexander showed that this probably wasn't a 2.8.1 regression, but was triggered with fixing the /dev/rfkill permissions. Now g-b displays the applet if the number of adapters is greater than 0 (should be false here), OR a killswitch is present.

This logic seems slightly broken to me. If I do not have any adapter, there is no reason to display it, ever. So at most it seems to me that the "|| killswitch" should be just dropped.

However, perhaps the intent was to do "num_adapters > 0 && killswitch->state == off"? (pseudocode). It does make sense to not display the icon while BT is disabled through the switch.

[Alexander Sack (asac)]

please run:

for i in /sys/class/rfkill/rfkill*; do echo Device; echo -n " Name: "; cat $i/name; echo -n " Type: "; cat $i/type; done

and see if you get any bluetooth type killswitches.

[Martin Pitt (pitti)]

Done:
--------------------------------
Device
  Name: phy0
  Type: wlan
Device
  Name: dell-wifi
  Type: wlan
Device
  Name: dell-bluetooth
  Type: bluetooth
---------------------------------

So it seems the BIOS does not quite disable it as much as it ought to.

[Martin Pitt (pitti)]

Or hang on, this is just for what the killswitch _can_ control. I don't actually have any adapter:

$ udevadm trigger --verbose --dry-run --subsystem-match=bluetooth
$

If I plug in my usb bluetooth dongle, your command adds a new one:

Device
  Name: hci0
  Type: bluetooth

and now udev also knows about it:

$ udevadm trigger --verbose --dry-run --subsystem-match=bluetooth
/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8.2/1-8.2:1.0/bluetooth/hci0
$

[Alexander Sack (asac)]

assuming that turning off bluetooth in bios is similar to turning on a hw killswitch, i wonder what you get
if you add a cat $i/state to the for loop?

[Alexander Sack (asac)]

besides from that getting the bluetooth-applet console output would be helpful as there are a bunch of g_message statements surrounding rfkill status et al

[Janne Hyötylä (janne-hyotyla)]

See also Bug #445462 for more confusion of the bluetooth states by gnome-bluetooth

[Martin Pitt (pitti)]

> assuming that turning off bluetooth in bios is similar to turning on a hw killswitch

I think it's stronger than that. When I turn it off in the BIOS, it doesn't appear anywhere in udev/kernel. If I killswitch my wifi, it still appears in iwlist, but you can't use it.

> i wonder what you get if you add a cat $i/state to the for loop?

All say "2". (This means "disabled", if it's the same value interpretation as for wifi killswitches)

[Martin Pitt (pitti)]

$ bluetooth-applet -d
** Message: adding killswitch idx 2 state 2
** Message: Reading of RFKILL events failed
** Message: killswitch 2 is 2
** Message: killswitches state 2
** Message: killswitch 2 is 2
** Message: killswitches state 2

[Alexander Sack (asac)]

got something more or less similar for dell bluetooth: bug 445462

[Alexander Sack (asac)]

i found this discussion wrt rfkill patches and dell-laptop.c in our kernel ... http://patchwork.kernel.org/patch/37539/

Tim (rtg), since you submitted that patch, did we ever apply something like that? I couldn't see that commit in linus tree and wonder if not-having/having that might cause this bug (and bug 445462).

[Alexander Sack (asac)]

marking as dupe of bug 445462 for now.