Change resolution to (0,0) disconnects the X11 output and breaks capture (displays len: 0)

[Infinifar]

RustDesk 1.5.1-0, Rocky Linux 9.8. The service runs as root (--service → --server) on a TigerVNC X display :1 (GNOME session, user uid 1000).

A connection from the web client triggered a resolution change with width=0, height=0. RustDesk applied it to XRandR, the output got disconnected, and capture has been broken since.

Server log:

13:40:56.993  #1883 Connection opened from [2403:...]:49536        (web client)
13:41:24.749  WARN  [src/platform/mod.rs:108] Change resolution of 'VNC-0' to (0,0)
13:41:24.998  INFO  [src/server/display_service.rs:721] Displays changed
13:41:25.033  INFO  [src/server/video_service.rs:769] switch to refresh
13:41:25.111  ERROR [src/server/service.rs:308] Error of monitor0 service: SWITCH
13:41:25.183  ERROR [src/server/service.rs:308] Error of monitor0 service: Failed to get display 0, displays len: 0

After this every capture attempt fails with displays len: 0; one controller shows a black screen, another reports no display available.

xrandr after the change:

Screen 0: minimum 32 x 32, current 32 x 32, maximum 32768 x 32768
VNC-0 disconnected primary

Only a manual xrandr --output VNC-0 --mode 1920x1080 brings the output back (and capture works again).

change_resolution() in src/platform/mod.rs only compares against the current mode and then calls change_resolution_directly() without validating the requested size.

Expected: a request with width or height 0 should be rejected or treated as "no change", and if applying a mode fails or disconnects the only output, the previous mode should be restored.

[Adrianogba]

I think rejecting invalid dimensions before calling XRandR would be the safest approach here.

A width or height of 0 should probably be treated as an invalid resolution (or as "no change"), rather than being passed directly to XRandR.

I'd also consider keeping the current resolution and restoring it if applying a new mode fails. That way, even if something goes wrong during the resolution change, the display doesn't end up disconnected and leave the session unusable.

Might also be worth checking where the web client is generating the (0,0) request in the first place, since that seems to be what triggers the issue.