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>
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.
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
Add a scenario for connecting a low-power charger.
1. The AC is online.
2. The battery is discharging.
3. The percentage drops to 2.5%.
4. The warning level will become UP_DEVICE_LEVEL_CRITICAL.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
For some USB battery solutions, the kernel reports charging when
connecting a charger but in reality, the battery discharges and
current_now is negative. This work reset the battery status to
"Discharging" when current_now is negative and line power is
online.
Resolves: #276
Signed-off-by: Kate Hsuan <hpa@redhat.com>
The model name of a device component may be different. For example,
Dualshock joystick owns "Sony Interactive Entertainment DualSense
Wireless Controller" for the joystick and "Sony Interactive
Entertainment DualSense Wireless Controller Motion Sensors" for the
accelerometer. If the device type is changed based on the device
priority, the corresponding model name have to be changed.
Resolves: #295
Tested-by: Mateus Rodrigues Costa <mateusrodcosta@gmail.com>
Signed-off-by: Kate Hsuan <hpa@redhat.com>
The DualSense and DualShock 4 have 3 main components: the gamepad proper,
a touchpad and motion sensors. They also have an extra component in the
form of a headphone jack, which is only available via BT on the
PlayStation consoles but can be used on other devices via USB.
Commit 00eb31a63c increased the priority of
Gaming Input so the controllers weren't accidentally identified as only
the Touchpad, which works on BT. This commit prioritizes Gaming Input over
Audio Device, fixing an issue that only happens on USB.
Resolves: #296
We ship the proposed patch already since Oct 2024 in Alpine Linux and is
working for us correctly and fixes the test.
Closes https://gitlab.freedesktop.org/upower/upower/-/issues/228
Co-Authored-By: Bastien Nocera <hadess@hadess.net>
Some slow systems take more than 5 seconds to stop the daemon. The
waiting time was extended to 10 seconds to ensure the daemon
shutdowns properly.
Resolves: #290
Signed-off-by: Kate Hsuan <hpa@redhat.com>
The parent id for the devices under "/sys/devices/virtual/misc/uhid/*"
points to /sys/devices/virtual/misc/uhid. It will cause the device
information to be updated incorrectly. For example, the type for a mouse is
updated to "keyboard". This patch makes sure the correct parent id for
each input device.
Resolves: #268#286
One of the charge_control_start|end_threshold isn't writable for some
systems, for example, Macbook Air. Therefore, if both files can't be
written, the error is returned.
This allows the one of charge_control_start|end_threshold can be ignored
by a "_" character.
The udev hwdb can be set in the following format.
- Skip charging start limit
CHARGE_LIMIT=_,80
- Skip charging end limit
CHARGE_LIMIT=30,_
Give a new priority for device type since the gaming_input may include
a keyboard, a touchpad... etc, for example, a Sony DualShock4 joypad.
A mouse and a touchpad may include a mouse and a keyboard.
Therefore, the priority is:
1. Audio
2. Gaming_input
3. Keyboard
4. Tablet
5. Touchpad
6. Mouse
If AllowRiskyCriticalPowerAction is true and the CriticalPowerAction
is "Suspend", The "Suspend" can be the CriticalPowerAction.
Otherwise, "HybridSleep" will be the CriticalPowerAction.
When using UPower in a non-hybernate setup, the result of a
CriticalPowerAction would be PowerOff. Certain users prefer
Suspend instead, because this is the only way to recover
graceful from that state.
Suspend action will only used, when explicit configured.
Closes: #23Closes: #59
Signed-off-by: Kate Hsuan <hpa@redhat.com>
This reverts commit 07565ef6a1.
In the current systemd stable release 255 org.freedesktop.login1 does
not emit a LidisClosed event, this has added in systemd `main` and will
be availble in the next release.
As GNOME control panel still uses UPower's `LidIsclosed` property and
many other DE's such as Xfce/LXQt/Deepin as well revert this until the
systemd changes are available in all Distributions.
https://github.com/systemd/systemd/pull/30706
Resolve: https://gitlab.freedesktop.org/upower/upower/-/issues/260
dbusmock 0.30.1 changed the BlueZ template to set the default "Class"
property to `MOCK_PHONE_CLASS` right away instead of in PairDevice() [1].
test_bluetooth_le_device() relied on the previous implicit default of a
"0" Class value. Set this explicitly to expect a "generic" device. This
makes the test work with old and current dbusmock versions.
https://bugs.debian.org/1059467
[1] https://github.com/martinpitt/python-dbusmock/pull/192
Some vendor kernel (most notably Android devices) expose various types
of BMS (battery management system) as power supplies. This is something
UPower has never designed to deal with, and thus UPower should not
represent or consider it to be a battery.
Fortunately, most of the time the actual "battery" power supply has the
correct type, so we can safely ignore those devices which have unknown
type. Also, the code that assumes power supply of unknown type seems
pretty dated and probably doesn't make sense anymore. So, let's remove
this assumption altogether.
