MASTER dell-bluetooth - confusing/contradictory bluetooth killswitch status / rfkill behaviour - potential regression in dell-laptop.c

Actually, there seems to be also a limitation in functionality: I don't seem to be able to switch off bluetooth by software (i.e. from gnome-bluetooth). Maybe because gnome-bluetooth thinks that it is already off due to the dell-bluetooth device being shown as off regardless of the hardware switch?

feels related to bug 445326

can you please killall bluetooth-applet and start it from console and post the output you get for two cases:

 a) starting with killswitch off
 b) starting with killswitch on

and yes. if there is a hard lock shown in rfkill, gnome-bluetooth does not think it can change anything.

Can you explain a bit more what you exactly selected in bios? maybe because of that selection the driver somehow always says that its hard blocked?

.. obviously implying the question if changing your bios setup helps?

bluetooth-applet output started with

killswitch off (bt on):
================
** Message: adding killswitch idx 2 state 2
** Message: adding killswitch idx 7 state 1
** Message: Reading of RFKILL events failed
** Message: killswitch 2 is 2
** Message: killswitches state 2
** (bluetooth-applet:17619): DEBUG: Unhandled UUID 00005001-0000-1000-8000-0002ee000001 (0x5001)
** (bluetooth-applet:17619): DEBUG: Unhandled UUID 00005002-0000-1000-8000-0002ee000001 (0x5002)
** (bluetooth-applet:17619): DEBUG: Unhandled UUID 00005003-0000-1000-8000-0002ee000001 (0x5003)
** (bluetooth-applet:17619): DEBUG: Unhandled UUID 00005557-0000-1000-8000-0002ee000001 (0x5557)
** (bluetooth-applet:17619): DEBUG: Unhandled UUID 00005601-0000-1000-8000-0002ee000001 (0x5601)
** Message: killswitch 2 is 2
** Message: killswitches state 2

killswitch on (bt off):
================
** 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

above, idx 2 is dell-bluetooth,
and idx 7 is hci0. This "device" gets removed every time I flip the killswitch, and then gets added with incremented id when I turn bt on again.

I think the root cause is that dell-bluetooth is still shown as soft and hard off, and bluetooth-applet gets confused by that. The dell-bluetooth behaviour is weird anyway, I'll write more after a few reboots. That is possibly another bug in itself

See attachment for the BIOS setting.

Now to the weird dell-bluetooth behaviour:

When I start the laptop with killswitch off, I get the following:

$ rfkill list
0: hci0: Bluetooth
 Soft blocked: no
 Hard blocked: no
1: dell-wifi: Wireless LAN
 Soft blocked: no
 Hard blocked: no
2: dell-bluetooth: Bluetooth
 Soft blocked: no
 Hard blocked: no
3: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no

and

$ bluetooth-applet
** Message: adding killswitch idx 0 state 1
** Message: adding killswitch idx 2 state 1
** Message: Reading of RFKILL events failed
** Message: killswitch 0 is 1
** Message: killswitch 2 is 1
** Message: killswitches state 1
** (bluetooth-applet:9715): DEBUG: Unhandled UUID 00005001-0000-1000-8000-0002ee000001 (0x5001)
** (bluetooth-applet:9715): DEBUG: Unhandled UUID 00005002-0000-1000-8000-0002ee000001 (0x5002)
** (bluetooth-applet:9715): DEBUG: Unhandled UUID 00005003-0000-1000-8000-0002ee000001 (0x5003)
** (bluetooth-applet:9715): DEBUG: Unhandled UUID 00005557-0000-1000-8000-0002ee000001 (0x5557)
** (bluetooth-applet:9715): DEBUG: Unhandled UUID 00005601-0000-1000-8000-0002ee000001 (0x5601)
** Message: killswitch 0 is 1
** Message: killswitch 2 is 1
** Message: killswitches state 1

Switching the killswitch on:

$ rfkill list
1: dell-wifi: Wireless LAN
 Soft blocked: no
 Hard blocked: no
