This tweaks match installation a bit: the match callbacks are now only
called for messages read after the AddMatch() reply was received and
never anything already read before. Thus, installing a match gives you a
time guarantee: only messages received after it will be matched.
This is useful when listening to PropertiesChanged signals as an example
to ensure that only changes after the point the match was installed are
honoured, nothing before.
If AddMatch() doesn't work, let's destroy the slot for it too as soon as
we received the failure for it.
This way the mere existance of the slot tells us whether the AddMatch()
method call is still pending or is complete.
Let's count incoming messages and attach the current counter when we
first read them to the message objects. This allows us to nicely order
messages later on.
Because it's not a device path and (slightly) bad things happen if it
gets confused with one:
$ udevadm info /sys/
Assertion 'device->devpath[0] == '/'' failed at
../src/libsystemd/sd-device/sd-device.c:958,
function sd_device_get_devpath(). Aborting.
Aborted (core dumped)
Previously, when a bridge or bonding interface is in degraded-carrier
state, then we cannot judge the interface has addresses or not.
By using the new states, dbus clients can distinguish such situation.
"Unknown interface or property." →
"Unknown interface org.freedesktop.network1.Link or property BitRates."
(I don't think the quotes are necessary. Dbus names have pretty strict rules.)
This augments the drm/input device management by adding a single method
call for setting the brightness of an "leds" or "backlight" kernel class
device.
This method call requires no privileges to call, but a caller can only
change the brightness on sessions that are currently active, and they
must own the session.
This does not do enumeration of such class devices, feature or range
probing, chnage notification; it doesn't help associating graphics or
input devices with their backlight or leds devices. For all that clients
should go directly to udev/sysfs. The SetBrightness() call is just for
executing the actual change operation, that is otherwise privileged.
Example line:
busctl call org.freedesktop.login1 /org/freedesktop/login1/session/self org.freedesktop.login1.Session SetBrightness ssu "backlight" "intel_backlight" 200
The parameter the SetBrightness() call takes are the kernel subsystem
(i.e. "leds" or "backlight"), the device name, and the brightness
value.
On some hw setting the brightness is slow, and implementation and write
access to the sysfs knobs exposes this slowness. Due to this we'll fork
off a writer process in the background so that logind doesn't have to
block. Moreover, write requestes are coalesced: when a write request is
enqueued while one is already being executed it is queued. When another
write reques is then enqueued the earlier one is replaced by the newer
one, so that only one queued write request per device remains at any
time. Method replies are sent as soon as the first write request that
happens after the request was received is completed.
It is recommended that bus clients turn off the "expect_reply" flag on
the dbus messages they send though, that relieves logind from sending
completion notification and is particularly a good idea if clients
implement reactive UI sliders that send a quick secession of write
requests.
Replaces: #12413
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
1848
Lubomir Rintel
Frantisek Sumsal
Susant Sahani