Hi Bastien, > > > I see that bluez has support for saving the current power state to disk > > > (in /var/lib/bluetooth/[id]/config) when the Powered adaptor property is > > > toggled, so that the same state can be restored when restarted. > > > However, this only works if the powered state is toggled via the Bluez > > > DBus API, applications which directly touch rfkill (such as > > > gnome-bluetooth) don't cause the current mode to be persisted. > > > > > > From a quick look at the code I'd say that rfkill_event() shouldn't > > > return early if the adaptor was powered down and instead get the adaptor > > > pointer and write the new mode state. Does this sound reasonable? > > > > I explained a couple of times that gnome-bluetooth should not use RFKILL > > as a way to toggle Powered state. Use the D-Bus interface to do so and > > not go behind its back. RFKILL states are not persistent and we will not > > take RFKILL as an input for this. > > Funny that. I was telling Ross I already knew what your answer would be. > > Except that means handling both rfkill switches from the kernel, ignore > the soft killswitches that'll only change the powered state of adapters, > and then poke bluetoothd directly about those. > > That means gnome-bluetooth handling 2 types of killswitches. Which is > the type of problems that having a decent kernel rfkill subsystem is > trying to avoid. > > I'll also note that setting the Powered state on the adapter on the > bluetoothd side won't be updating the rfkill state to soft killed. > > So there's a few holes in your theory there. you are trying to use RFKILL for something that it is not. What you want is to power your Bluetooth adapter on or off. And we do hciconfig down for that adapter when Powered=false. This is as effective as using RFKILL and hope you hit the special platform one that takes it off the bus. We have a kernel with proper USB power saving for btusb now and it does the right thing when hciconfig down. The USB device will be powered down since all URBs are killed and the port will be switched off after some idle time. What else do you want. The RFKILL support is for a third entity that has to kill a radio technology for some reasons. Like policy, flight mode or because it is just a hardware button. And RFKILL itself is not persistent. You need something that makes it persistent and this will not be bluetoothd nor should it be the UI. 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
