rustdesk/rustdesk · warning

display {display} ({}) is no longer in the service's list; t

Error message

display {display} ({}) is no longer in the service's list; the video service will rebuild against the fresh topology

What it means

The client requested a display by index into the client's list, but the service's freshly received DrmDisplayList no longer contains a matching (device, name) entry. recv_thread refuses to proceed and reports that the video service should rebuild against the new topology.

Source

Thrown at src/server/drm_capturer.rs:569

            let _ = tx.send(Err(err));
            return;
        }
        None => {
            let _ = tx.send(Err(anyhow!("timed out waiting for DrmDisplayList")));
            return;
        }
    };
    // Our monitor's index IN THIS CONNECTION'S LIST; `display` indexes the CLIENT's. Measured on a
    // T2: a woken 2880x1800 panel re-enters ahead of the Touch Bar, flipping index 0.
    let wire_idx = match &expected {
        Some(e) => {
            match displays
                .iter()
                .position(|d| d.device == e.device && d.name == e.name)
            {
                Some(i) => i,
                None => {
                    let _ = tx.send(Err(anyhow!(
                        "display {display} ({}) is no longer in the service's list; \
                         the video service will rebuild against the fresh topology",
                        e.name
                    )));
                    return;
                }
            }
        }
        None => {
            let _ = tx.send(Err(anyhow!(
                "display {display} is not in the advertised list; not guessing a monitor for it"
            )));
            return;
        }
    };
    // (device, crtc_id) survives a topology change; list indices do not.
    let bound_to = displays
        .get(wire_idx)

View on GitHub (pinned to 91c9fccbb0)

Solutions

  1. Rebuild the capturer against the current display list and pick a valid display (the video service does this automatically)
  2. Verify the target monitor is connected, awake, and listed by the service
  3. Retry after displays settle following a topology change
Defensive patterns

Strategy: fallback

Validate before calling

// confirm the requested display still exists in the service's list before new()
let listed = service_display_list()?.iter()
    .any(|d| d.device == expected.device && d.name == expected.name);
if !listed { /* rebuild display list / pick another display */ }

Try / catch

match DrmCapturer::new(...) {
    Err(e) if e.to_string().contains("no longer in the service's list") => {
        expected = resolve_display_against_fresh_topology()?;
        capturer = DrmCapturer::new(...)?;
    }
    r => r,
}

Prevention

When it happens

Trigger: The expected display (identified by device and name) disappeared from the service's advertised list between the request and the handshake — monitor unplugged, service re-enumerated outputs, or the panel went to sleep and dropped out of the list.

Common situations: Hot-unplug or power-off of a monitor (e.g. T2 panel sleeping) during connection setup; topology change racing a capture-session start.

Understand the failure class

Background: "Not found" and "does not exist" errors: why "Task not found", "No such folder", and "Can't find" fire when a lookup comes back empty — this error's family across 14 libraries.

Related errors


AI-assisted analysis of rustdesk/rustdesk@91c9fccbb0 (2026-09-10). Data as JSON: /api/errors/3949ff2ca29ade41. Report an issue: GitHub.