Adapters power management
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
Quoted 8 lines · 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::powerednot 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.
Quoted 4 lines
In the case that
Adapter::poweredhas 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/
Hi Alex,
Quoted 9 lines · Àlex Fiestas
Quoted 8 lines · 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::powerednot 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.
Quoted 6 lines
Quoted 4 lines
In the case that
Adapter::poweredhas 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 thinkingThat bluez could implement something similar so when the application that changed
Adapter::poweredto 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
Quoted 6 lines · On Sunday 23 March 2014 17:08:42 Johan Hedberg wrote:
Quoted 2 lines
That bluez could implement something similar so when the application that changed
Adapter::poweredto 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).