path: root/src/test
diff options
authorRay Strode <>2018-10-06 06:08:31 -0400
committerSven Eden <>2018-10-29 10:18:29 +0100
commitc4705b5d1886b1d4f8a6e0ef55a4e3f3b620e97e (patch)
tree525db06096ba288cf028a94f43a410349e74d6f4 /src/test
parent3cbd272c7a95fb728ebdeeadeccd0f15a2da34f7 (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')
0 files changed, 0 insertions, 0 deletions