On Mon, 2016-01-04 at 10:11 -0800, Marcel Holtmann wrote: > 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. OK. > > 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. That's a more likely problem, yes. Removing the Bluetooth files in /var/lib/systemd/rfkill/*:bluetooth seems to solve the problem. I'll still need to find a way to avoid those inconsistent state problems. > 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. I was wondering whether changes around this were responsible for the problem. > > 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. Right, knew that, but was wondering whether the layering of rfkills, in addition to other changes, might have been the reason why this broke. 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
