Hi Bastien, > I was wondering the reasoning behind the recent changes in rfkill > handling for hci interfaces, in particular the addition > of MGMT_STATUS_RFKILLED as an error message. > > Before those changes (for which I couldn't find an initial kernel side > commit), the Powered state of the adapter was tied to its rfkill > status. actually RFKILL was never tied to the controller's power state. Neither via mgmt nor via the old legacy ioctl that do the hciconfig hci0 up. We also have an ERFKILL errno error code introduced for RFKILL a long time ago. It is a special error code that you would get when trying to hciconfig hci0 up or even ifconfig wlan0 up (in case of WiFi). RFKILL does two things, a) force an interface down in case it is up and you RFKILL block it, b) return an error when you try to bring up a blocked interface. It always worked this way. The MGMT_STATUS_RFKILLED is just the mgmt error status equivalent of ERFKILL. > When a soft rfkilled device showed up, which was to be the default > adapter, bluetoothd would remember that it was powered, and unrfkill > it. If the state was unpowered, or it had been rfkilled, GNOME's > Bluetooth panel would set Powered to true, un-rfkill'ing the adapter. I do not remember that automatic un-rfkilling from within bluetoothd. Maybe Johan and Luiz remember something in this area. > In 99% of cases, this meant that plugging in a Bluetooth adapter would > work out of the box. > > Now, bluetoothd doesn't remember the power state, and the rfkill isn't > tied to the Powered state. Calling to set the Power state will fail > with the "Blocked" error, and we're expecting something else to unset > the adapter's rfkill status. My feeling is that you are running into the case where something changed in the RFKILL subsystem or how systemd started to interact with RFKILL. I have seen the cases where it boots up with a soft-blocked state, but I never really tried to analyze the case. The automatic power and remembering of powered state has been removed since BlueZ 5.0, but recently we have introduced the AutoEnable main.conf option in case you prefer to always power on your adapters during early boot. This helps for cases where Bluetooth needs to be up before an user logged in, but it also means that no agent is available. So choose that option wisely. > What did the developers making those changes hope that would unrfkill > and power up the adapter when plugged in? > > Note that this might be a side-effect of the machine I'm using which > has 2 layers of Bluetooth rfkill: > $ rfkill list bluetooth > 0: tpacpi_bluetooth_sw: Bluetooth > Soft blocked: no > Hard blocked: no > 4: hci0: Bluetooth > Soft blocked: yes > Hard blocked: no > > hci0 won't be visible if tpacpi_bluetooth_sw is soft-killed. The work- > around I have planned is to wait for "hci*" to appear if the Bluetooth > rfkill we unset doesn't start with "chi". That is the Thinkpad specific platform RFKILL switch that kills the power to the USB device. Some platforms have this switches. They are owned by the platform or ACPI. The hci0 is the one represented by the Bluetooth subsystem. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
