As some systems only allow for one charge threshold setting, the overall
process is treated as a success as long as one of the values is set
correctly. We only treat it as an error (and return FALSE) if both the
start and end threshold settings fail. For this reason, we don't need
to track specific errors for every write, so the GError parameter in
g_file_set_contents_full() is set to NULL.
Fedora upowerd[1326]: g_file_set_contents_full: assertion 'error == NULL || *error == NULL' failed
Fedora upowerd[1326]: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Failed to set charge control thresholds
Resolves: #331
This change adds the feature to read config from conf.d style
directories (UPower.conf.d), commonly supported by other tools, as an
extension of the main config file.
This is useful and convenient in several situations, for example:
- distributions can set different values from the defaults shipped
upstream without having to modify the main UPower.conf
- different packages or config-management tools can change config just
by adding, removing or modifying files in that directory
The main config file, e.g. '/etc/UPower/UPower.conf', will be
processed first, and then files in the UPower.conf.d dir, if existing.
The directory to use is derived automatically, e.g.
'/etc/UPower/UPower.conf.d/' if the main config file is
'/etc/UPower/UPower.conf'. Only files within that directory are
considered, and only those with valid config-group 'UPower' and with
the filename format: starting with '00-' to '99-', ending in '.conf'
and with alphanumeric characters, dash or underscore in between.
The candidate files within the given directory are sorted (with
g_strcmp0(), so the ordering will be as with strcmp()). The
configuration in the files being processed later will override
previous config, in particular the main config, but also the one from
previous files processed, if the Group and Key coincide.
Add also relevant integration test: 'test_conf_d_support'
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.
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 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
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.
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.
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.
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>
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.
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.
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
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 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>
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>
Updates the "test_battery_ac" test case with the changes introduced by
the addition of the "state_all_discharging" field.
Namely, we now assert that the "OnBattery" property is False while
still checking that the correct "WarningLevel" property is set.
In order to handle a situation where external power is connected but
all batteries are still discharging, introduce a new field
"state_all_discharging" that tracks if all batteries are currently
discharging irrespective of external power availability.
By predicating the warning level check and dispatch on this new
parameter we can ensure critical actions are still dispatched when we
have external power available, but the batteries are still draining.
Resolves: #276
The commit being reverted introduces the bug #306 by claiming external
power is not available when the device battery begins to discharge for
any reason.
We fix this issue by reverting to the old behaviour of reporting
external power being available as long as it's online. We then fix
issue #276 via alternative means.
Resolves: #306
This reverts commit 9d754d8b2f.
The up_device_get_id() returns a string, and the caller has to free it.
A comment is also left in the code to inform the behavior.
...
<snip>
...
=229301== 1,280 bytes in 10 blocks are definitely lost in loss record 1,837 of 1,852
==229301== at 0x4849347: realloc (vg_replace_malloc.c:1801)
==229301== by 0x48E7D6A: g_realloc (gmem.c:171)
==229301== by 0x4907239: g_string_expand (gstring.c:82)
==229301== by 0x49072B0: g_string_sized_new (gstring.c:113)
==229301== by 0x10E287: up_device_get_id (up-device.c:347)
==229301== by 0x10ED55: up_device_notify (up-device.c:241)
==229301== by 0x49F67D9: g_closure_invoke (gclosure.c:833)
==229301== by 0x4A26A1F: signal_emit_unlocked_R.isra.0 (gsignal.c:3720)
==229301== by 0x4A173E8: signal_emit_valist_unlocked (gsignal.c:3519)
==229301== by 0x4A17670: g_signal_emit_valist (gsignal.c:3262)
==229301== by 0x4A17732: g_signal_emit (gsignal.c:3582)
==229301== by 0x4A02973: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1819)
The AC was plugged and unplugged repeatedly, and hit this leak in
up_device_supply_battery_refresh(). Four variables in UpBatteryInfo
need to be free.
...
<snip>
...
==2825085== 1,152 bytes in 9 blocks are definitely lost in loss record 1,851 of 1,865
==2825085== at 0x484CE40: realloc (vg_replace_malloc.c:1801)
==2825085== by 0x4916ADA: g_realloc (gmem.c:171)
==2825085== by 0x4939E06: g_string_expand (gstring.c:82)
==2825085== by 0x4939EA1: g_string_sized_new (gstring.c:113)
==2825085== by 0x11262C: up_device_get_id (up-device.c:347)
==2825085== by 0x113136: up_device_notify (up-device.c:241)
==2825085== by 0x4A1B811: g_closure_invoke (gclosure.c:833)
==2825085== by 0x4A4C0C1: signal_emit_unlocked_R.isra.0 (gsignal.c:3735)
==2825085== by 0x4A3CCE8: signal_emit_valist_unlocked (gsignal.c:3534)
==2825085== by 0x4A3CF71: g_signal_emit_valist (gsignal.c:3277)
==2825085== by 0x4A3D033: g_signal_emit (gsignal.c:3597)
==2825085== by 0x4A27C75: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1827)
==2825085==
==2825085== LEAK SUMMARY:
==2825085== definitely lost: 3,663 bytes in 333 blocks
==2825085== indirectly lost: 0 bytes in 0 blocks
==2825085== possibly lost: 960 bytes in 3 blocks
==2825085== still reachable: 172,351 bytes in 2,205 blocks
==2825085== suppressed: 0 bytes in 0 blocks
==2825085== Reachable blocks (those to which a pointer was found) are not shown.
==2825085== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==2825085==
==2825085== For lists of detected and suppressed errors, rerun with: -s
==2825085== ERROR SUMMARY: 20 errors from 20 contexts (suppressed: 0 from 0)
Resolves: #305
