diff options
author | Ray Strode <rstrode@redhat.com> | 2018-10-06 06:08:31 -0400 |
---|---|---|
committer | Sven Eden <sven.eden@prydeworx.com> | 2018-10-29 10:18:29 +0100 |
commit | c4705b5d1886b1d4f8a6e0ef55a4e3f3b620e97e (patch) | |
tree | 525db06096ba288cf028a94f43a410349e74d6f4 /src/test/test-extract-word.c | |
parent | 3cbd272c7a95fb728ebdeeadeccd0f15a2da34f7 (diff) |
logind: ensure seat0 CanGraphical state is written
For non-`seat0` seats, attaching a graphics card to a seat can
lead to it getting created. This is because the graphics device
is a "master device" which means that device is a seat-defining
device.
`seat0` may get created, even before the graphics driver is loaded,
though. This is because the graphics driver is loaded
asynchronously at startup, and `seat0` is the primary seat of
system, associated with the system VTs.
When a graphics card is attached to a seat the `CanGraphical`
property on that seat will flip to `true`.
For seats that haven't been created yet (non-`seat0` seats), this
leads to `seat_start` getting called which ultimately causes the
seat to get serialized to `/run/systemd/seats`.
For `seat0`, which is already created, `seat_start` will return
immediately, which means the updated `CanGraphical` state will
never get written to `/run/systemd/seats`.
The end result is that clients querying `sd_seat_can_graphical`
won't get the correct answer for `seat0` in cases where the
graphics device takes a long time to load until some other peice
of seat state is updated.
This commit fixes the problem by calling `seat_save` explicitly
for already running seats at the time a graphics device is
attached.
(cherry picked from commit ad1bf59c67e8d05629a4db00bbbe4d4c1c37fe46)
Diffstat (limited to 'src/test/test-extract-word.c')
0 files changed, 0 insertions, 0 deletions