2: dell-bluetooth: Bluetooth
 Soft blocked: no
 Hard blocked: no
3: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no

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

Now bluetooth-applet shows a greyed out "Bluetooth: On" and a clickable "Turn off bluetooth", although it is already off, as correctly displayed with an X in the icon itself.

Clicking "turn off bluetooth" shows the following from bluetooth-applet:
** Message: updating killswitch status 2
** Message: killswitch 2 is 2
** Message: killswitches state 2
** Message: killswitch 2 is 2
** Message: killswitches state 2
** Message: RFKILL event: idx 2 type 2 op 2 soft 1 hard 1

** Message: killswitch 2 is 2
** Message: killswitches state 2

and:

$ rfkill list
1: dell-wifi: Wireless LAN
 Soft blocked: no
 Hard blocked: no
2: dell-bluetooth: Bluetooth
 Soft blocked: yes
 Hard blocked: yes
3: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no

At the same time, the option to turn BT off disappears from the applet icon, and clicking "Turn on Bluetooth" in the preferences window does not do anything.

After switching the killswitch off, I get:
** Message: killswitch 2 is 2
** Message: killswitches state 2
** Message: RFKILL event: idx 4 type 2 op 0 soft 0 hard 0

** Message: adding killswitch idx 4 state 1
** Message: killswitch 2 is 2
** Message: killswitches state 2
** Message: RFKILL event: idx 4 type 2 op 2 soft 0 hard 0

** Message: killswitch 2 is 2
** Message: killswitches state 2
** Message: RFKILL event: idx 4 type 2 op 0 soft 0 hard 0

** Message: adding killswitch idx 4 state 1
...

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

Tim, did we apply this? I couldn't see that commit in linus tree. do we have this?

given that this works well with other bluetooth chipsets, I think its safe to move this to linux for now. my bug account is still subscribed though ...

we also have some odd behaviour wrt intel wifi + dell + rfkill reported in bug 437940 and bug 441161 etc.

I can confirm this bug, it affects also my Dell Inspiron 1525.
There is also this one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/421662.

Main problem for me is because i use switch only for BT, and wifi is regulated from inside operating system.
When i boot with switch off(BT to be turned off) network manager disables my wireless and in applet it says wireless disabled (but my wifi led is on and i can use wifi for example: iwlist eth1 scan works..).

I can provide all logs and informations if it is needed to fix the bug. Feel free to contact me.

rmmod/modprobe dell_laptop seems to put things the way they should be.(wireless is enabled in network manager and i can connect to network from within network manager applet)

Bobenceto: I have the same problem, I left it out of this report to not confuse things further.

Alexander: Do you want to have wlan killswitch problems also in this bug or should this go in a new one?

Ah I just saw: Bug #441161 is exactly the wifi killswitch problem you and I experience Bobenceto. So we should move any discussion of it to that bug and leave this for bluetooth only.

Janne Hyötylä: Yes this is same problem we have. And it is not related to the wifi card driver or something like that. It is dell-laptop.c problem as someone noticed. We should hope this problem will be solved by the end of kernel freeze, since it affects whole spectrum of Dell laptops.

milestoning as this sems to affect a lot of dell laptops.

See also https://bugs.launchpad.net/ubuntu/+source/linux/+bug/441161/comments/26 and following comments.

With mainline kernel 2.6.31.3 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31.3/ normal functionality is restored.
I.e. independent on whether I boot with killswitch on or off, I can now turn on and off bluetooth by killswitch and/or software.

The main difference that I see now is that the hardware killswitch only adds and removes the 'hci0' device. The hard block on 'dell-bluetooth' stays on "no" all the time.

bluetooth-applet sets 'dell-bluetooth' soft block to yes, and also removes 'hci0' if it is present.

So this functionality is correct. What remains are small inconsistencies in the bt-applet menu regarding the BT state but this is minor.

this is a dupe of bug 430809 and is fixed in latest kernel update. please confirm. thx