Ray Strode
ad1bf59c67
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.
systemd - System and Service Manager
Details
General information about systemd can be found in the systemd Wiki.
Information about build requirements are provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the HACKING file for information how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.