mirror of
https://github.com/rustdesk/rustdesk.git
synced 2026-10-20 17:05:36 +00:00
Mariano Abad
49a9574f97
* fix(drm): pace the producer to the rate the encoder takes, with the panel refresh as floor The root producer slept a fixed 33 ms after every grab, so every DRM stream topped out at 30 fps whatever the client asked (rustdesk#16175). Measured on a 1920x1080@60 i915 box with the client at Custom 60 and QoS settled at 60: 30 grabs, 30 converted, 29.8 sent. A shorter fixed interval reaches the rate but oversamples: at 8 ms the same box grabbed and converted 117/s for 60 sent. The consumer now tells the producer the rate it encodes at, in the ack byte it already sends per converted frame: 0x01 as before, or 0x80|fps. Every producer counts ack bytes and never read their value, so an older service sees exactly the same credit and keeps its 33 ms; the JSON handshake and the ack count and timing do not change. The rate is the encoder's spf (what frame() is called with), lowered to what the encoder achieves when it is busy longer than spf per frame: the time from one frame() call to the next, less what the call spent waiting for a frame, so a late producer cannot talk its own demand down. The producer replaces the post-work sleep with a deadline: the encoder's period above 30 fps, the old 33 ms from 30 down to 15, and half the encoder's period below 15, never faster than the panel (the exact CRTC refresh from libdrmtap 0.5.9's drmtap_crtc_refresh, re-read once a second; with an older library the whole-hertz refresh the enumeration already read, so no extra connector probe). The worker still wakes at least every 33 ms, because each tick also reads the cursor and a slow frame rate must not slow the cursor down. Without a demand (an older consumer, or before the first frame() call) the old 33 ms sleep stays. MAX_STALLED and the WouldBlock retry keep their 5 s budget, pinned by a const assertion. Tests: the ack byte round trip and that it is one byte on the wire, the drain (seeded byte streams: every byte one credit, the newest demand wins), the pacing interval table (panel floor, below 30 and below 15, a 23.976 Hz panel), the panel period rounded up, the deadline and its overrun, the wake that keeps the cursor at 33 ms, the demand from spf and from a busy encoder, the busy time without the wait (pure and through frame()), the demand log once per connection, the whole-hertz fallback, and the reader's refresh answer. Each rule has a mutation that turns its test red. * ci: run the drm pacing tests in the drm step drm_pacing_tests (src/ipc/drm.rs) and crtc_refresh_tests (libs/scrap drm_reader.rs) match none of the existing filters. * test(drm): keep three tests, on outputs and not on internal state Per AGENTS.md (Tests), keep one to three tests, on outputs and not on internal state: the demand ack as it goes on the wire, the producer interval for a demand and a panel, and the exact refresh the reader returns. * test(drm): the ack test goes through the producer drain Per review: send_frame_ack(60) read back through drain_frame_acks gives one credit and a demand of 60, so dropping the demand read in the producer turns the test red. The interval test also pins drm_panel_period(148352, 2475) to 16_683_294 ns. * fix(drm): time the encoder only after a frame() call that returned a frame Since #16450 frame() drops a repeat as WouldBlock. The time after such a call is video_service sleeping out its spf, and after a timeout it is about zero once the wait is subtracted. Neither follows an encode, so neither is a sample of the encoder pace now. Uses returned_at from #16450; no new state. * fix(drm): ask for the old 33 ms tick while the screen is still Since #16450 a still screen is grabbed at the demand and dropped in frame(), twice as often as master at 60. After 100 ms without a new frame the demand is capped at 30, the old producer tick, and the next new frame lifts it. 100 ms is three of those ticks, so a producer paced at 30 in motion never reads as still. Uses returned_at; no new state. * test(drm): a dropped repeat or timeout is no encoder time; a still screen asks for the old tick Per review: the demand frame() reports stays with a 50 ms encoder through a still screen of repeats and timeouts, and a still screen asks for 30 after STILL_AFTER until a new frame brings back 60. * fix(drm): start the encoder average over when the rate goes up Per review: the samples hold the sleep video_service paces itself with, so after a rate increase (custom fps 1 -> 60, or QoS recovering) an average taken at the old rate kept the demand low and the producer slow. A shorter spf than the last now starts the average over and drops the sample that spans the change. The demand is computed in one method that takes its time as input, the still cap included. * test(drm): drop the two pacing tests of the last round Per review: they read shared.demand_fps and slept for real. The three tests stay. * build: pin libdrmtap 0.5.12 (rustdesk-org/libdrmtap 5936a7a88) The panel floor of the pacing reads drmtap_crtc_refresh(), added in libdrmtap 0.5.9. The mirror carries v0.5.12 since 2026-10-13, so the pin moves there. The rest of the range from 0.5.8 changes no struct in drmtap.h: 0.5.10 reads its environment through secure_getenv and loads no GL in a setuid, setgid or file-capability process, which rustdesk does not run; 0.5.11 makes drmtap_deswizzle, also the CPU fallback of a tiled grab, refuse a destination stride narrower than its rows instead of writing past it, and exports drmtap_frame_owns_data, unused here; 0.5.12 changes only docs and the version.