Persisting power state when set via rfkill directly

Persisting power state when set via rfkill directly

[Ross Burton]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

Hi,

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?

Ross
-- 
Intel Open Source Technology Centre
http://oss.intel.com/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: Persisting power state when set via rfkill directly

[Marcel Holtmann]

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

Re: Persisting power state when set via rfkill directly

[Bastien Nocera]

On Wed, 2009-11-04 at 01:52 +0900, Marcel Holtmann wrote:
> 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.

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.

Cheers

Re: Persisting power state when set via rfkill directly

[Marcel Holtmann]

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

Re: Persisting power state when set via rfkill directly

[Bastien Nocera]

On Wed, 2009-11-04 at 02:16 +0900, Marcel Holtmann wrote:
> 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.

For the little light to go off, for us to be able to tell the user that
there's no Bluetooth adapters because the hardware killswitch is on.

Even if we had a UI to handle killswitches (say, press button, dialogue
pops up and asks you which devices you want to disable), we'd need
special handling just for Bluetooth devices because of the original
problem Ross mentioned.

> 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.

I know, and I still think it should be bluetoothd. What else knows that
the device was rfkill'ed as opposed to just being plugged in?

Re: Persisting power state when set via rfkill directly

[Marcel Holtmann]

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.
> 
> For the little light to go off, for us to be able to tell the user that
> there's no Bluetooth adapters because the hardware killswitch is on.
> 
> Even if we had a UI to handle killswitches (say, press button, dialogue
> pops up and asks you which devices you want to disable), we'd need
> special handling just for Bluetooth devices because of the original
> problem Ross mentioned.

let me repeat this. Don't misuse the RFKILL switches for persistent
power state control. Once it is unblocked we have to get it back into
the state that it was before. Especially with the hard kill switches.

And it is RFKILL design that an interface that has been taken down by
RFKILL will not be brought up by RFKILL. That is the system daemon (in
this case bluetoothd) that does that based on a power state of it.

> > 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.
> 
> I know, and I still think it should be bluetoothd. What else knows that
> the device was rfkill'ed as opposed to just being plugged in?

There is no difference between a device plugged in and down or killed by
RFKILL. You are making assumptions base on some laptops with platform
switches where they take the device off the bus. Please stop assuming
there are only these. There is a reason why we added OP_CHANGE_ALL since
these switches are the worst. And whatever you try to express with them
will fail one way or another for someone else.

Have the Bluetooth UI use the Powerd property and let RFKILL be handled
by something else that can make proper decision and has the policy
implemented that the user really wants.

Regards

Marcel