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>
ChargeThresholdSupported property is used to show if the battery supports
Charging threshold feature. ChargeThresholdEnabled is used to show the
configuration (enabled/disabled) status of the feature.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
Set per battery-specific start/stop charge limits in udev as environment
variable with the option to allow a user to override the default 60%
start and 80% stop charge limit.
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>
1. Resolved high disk and CPU rate.
2. Update glib2 requirement to 2.66.0.
3. Stop guessing the unknown battery as a power supply.
4. Continue to support lid handling.
5. Document fixes and bug fixes.
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
This reverts commit 6766602954.
Removing this and renaming up_client_get_devices2 to
up_client_get_devices means consumers have to support three cases to
support older UPower versions. So for example GNOME Control center now
uses up_client_get_devices2 and would have to now check if UPower
version > 0.92.
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.
udev is available only on Linux, so limit their usage when the backend
is 'linux'.
This fixes the build when the backend is different than 'linux', i.e.
typically on non-Linux OSes.
