I'm finishing the port of KDE's bluez interface to BlueZ5 and I am wondering a
few things about power management.
First thing is, why is Adapter::powered not hook into rfkill? Is there any
difference power consumption-wise whether the power state is true or false?
I look into the source code and only saw code to monitor the rfkill state but
not for modifying it.
In the case that Adapter::powered has an impact on power consumption, then the
ideal state is to have it to false as much as possible. Are there any plans to
make that easy for frontend developers? In a sense this is very similar to
Inhibitions in systemd[1] so I was thinking
On Sunday 23 March 2014 17:08:42 Johan Hedberg wrote:
> > That bluez could implement something similar so when the application that
> > changed Adapter::powered to true exists the state is set back to false.
>
> How would you suggest to make this work together with Bluetooth mice and
> keyboards that need to be connected or at least able to initiate
> connections on demand (when you press a button or move the mouse).
My idea was to enable Bluetooth for a few minutes after boot and resume so
mouse/keyboard have a chance to connect at least on laptops (given that in
that form factor you have the touchpad always present).
Hi Alex,
On Sun, Mar 23, 2014, ?lex Fiestas wrote:
> On Sunday 23 March 2014 01:42:49 you wrote:
> > I'm finishing the port of KDE's bluez interface to BlueZ5 and I am wondering
> > a few things about power management.
> >
> > First thing is, why is Adapter::powered not hook into rfkill? Is there any
> > difference power consumption-wise whether the power state is true or false?
> > I look into the source code and only saw code to monitor the rfkill state
> > but not for modifying it.
> >
> > In the case that Adapter::powered has an impact on power consumption, then
> > the ideal state is to have it to false as much as possible. Are there any
> > plans to make that easy for frontend developers? In a sense this is very
> > similar to Inhibitions in systemd[1] so I was thinking
> That bluez could implement something similar so when the application that
> changed Adapter::powered to true exists the state is set back to false.
How would you suggest to make this work together with Bluetooth mice and
keyboards that need to be connected or at least able to initiate
connections on demand (when you press a button or move the mouse).
Johan
On Sunday 23 March 2014 01:42:49 you wrote:
> I'm finishing the port of KDE's bluez interface to BlueZ5 and I am wondering
> a few things about power management.
>
> First thing is, why is Adapter::powered not hook into rfkill? Is there any
> difference power consumption-wise whether the power state is true or false?
> I look into the source code and only saw code to monitor the rfkill state
> but not for modifying it.
>
> In the case that Adapter::powered has an impact on power consumption, then
> the ideal state is to have it to false as much as possible. Are there any
> plans to make that easy for frontend developers? In a sense this is very
> similar to Inhibitions in systemd[1] so I was thinking
That bluez could implement something similar so when the application that
changed Adapter::powered to true exists the state is set back to false.
Sorry for the double email.
Cheers.
[1]http://www.freedesktop.org/wiki/Software/systemd/inhibit/