| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Update to the latest hwdb from NUT.
Link: https://networkupstools.org
Link: https://raw.githubusercontent.com/networkupstools/nut/master/scripts/upower/95-upower-hid.hwdb
|
|
Default to installing them, while letting people/distributors decide
what they want.
|
|
While common keyboard backlight devices use 'kbd_backlight' in the name, per
linux kernel include/dt-bindings/leds/common.h, there are a few legacy names,
including 'lp5523:kbN'. They cannot be easily changed now because it would
break userspace, hence the names are still provided in the kernel. Support
them in upower as well. The lp5523 as used on the Nokia N900 exposes six
independent keyboard backlight LEDs, and UPower is able to manage them with
this patch in place.
|
|
The integration test for multiple keyboard backlight support.
|
|
The implementation for enumerating all keyboard backlight LED objects
on the system.
|
|
Enumerate all keyboard backlight LED objects on the system.
|
|
The LED udev subsystem was added to the list to watch the
keyboard backlight LED device events.
|
|
The keyboard backlight device will be added to or removed from DeviceList
when receiving the "device-added" and "device-removed" signal.
|
|
The DeviceList was created to store the keyboard backlight LED devices.
|
|
keyboard backlight device
Add, update, and remove the keyboard backlight LED device when receiving
add, change, and remove udev events.
|
|
for Linux
The implementation for Linux included:
1. Set and get brightness.
2. Get max brightness.
3. Signal if the brightness was changed by the device.
|
|
These are the callback functions for the signals "device-added" and
"device-removed" to add and remove keyboard backlight devices.
|
|
This commit makes UpDeviceList store the UpDeviceKbdBacklight objects and
sets the udev native path property of UpDevice and UpDeviceKbdBacklight.
|
|
This parent class can be used for multiple implementations, such as freebsd
and Linux. The child class inherits it to register the device to upower
and access the dbus services.
|
|
the KbdBacklight object path
The object path /org/freedesktop/UPower/KbdBacklight is going to be deprecated in the future.
The upper-layer app should migrate to the new API instead.
|
|
The DBus property shows the udev native path.
|
|
- Fix wrong model name of the devices (!267, #309)
- Switch charge_types to "Custom" when charging threshold is enabled (!268, #275)
- Fix invalid command line arguments (!269)
- Fix leak when reporting daemon usage error (!270)
- OpenBSD: support battery status from qcpas (!272)
- Fix history progression (!274, #316)
- Add a battery filter to the upower command line (!275)
- Change the charging behaviors using charge_types (!276, !46, #275)
- Fix integration tests issues, including floating point value and race between umockdev and upower (!277, !278)
- Rework upower command (!280)
- Propagate charge-threshold-enabled to display device (!281)
|
|
This is useful when asking people to give information about battery
health. It avoids having to give two-step instructions of first
enumerating devices with `upower -e`, then looking for a device whose
name starts with `/org/freedesktop/UPower/devices/battery_`, then
running `upower -i` on that device.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
|
|
The property indicates that a device is plugged-in but not charging
because of the charging threshold. Desktops may want to indicate
that state, but the property is currently only exposed on actual
devices, not the virtual display device that is usually exposed
in the interface.
To address this, propagate the property to the display device
if at least one device has charge thresholds enabled.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5228
|
|
1. Move dump and enumerate to the separated functions.
2. Introduce an output filter.
Co-work-with: Cursor
Reviewed-by: Kate Hsuan <hpa@redhat.com>
|
|
The data type of the "Percentage" property is double, so the value is a
floating point number, ex, 100.0
|
|
Use assertAlmostEqual for all values that are floating point numbers:
https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertAlmostEqual
This avoids issues with excessive precision on i386.
More information https://wiki.debian.org/ArchitectureSpecificsMemo#i386
See also the corresponding downstream bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050436
The patch was generated using:
for i in Capacity Energy EnergyEmpty EnergyFull EnergyFullDesign EnergyRate Luminosity Percentage Temperature Voltage ; do
sed -i -r "s/(assertEqual)(.*$i)/assertAlmostEqual\2/g" src/linux/integration-test.py
done
Fixes: #251
|
|
The test case for settings discovery for charge threshold.
The test cases include:
1. only charge_types (4)
2. charge_control_start_threshold + charge_control_end_threshold +
charge_types (7)
3. charge_control_end_threshold + charge_types (6)
|
|
This commit discovers the settings, including charge_control_start_threshold,
charge_control_end_threshold, and charge_types and update the results to
the battery information.
|
|
Setup and update the charge-threshold-settings-supported property.
|
|
property
The types of settings for charge thresholds that are supported. The value
is a bitmask value and it is the sum of the supported types.
1: The system supports charge start threshold. The battery discharges to a
percentage, then starts charging.
2: The system supports charge end threshold. The battery charges to a
percentage, then stops charging.
4: The system supports optimized charging behaviors controlled by the
system firmware.
Examples:
If the system supports charge start threshold and charge end threshold,
the value is 3.
If the system supports charge end threshold and the battery charging
behavior is controlled by the system firmware, the value is 6.
|
|
Charge_types has to be "Long_Life" if charging threshold is enabled.
Charge_types has to be "Fast", "Standard", or "Adaptive" if charging
threshold is disabled.
|
|
charge threshold
If the charge threshold is enabled, the charge_types set "Long_Life". If
the charge threshold is disabled, the charge_types set to any of
charge_types for charging, such as "Fast", "Standard", and "Adaptive".
This commit is only for the system that only has the charge_types attribute
to control the battery behaviour.
|
|
to manage charging threshold
We found some systems, such as Lenovo ideapad that don't support
charge_control_start_threshold and charge_control_end_threshold but it
provide the charge_types Long_Life and Standard. The chatre_types
Long_Life operate the battery in the conservation mode. That means
if Long_Life and Standard are found, the system supports the
charge threshold feature.
Co-work-with: Cursor
Reviewed-by: Kate Hsuan <hpa@redhat.com>
|
|
The charge enum is used to set the charge_types and namespacing the
emum to prevent varaible name conflicts.
|
|
On a slow system like riscv64, the test_daemon_version and
test_daemon_restart tests sometimes failed. A delay was added after the
daemon starts to give it enough time to fully initialize, which has
reduced the chance of these tests failing.
|
|
Sometime we found the errors shows below when pipeline test was running.
379s ERROR: test_bluetooth_hidpp_mouse (__main__.Tests.test_bluetooth_hidpp_mouse)
379s Logitech Bluetooth LE mouse with HID++ kernel support
379s ----------------------------------------------------------------------
379s Traceback (most recent call last):
379s File "/usr/libexec/upower/integration-test.py", line 4380, in test_bluetooth_hidpp_mouse
379s self.assertEventually(
379s ~~~~~~~~~~~~~~~~~~~~~^
379s lambda: self.get_dbus_dev_property(bat0_up, "Model"), value=alias
379s ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
379s )
379s ^
379s File "/usr/libexec/upower/integration-test.py", line 399, in assertEventually
379s if condition() == value:
379s ~~~~~~~~~^^
379s File "/usr/libexec/upower/integration-test.py", line 4381, in <lambda>
379s lambda: self.get_dbus_dev_property(bat0_up, "Model"), value=alias
379s ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
379s File "/usr/libexec/upower/integration-test.py", line 316, in get_dbus_dev_property
379s return self.dbus.call_sync(
379s ~~~~~~~~~~~~~~~~~~~^
379s UP,
379s ^^^
379s ...<7 lines>...
379s None,
379s ^^^^^
379s ).unpack()[0]
379s ^
379s gi.repository.GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path “/org/freedesktop/UPower/devices/mouse_dev_11_22_33_44_AA_BB” (19)
379s
The upower and bluez daemons were started after the udev was
initialized to avoid the random errors.
|
|
with charging threshold status
The charge_types is set to "Custom" when the charging threshold is
enabled. If the charging threshold is disabled, it will be reset
to "Fast".
|
|
charging threshold
If the charge_types isn't set to "Custom" on a Dell laptop, the charging
threshold doesn't work. This commit sets the charge_types to "Custom" if
the charging threshold is enabled. Also, the charge_types will be set to
"Fast", "Standard", or "Adaptive" when the charging threshold is disabled.
This commit reads and writes the battery udev attribute "charge_types".
However, this attribute can't be found on some of the systems, so the error
on reading and writing charge_types attribute is ignored.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The model name of the two mice should be displayed when paired with one
unifying receiver.
|
|
non-GUdevDevice object
A non-GUdevDevice object may be included in the sibling device list,
since the udev information was created slowly. This object triggers
errors when upower tries to get udev information. Therefore,
get_latest_udev_device() returns NULL, when it receives a non-GUdevDevice
object.
The error messages are shown as follows:
(upowerd:2026931): GUdev-CRITICAL **: 10:38:29.775: g_udev_device_get_sysfs_path: assertion 'G_UDEV_IS_DEVICE (device)' failed
(upowerd:2026931): GUdev-CRITICAL **: 10:38:29.775: g_udev_client_query_by_sysfs_path: assertion 'sysfs_path != NULL' failed
|
|
same parent
f17d3bf fixed the unstable joypad model name but led the hid++ devices
to show the incorrect model name if more than one device is paired to a
unifying receiver. The patch only updates the model name when the device
is under the same parent.
Resolves: #309
|
|
Add test for DBus exporting of the following sysfs attributes:
1. capacity_level
2. voltage_min_design
3. voltage_max_design
Related: #301
Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com>
|
|
For supplies that report the voltage_min_design, voltage_max_design, and
capacity_level attributes on sysfs, expose them via libupower for possible
use by clients.
Related: #301
Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com>
|
|
voltage_min/max
For Linux systems that provide these attributes, extend the implementation by
reading the values for the design maximum and minimum voltage for the battery,
as well as the coarse capacity level reported by the kernel.
Related: #301
Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com>
|
|
voltage-max-design properties
Extend the parent class of the battery to support reporting the design maximum
and minimum voltage, as well as the kernel-derived capacity level.
Related: #301
Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com>
|
|
Some drivers provide capacity_level, voltage_min_design, and voltage_max_design
properties on sysfs even for system supplies. Expose these properties over DBus
for consumption by clients.
Related: #301
Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com>
|
|
information
|
