PowerDevil/new: Difference between revisions
Created page with "==Brightness== === Displays === Technical stuff, XRandR, Udev, helper... === Keyboards === Technical stuff, upower? udev as well? ==Inhibition== Types of inhibition, api, fd...." |
|||
| (5 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
=== Displays === | === Displays === | ||
Technical stuff, XRandR, Udev, helper... | Technical stuff, XRandR, Udev, helper... | ||
Smooth brightness change | |||
Try to avoid double brightness changing (some hardware is wired in a way that it does not require us to actually change the brightness, but we still have to show the osd) | |||
=== Keyboards === | === Keyboards === | ||
Technical stuff, upower? udev as well? | Technical stuff, upower? udev as well? | ||
| Line 7: | Line 9: | ||
Types of inhibition, api, fd.o spects | Types of inhibition, api, fd.o spects | ||
Note to myself: fd.o spec should inhibit dimming as well ? | Note to myself: fd.o spec should inhibit dimming as well ? | ||
===Technical bits === | |||
There are mainly 2 kind of inhibition an application can do: | |||
*System inhibition | |||
*Session inhibition | |||
Both are going to be implemented in libsolid/powermanagement. The System one will call systemd (for platforms supporting that), and Session will talk to PowerDevil. | |||
This will allow us to use libsolid from PowerDevil directly for the cases of System Inhibition so we will be able to remove a lot of code we have to either call systemd/upower/hal and to keep track of inhibitions. | |||
==== API ==== | |||
The API will be completely ASYNC, the current SYNC api will be kept depending of how much applications are using it. | |||
==Devices== | ==Devices== | ||
| Line 23: | Line 38: | ||
Should we agresively restore settings like we are doing right now? or should we trust the user knows what it wants every time? | Should we agresively restore settings like we are doing right now? or should we trust the user knows what it wants every time? | ||
Should we restore everything but brightness? | Should we restore everything but brightness? | ||
== Extensibility == | |||
Power Management is a tricky matter, we need it to be extensible so all use cases can be fit. | |||
for example, executing a script when AC is disconnected. | |||
== Backends == | |||
We need multiple backends, a clear example of it is KDE Connect. Question is, how do we want them to look like? | |||
First idea is Binary plugins, just good old QLibrary but that might be dangerous given that an in correct written plugin might break all app's linking to libsolidpower. | |||
Another idea would be create some kind of DBus api that people can use to add batteries, it could even have the same API UPower have... just in different service/path. This will be safe and will allow third parties to create batteries in a safe way. | |||
== Technical Bits == | |||
PowerDevil has a backend architecture that should be moved into a library which allows to perform the operations that currently are possible in those backends. | |||
A great example of what should be avoided is The Solid::PowerManagement API, which relays on having powerdevil running to support different backends. | |||
Latest revision as of 10:40, 10 October 2013
Brightness
Displays
Technical stuff, XRandR, Udev, helper... Smooth brightness change Try to avoid double brightness changing (some hardware is wired in a way that it does not require us to actually change the brightness, but we still have to show the osd)
Keyboards
Technical stuff, upower? udev as well?
Inhibition
Types of inhibition, api, fd.o spects Note to myself: fd.o spec should inhibit dimming as well ?
Technical bits
There are mainly 2 kind of inhibition an application can do:
- System inhibition
- Session inhibition
Both are going to be implemented in libsolid/powermanagement. The System one will call systemd (for platforms supporting that), and Session will talk to PowerDevil.
This will allow us to use libsolid from PowerDevil directly for the cases of System Inhibition so we will be able to remove a lot of code we have to either call systemd/upower/hal and to keep track of inhibitions.
API
The API will be completely ASYNC, the current SYNC api will be kept depending of how much applications are using it.
Devices
dpms
Technical info, most probably port to xcb
dimdisplay
Technical info
Suspend
Technical info (suspend vs hibernation vs hybrid)
Special buttons
Lid
What should happen by default? and when you plug a monitor?
Power
Showing menu by default?
Restore settings
Should we agresively restore settings like we are doing right now? or should we trust the user knows what it wants every time? Should we restore everything but brightness?
Extensibility
Power Management is a tricky matter, we need it to be extensible so all use cases can be fit. for example, executing a script when AC is disconnected.
Backends
We need multiple backends, a clear example of it is KDE Connect. Question is, how do we want them to look like? First idea is Binary plugins, just good old QLibrary but that might be dangerous given that an in correct written plugin might break all app's linking to libsolidpower.
Another idea would be create some kind of DBus api that people can use to add batteries, it could even have the same API UPower have... just in different service/path. This will be safe and will allow third parties to create batteries in a safe way.
Technical Bits
PowerDevil has a backend architecture that should be moved into a library which allows to perform the operations that currently are possible in those backends.
A great example of what should be avoided is The Solid::PowerManagement API, which relays on having powerdevil running to support different backends.