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.
Some devices change the 'present' sysfs attribute after upower
registers them. This should be updated in upower, otherwise
applications will ignore present devices, or listen to absent devices.
Fixes: 0b7d7cfc08 ("linux: Fix is-present for devices at startup")
The property will be FALSE and stay FALSE for all devices, except for
the Linux ones that have a "wireless_status" attribute set to
"disconnected". This will then be used by the backend to hide the device
until the wireless device is turned on again.
When a UpDevice is finally created, it's possible that we've seen "add"
events as well as "change" events for siblings. But as the "change"
events don't create new unknown siblings to store, we have GUdevDevices
from the original "add" event in that store.
As the GUdevDevice documentation mentions:
"By design, GUdevDevice will not react to changes for a device – it
only contains a snapshot of information when the GUdevDevice object
was created. To work with changes, you typically connect to the
“uevent” signal on a GUdevClient and get a new GUdevDevice
whenever an event happens."
To avoid having to try and update the siblings store, fetch an updated
GUdevDevice for the sibling we want to tell the core about, with the
properties all updated.
This fixes headsets plugged in after the daemon start being detected as
keyboards when the sound card device is tagged with the form factor
in a change event before the battery is exported.
Closes: https://gitlab.freedesktop.org/upower/upower/-/issues/239
building natively on OpenBSD with clang 13, i get those warnings:
../src/up-device-battery.c:128:53: warning: absolute value function 'abs' given an argument of type 'gint64' (aka 'long long') but has parameter of type 'int' which may cause truncation of value [-Wabsolute-value]
if (abs(UP_DAEMON_LONG_TIMEOUT * G_USEC_PER_SEC - abs (td)) > abs(UP_DAEMON_SHORT_TIMEOUT * G_USEC_PER_SEC - ref_td))
^
../src/up-device-battery.c:128:53: note: use function 'llabs' instead
if (abs(UP_DAEMON_LONG_TIMEOUT * G_USEC_PER_SEC - abs (td)) > abs(UP_DAEMON_SHORT_TIMEOUT * G_USEC_PER_SEC - ref_td))
^~~
llabs
../src/up-device-battery.c:128:65: warning: absolute value function 'abs' given an argument of type 'long long' but has parameter of type 'int' which may cause truncation of value [-Wabsolute-value]
if (abs(UP_DAEMON_LONG_TIMEOUT * G_USEC_PER_SEC - abs (td)) > abs(UP_DAEMON_SHORT_TIMEOUT * G_USEC_PER_SEC - ref_td))
^
../src/up-device-battery.c:128:65: note: use function 'llabs' instead
if (abs(UP_DAEMON_LONG_TIMEOUT * G_USEC_PER_SEC - abs (td)) > abs(UP_DAEMON_SHORT_TIMEOUT * G_USEC_PER_SEC - ref_td))
^~~
llabs
Avoid warning if one of the devices doesn't have a serial:
GLib-CRITICAL **: g_ascii_strcasecmp: assertion 's2 != NULL' failed
#1 0x00007fbe1b7c0b6d in g_log (log_domain=log_domain@entry=0x7fbe1b81300e "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7fbe1b81e9dd "%s: assertion '%s' failed") at ../../../../Projects/jhbuild/glib/glib/gmessages.c:1460
#2 0x00007fbe1b7c1af9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7fbe1b81300e "GLib", pretty_function=pretty_function@entry=0x7fbe1b8238c0 <__func__.24> "g_ascii_strcasecmp", expression=expression@entry=0x7fbe1b815e0e "s2 != NULL") at ../../../../Projects/jhbuild/glib/glib/gmessages.c:2930
#3 0x00007fbe1b7dad3a in g_ascii_strcasecmp (s1=<optimized out>, s2=<optimized out>) at ../../../../Projects/jhbuild/glib/glib/gstrfuncs.c:1878
#4 0x0000000000411025 in find_duplicate_device (backend=backend@entry=0xc3dc00, device=device@entry=0xc782e0) at ../../../../Projects/jhbuild/upower/src/linux/up-backend.c:139
Make our unduplicating code a bit more clever and hide the non-BlueZ
devices with the "unknown" battery state.
When Logitech devices are connected through Unifying and USB, with the
correct Linux patches[1], their serial numbers match, but the Unifying
connection stops exporting the battery information, so hide that one
from the export.
Closes: #206
[1]: https://patchwork.kernel.org/project/linux-input/list/?series=726116
