Delay connecting with gui-daemon until after starting Xorg

[marmarek]

Until now, Xorg was started only after connecting with gui-daemon and
receiving xconf message. This was mostly because initial
resolution/video mem specified in the xorg.conf couldn't later be
changed and that affects maximum working resolution.

Since 49420c5 "Increase screen pixmap size beyond initial video RAM if
needed", this is no longer a problem. The only parameter (still) needed
before starting Xorg is GUI domain id, but this is available on the
command line. Change gui-agent to start Xorg earlier and only then wait
for gui-daemon. This allows starting all of the user session earlier,
optimizing startup time. This is especially relevant for VMs started on
boot (before user logs in), when GUI daemon isn't started yet. And also
helpful for preloaded disposables, which may start user session as part
of preloading now.

The current implementation is rather naive: it starts Xorg with
hardcoded 1920x1080 resolution (which will later be updated by the
qubes.SetMonitorLayout qrexec call), selects which events it want to
receive and then waits for the GUI daemon. Especially, no events are
actually processed before GUI daemon connects. This assumes all events
will be queued and can be processed after GUI daemon connection. Very
similar approach is already taken on GUI daemon re-connection, and it
works.

There is a potential issue, if too many events get queued before GUI
daemon connects and some get dropped. It's unclear how Xlib handles that
(and what is the limit), but if that happens there are two alternative
solutions:

1. Start processing events normally, especially collect info about all
   relevant windows, but dont send anything to GUI daemon before it
   connects - this basically requires changing write_struct() (and other
   similar places) to check if GUI daemon is connected. And once GUI daemon
   connects (first event received on the vchan FD), call
   send_all_windows_info().

2. Wait for GUI daemon before registering for events, but then iterate
   over all windows to collect necessary info and send it to dom0. This
   approach theoretically can be more reliable (and might even allow
   restarting gui-agent without restarting Xorg as a side effect), but it's
   unclear if all data can be rebuilt this way. Especially tray icons may
   be problematic, as it isn't any window property, but a message sent to
   relevant selection owner (but theoretically
   https://tronche.com/gui/x/icccm/sec-2.html#s-2.8 provides
   solution for this issue).

QubesOS/qubes-issues#9940 (comment)

[marmarek]

@ben-grande I've looked at gui-agent and I think this should be enough to start user session without waiting for GUI daemon. See above description for specific details.

Generally, this should allow using qubes.WaitForSession even if gui-daemon isn't started yet.

This is only lightly tested, needs checking for various corner cases. A few cases that are worth testing:

1. Start VM, but not gui-daemon, start some GUI apps, and only then start gui-daemon - app windows should appear.
2. As with 1, but start and stop an app several times before starting gui-daemon (while an app window may flicker at gui-daemon startup, nothing should crash).
3. Start something with tray icon (both before starting gui-daemon and after)
4. Restart gui-daemon (logout and login to dom0?)
5. Move/resize app window before starting gui-daemon (via qvm-run ... xdotool ...?)
6. And ofc, try preloading with using qubes.WaitForSession instead of qubes.WaitForRunningSystem (but still start gui-daemon only when preloaded is used)

When I write "start gui-daemon", I mean the whole thing that qvm-start-daemon does, including qubes.SetMonitorLayout call.

There are probably some more cases to test, I hope you'll think of something :)

[ben-grande]

Thanks for the PR, seems very good. Will make the GUI connection much faster. Apart from this PR, I think just some other PRs are needed:

• qubes-core-admin-client to remove the "is_preload" checks from qvm_start_daemon.py
• qubes-core-admin to wait service qubes.WaitForSession also if self.guivm and self.features.get("gui", True)

But that is mostly it (besides testing all scenarios).

[marmarek]

Actually, I think the qvm-start-daemon should retain is_preload check - this PR makes it possible to start user session still without gui daemon.

[qubesos-bot]

OpenQA test summary

Complete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026031512-4.3&flavor=pull-requests

Test run included the following:

• Add option to wait for GUI session qubes-app-linux-input-proxy#42 (QubesOS/qubes-app-linux-input-proxy@cd6d205)
• Add Arch packaging qubes-core-admin-client#332 (QubesOS/qubes-core-admin-client@71b1e21)
• version 4.3.999 qubes-core-admin-client#454 (QubesOS/qubes-core-admin-client@fa35e91)
• re-add qubesadmin.tags import qubes-core-admin-client#456 (QubesOS/qubes-core-admin-client@cbdd653)
• tests: log more info on failure qubes-core-admin#736 (QubesOS/qubes-core-admin@a3fc21c)
• Allow GUIVM clients to know if GUIVM has session qubes-core-agent-linux#625 (QubesOS/qubes-core-agent-linux@e7db241)
• minimal-vms: mask gvfs-daemon to prevent dbus timeout qubes-core-agent-linux#636 (QubesOS/qubes-core-agent-linux@c28c0f1)
• Query GUIVM session or GUID from client in GUIVM qubes-core-qrexec#217 (QubesOS/qubes-core-qrexec@5dc1b28)
• Add disk2 status and update volume retrieval method qubes-desktop-linux-i3-settings-qubes#23 (QubesOS/qubes-desktop-linux-i3-settings-qubes@8b3f6d3)
• Rewrite qubes-i3-sensible-terminal qubes-desktop-linux-i3-settings-qubes#24 (QubesOS/qubes-desktop-linux-i3-settings-qubes@34e4251)
• Delay connecting with gui-daemon until after starting Xorg #251 (a981e36)
• Don't hang is-system-running when GUI is disabled #255 (9129d1c)
• Fix reporting error status for multi-command actions qubes-mgmt-salt-base#20 (QubesOS/qubes-mgmt-salt-base@53ec41a)
• Allow GUIVM clients to know if GUIVM has session qubes-mgmt-salt-dom0-virtual-machines#88 (QubesOS/qubes-mgmt-salt-dom0-virtual-machines@4c3007f)
• Wait for GUI session on the server side qubes-notification-proxy#14 (QubesOS/qubes-notification-proxy@6da96ee)

Installing updates failed, skipping the report!

[marmarek]

Unexpected side effect: notification proxy starts earlier, before user logs in, and fails to connect to (not running yet) notification daemon in dom0: QubesOS/qubes-video-companion#33 (comment)
Hopefully harmless (it retries), but pollute logs...

[marmarek]

This also breaks (kinda) sys-gui... Xephyr gets started with wrong resolution (the hardcoded 1920x1080, instead of what dom0 sends). I'm not sure why, could be startup timing, but maybe sending monitor layout is broken with sys-gui.