Let's document the discrepancy between the Sec and USec suffixing of
unit files and D-Bus properties at three places: in "systemctl show"
(where it already was briefly mentioned), in the D-Bus interface
description (at one place at least, i.e. the most prominent of
properties that encapsulate time values, there are many more) and in the
general man page explaining time values.
By documenting this at all three places I think we now do as much as we
can do about this highlighting the discrepancy of the naming and the
reasons behind it.
Fixes: #2047
We need to include `<sys/stat.h>` for usage of the `struct stat` in
the Manager struct, much as we already include `<stdbool.h>` for C99
booleans.
This helps alleviate another minor build failure on non-glibc systems.
This file must be included on non-glibc systems to ensure
the `LOCK_EX` definition is available.
Signed-off-by: Ikey Doherty <ikey.doherty@lispysnake.com>
Any uevent other then the initial and the last uevent we see for a
device (which is "add" and "remove") should result in a reload being
triggered, including "bind" and "unbind". Hence, let's fix up the check.
("move" is kinda a combined "remove" + "add", hence cover that too)
As discussed in https://gitlab.freedesktop.org/libinput/libinput/-/issues/521, it adds a narrower
match that only applies to X240. Other laptops that match `pvrThinkPad??40` are not affected:
$ systemd-hwdb query 'evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO*:pvrThinkPadX240:*'
EVDEV_ABS_00=1232:5711:51
EVDEV_ABS_01=1159:4700:53
EVDEV_ABS_35=1232:5711:51
EVDEV_ABS_36=1159:4700:53
$ systemd-hwdb query 'evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO*:pvrThinkPadX140:*'
EVDEV_ABS_00=::41
EVDEV_ABS_01=::37
EVDEV_ABS_35=::41
EVDEV_ABS_36=::37
This makes use of the developer mode switch: the test is only done
if the user opted-in into developer mode.
Before the man/update-dbus-docs was using the argument form where
we don't need to run find_command(), but that doesn't work with test(),,
so find_command() is used and we get one more line in the config log.
There is little point in #defining and #undefining CAP_LAST_CAP multiple times.
The check is only done in developer mode. After all, it's not an error to
compile on a newer kernel, and we shouldn't even warn in that case.
