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,_
The configuration file holds the enable status of the battery charging
threshold for individual batteries. If it is enabled, upower will recover
the settings when upower starts up. If the configuration file is not
present, the battery charging threshold is disabled by default.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
It sets the battery start and end charging threshold to the kernel and also
saves the configuration in a file. If upower is restarted, upower
can recover the charging threshold setting through the configuration file.
The configuration file is based on the model name and serial number of the
battery so the battery can be configured individually.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
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.
The warning message will be shown when CriticalPowerAction is "Suspend".
One iwarning message is for enabling the risky CriticalPowerAction and
the other is to show the potential risk when
AllowRiskyCriticalPowerAction is true.
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 resolves the following deprecation warning, meson these days has a
special function for installing an empty directory:
* 0.60.0: {'install_subdir with empty directory'}
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.
