summaryrefslogtreecommitdiff
path: root/dbus
Commit message (Collapse)AuthorAgeFilesLines
* device: Only handle Refresh() method if in debug modeBastien Nocera2022-04-191-1/+1
| | | | | | | | | | | | | | | | | The Refresh D-Bus method could be used by clients to force re-reading the state of batteries in the upower backends. This is not needed as all the backends should be sending events when their states changes, removing the need for an explicit refresh. This is also a potential security problem if applications keep on refreshing their data. We now only allow access to the Refresh() method if the daemon was started in debugging mode. This should make it clearer that it is a debug tool. Also remove a mention of the never implemented refresh-power-source polkit authorisation.
* Remove Wakeups APIBenjamin Berg2022-03-242-132/+0
| | | | | | | | | | | | | | | | The API relied on /proc/timer_stats which has been removed from the kernel in 2017. Since then, the API has been non-functional (yet incorrectly reporting support because the support test was buggy). Just remove it completely. The debian codesearch does not uncover any API users. Also, I doubt that any new API (based on tracing scheduler events as perf would do) would map well to what exists now. i.e. if something like this is re-implemented in UPower or elsewhere, then the API should likely look different. And, realistically, if this does need root privileges (i.e. can't be moved to use BPF programs or so on user units), then we can also create a new small daemon that is launched on-demand just for that.
* dbus: Add ChargeCycles propertyBastien Nocera2021-09-131-0/+11
|
* build: Remove autotoolsBastien Nocera2021-09-061-64/+0
|
* meson: Fix header/source extraction from gdbus_codegenBenjamin Berg2021-09-061-2/+2
| | | | | Otherwise we depend on the C sources being ready rather than the headers for building the rest of upowerd.
* build: Support building upower with mesonBenjamin Berg2021-09-021-0/+39
|
* docs: Mention that not all batteries are laptop batteriesBastien Nocera2019-05-071-0/+6
| | | | | They might be device batteries where the device type is not known or catalogued.
* docs: Mention to try and not use IconName when possiblewip/hadess/no-icon-nameBastien Nocera2018-10-021-1/+2
| | | | See https://gitlab.freedesktop.org/upower/upower/merge_requests/16#note_41003
* docs: Better documentation for the BatteryLevel propBastien Nocera2017-10-311-1/+6
| | | | https://bugs.freedesktop.org/show_bug.cgi?id=103361
* all: Add BatteryLevel propertyBastien Nocera2017-04-061-0/+33
| | | | | | | | | | Export approximate battery levels that devices can use, exported by the kernel as POWER_SUPPLY_CAPACITY_LEVEL_* values. This avoids bizarrely accurate values showing up in UIs when we only have ok/warning levels of accuracy in some cases. https://bugs.freedesktop.org/show_bug.cgi?id=100359
* UpKbdBacklight: Add new BrightnessChangedWithSource signalHans de Goede2017-02-151-0/+28
| | | | | | | | There are multiple possible causes for the keyboard brightness to change, e.g. SetBrightness may get called, or the brightness may get changed through a hotkey which is handled in firmware. https://bugs.freedesktop.org/show_bug.cgi?id=98404
* Share generated code between daemon and libraryCosimo Cecchi2015-07-295-0/+1217
Since we use the same GDBus code in libupower-glib and the daemon, auto-generate a private library that can be used by both.
View Lorry Controller Status