Hey, 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. 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. 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. 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 "hci". Any better ideas? Cheers -- 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
