[whoisaldo]

Supersedes #166, which was held after 0.3.4 for two review findings. Both are fixed here, along with the findings of two reviews of this PR.

What changed

A graphics driver deadlock on an AMD laptop held the host's startup for 62 s inside GpuInfo::detect, and the window showed nothing for that minute. #166 time-boxed detection. Review found that the window still made its own graphics calls before the first paint: AnalyzerApp::new lists the screens, and the renderer and wgpu create their own DXGI factories. It also found that a timeout left the whole session on the processor (libx264, or libx265 with HEVC) with no notice.

Startup lane. GpuInfo::detect runs under the stall guard in a new gpu_detect lane: warning at 1 s, limit at 4 s (from #166). The same lane holds the screen lists for the startup banner (main.rs) and the window (AnalyzerApp::new), and the window's DXGI adapter list. After one hangs, the others are refused at once instead of each waiting out its own limit. A refused or timed-out screen list is empty: the banner says unknown, and the screen picker fills in when Settings opens.

Before the window (gui/driver_wait.rs, before_window). The window's thread lists adapters, creates its device and draws through the driver, and Windows can't stop a thread stuck there. So before run_native:

1. The graphics cards are listed through DXGI on another thread, in the startup lane, once nothing is stuck there, until one list returns in time. Only that list configures the renderer; crash avoidance keys its history by it, and the window keys its adapters by it until it is confirmed drawing. A stuck or timed-out list never gives an empty key, which would pick a known-bad backend again and record a crash under an empty key.
2. A probe makes the calls wgpu makes first, once, on another thread, in a lane of its own (gpu_probe, same limits): an instance with this launch's backends lists its adapters, and DX12 creates a device on each to describe it. The window opens once it returns.

The list and the probe are one call each, waited for as long as they run: past the 4 s limit the notice goes up, and a driver that answers late still opens the window (the late result is used, not thrown away and tried again).

Until the window draws (watch_first_paint, Watch::look). The window's own device and swap chain, and a surface it recreates after a failed acquire, can't be moved off its thread. A watcher runs until the renderer confirms the window drawing, and raises the notice when either:

• the window's thread has begun no UI pass for 4 s (the window repaints at least every 200 ms), or
• it has run UI passes for 12 s without being confirmed (a working window is confirmed at about 3.5 s).

Both are counted from the latest of the watch's start and the last time the window was held: minimized (IsIconic), or its title bar or system menu held (GetGUIThreadInfo: GUI_INMOVESIZE, GUI_INMENUMODE). eframe runs no UI pass for a minimized window, so the watcher checks the window itself, live.

Confirmed drawing. The renderer confirms the window only after frames for a while with no surface error, no skipped frame and no new device, visible, and then a screenshot: egui-wgpu (also #201's vendored painter) answers one only from a frame it acquired, drew and submitted. Each ask carries its span (a new one after each surface error, skipped frame or device) and a request id, and only an answer to the current span's asks confirms; a late answer from before a change proves nothing.

The notice. Whenever the window waits on the driver, a message box says the graphics driver is not responding and that the window will open by itself. Windows draws it without the graphics driver.

• OK hides it for 15 s; it comes back while the wait goes on.
• Cancel quits through the app's normal quit path (VDD off, input released, logs flushed). The window's thread may never return, so that path is one closure that main.rs and the watcher share, run once by whichever comes first. A Cancel also clears the renderer's crash marker, so the next launch does not count a deliberate quit as a failed start.
• The end of the wait, the user's answer and showing the box change one state under one lock: a Cancel that comes as the window draws still quits, and the box never goes up after the wait ended.
• The box closes when the window is confirmed drawing, on a thread of its own, so the window's thread never waits on it.

Crash markers. The DXGI list leaves a marker before it starts and names its thread once it runs; the probe names its thread while it runs. A driver crash in either is the window's, as one on the window's thread is. A launch that dies listing makes the next ones key the GPUs by wgpu's driver text instead, until clean launches retry the list. The marker and a quit share one lock, so a worker still in the driver can't save it again after a Cancel. After the window is confirmed, a renderer rebuilt later (after a lost device) lists adapters in the gpu_facts lane, so it neither waits behind nor holds the startup lane.

The late result is used. A detection given up on keeps what it found when it returns (gpu::take_late_detection). The next pipeline (Restart, or any later restart) takes it and encodes on the graphics card. Until then the processor encodes, and the Stream page shows the software-encoding notice from the start: "The graphics driver did not respond when EternalMonitor started, so the processor encodes the video for now. … Click Restart to try the graphics card again." Its button is Restart. A detection that answered and found no graphics card, or libx264 chosen in Settings, shows no notice, as before.

This doesn't touch the encoder_open stall path or the window's handling of device loss once it is up.

Tests

• gpu::tests: a stuck detection gets the software facts, marked as stalled, at its limit, with one stall=gpu_detect WARN. Once it returns, its facts are kept for later pipelines. A detection that returns in time keeps its facts; a failed one is not marked.
• gui::driver_wait::tests. The steps before the window order events on channels and use 60 s limits for steps that answer; the watcher's decisions are a step function (Watch::look) the tests call with each state in turn:
  • while detection is stuck, nothing lists and the notice is up;
  • a list or a probe that answers after its limit is waited for, its late result used, once;
  • Cancel while a call hangs opens no window and leaves its lane taken until it returns; Cancel as the driver answers still quits;
  • OK hides the notice until the reminder;
  • a failed first acquire then a stuck recreation: the notice 4 s after the last pass;
  • UI passes without a proof of a presented frame: the notice at the 12 s bound;
  • a held window (minimized, dragged) suspends both bounds, which count again from its release;
  • controlled interleavings: a Cancel that comes with the window drawing still quits; a window that draws while the watcher is about to raise shows no notice.
• renderer::tests: confirmation needs the screenshot proof, and frames that present nothing are never confirmed; a late answer from before a surface error, or from before skipped frames and a new device, proves nothing; a quit from the notice leaves no marker and no late worker writes it again; a launch that dies listing is recorded and skips the list next time; after the window is confirmed, the adapter list leaves the startup lane.
• supervisor::tests::a_late_detection_is_used_by_the_next_pipeline_only_after_a_stall.
• tests/gpu_detect_fallback.rs runs the real encode stage on the stalled facts. The processor encodes with the notice flags set; libx264 chosen in Settings and a detection that found no card set neither. With the old set_software_fallback(false) it fails with (false, true).
• gui::tests::a_driver_that_did_not_answer_at_startup_is_named_with_a_restart: the stalled detection is named first, before custom settings and the driver hints for NVIDIA, AMD and Intel from Stream on libx264 when a hardware encoder open hangs, remember failed encoders, change Quick Sync's bitrate in place #202.

Checks

• Windows (RTX 5080 + AMD iGPU), at the pushed head, cargo test -p eternal-host --no-fail-fast: 1225 passed, including all 13 window_device_loss tests; cargo clippy -p eternal-host --all-targets -- -D warnings is clean. The AMF hardware tests failed in that run: AMF did not open on the AMD iGPU of the shared test PC. In an A/B right after, amf_encoder passed 5 of 5 at this head and failed 2 tests in 1 of 5 on the candidate (241fa1b).
• macOS: cargo test -p eternal-host (all 1240), cargo clippy --workspace --all-targets -- -D warnings, cargo fmt --check.

Native runs (Windows 11, RTX 5080, at 8f660c2)

Test copies of the host, debug builds, synthetic capture, against the candidate. A local test-only patch held detect_from_dxgi for 20 s, like a stuck driver, in both builds.

	First thing on screen	Window
Candidate, detection held 20 s	22.0 s (the window)	22.0 s
This PR, detection held 20 s	4.2 s (the driver notice)	21.5 s
This PR, normal start	1.1 s	1.1 s, confirmed drawing 3.2 s later
This PR, minimized 0.5 s after the window appeared, watched 60 s	no notice	confirmed 0.3 s after it was restored

• Minimized: the host logged no "graphics driver is not answering" line while minimized. After the restore, Window renderer is drawing came once the screenshot proof was answered.
• Held detection: stall=gpu_detect after_ms=4019, then the notice. The list and the probe answered (The graphics driver answered call="gpu_detect" waited_ms=16019, then call="gpu_probe"), and the window opened with the software-encoding notice.
• From the previous round (e5cc8e0): with the renderer stuck 30 s on the window's thread, the notice went up at 4.4 s by the host's log. After Restart from a held start, the log shows this pipeline uses its graphics card … encoder=h264_nvenc.

Release notes

EternalMonitor's window no longer waits up to a minute to appear when the graphics driver stops responding at startup. It says the driver isn't responding, opens once the driver answers, and the Stream page explains why video uses the processor until Restart.