Unattended Wayland DRM/KMS multi-monitor capture limited to ~30 FPS

Bug Description

When using the new unattended Wayland implementation on a multi-monitor Linux system, all remote displays appear to be limited to approximately 30 FPS, even when the RustDesk client is configured for 120 FPS and all remote displays are running at 120 Hz.

The new unattended Wayland implementation is an improvement over the previous behavior because all three displays are now captured consistently. However, none of the displays exceed approximately 30 FPS.

With the previous Wayland build, one display could reach approximately 60 FPS, while the other two displays were often limited to around 8 FPS.

With unattended Wayland 1.5.0, the result is now approximately: Display 1: 30 FPS Display 2: 30 FPS Display 3: 30 FPS

This happens even with continuous motion, for example when playing a YouTube video.

The remote displays themselves are confirmed to be running correctly at 120 Hz under KDE Plasma / Wayland.

Looking at the current RustDesk source, the DRM/KMS capture implementation contains: const FRAME_INTERVAL: Duration = Duration::from_millis(33);

in: src/ipc/drm.rs

33 ms corresponds to approximately 30.3 FPS, which appears to match the observed limitation.

How to Reproduce

1. Use a Linux remote machine running KDE Plasma on Wayland.
2. Configure three active displays.
3. Set all three displays to 120 Hz.
4. Install the RustDesk unattended Wayland 1.5.0 build on the remote machine.
5. Connect from another Linux system using RustDesk.
6. Configure the controlling client for Custom quality and 120 FPS.
7. Open all three remote displays.
8. Generate continuous movement on the remote displays, for example by playing video.
9. Enable the RustDesk quality monitor and observe the FPS.

All three remote display streams remain at approximately 30 FPS and do not increase toward the configured 120 FPS.

Expected Behavior

The unattended Wayland DRM/KMS capture backend should ideally respect the requested/custom FPS setting instead of being limited to approximately 30 FPS.

For example, if the client requests 60 or 120 FPS and the remote hardware, display refresh rate and network connection are capable of handling it, the capture backend should be able to produce frames at that rate.

Alternatively, the DRM capture frame interval could be configurable instead of using a fixed 33 ms interval.

Examples: 33 ms → ~30 FPS 16 ms → ~60 FPS 8 ms → ~120 FPS

For high-bandwidth LAN connections, at least a 60 FPS option would already provide a significant improvement.

Operating system(s) on local (controlling) side and remote (controlled) side

Ubuntu Linux -> Kubuntu Linux, KDE Plasma / Wayland

RustDesk Version(s) on local (controlling) side and remote (controlled) side

RustDesk Wayland 1.4.9 Stable -> RustDesk unattended Wayland 1.5.0

Screenshots

Ubuntu Linux -> Kubuntu Linux, KDE Plasma / Wayland

Remote system details: NVIDIA RTX A4000 NVIDIA driver 595.91.07 Linux kernel 7.0.0-31-generic Three active displays driven by the NVIDIA GPU

Display configuration: Display 1: 1440x2560 @ 120 Hz Display 2: 2560x1440 @ 120 Hz Display 3: 2560x1440 @ 120 Hz

Additional Context

The remote display configuration itself appears to be working correctly.

All three displays are confirmed by KDE/KWin and DRM/KMS to be running at 120 Hz. The limitation therefore appears to be in the RustDesk unattended Wayland capture path rather than in the display configuration.

The behavior also changed between the previous Wayland implementation and the new unattended Wayland implementation:

Previous behavior: One display: up to approximately 60 FPS Two additional displays: approximately 8 FPS

Current unattended Wayland 1.5.0 behavior: All three displays: approximately 30 FPS

This suggests that the new multi-monitor capture implementation distributes capture correctly across the displays, but that each stream is now limited by the DRM capture frame interval.

The following code in src/ipc/drm.rs appears relevant: const FRAME_INTERVAL: Duration = Duration::from_millis(33);

Would it be possible to derive this interval from RustDesk's requested/custom FPS setting instead of using a fixed 33 ms value, while keeping 30 FPS as the default?