Hi Ross, > 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. 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
