mirror of
https://github.com/rustdesk/rustdesk.git
synced 2026-10-20 19:27:35 +00:00
fix/linux-window-close-after-destroy
1054
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Mariano Abad
|
d011aa3ea6 |
fix(wayland): a pending portal request no longer stalls the server (#16542)
* fix(wayland): a pending portal request no longer stalls the server The screencast portal waits for the user while its picker is open, up to three minutes. check_init waited under the CAP_DISPLAY_INFO write lock on a tokio worker and get_capturables under RDP_SESSION_INFO. Every desktop login read the display state on a worker behind them, and the session close when the last connection went waited for the slot on a worker too. With the server on 4 cpus a second login was enough: new connections were accepted by the kernel and not served until the request ended (#15973). The locks keep their role: the write lock still serializes inits and orders them with clear(), and the slot still orders the session close calls after a pending request. What changes is where the waiting happens. The part of check_init under the write lock moves, as is, to init_displays(), run in spawn_blocking. is_inited and the first look in check_init use try_read; when a writer holds the lock, is_inited answers not inited yet and check_init redoes its look in spawn_blocking, then goes on as before. get_displays_and_primary takes its read guard in spawn_blocking, is_rdp_session_hold uses try_lock, close_session from the ipc listener runs in spawn_blocking, and try_close_session from AuthedConnID::drop on its own thread. * fix(wayland): throttle the log when the session close thread cannot start A peer can drop connections at any rate, so the error logged when AuthedConnID::drop cannot spawn the thread for try_close_session goes through throttled_log!, once a minute, like the auto-login logs of this file (greptile on #16542). * fix(wayland): count the remote connections again in the close thread The session close moved to its own thread in this pr, so a remote that comes in after the count and before the thread runs could have the session it reuses closed under it. The thread counts the remote connections again right before try_close_session, which brings the window back to the one the close had on the dropping thread (coderabbit on #16542). * fix(wayland): one portal session close at a time, for remote and camera connections only The close that AuthedConnID::drop runs off the dropping thread spawned one OS thread per drop that left no remote connection, whatever the connection type, and while a portal request waits for the user each of those threads waited for the session slot. Now only a remote or view camera connection leaving asks for the close (their video service is the one that opens the portal session), no thread starts when the slot is free and empty (drm, x11, nothing left to close), and one close runs at a time: a close asked while one runs is left to it. The logic moves to wayland.rs; connection.rs keeps a hook. |
||
|
RustDeskandClaude Opus 5.5
|
9997b7a3b8 |
test: remove tests that do not pin user-visible behavior (#16539)
* test: remove tests that do not pin user-visible behavior Apply the AGENTS.md test rules to the existing Rust and Flutter suites. A test is kept when it is the only coverage of user- or API-visible behavior, the regression test of a reported or fixed bug, a security boundary (one test per rejection class), or a check against an external reference. Tests that assert private state or the order of internal steps, pin review-round corner cases, or repeat what a kept test already covers are removed. Rust: 679 -> 298 tests. Dart: 118 -> 45 tests. Test-only helpers left without callers go with them (applyLastOnlineStateForTesting, terminalKeyboardRowWidth, debugBufferedInputCount, tokio's test-util dev feature), and cfg gates and visibility that existed only for the deleted tests are narrowed. Runtime behavior is unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WS1HTjp6UQuG43KEcQPq1R * test: keep tests that pin security and user-visible behavior Restore six tests that review showed are the only coverage of their behavior: - update metadata rejects an artifact file name with path components; - ICE candidates from another session are dropped; - KCP delivers every multi-segment frame queued before a close; - set_files rejects an empty name in a multi-file transfer; - a lopsided elongated cursor keeps its centre hotspot (#16242); - toggling Show hidden during a pending same-path read issues a new read. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WS1HTjp6UQuG43KEcQPq1R * test: keep offline update and key-exchange downgrade rejections Restore three tests that are the only coverage of their rejection class: - offline update metadata rejects a signed artifact with an http or credential-bearing URL; - offline verification rejects a renamed local file and a version that does not match the release; - a key-exchange pick lowered in transit leaves both sides unable to decrypt, so a v0 fallback after a failed v1 decrypt cannot pass unnoticed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WS1HTjp6UQuG43KEcQPq1R * test: keep the decomposed-grapheme and reconnect-cancel tests Each catches a plausible wrong change that passes every kept test: mapping the first scalar under a locked Ctrl turns é into \x05, and a reconnect that does not fail pending reads leaves them hanging until the 30 s timeout. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WS1HTjp6UQuG43KEcQPq1R --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Leo Camus
|
76ab280ae9 |
fix(terminal): trim the replay buffer when output has no newline (#16545)
* fix(terminal): trim the replay buffer when output has no newline OutputBuffer::append returned early when the last line was incomplete and the new chunk had no newline, so the trim loop never ran. A program that writes without newlines (a minified file through cat, a \r progress bar) grew the replay buffer past MAX_OUTPUT_BUFFER_SIZE without bound, one 4 KiB PTY read at a time, until a newline arrived. Signed-off-by: leoca <leo.camus23@gmail.com> * fix(terminal): keep recent output when trimming a line without newline Trimming popped the whole incomplete line once it passed MAX_OUTPUT_BUFFER_SIZE, so the reconnect replay could come back empty. Newline-free output now goes into a new chunk once the incomplete one holds DEFAULT_RECONNECT_BUFFER_BYTES, and trimming drops the oldest chunks while the newest bytes stay. The test checks get_recent. Signed-off-by: leoca <leo.camus23@gmail.com> * fix(terminal): trim an oversized incomplete line to its newest half Splitting the incomplete line into chunks made get_recent return whole chunks only, so a reconnect could replay as little as the newest read. Keep one line and, when it alone is over MAX_OUTPUT_BUFFER_SIZE, drop its oldest bytes down to half the cap. The copy then happens once per half buffer instead of on every append, and the replay keeps the newest DEFAULT_RECONNECT_BUFFER_BYTES. Signed-off-by: leoca <leo.camus23@gmail.com> --------- Signed-off-by: leoca <leo.camus23@gmail.com> |
||
|
Mariano Abad
|
49a9574f97 |
fix(drm): pace the producer to the rate the encoder takes, with the panel refresh as floor (#16423)
* 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. |
||
|
RustDeskandClaude Opus 5.5
|
13e1278b4c |
fix: auto-login types the OS password only at the logon or lock screen (#16520)
* fix: auto-login types the OS password only at the logon or lock screen A remote-control login on Windows and macOS now reports is_logon_screen in platform_additions, and the client skips auto-login when the peer reports false. Peers that don't report it (older ones, Linux) keep today's behaviour, so this narrows the leak into the focused window without closing it: the value is a snapshot taken at login. Windows 7 and Server 2008 R2 report the WTS lock flag reversed, so there only LogonUI.exe tells the lock screen apart. Refs #16510, #15261 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01P1grQ39ByRWPUtTBdTzEBF * windows: drop the LogonUI.exe check from is_logon_screen LogonUI.exe can outlive the unlock and is matched by name only, so its presence reported a lock screen on an unlocked desktop and let the password through. Only the WTS lock flag decides now; on Windows 7 and Server 2008 R2, which report it reversed, the result is inverted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01P1grQ39ByRWPUtTBdTzEBF * windows: count only a confirmed logon or lock screen for auto-login is_prelogin() reads a failed WTS user-name query as no user signed in, and on Windows 7 the inverted is_locked() read a failed lock-flag query as locked, so either failure let the password through. is_logon_screen now uses its own queries that keep a failed read apart, and reads LOCK and UNLOCK the other way round on Windows 7 and Server 2008 R2. The existing functions stay as they are for their callers. If the check task itself fails, the server reports false instead of leaving the key out, which old clients' peers would mean. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01P1grQ39ByRWPUtTBdTzEBF * auto-login: ask the peer with a protobuf field instead of a JSON key The client sets the new LoginRequest.auto_login only when Auto Login would type the OS password, and the server runs the logon-screen check only then, so nothing new runs for any other login. The answer is the new PeerInfo.skip_auto_login: its default, false, is what an old or Linux server means, so those peers keep typing as before, and neither field is encoded unless set. The is_logon_screen key in platform_additions is gone. Windows is_locked() now reads the lock flag through is_session_locked_flag(), which handles the reversed LOCK/UNLOCK of Windows 7 and Server 2008 R2. Its only caller is the allow-logon-screen-password check, which on those systems accepted the permanent password on an unlocked desktop. Windows 8 and later read the same as before. The C is_session_locked() is removed and its WTS_CURRENT_SESSION guard moves into get_session_flags(). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01P1grQ39ByRWPUtTBdTzEBF * auto-login: let the peer type the password, after checking its screen The login-time check left the whole time until the password arrived open: the screen could be unlocked during the click, the 1.2 s wait and two network trips, a second client's password landed on the desktop the first one had just unlocked, and turning Auto Login on mid-login skipped the check. Now the client still clicks and waits, then sends the password in a new Message.os_login (reusing OSLogin) to a Windows or macOS peer from 1.5.1. The peer checks for its logon or lock screen right then and types the password and Return only if it finds one; otherwise it drops them. Other peers get the keys as before, and the OS Password menu item is unchanged. The password goes out only after login, never in the login request. LoginRequest.auto_login and PeerInfo.skip_auto_login are removed, so nothing new runs unless os_login arrives. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01P1grQ39ByRWPUtTBdTzEBF * server: name os_login in scope-violation logs A rejected os_login was logged as message.other. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01P1grQ39ByRWPUtTBdTzEBF --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Mariano Abad
|
109c39bccb |
fix(drm): drop a frame equal to the previous one, as the other capturers do (#16450)
* fix(drm): drop a frame equal to the previous one, as the other capturers do The producer grabs on a timer, so a still screen reached the encoder as the same frame every tick and the client decoded about 30 frames per second of nothing new (rustdesk#16449). The x11, pipewire and quartz capturers drop a repeat with would_block_if_equal; the drm capturer now does the same. A regression test checks that a repeat is not encoded again and that the next new frame is. The frame helper of the tests now differs per call, and the 180 test forgets the frame its last case repeats on purpose. * fix(drm): a frame whose encode failed is not dropped as a repeat The capturer marked a frame as seen when it returned it, so when its encode failed and the screen then stayed still, every later grab compared equal to it and it was never sent: the client kept the previous image, and a hardware encoder never reached its failure count to switch away. handle_one_frame now also says whether the frame was encoded, and when it was not the loop calls TraitCapturer::forget_last_frame(), a new method whose default does nothing. The DRM capturer then returns the next repeat instead of dropping it. The DRM capturer also stops keeping a copy of the last frame: it compares the new buffer with the one it returned last before replacing it, and a turned frame is turned into a spare buffer first. * fix(linux): x11 and pipewire do not drop a failed frame as a repeat either Both capturers drop a frame equal to the one they returned last, so they had the same hole as the drm one: a frame whose encode failed was not sent again while the screen stayed still. They now forget it when the loop says so. * fix(linux): every video run starts by forgetting the last frame A pipewire recorder outlives a restarted run while another display keeps the session open, and so did the frame it returned last. A run restarted by an encoder switch or a new subscriber then dropped the first repeat and sent nothing until the screen changed. The capturers of the other paths are built fresh for each run, so for them the call does nothing. * fix(drm): keep the repeat drop in the drm capturer, with one repeat a second The shared part of the three commits before is reverted: TraitCapturer, the video_service loop, x11 and pipewire are as on master again. So is the restructure of frame() from the second commit: the drop is again the one of the first commit, would_block_if_equal on the frame returned last, as the other capturers do. A repeat is dropped until a second has passed since frame() last returned a frame, so a frame whose encode failed reaches the encoder again a second later even if the screen stays still. The tests check the drop, the repeat a second later, and that the second starts over after it. * fix(drm): a frame is a repeat only when its format matches too The same bytes as BGRA and as RGBA are two pictures when red and blue differ, and the convert path can return either, so a change of format clears the saved frame and the new one goes out. The 180 test no longer checks a turned repeat: nothing reported asked for it. * fix(drm): compare a frame with cur before replacing it, without a copy saved_raw_data copied every changed frame (8 MB at 1080p). The previous frame is still in cur when a new one arrives, so the bytes and the format are compared with it before the swap; a rotated output turns the frame into a spare buffer first. The 180 test checks the turned repeat again, since that path compares on its own now. |
||
|
|
67090d3aa1 |
fix: a refused privacy-mode request no longer turns off another connection's (#16507)
* fix: a refused privacy-mode request no longer turns off another connection's `Connection::turn_on_privacy`'s error arm tore down whatever privacy mode was active, whoever owned it. With connection A in privacy mode, connection B's request is correctly refused with OCCUPIED, and the error arm then called `turn_off_privacy_to_msg(INVALID_PRIVACY_MODE_CONN_ID, ..)`. That id bypasses the ownership check in `check_off_conn_id`, so A's privacy mode went away: the screen was un-blanked and local input un-hooked. The call passes `state: None`, so no `set_privacy_mode_state` goes out either and A was never told, leaving its client showing privacy mode as on. `check_privacy_mode_changed` doesn't cover it, as it only sends PrvOnByOther while a privacy mode is still active. Pass `self.inner.id`, as the sibling error path above already does. `check_off_conn_id` then cleans up after this connection when it owns privacy mode, and refuses when another connection does. The bypass itself stays: `ipc::Data::Close`, `reset_all` and `TurnOnGuard` need an unconditional teardown. Its contract is now noted on `check_off_conn_id`, since that is what the buggy call site got wrong. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: Steven Storie <sstangle73@gmail.com> * fix: disconnect other remote sessions when privacy mode starts Signed-off-by: fufesou <linlong1266@gmail.com> * fix: exclude privacy disconnect hook from iOS builds Signed-off-by: fufesou <linlong1266@gmail.com> * fix: validate privacy mode before disconnecting other sessions Signed-off-by: fufesou <linlong1266@gmail.com> * chore Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: Steven Storie <sstangle73@gmail.com> Signed-off-by: fufesou <linlong1266@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: fufesou <linlong1266@gmail.com> |
||
|
Hintay
|
0bc2473ffe | fix(drm): size a plane-rotated scanout as the mode transposed (#16444) | ||
|
fufesou
|
3f4bfe535e |
Fix/wayland input keyboard layout (#16462)
* fix(linux): respect Wayland keyboard layouts for uinput Resolve printable keys from GNOME input sources or the Wayland keymap and KDE active layout group. Refresh layout metadata on input at most once per second, and preserve the keycode and owned modifiers until release. Preserve the original Legacy character on client key release and handle Caps Lock shortcuts without introducing an unwanted Shift modifier. Validated with GNOME/KDE full-service input and disconnect checks, plus Windows/Linux native keyboard capture and release checks. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): harden Wayland keyboard layout detection Keep the last usable map on transient discovery failures and preserve the legacy character path when no map is available, with explicit warnings. Retain each injected key representation through release and handle IBus default layout and variant metadata without compiling a layout named default. Use native GNOME and Plasma sources, including KWin sessions without the optional layout service. Read the Xwayland keymap and effective group from the same keyboard on other desktops. Load XCB/XKB libraries dynamically and accept the unix/:N local display spelling. Validation: 24/24 temporary Linux production-module and IPC checks passed, including an actual read-only Xwayland query. The two latest routing/display regressions failed before their fixes. Rustfmt and git diff --check passed. No Cargo/Flutter commands or full remote application tests were rerun. Xwayland state freshness and synchronous desktop I/O remain known limits. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): bound input waits for layout refresh Run throttled Wayland layout discovery in a single background worker and give the triggering input a 25 ms wait budget. Later input uses the existing map without waiting or queuing more queries. Preserve source error handling and skip known Legacy clipboard-only text. Document Xwayland freshness and per-character modifier ownership limits. Desktop calls remain uncancelled; the budget bounds input waiting, subject to OS scheduling. Validation: Linux module compilation with cached dependencies, 23 existing temporary module/IPC checks, and stalled-XCB timing probes passed. Rechecked cache/error/release cases after the final lock-scope change. No permanent regression tests or Cargo/Flutter commands. Signed-off-by: fufesou <linlong1266@gmail.com> * docs(linux): record layout query latency measurements Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): reply to failed uinput key state queries Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): prefer non-keypad character mappings Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): preserve text after unmappable uinput characters Continue processing a text sequence when one character cannot be resolved in the host layout. Return the first mapping error after the supported characters are injected, so the existing throttled log still reports failure. Keep modifier-query, injection and release errors fail-fast. This fixes German a^bc losing bc without adding clipboard or fixed-US fallback. The unsupported caret remains an explicit mapping error. Validation: three temporary Linux checks (nine inputs) passed using the production resolver and sequence methods, real framed IPC and native XKB decoding. The suffix check failed before the fix. Formatting and diff checks passed; no permanent tests, Cargo/Flutter commands or full app build added. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): preserve Latin shortcuts on non-Latin layouts Detect Ctrl/Alt/Meta independently of CapsLock. If the active XKB map lacks an ASCII shortcut letter, reuse the existing physical letter mapping while preserving explicit Shift and the press-time key for release. Existing layout mappings and unsupported ordinary text retain their behavior. Honor disable-uinput-layout-fallback and log this compatibility path with the existing throttle. Validation: 12 temporary Linux production-module/IPC checks passed, including 43 non-Latin shortcut/layout/lock/Shift cases. The new checks failed before the fix. Formatting and git diff --check passed. No real mobile/compositor session or Cargo/Flutter build was run. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): preserve missing punctuation shortcuts Allow missing ASCII graphic shortcuts to reuse the existing physical key table when Ctrl, Alt or Meta is active. This restores Ctrl+[ and Ctrl+] with a valid Russian layout instead of discarding their character events. Retain the table's Shift requirement for punctuation and use existing modifier ownership and press-time release tracking. Uppercase letters do not synthesize Shift. Active-layout mappings, ordinary text errors and disable-uinput-layout-fallback retain their behavior. Validation: 14 temporary Linux production-module/IPC checks passed after recompiling the final source with rustc and cached dependencies. Includes 19 punctuation/lock/Shift combinations and 43 existing Latin-shortcut cases. The two new checks failed before the fix. Formatting and git diff --check passed. No Cargo/Flutter build or real mobile/native Wayland session was run. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): respect held Shift when resolving shortcuts Derive Shift-held candidates from the same XKB keymap and query the caller's Shift state for character shortcuts. On US layouts, Ctrl+Shift+< now uses the comma key instead of the extra ISO key that produces >. Keep caller-held Shift out of synthesized modifier ownership. Preserve ordinary input and letter-shortcut identity, and do not replace an ordinary shortcut with a keypad alias to satisfy the held-Shift lookup. Validation: 16 temporary Linux production-module/IPC checks passed with native XKB event replay and cached dependencies via rustc. Includes 30 US text/shortcut cases and 40 UK/DE/FR character/lock cases. The new Ctrl+Shift+< check failed before the fix. Changed sections pass formatting and git diff --check. No Cargo/Flutter build or real mobile/native Wayland session was run; device-state and packet-modifier handling use fixtures. Signed-off-by: fufesou <linlong1266@gmail.com> * docs(android): document paired-punctuation input limitation Signed-off-by: fufesou <linlong1266@gmail.com> * docs(linux): explain Xwayland layout synchronization limits Document the focus-scoped modifier updates observed on GNOME and KWin. Core and physical X11 keyboards can retain an old layout group while native Wayland windows have focus; reconnecting or waiting cannot request the missing update. Validation: 16 existing module/IPC probes and the live GNOME mapping probe passed. Live KDE queries reproduced native French versus stale Xwayland US. Formatting and diff checks passed. This is a comment-only change; strict Xwayland-only behavior is preserved. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): query native Sway and Hyprland keyboard layouts Read the uinput keyboard's active layout through compositor IPC and validate its group against the native Wayland keymap. Match the IPC server to the Wayland session, and accept numbered Hyprland device names while rejecting ambiguous keyboard selections. Validation: 21 temporary production-module and framed-IPC checks passed. Live Sway US/FR group and a/q mapping checks passed with Xwayland disabled; the GNOME French layout probe also passed. Formatting checks passed. A live Hyprland session and a full application build were not tested. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): defer unverified native compositor layout queries Remove the Sway/Hyprland adapter that paired a uinput device's layout group with a seat keymap based only on matching layout names. Different device options can make a synthesized AltGr key toggle CapsLock instead. Restore the existing best-effort Xwayland source for other desktops and document the device-keymap information missing from the examined native queries. GNOME/KDE discovery and injection/cache behavior are unchanged. Validation: 16 temporary production-module/IPC checks passed after the removal, plus read-only GNOME French and Xwayland mapping checks. Rust formatting and diff checks passed. No full application build or mobile end-to-end test was run for this follow-up. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): reject unreliable GNOME per-window layout sources GNOME restores per-window layouts without persisting MRU. Reject MRU selection when per-window input sources are enabled with multiple sources, and invalidate the cached map and source identity for this typed error. Transient discovery failures still retain the last valid mapping. Reuse the existing logged/disableable compatibility policy. This contains stale-map acceptance; it does not add effective per-window layout discovery. Single-source and global-source GNOME configurations retain their path. Validation: the old code failed the temporary stale-cache regression. All 3 focused production-module checks pass after the fix, covering cache invalidation/recovery, compatibility modes, single/default source mapping, UK punctuation, and last-good retention after an IBus connection failure. Compiled with rustc and cached Linux dependencies; formatting/diff checks passed. No permanent tests, Cargo/Flutter build or mobile session added. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): reject inactive IBus layout sources Read the current GlobalEngine description instead of looking up the persisted MRU engine by name. GNOME can suppress IBus for password entry without updating MRU, leaving the old engine's layout valid but inactive. Report an engine-ID mismatch as UnreliableSource so the existing cache invalidation path drops that mapping. Keep transient query-error handling and layout/variant normalization. Do not infer a US compositor layout from GNOME's xkb:us::eng echo engine. Validation: the old code failed the inactive-engine cache and default-layout checks. All 3 temporary production-module/D-Bus checks pass with this fix, covering invalidation/recovery, compatibility policies, metadata sentinels, query failures and ordinary French XKB selection. Compiled with rustc and cached Linux dependencies; formatting/diff checks pass. No permanent tests, Cargo/Flutter build or live password/mobile session added. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): prewarm uinput layout discovery at startup Start the existing layout worker when the uinput keyboard client connects, before the server accepts remote input. Reuse its throttle and single-worker logic; keep the existing 25 ms input wait and background completion policy. Prewarming reduces cold-start fallback without introducing input queues or promising readiness while a desktop query remains outstanding. Verified with three temporary Linux production-module checks using cached dependencies: a 125 ms query resolves UK @ before first input, a 200 ms outstanding query stays nonblocking and publishes its map, and a failed startup query retries successfully. All three fail their startup assertions before the change. No permanent tests or Cargo/Flutter builds were added. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): preserve first input wait during layout prewarming Keep the startup query's completion receiver until the first relevant input takes it. That input can wait for the already-running query within the existing 25 ms deadline, without holding the receiver handoff lock. Later input remains nonblocking and the existing single-worker guard is unchanged. Prefer a due refresh to an old completed startup notification. Verified with four temporary Linux production-module checks compiled with rustc -C opt-level=3 and cached dependencies: joining a pending UK query, one bounded wait followed by nonblocking input, due refresh after prewarm, and recovery after query failure. Both lost-wait checks fail before the fix. Formatting and git diff --check pass. No permanent tests or full build added. An unoptimized delayed-query probe still exceeded 25 ms and used fallback; this restores the wait opportunity, not an initial-readiness guarantee. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(uinput): remove unnecessary change Signed-off-by: fufesou <linlong1266@gmail.com> * refactor(linux): simplify uinput character releases Release the mapping stored for the same character. Linux character input already pairs down/up events, so opposite-case matching is unnecessary. Validation: git diff --check passed. Static comparisons confirmed that Map-mode dispatch, raw-key injection and keycode offsets match the PR base. No Cargo/Flutter commands or live-session tests were run. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): normalize Unicode CapsLock shortcuts Normalize single-scalar Unicode lowercase for CapsLock shortcuts without adding Shift. For lowercase expansions, resolve the original symbol with the actual CapsLock state instead of truncating it. Document the existing first-seat discovery limitation. Validation: two temporary Rust context checks against lookup fixtures failed before the fix and passed afterward. No Cargo/Flutter build or end-to-end input test was run. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): derive CapsLock shortcut keys from XKB Keep the actual CapsLock state when resolving shortcut characters. Use the existing Caps-off and Caps+Shift mappings to omit generated Shift only when XKB confirms the same physical key and remaining modifiers, preserving the Turkish I/ı and İ/i key identities. Validation: three temporary production-module checks passed on 192.168.5.32 with native libxkbcommon; two failed before this fix. Covered Turkish, German, Cyrillic and ASCII shortcuts, explicit Shift, ordinary text and UK punctuation. No full application build, IPC or end-to-end input test was run. Signed-off-by: fufesou <linlong1266@gmail.com> * refactor(linux): remove CapsLock shortcut special cases Use the existing lock-state synchronization and ordinary XKB mappings for mobile soft-keyboard input. Remove CapsLock-specific shortcut remapping and compatibility-path lowercasing while retaining held-Shift punctuation handling. Validation: rebuilt the Linux Rust library and reused the unchanged Flutter UI. Actual Android Gboard input matched UK punctuation on GNOME and KDE; French/German switching on KDE passed after the refresh interval. The user confirmed real iPad input on both hosts, including smart quotes. Formatting and whitespace checks passed. The optional Ctrl/Shift toolbar automation was inconclusive and is not counted as passing coverage. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): press Level3 before Shift for uinput characters Preserve mapping candidate preference while storing generated modifiers in Level3-before-Shift order. This avoids activating Compose with lv3:ralt_switch_multikey; releases retain their existing reverse order. Verified on Linux with temporary production-mapper/libxkbcommon tests: Lithuanian ! fails before this change and passes afterward; all 24 UK punctuation/lock-state cases pass with released modifiers and unchanged lock state. Formatting and diff checks pass. No full application build or mobile end-to-end test was run for this change. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): preserve legacy uinput IPC without a keymap Send sequences and character clicks through their original IPC messages when the layout cache is unavailable, avoiding unnecessary synchronous key-state queries. Keep throttled fallback warnings and leave layout discovery, retry policy, and key-down/up pairing unchanged. Verified with three temporary production-method checks on Linux using a recording transport and injected query errors. The unavailable-map routing check fails before the fix and passes afterward; raw-click routing and available-map query-error handling remain unchanged. Changed-code formatting and diff checks pass. No full application build or end-to-end input test was run. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): skip layout queries for legacy uinput fallback When no keymap is available, single-character input must use the legacy KeyDown/KeyUp path without querying lock or modifier state first. Retain the legacy key in the existing press record so discovery completing before a repeat or release cannot change the selected representation. Validated with four temporary production-method checks on Linux using a controlled cache/resolver and recording transport: missing-map fallback with query failures, press/release across cache transitions, unchanged raw-key dispatch, and Ctrl+C without extra Shift or queries. The initial fallback check failed before this change. Valid-map errors still surface. Changed-code formatting and git diff --check pass. No full Cargo/Flutter build or live service/mobile test was run for this change. Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: fufesou <linlong1266@gmail.com> |
||
|
NetViperandRustDesk
|
6da7977a94 |
fix(video): defer refresh teardown until hw encoder warms up (#16459)
* fix(video): defer refresh teardown until hw encoder warms up
On macOS, hevc_videotoolbox (the only encoder there reporting
!latency_free()) can return no packet for its first encode call. The
OPTION_REFRESH check in run() tore the encoder down with
bail!("SWITCH") inside that window, so each new encoder was destroyed
before producing a frame and rebuilt about once a second. With H265
selected on macOS 27 / Apple silicon, the picture froze or the session
dropped every 1-3 minutes.
On macOS, once the encoder has been fed a frame, defer the refresh
until it emits its first packet. Before that there is no warm-up to
lose, so a refresh can still restart a stalled capturer. Other
platforms and every latency-free encoder behave as before. An encoder
that never emits is still switched away from by the unchanged
max_fail_times path. The only new state is one flag.
Verified on macOS 27.0 / 27.0.1, M5 Pro, 2560x1440 H265. Soaked for two
weeks on a 1.4.9-based build carrying this deferral:
- before: ~40 "no valid frame" and ~27 refresh teardowns per 60s
- after: 37 sessions, every "no valid frame" at times:1, so
max_fail_times was never approached; H265 never lost
Fixes #16457
Signed-off-by: David Riding <48262524+dmriding@users.noreply.github.com>
* Update video_service.rs
---------
Signed-off-by: David Riding <48262524+dmriding@users.noreply.github.com>
Co-authored-by: RustDesk <71636191+rustdesk@users.noreply.github.com>
|
||
|
fufesou
|
25d2c6db55 |
log key-up and text injection failures (#16455)
* fix(macos): log key-up and text injection failures Report failed key releases through the rdev input path and missing sources, mappings, or events in the Enigo keyboard path. Throttle repeated failures without logging text contents or changing input behavior. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(macos): refine keyboard failure diagnostics Remove key identities from virtual-input and Enigo failure logs while preserving operation and failure details. Also report key-down event creation failures in key_click with the existing throttle, without changing event posting or error propagation. Signed-off-by: fufesou <linlong1266@gmail.com> * refact(logs): update rdev, add diagnostic logs Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: fufesou <linlong1266@gmail.com> |
||
|
Mariano Abad
|
685fa2e4a1 |
fix(drm): the startup cache warm does not wake sleeping displays (#16437)
* fix(drm): the startup cache warm does not wake sleeping displays
Every `_drm` connection ran the display wake before the service answered with
its list, so the cache warm that each --server start runs (the service restarts
the --server every hour) woke displays that had idled off, with no client
connected (rustdesk#16356).
The --server now opens the handshake with DrmHello{wake}, and the service wakes
and settles only when asked. The warm asks without a wake; the availability
probes, the login refresh and the capture stream keep it, since a client is
waiting for them. Without a wake the service still clears the wake latch of a
connector it sees lit, as the warm did.
A warm that finds nothing lit leaves the cache without a verdict, where its own
wake used to make it Available. So a login that the DRM path can serve now
probes on a missing verdict before anything reads the cache (the greeter check,
the PipeWire prompt, the display list). That probe wakes the displays as the
warm did, but only when a client logs in.
* fix(drm): throttle the log of a peer that does not open with DrmHello
AGENTS.md: a log call that can fire at a rate a peer controls must not use
debug or higher unthrottled. Same 5 s interval as the rejected-IPC logs in
ipc/auth.rs.
* fix(drm): the startup warm keeps a list a login published while it queried
Per review: the warm samples the state generation before its query and
publishes only if no other probe published since, the check the two
background refreshes and the login refresh already use.
* fix(drm): log a failed login settlement task instead of dropping its error
Per review: the JoinError of the blocking task was discarded with `let _ =`.
|
||
|
berce
|
40a4aa34c8 |
Don't retry the _pa ipc at a Linux login screen (#16390)
At a greeter the cm is not started, so the `_pa` socket never exists and the audio service fails to connect and logs an error once per second for as long as a client is connected. Wait in `pa_impl::run` while `is_prelogin()` is true; audio starts once a user logs in. Fixes #16012 |
||
|
|
b6b11fd9b1 |
fix(drm): apply the uinput range on one thread instead of holding a lock across the await (#16362)
* drm: apply the uinput range on one thread instead of holding a lock across the await #16122 serialized the three paths that apply a uinput range in a DRM session (the layout poll, `update_uinput_resolution` and `check_init`) with a tokio Mutex held over the awaited `update_mouse_resolution`, which AGENTS.md rules out ("Do not hold locks across `.await`"; greptile on #16122). The serialization itself has to stay: the uinput service keeps the range of whichever request reached it last and each apply sends it over its own connection, so two overlapping applies can leave the device on one range while the other one is recorded. The check, the apply and what it records now run as one job on a dedicated thread (`run_uinput_apply`), one job at a time in the order asked, with the runtime of that thread for the IPC and its 3 s timeout. The async paths await the answer and the display service loop blocks on it; nothing holds a lock while it waits. The poll publishes its drift flag inside its job, as it did under the lock. A thread that failed to start or died is started again for a later job, so one failure does not stop every later apply (the poll used to build a runtime per attempt and retry). The drm-off build keeps the code it had. Tests (in `input_map_tests`, which CI runs): uinput_applies_run_one_at_a_time_in_the_order_asked, a_uinput_apply_job_can_bound_its_ipc_with_a_timeout, a_uinput_apply_thread_that_died_is_started_again. Mutations: every job on its own thread, the apply runtime without timers, the answer never sent, a dead thread not started again; each turns a test red. The call sites run IPC and are covered by reading. * drm: log a layout poll whose uinput apply job got no answer The layout poll dropped the result of its job with let _ =, so a poll whose job was dropped (the apply thread failed to start or went away) left no trace, while update_uinput_resolution and check_init log it (greptile and CodeRabbit on #16362). It logs now. The drift flag keeps what the last poll that ran published; a later poll starts the thread again and publishes it. * drm: throttle the uinput apply thread failure logs The layout poll hands the apply thread a job every 1.5s, so a thread that cannot start logged two errors per poll for as long as a session lasted. Keep one line per site every 10 minutes, with the count of the rest. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: rustdesk <71636191+rustdesk@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Cipher Professor
|
d1722c5d6d |
fix(linux): use BUS_VIRTUAL for the virtual mouse device (#16382)
The uinput virtual mouse RustDesk creates on Linux reported bustype BUS_USB. libinput's evdev_tag_external_mouse() tags any BUS_USB or BUS_BLUETOOTH pointer device as an external mouse, so desktop environments' "disable touchpad when an external mouse is present" setting suspends the user's real touchpad whenever RustDesk creates this device, even though nothing is physically plugged in. Changed the constant to BUS_VIRTUAL (0x06, verified against the current upstream kernel's include/uapi/linux/input.h), which correctly identifies this as the software-only device it is. Fixes #16318. Signed-off-by: Mohsin Manzoor Bhat <mohsinmanzoor1913@gmail.com> |
||
|
Mariano Abad
|
0d49ead0c3 |
fix(drm): turn a captured frame only when the plane did not rotate it (#16345)
* fix(drm): turn a captured frame only when the plane did not rotate it A compositor rotates an output either in hardware, setting the primary plane's `rotation` property, or in software, drawing the scanout already turned. `wl_output` cannot tell the two apart, and `frame_transform` guessed: 90/270 turned, 180 left alone, which is right for i915 + mutter (rotate-180 in hardware, scanout upright) and wrong wherever the compositor drew the scanout turned, where 180 comes out upside down. Measured before changing it. virtio-gpu (no rotation property, mutter 46): the scanout dump at 180 is the desktop upside down, at 90 and 270 the logical desktop turned inside the native mode framebuffer. i915 + mutter (GNOME 50) at 180: the plane reports rotate-180 and the dump is upright, identical to the unrotated one. amdgpu + KWin 6 at 180: the plane stays at rotate-0 and the dump is upside down. The producer reads `drmtap_plane_rotation()` (libdrmtap 0.5.8, optional symbol) right after each grab and stamps it on the frame, in the dma-buf descriptor and in the CPU frame header, both `serde(default)` so an older producer still parses. A plane that rotated scans out the logical desktop whatever the output transform says: the compositor programs it from the CRTC transform, which also folds in the connector's panel orientation that `wl_output` never carries, so the consumer leaves such a frame alone. A plane at rotate-0 scanned out what the compositor drew, and the frame is turned by the whole output transform. `None` (a library before 0.5.8, or nothing it could read) keeps the previous rule, so nothing changes until the library says otherwise. The session is still sized from the output transform: a plane that rotated 90 in hardware hands over the portrait scanout those dims already name. * build: pin libdrmtap 0.5.8 (rustdesk-org/libdrmtap 95d4d7454) The rotation fix reads drmtap_plane_rotation(), added in libdrmtap 0.5.8. The mirror carries that commit since 2026-09-25, so the pin moves there. * drm: pin the decoding of a frame from a producer older than the plane rotation The root service and the --server are upgraded separately, so a frame header or a dma-buf descriptor without `plane_rotation` must still decode, as None, which keeps the previous rule. The tests built both messages with the field set to None; this one decodes payloads that omit it, and one that carries it (greptile on #16345). Serde already reads a missing Option as None, so what the test pins is the wire name and the None on absence, for both messages. Mutation: renaming the field on the wire, in either message, turns it red. * drm: take the plane rotation right after the grab, not after the copies `drmtap_plane_rotation()` reads the rotation property of the plane the last grab came from at the moment it is called. The cpu path asked only after `DrmReader::grab()` had copied the frame into its buffer and the producer had copied it again into the message, so on a large frame the compositor had time to change the plane and the frame went out with the rotation of the next one; `frame_transform` turns that frame by it with nothing to absorb the skew (zhou, review of 26-sep). `DrmReader` now reads the rotation right after a successful `drmtap_grab_mapped` or `drmtap_grab_desc`, before any copy or release, and `plane_rotation()` returns that snapshot, so both paths stamp a frame with the rotation its own grab saw. Test: a_frame_keeps_the_rotation_its_plane_had_when_it_was_grabbed, in `plane_rotation_tests` (which CI already runs), drives the reader through a fake library whose frame release turns the plane: the rotation read at the grab survives on the cpu grab and on the dma-buf export. Mutations: no snapshot on the cpu grab, none on the export, and the cpu snapshot taken after the release, each turn it red. |
||
|
Mariano Abad
|
50258e21e9 |
fix(drm): measure the cursor hotspot on drivers without HOTSPOT_X/Y, confirm before publishing (#16122)
* drm: carry the cursor plane position on the frame header
CursorSnapshot gains the plane position x/y. It rides DmabufDesc.cursor_pos
and Data::DrmFrame.cursor_pos as a serde-default Option, so a producer that
predates the field reads as None on the consumer, and a consumer that predates
it ignores the key. The producer reads the cursor once per delivered frame,
after the grab, so a WouldBlock retry does no cursor work; the position is a
few ms newer than the frame, which the consumer tolerates because it only
counts consecutive identical positions. The consumer destructures the field
and does not use it yet.
* input: remember the last absolute peer move and forget it on any other move
The DRM cursor calibration subtracts a cursor plane origin from the point this
process injected, so the point has to be the post-remap uinput one and nothing
else: LATEST_PEER_INPUT_CURSOR stores an X-server coordinate on the relative
arm. The new sample carries an Instant, a sequence number (two measurements
against one sample are not independent) and the layout generation it was
mapped against. A relative delta and a move this process makes itself forget
it. display_service exposes the existing drift flag to readers.
* drm: resolve the cursor calibration context once, with the capturer
CalContext { rect, physical_size, built_gen } is computed in
IpcDrmCapturer::new from the same wayland snapshot the transform comes from,
and only when the snapshot is complete, the output is an identity match, the
unfolded transform is 0 (180 included) and the geometry is valid. It is
stored in Shared before the transform's Release store, so a receive thread
that has seen the transform sees the context. Nothing reads it yet.
* drm: measure the cursor hotspot and confirm it before publishing
On a driver without HOTSPOT_X/Y the wire carries infer_hotspot's guess, which
the bitmap cannot get right for a shape whose click point the theme put where
the alpha does not mark it. This process injects the tip and the plane origin
rides every frame: once both are still, tip - origin is the hotspot.
Only a guessed shape is measured. The first measurement is a candidate and
changes nothing visible. A second measurement confirms it only from another
stable plane position and another peer sample, and then the retained
candidate is the one value that reaches the cache, the served hotspot, the id
remix and the delivery. Near what is served, nothing changes, even when the
value is also near the wire, so a correction a few px from the wire does not
flap; near the wire otherwise, the wire is served and the cached correction is
dropped. A stable position is measured at most once, a layout generation
change stops measurement once the display service's poll has seen it, and the
cache is read only behind the context gate, so a correction measured upright
never reaches a rotated output.
Each of these gates has a test that goes red with the check removed or
altered (file restored byte for byte afterwards):
publish the first measurement -> retained candidate, same sample, still plane, local nudge
same sample confirms -> same sample never confirms, local nudge
confirm with the new value -> retained candidate, near wire, in band
drop the near-wire arm -> near wire serves the wire
drop the in-band arm -> in band changes nothing visible
drop the re-store after clear-on-cap -> in band stays cached
measure a kernel-measured hotspot -> never calibrated at the origin
read the cache without a context -> not served without a context
drop the once-per-position flag -> still plane measured once
drop the transform gate -> context only for an upright output
swap phys and extent -> the arithmetic, the scaled context
drop the clear-on-cap -> cache bounded
drop the partial-snapshot gate -> context only for an identity match
drop the generation check -> closed intervals
compare the wire before the served -> in band with both keeps the served correction
* drm: a cached hotspot correction is served only under the generation it was confirmed in
The calibration cache mapped a wire cursor id to its confirmed hotspot
and nothing else. A pair of stops taken inside the layout poll window,
after a monitor moved and before the poll saw it, could confirm a value
measured against the old layout; the generation gate then stopped that
stream, but the capturer rebuilt after the promotion seeded its served
hotspot from the cache and replayed the value under the new layout, until
another pair of its own replaced it (zhou, review of 25-sep).
Each entry now carries the layout generation it was confirmed under, and
a stream reads the cache under its own `built_gen` only: a value from
another generation is not served, the wire hotspot is, until a pair on
this generation confirms one. Checked at the read rather than by clearing
on promotion, and an entry is replaced or dropped only by its own
generation or a newer one, the bound included (at the cap the cache
clears what the writer's generation or an older one confirmed, and
caches nothing if only newer entries are left), so a receive thread
still running on the old layout can neither serve its value to the
rebuilt stream nor undo the value that stream confirmed.
Tests: a_correction_confirmed_under_an_older_generation_is_not_served (two
stops under one generation, the stream rebuilt under the next, its own
pair, then the old stream writing late),
the_bound_never_drops_an_entry_from_a_newer_generation. Mutations:
reading without the generation filter, replacing or dropping a newer
entry from an older generation, and at the cap either clearing
everything or caching when only newer entries are left, each turn one
of them red.
* drm: calibrate only against samples injected under the layout's adopted uinput range
`usable_sample` took the remap flag being clear as "the input mapping is
ready". It is not: the display service bumps the layout generation and
promotes the baseline before the uinput range update completes, and a
failed or pending update leaves the device mapping absolute coordinates
with the range of the previous layout. Every sample then carries the new
generation while its point lands scaled by the old range; two stops share
that error and agreement confirms it (zhou, review of 25-sep: a desktop
narrowed from 4000 to 3800 px puts a hotx of 4 at 54, inside the bitmap).
The display service now keeps the layout generation whose uinput range
the device runs, and a count, raised when an apply starts and again when
the device acknowledges it. Both move when `update_mouse_resolution`
returns Ok, on the DRM session-init path (also run by the hotplug
worker) and in the layout poll; the session-init path labels the range
with the generation read before it computed the rect, and the raw DRM
union it falls back to when the compositor cannot be asked with no
generation, so no stream measures on it until the poll applies or finds
a compositor range. A range that already fits the layout moves the
generation only, so the samples injected under it stay valid. From the
moment an apply starts, on any path, no generation is ready, the count
is raised and the recorded rect is forgotten, so an apply that fails or
times out (the device may still take the range late) leaves nothing
ready, and only an acknowledged apply records a generation again. The
poll and `update_uinput_resolution` run on different threads; they
check, apply and record under one lock. `check_init`, which a display
falling back to PipeWire runs inside a DRM session, records its apply
the same way (cfg(feature = "drm") lines only; the drm-off build is
unchanged). It has no fits check and applies on every run, as before, so
each run moves the count. A path that read its generation before the
poll bumped it records under the older one; no stream measures then
until a later layout check records the current one. A sample is stamped
under the ENIGO guard of its move, which an adoption also needs for its
refresh, so a move stamped with the count of an adoption was injected
after that adoption's refresh. The count is raised before the generation
is published and read after it. A stream measures only while that
generation is its own; each peer sample carries the count at injection
and is a reference only under the current one; a candidate measured
under one count starts over instead of confirming under the next. The
remap flag is untouched.
Tests: a_stale_input_mapping_publishes_nothing_until_fresh_samples_follow_the_adoption
(generations equal, no drift, the device on the previous range: two
stops publish and cache nothing; after the adoption a sample from before
it does not count, and fresh ones confirm),
a_sample_is_a_reference_only_under_the_adopted_input_mapping,
a_candidate_does_not_confirm_across_an_input_mapping_change,
an_acknowledged_range_is_an_adoption_and_a_fitting_one_is_not,
the_raw_drm_union_labels_a_range_with_no_generation,
an_apply_leaves_no_range_ready_until_it_is_acknowledged; the drm CI step runs
input_map_tests. Mutations: dropping the adopted-generation gate,
dropping the count gate, confirming across counts, an adoption that does
not count, a fitting range that counts, the union labelled with the
generation, and an apply that keeps the recorded rect or leaves a
generation ready, each turn one of them red. The call sites (the lock,
the calls before and after each apply on the three paths, the range-fits
branches) run IPC and are covered by reading.
* drm: forget the peer sample under the mouse lock on a move of this process
The temporary-move thread (the display probe `fill_displays` runs in the
PipeWire init, `check_init`) forgot the last absolute peer sample before
it took ENIGO. A peer move holding ENIGO at that moment moved the pointer
and recorded its sample after the forget, and the temporary move then
landed on top: the pointer somewhere else, the sample still the peer
point, with the current generation, count and a fresh sequence, so two
such overlaps could confirm a wrong hotspot (zhou, review of
|
||
|
RustDeskandClaude Opus 5.5
|
e9ddbd8f46 |
cursor: bound the decoded cursor caches on the Flutter client (#16304)
* cursor: name a shape by what it looks like, not by its handle A cursor id was the platform's handle for the shape: HCURSOR on Windows, the XFixes serial on X11. Apps mint a new handle for a shape they have shown before (Chrome, Electron, Qt custom cursors), and an X11 animated cursor gets one per frame, so one arrow arrived under thousands of ids over a session. The controlled side cached and sent it again under each, and the controller decoded, rendered and kept it again under each, and grew by gigabytes over weeks of connection. The controlled side now names a shape by an xxh3 hash of its size, hotspot and pixels, taken once when a handle is first seen, before the pixels are compressed. The per-connection send already sends a shape once and afterwards only its id, so a shape now crosses once however many handles it has. The id is opaque in the protocol, so controllers of any version accept it. The DRM backend already named shapes by content with FNV-1a; it uses the same hash now. A peer before 1.5.0 still names shapes by handle, and the fix has to work against every deployed peer. For those peers the controller hashes each CursorData's compressed colors with its geometry: one peer compresses the same pixels to the same bytes, so a shape seen before is recognised without being decompressed. The UI gets that shape once, under one id, and every later handle for it is passed on as a cursor_id of that id. The map from the peer's ids is kept for the connection, unbounded, since the peer sends a shape once and may select any id it named again; an entry is two integers. From 1.5.0 the controller passes the peer's ids through unchanged, on the old path. The web core in flutter/web does the same in its own tree. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: hold a content id to what the web client can read The web client decodes a u64 into a JS number and throws on a value past 2^53, which drops the whole message. A full 64-bit xxh3 id is almost always past it, so a web client connected to a peer on this build would never have been given a cursor shape. DRM's ids were already full width, so web clients lost the cursor on DRM peers too; the controlled side now renames those as well. The id keeps the hash's low 53 bits. Two of ten thousand distinct shapes then collide with a chance of about one in two hundred million. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: hand the UI a shape's pixels as they are, not as text A shape's pixels went to the Flutter UI as a JSON array of integers inside the cursor_data event: the core serialised a 1 MiB shape into up to 4 MiB of text on the receive loop, and the UI parsed that into a million-element list and copied it into bytes, on the UI thread. The event, text and all, was then kept for the session so that a tab moved to another window could replay it, and a reconnect, on which the peer sends every shape again, appended another copy of each. The core now sends a shape as an EventToUI::Cursor variant carrying Vec<u8>, which flutter_rust_bridge hands to Dart as a Uint8List, on the same per-session stream as the events so that it keeps its order with the cursor_id events around it. The web core calls onCursorData with the Uint8Array, as it calls onRgba for a frame. The id stays text, since the peer's ids can exceed Dart's int. The replay keeps each shape's pixels once, by id, and encodes them as base64 only when a tab moves. A shape arriving is also recorded as the last one selected, since the replay goes in first-seen order; before, a tab moved right after a new shape came back on the previous one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: let a controller ask the peer for a shape again A peer sends each shape once per connection and afterwards only its id, so a controller must keep every shape it was sent for as long as it is connected. The controlled side now answers Misc::request_cursor_data with the CursorData of that id, from the shapes it has sent, and only to a connection the cursor service would send it to. A controller from 1.5.0 on can then bound what it keeps and ask again for a shape it let go. None asks yet: the peer has to have the answer before a controller can rely on it, and peers are updated last. The shapes are kept by content id, and every handle for a shape shares its one message, where each handle used to keep its own copy. They are dropped with the service's own cache. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: keep a shape as its ui.Image and nothing else Each shape the UI had been sent stayed in four copies for the session: the pixels for a tab move, an image package copy to resize from (on a macOS or Linux controller of a Windows or Linux peer, a second one decoded back from a PNG), the bytes handed to the native cursor, and the ui.Image painted when the peer moves the pointer. A shape now keeps only its ui.Image. The resize source and the native bytes exist while a native cursor is being registered and are dropped once it is; a shape shown again at a raster it was registered at needs neither. For a raster it lacks, the pixels are read back from the ui.Image, which returns them exactly as they came. A tab move reads every shape back the same way, and the moved window decodes them as it would have on arrival. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: pin that a released shape keeps neither its pixels nor its bytes The shape in use once registered, the shapes not in use, and the pixels read back for a moved tab are all dropped; the tests now say so, so that a later change keeping one of them fails. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: keep one native cursor per shape, and each tab its own A shape got a native cursor for every raster it was shown at, and all of them stayed until the session ended, so every zoom or DPR change added a native cursor for each shape in use. A shape now keeps the one at its current raster; the one it replaces is deleted the next time a cursor already registered is built, by when its successor has been activated. A raster returned to before that takes its cursor back instead of registering another under the same name. The native cursors of a window's engine are shared by its tabs, and the predefined cursors had one name in all of them, so a tab closing deleted the default and forbidden cursors the other tabs still showed. Names are now scoped to the tab's cursor model. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: keep the shapes compressed in the core, and only the one in use in the UI The UI kept every shape as a ui.Image, one raw copy each, for as long as the session lasted, because the peer sends a shape once and a shape might have to be drawn again. The core receives the shapes compressed, at a few hundredths of that, and now keeps them so: Session::cursor_shapes holds each shape that decoded, as the peer sent it, under the id the UI knows it by. The colors are copied, since the message's may be a slice of a larger received buffer. The UI keeps a ui.Image for the shape in use alone. A shape shown again at a raster its native cursor has needs no pixels at all; for a raster it lacks, for painting it, or for the window a tab moved to, the UI asks the core through session_get_cursor_shape, which decompresses and checks the shape again with decode_cursor_data, the same size and decompression limits as on arrival. A shape the core cannot give is not asked for again until the peer sends it. A tab move now carries only the id in use, and nothing is read back from the GPU. The web core keeps the shapes the same way and gives them back through getCursorShape. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: a decode that finishes after the session clears keeps nothing A shape asked of the core while a tab closed was decoded after the cursor model had been cleared and stored in it, where nothing disposed of its ui.Image again; a shape whose cache failed to build left its ui.Image undisposed as well. A clear now starts a new generation, and a fetch or decode from an earlier one disposes what it made. A shape the core gave but that did not decode is not asked for again on every frame it is painted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: keep a native cursor for the shape in use alone Every shape the peer showed kept a native cursor for the session, each a raster the size of the shape as displayed. A shape switched away from now gives its native cursor up the way a replaced raster does: deleted the next time a cursor already registered is built, taken back if the shape returns first. A shape shown again after that is rebuilt from the compressed copy the core keeps. The predefined cursors are not the peer's shapes and stay registered. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: keep the native cursors of the 16 shapes used last Keeping a native cursor for the shape in use alone rebuilt one on nearly every switch, since the pointer moves among a few shapes: the arrow, text, hand, four resize arrows, wait. The native cursors of the peer's shapes are now kept in order of use, 16 of them, and the one used longest ago gives its cursor up the way a replaced raster does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: forget the native cursors a session clear deletes The clear deleted every registered native cursor but kept their names, so a cursor model used again, as the mobile client's is, took each name for registered and showed a cursor that no longer existed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: hold a native cursor to 512 pixels a side A native cursor could be registered up to 1024 pixels a side, four MiB of pixels each, which with sixteen kept made 64 MiB at worst. The largest cursor a system shows is 256 pixels (Windows' largest pointer size), so a raster twice that is shown no larger: the cursor is drawn smaller rather than rejected, and sixteen kept come to 16 MiB at most. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: a shape switched away from while it decodes is not marked lost A shape asked of the core was taken for undecodable when it was no longer kept once its decode finished, but a shape the peer switched away from in the meantime is let go on purpose, and marking it made every later request for it be skipped: its native cursor stayed deferred and its painted cursor missing for the rest of the session. The decode now reports whether it decoded, and only a failure marks the shape. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * flutter: leave two untouched signatures as they were dart format had rewrapped registerEventHandler and sessionSetCommon next to the cursor additions. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: read a shape's pixels from where its view starts The pixels used to be copied out of the JSON event into a fresh list, so the list's buffer began at its first pixel. Now they come straight from the core, native or web, as whatever Uint8List it hands over, and img2's fromBytes takes the buffer, not the list, so a view into a larger buffer would have been read from the buffer's start. Neither core gives a view today; this stops depending on that. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: a DRM cache reset keeps the shape it was making room for The shape being sent was filed in CURSOR_SHAPES before the DRM ceiling cleared it with everything else, so a controller asking for the shape on screen got nothing until the next new shape. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: delete a replaced native cursor at the next build that shows one A replaced native cursor was deleted only by a build of a cursor already registered, so a run of new shapes, each shown once, left every replaced cursor registered: 16 on the books, all of them in the system. Now every build that shows a cursor deletes the ones replaced before it, right before it registers or takes one back; what replaced them was activated in an earlier frame, so they are off screen. A build that has to ask for pixels shows nothing new and deletes nothing, so a raster returned to right after being replaced still takes its cursor back; one returned to later registers again. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: a shape that does not decode leaves no handle and no copy CursorDedupe named a handle as it hashed the shape, before the shape was checked, so a peer sending shapes that fail the checks under new handles grew the map with nothing the UI could ever select, and such a shape took over the handle of one that had decoded. The handle is now named once its shape decoded, or was shown before. The flutter build also copied a shape's compressed colors out of the message before the checks, so a message with a small size and huge colors was copied whole before being rejected. The copy is made once the shape decoded; until then the message's own bytes are held. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: remember the shape the core lacks only while it is in use Every id the core could not give was kept in a set for the session, so a peer sending cursor_id after cursor_id of shapes it never sent grew it by a string each, at a few bytes of traffic per entry. The mark exists so that painting does not ask for the shape in use on every frame, and the shape in use is one, so one mark is kept: the peer selecting another shape forgets it, and selecting a lost shape again asks once more. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: forget the shape the core lacks once the peer selects another The mark was replaced only by another shape the core lacked, so a lost shape selected again after a known one was still not asked for. Selecting any other shape now clears it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: leave the DRM cursor's own id as it was The wire id is cursor_content_id whatever the platform, set in run_cursor over the shape's pixels, so the id the DRM reader derives for itself only tells one hardware cursor from the next and keys the service's cache. Which hash it uses does not reach a controller; the change to xxh3 and the dependency it brought to scrap go. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: say the 1.5.0 gate means the release Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: say why the peer answers request_cursor_data with what it holds No controller sends it yet, and a review asked for it to go because a cache reset on the peer could leave a request unanswered. A shape the peer's cache dropped is rebuilt, and indexed again, the next time it is shown, before any connection names it by id, so the shape a controller has just been told to show is always there to give; that is the contract a future bounded controller relies on. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: drop the tests nothing can fail a_handle_is_named_once_its_shape_is_shown dates from when `name` wrote the handle map. `name` is pure now, so its last assertion cannot fail, and the others repeat two neighbours. every_handle_the_peer_named_stays_for_the_connection fails only for a bound added on purpose, which the struct's doc rules out. The Dart arrival test is covered by the first test of its file. The kept-shape test now asserts what `cursor_shape` is for, a copy rather than a view of the received buffer, in place of the unknown fields it drops. The content-id test moves out from between two `use` lines. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: let the kept-shape tests run without the flutter feature CI's cargo test builds the default features, and the two functions under test are pure, so they compile for every test build and the module loses its feature gate. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: keep native cursors for every frame of an animated cursor An animated cursor is a shape per frame, 18 for the Windows busy cursor and 23 for KDE's wait cursor. With 16 native cursors a cycle longer than that missed on every frame: fetched from the core, decoded, registered again and the replaced cursor deleted, about thirty times a second for as long as the peer was busy. 64 holds two such animations and the everyday set besides. The tests settle in 10 ms instead of 100 ms, so the ones that fill the limit stay quick. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: release only the shapes that can hold pixels Selecting a cursor swept every shape of the session to release pixels, though only two can hold any: the shape selected before, and a shape that finished decoding after the peer moved on. Release those, so a cursor_id costs the same however many shapes the peer has shown. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: show the native cursor limit holds two animations and the everyday set 64 is a working set, not the longest animation: KDE's wait and progress cursors are 23 frames each, and a session that meets both plus a dozen static shapes must keep them all, or every turn rebuilds. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: let the shape in use keep its pixels for a new raster Dropping them once the native cursor was registered meant every scale change, zooming with the cursor zoomed or crossing to a display of another scale, showed the system arrow while the core gave the shape back and it decoded again. The shape in use now keeps them and makes the new raster at once; a shape switched away from still keeps none. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: never fall back to the default cursor on a switch A switch to a shape without its image, or without a native cursor at its raster, showed the default arrow until the core gave the shape back and it decoded: the painted cursor on every switch back, the native one after an eviction or while a new shape decoded. - The shape shown before stays, image, hotspot and native cursor, until the one in use is ready. - Where the cursor is painted, on mobile or with the remote cursor shown, the images of the 64 shapes used last are kept, like the native cursors, so an animation does not decode a frame per turn. Elsewhere only the shape in use keeps one. - A shape that finishes decoding after the peer moved on is kept with them instead of dropped, so a fast animation fills them at all. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: name the dedupe's content-id set for what it holds `shown` read as the shape on screen. It is the shapes decoded and given to the UI, keyed by content id, so a shape arriving under a new handle is looked up once instead of scanning the handle map: `decoded`, `has_decoded`, and `record` for the call that fills both maps. The web mirror is renamed the same way. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: keep native cursors for the session, as before Evicting native cursors and deleting a shape's replaced raster made Windows leak more than master. The engine's deleteCustomCursor/windows frees the HCURSOR with DeleteObject, which does not take a cursor, so a delete frees nothing and each cursor made again for a raster, or for a shape shown once more, leaks another handle. Keeping every raster of every shape until the session is cleared creates each one once, as master does. Fixing the engine instead is not cheap: x64 runs our fork on Flutter 3.24, where the fix is one more patch to rebuild and carry across every upgrade; arm64 runs the stock engine of a newer Flutter with the same code, where it means porting the fork and publishing an arm64 engine too, or waiting for an upstream fix to reach stable. Content ids keep the count to the shapes the peer really shows. The painted images, the compressed shapes in the core, and a switch showing the cursor shown before are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: record the Windows measurement behind keeping native cursors A measurement on Windows confirmed what the engine source implied: of 500 cursors made by CreateIconIndirect, DeleteObject freed none and left 500 USER objects alive, while DestroyCursor and DestroyIcon freed all 500. The comment now says so, that native cursors have no LRU for that reason only, and that one can come back once both engines destroy cursors. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: look a native cursor up by the raster asked for The key ended in the raster made last. A shape switched away from keeps no pixels, so its raster stays where it was, and going back to a raster it was shown at before looked up the wrong key: A at 1.0, A at 0.5, then B, then A at 1.0 again missed the 32x32 cursor that was still there, fetched A from the core, and showed B meanwhile. With native cursors kept for every raster, the key now ends in the raster asked for; with pixels, that is the raster made, as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: let a shape keep its pixels until a native cursor holds them A shape switched away from, or decoded after the peer moved on, let its pixels go whether or not it had a native cursor, and a native cursor is made only for the shape in use. A shape whose restore kept finishing after the next switch, as an animation's frames can, was fetched and decoded again every time it came back and never got a native cursor. A shape without one now keeps its pixels until one is made, at most kRecentShapes of them, the one waiting longest let go first. Mobile only paints the cursor, so it lets them go as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * proto: keep cursor ids as strings in JS A Windows peer before 1.5.0 names a cursor by its handle, sign-extended above 2^53 when its top bit is set. The web client decodes u64 fields into JS numbers, and ts-proto throws on a value a number cannot hold, so each such cursor_data or cursor_id was dropped whole and the web cursor stayed on the shape before. [jstype = JS_STRING] makes ts-proto generate these two fields as strings; the wire format, the Rust code generated and every other client are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: wait for a native cursor at the raster asked for, not any raster A shape let its pixels go once it had a native cursor at some raster. After a zoom, or on a display of another scale, an animation's frames had native cursors at the old raster only; each was fetched again at the new one, and a restore that finished after the next switch let its pixels go at once, so the frames never got a native cursor at the new raster and the cursor stayed on the one shown before. A lookup that finds no native cursor at the raster asked for now counts the shape as waiting for one, so a late restore keeps its pixels until it has one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cursor: count a shape held again when its asked raster has a native cursor A lookup that missed took the shape out of _nativeIds, but one that hit did not put it back. A shape asked at a new raster, then at one it has a native cursor for, still counted as waiting: a restore finishing after the switch away kept its pixels in _awaitingNative instead of letting them go. The set now says whether the raster asked last has a native cursor, either way. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * Revert "cursor: count a shape held again when its asked raster has a native cursor" This reverts commit |
||
|
fufesou
|
bb924d2939 |
fix: avoid unnecessary clipboard reads and stale initial sync (#16293)
* refact: simple refactor Signed-off-by: fufesou <linlong1266@gmail.com> * refact(clipboard): don't keep the clipboard cache Signed-off-by: fufesou <linlong1266@gmail.com> * fix: prevent initial clipboard sync from overwriting newer updates Signed-off-by: fufesou <linlong1266@gmail.com> * fix: invalidate initial clipboard snapshots on remote and file updates Signed-off-by: fufesou <linlong1266@gmail.com> * fix: handle clipboard changes during initial sync Track clipboard changes even when they produce no sync message. Refresh invalidated snapshots to preserve sync after Wayland startup. Prevent repeated PeerInfo responses from restarting initial sync. Signed-off-by: fufesou <linlong1266@gmail.com> * fix: skip file clipboard reads when file sync is not required Check is_file_required() before reading clipboard file URLs to avoid unnecessary clipboard access when no session needs file synchronization. Signed-off-by: fufesou <linlong1266@gmail.com> * fix: refresh clipboard requirements before listener startup Update Flutter's text and file clipboard requirements before starting the shared clipboard loop so startup notifications use the current settings. Signed-off-by: fufesou <linlong1266@gmail.com> * fix: exclude disconnected sessions from clipboard requirements Only count connected Flutter sessions when checking clipboard requirements. Recompute them on disconnect so a remaining session with sync disabled does not keep unnecessary clipboard reads enabled. Signed-off-by: fufesou <linlong1266@gmail.com> * fix: filter disconnected sessions from clipboard requirements Exclude disconnected Flutter sessions from text and file clipboard requirement calculations, even when their tabs remain open. Signed-off-by: fufesou <linlong1266@gmail.com> * fix: block file clipboard traffic before login Signed-off-by: fufesou <linlong1266@gmail.com> * fix: skip Wayland host startup clipboard broadcasts Signed-off-by: fufesou <linlong1266@gmail.com> * fix: respect initial clipboard sync setting on Wayland Stop broadcasting startup selections through the normal clipboard sync path. Keep generation invalidation for snapshots captured before the listener becomes active. Signed-off-by: fufesou <linlong1266@gmail.com> * fix: wait for clipboard listener readiness before initial sync Wait for Linux clipboard backends to finish subscribing before the initial read. Update clipboard-master to use its readiness callback. Report completion for empty or failed reads so initial sync does not remain pending. Document snapshot invalidation across listener restarts. Signed-off-by: fufesou <linlong1266@gmail.com> * fix: wait for Linux clipboard readiness asynchronously Use watch notifications to keep the connection loop responsive during clipboard startup. Cancel readiness waits when the session channel closes. Advance generation on readiness and capture it with each initial read so listener restarts invalidate older snapshots. Signed-off-by: fufesou <linlong1266@gmail.com> * fix: preserve Wayland startup file clipboard sync Distinguish startup selections from normal clipboard changes. Process startup files through the existing client clipboard worker, while keeping text initial sync and host startup suppression unchanged. Signed-off-by: fufesou <linlong1266@gmail.com> * fix: bound clipboard readiness waits on Linux Add a five-second timeout to the initial-sync readiness wait and log failures. Update clipboard-master to support timeout and cancellation while waiting for the initial Wayland selection. Signed-off-by: fufesou <linlong1266@gmail.com> * refact(clipboard): update clipboard-master Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: fufesou <linlong1266@gmail.com> |
||
|
RustDeskandClaude Opus 5.5
|
f299fb9906 |
fix(clipboard): unix, check file transfer permission on incoming file… (#16333)
* fix(clipboard): unix, check file transfer permission on incoming file clipboard The Cliprdr arm served incoming file clipboard messages on Linux/macOS without checking the file transfer permission, which the controlled side can turn off mid-session. can_sub_file_clipboard_service() only gates the outgoing service, so a peer could keep pushing files in and keep requesting the host's copied file list and contents. Check file_transfer_enabled() on every message. It is the same permission the client and the Windows cm use for file copy-paste. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(clipboard): honor one-way file transfer on incoming file requests One-way file transfer was only enforced on the outgoing side: the host never announces its clipboard files. A controller could still send FormatDataRequest / FileContentsRequest directly, and the host answered them, from the live clipboard on Windows and from serv_files on Linux/macOS. Drop those two requests when one-way file transfer is on, before any platform handling. The messages that carry the peer's own files to this side are untouched. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * style: drop redundant doc comment Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
Mariano Abad
|
7c21b4569c |
test(drm): bound the excused shapes at their worst angle, not only on average (#16320)
Both of the review follow-ups on rustdesk#16242. One comment still said alias was 0.11 px worse than master. That was the number before the directional rule; it is 0.51. And the exemption for help and alias was bounded only on the average over the angles master handles. The worst single angle is the larger number and the one that would be felt - help is 8.00 px under master at 270 and 21.54 here - so leaving it unbounded let the exemption widen quietly. Both directions are bounded now, at the measured values: alias 0.51 mean and 8.94 at 90, help 4.73 mean and 13.54 at 270. Tests only. |
||
|
fufesouandMariano Abad
|
12f61b1fda |
Fix/drm rotated cursor (#16242)
* fix(drm): turn the cursor by the output's real angle, and guess its hotspot upright Two things were wrong with a rotated output's cursor, and the maintainer's physical test found both. The bare-metal hotspot is a guess - the top-left of the sprite's opaque box, since HOTSPOT_X/Y only exist on para-virtualised drivers - and it was guessed on the sprite as scanned out, then mapped as if it were a point on it. A turned arrow's tip is never in that corner: at 90 the guess is off by the arrow's width along x, small enough to pass as fine, and at 270 by its height along y, which is what was noticed. Measured on an i915 box with a 64x64 Adwaita arrow, hotspot against tip: +11,0 at 90 and 0,+18 at 270 before, 0,0 at every angle after. A guessed hotspot is now guessed on the upright sprite, in the consumer, and the wire says whether the driver measured it so a real one still maps as a point. And 180 was clamped to 0 for the whole session because a hardware-rotated primary plane scans out upright. That holds for the frame and not for the cursor: the compositor pre-rotates the sprite in software either way, so it arrived upside down. The frame keeps the clamp; the cursor gets the real angle. (cherry picked from commit 6a73100b4783fbf9c8f43e0dc7651b7568db9ea9) * test(drm): drive the cursor path, and drop the field nothing reads The two tests called the helpers, so nothing pinned the production decision: restore master's `t == 90 || t == 270` in deliver_drm_cursor and both still pass while the 180 sprite goes back to upside down. The new test drives deliver_drm_cursor and reads back what it published, and it fails under exactly that mutation. The other way to reintroduce the bug was to point the receive thread at `Shared::transform` again. That field had no readers left once both gates moved to `cursor_transform` - it was stored and never loaded - so it is gone, and the doc above TRANSFORM_PENDING now names the field that actually holds a racing cursor back. Also four comments that said more than the code does: the sprite is treated as pre-rotated at every angle because wl_output cannot say otherwise, not because the compositor provably always does it; the old flow was off at every angle, not just at one of 90/270; the 180 symptom had its own cause, the clamp, rather than all of it coming out of the hotspot guess; and the test arrow's opaque box is its left three columns, not the whole bitmap. * docs(drm): say what the 180 measurement actually showed The loop asserts the old mapping was wrong at 180 too, and that is true of the mapping, but master never ran it there: the clamp sent 180 down the untouched branch, so guess and sprite turned together and the hotspot landed on the tip. The bench measured exactly that - (0,0) at 180, with only the sprite upside down. The comment said the old flow was wrong at every angle without that distinction, which is the kind of gap between a claim and a measurement worth closing before someone else finds it. * fix(drm): centre the guessed hotspot of an I-beam lying either way The bounding-box guess only centred TALL shapes, so a HORIZONTAL I-beam was handed the top-left corner of its box. Adwaita's `vertical-text` is exactly that shape: at 24 px its opaque box is 20x9 and the theme's own hotspot is (12, 11), its centre. The corner guess lands 11.2 px away; the centre lands 1.4 px away. It matters more since this branch turns the sprite upright before guessing. Such a cursor used to reach a quarter-turned output as a TALL bitmap, where the tall-only rule centred it by accident; guessing on the upright bitmap - correct in itself, and what fixes arrows at every angle - is what exposed the asymmetry. Found by fufesou at pixel level on rustdesk#16242, and reproduced here against the installed theme before changing anything: same declared hotspot, same bounding box, same two errors. Then checked across ALL 35 shapes of that theme at 24 px: making the aspect test symmetric moves exactly one of them, `vertical-text`, from 11.2 px to 1.4 px, and leaves the other 34 byte-identical. The old flow is not the fix. It was right for this one shape and wrong for arrows at every angle, which is what `a_guessed_hotspot_is_guessed_on_the_upright_sprite` pins; the fix belongs in the guess, not in the order of operations. The regression test that missed this used only `arrow()`, as fufesou pointed out. Three things the first version of the replacement got wrong, all of them in what it CLAIMED rather than in the fix: - Its expected point was the centre of the BITMAP, which equals the centre of the opaque box only because the fixtures filled their bitmaps symmetrically. Both I-beam fixtures are now off-centre in their buffers, the way a sprite sits in a 64x64 hardware cursor, and the test asserts up front that the two centres differ so the fixture cannot quietly stop discriminating. - It called the arrow's box "elongated by less than the factor of two", when 3x6 IS the factor of two and the arrow keeps its tip only because the comparison is strict. That makes the arrow the control for one side of the threshold, and it is now described as such. - It said the case was driven "through the whole delivery path" while chaining the helpers itself. It now calls `deliver_drm_cursor` and reads the published hotspot back out of DRM_CURSOR, at 0, 90, 180 and 270, feeding it what the producer really sends for a guessed hotspot: the producer's own guess, made on the sprite as scanned out. And the threshold was pinned from one side only. A third fixture carries the real 2.22:1 aspect of the shape that was wrong, so a stricter rule cannot pass on 6:1 bars while silently un-centring the actual cursor. Mutations, each restored byte-for-byte afterwards: back to tall-only, the bitmap centre instead of the box centre, the threshold loosened to one and tightened to three. All four fail the test. * build(drm): point the pin at the synced mirror and drop the helper fallback The mirror is synced, so the pin moves from 5da68a3a (libdrmtap 0.5.4) to 49b204f (0.5.6), which is what rustdesk-org/libdrmtap now carries. -Dhelper=disabled, as the maintainer asked on #16242. rustdesk never uses the privileged helper: every drmtap_open lives in src/ipc/drm.rs, i.e. the root service, which already holds CAP_SYS_ADMIN, and the unprivileged side opens a render node instead. What the library carries without the option is a fallback that walks six hardcoded paths, two of them under /usr/local, and execs the first one that passes access(X_OK) -- no check of its owner, no check of its mode -- from inside the ROOT process. The option compiles that path out. Asserted on the artifact as well as passed as a flag, for the same reason the EGL check is: a flag cannot notice a stale build-pkg or an object substituted by hand, and meson accepts an unknown -D silently on versions predating the option. Measured on the produced .so: socketpair 4 -> 0, the helper search paths 3 -> 0, and nm -D shows no fork, execl or socketpair import. The check fails as it should when pointed at a .so built with the helper. * fix(drm): use the library's hotspot provenance, and keep legacy IPC meaning Answers the two blockers in the maintainer's review of |
||
|
RustDeskandClaude Fable 5.1
|
dd9b21cf86 |
server: hold an unauthenticated connection to a small message (#16254)
* server: hold an unauthenticated connection to a small message Until a peer authorizes it sends only a public key, a login request, a test delay and a close reason, none of them large. Nothing said so: a frame header could declare up to whatever the transport allowed, 1 GiB on TCP and WebRTC, and a connection holds its place for up to LOGIN_GRACE before it has to authorize. With MAX_UNAUTHORIZED_CONNS places to fill, that is 64 GiB of header-declared payload one peer could make us hold - or, on WebSocket, 1 GiB bought outright with a few hundred bytes of frame headers, because tungstenite reserves a frame's declared payload as soon as it passes max_frame_size. The cap goes on in create_tcp_connection, before the identity handshake, so that read is bounded too, and comes off once the login is settled. It comes off before connect_port_forward_if_needed rather than beside the rest of authorization: a multiplexed tunnel narrows the same knob again for its own framing and has to have the last word. 128 KiB is several times the largest login request anyone sends - a long hostname, an os_login, an avatar URL, a file-transfer path - and is also the read buffer tungstenite allocates per WebSocket connection whatever we do, so on that transport the bound costs nothing beyond a floor already paid. A server hands that avatar out as a URL; only a custom client that inlines an image into the avatar option instead can reach the bound at all. Together with MAX_UNAUTHORIZED_CONNS it holds every unauthorized connection to 8 MiB. Redis answered this same shape in CVE-2021-32675 with 16 KiB, tighter because a per-message bound is the only one it has; here the connection count is the other. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * server: test that the unauthenticated cap is on before the handshake reads hbb_common covers each transport's cap; nothing covered where the connection layer puts it. A header one byte over MAX_UNAUTHORIZED_MESSAGE, written to a connection stalled in the identity handshake, has to end the handshake on the header alone and release the connection's place: the test fails with the cap moved past the handshake or dropped. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * client: hold the clipboard until this round's login is accepted The clipboard listener is one per process, started by the first session to log in, and its broadcast went to every session - one whose login was still waiting on a password, 2FA or the peer's consent included. What the user copied meanwhile went to a machine that had not admitted them; the peer drops it unread before authorization, but it is in that peer's hands. The check goes on the round, not the session: a session-level one reads a state and later a sender that a reconnect can have swapped in between, so a broadcast that passed for the round before could still queue on the next. Remote is the round - its queue, and is_connected set once its own PeerInfo is in - so a Clipboard or MultiClipboards that reaches handle_msg_from_ui before then is dropped there, on the line before it would go out. What the login itself sends through the same queue, Auth2FA among it, goes as before. The unauthenticated cap on the other side is how this came up: a clipboard over 128 KiB ended such a login with "Reset by the peer". The small case had always gone through quietly. A test drives a round's Remote over a loopback pair before any login: a clipboard does not reach the far end, a 2FA code does, and once the round is connected the clipboard does too. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
RustDeskandClaude Fable 5.1
|
d4ac2c07b7 |
temporary password: rotate when a peer is let in, not when it leaves (#16080)
The one-time password was regenerated after the connection loop exited, so a remote desktop session kept it valid for hours and a port-forward tunnel for as long as its mapping lived. It now rotates the moment a connection becomes authorized. Reconnects and windows opened from a live session are unaffected: they log in on the password the session remembers, for 30 seconds past its last activity. Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> |
||
|
RustDeskandClaude Fable 5.1
|
092a961b62 |
server: bound unauthenticated connections in number and in time (#16237)
A connection that never logs in costs whatever its transport costs, for as long as it keeps itself alive: the only limit was the 30s idle timeout, which any message resets. Nothing bounded how many such connections one machine holds, on any transport. The shape sshd_config answers with LoginGraceTime and MaxStartups. Every connection is admitted among the unauthorized ones before its identity handshake, in create_tcp_connection, and holds that place until it authorizes or ends: the count of live places is the bound, not a ledger beside the connections: the resource bound. One address may hold sixteen, a quarter of the room; a further connection from it is refused before the handshake. That share is a fairness cap against the cheapest flood, one host with one address, not a security boundary: any pool of addresses passes it, and the global limit is what holds. With 64 held in all, a further arrival is refused too, and the oldest connection is told to go, unless one is on its way out already: the handshake is raced against that eviction and ends at once, and the session loop has it as a branch of its select, so the place opens as soon as the connection has actually gone and not on a timer tick. The newcomer is not let in on a place still occupied; the controller retries on its own with backoff, and by then the place is free. At most one connection is ever on its way out, so a burst of refused arrivals clears no more room than a single one, and the retry that takes the freed place counts against its address's share: one address turns out at most as many connections as it may hold. One deadline, from the moment the connection starts, a branch of the session loop's select rather than a check on the TestDelay tick: a connection not authorized after 180s is closed, however alive it keeps itself, a wrong password, a pending 2FA, an accept prompt or an admin-terminal credential prompt left unanswered. The controller reconnects on its own and the prompt comes back. It closes with the Timeout reason the idle path uses, and that path still ends a connection that says nothing for 30s. There is no shorter deadline for the first login request: an admin-terminal controller shows its credential prompt before sending one, and a peer that wanted to dodge such a deadline would only have to send a login request, so it would bound nothing. The peer address is normalized with try_into_v4 before admission, the same form Connection::start keys the whitelist on, so an IPv4 peer and its IPv4-mapped IPv6 form are one address and not two shares. The WebRTC answerer's slot keeps bounding peer connection setup up to the open data channel; from there this covers it like every other transport. Tests cover the registry and the live bound: an address over its share is refused while others are admitted; at the limit the newcomer is refused, the oldest is told to go, nobody else is while it is on its way out, and its place frees only when it has; an address at the limit turns out no more connections than its share and is then refused without evicting anyone; and with the limit held by 64 connections stalled in the handshake, one more arrival is refused while the oldest handshake ends at once and only then is there a place again. Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> |
||
|
Joss Gray
|
f9c2f16857 |
fix: recover DXGI capture after access loss (#16024)
* fix: recover DXGI capture after access loss * fix: track DXGI frame ownership * fix: only recover DXGI access loss * fix: stabilize DXGI recovery after mode switches * fix: preserve DXGI recovery budget * refactor: model DXGI frame lifecycle as enum * docs: clarify DXGI frame cleanup order * fix: scope DXGI frame grace to access loss recovery * fix: preserve DXGI recovery across display changes * chore: log DXGI recovery attempts at debug level |
||
|
fufesou
|
28269af9c7 |
fix(audio): preserve compatible playback and recover failed Windows outputs (#16150)
* fix(audio): preserve compatible playback on replacement failure * fix(audio): use Windows events for capture worker wakeups * fix(audio): recover Windows playback after output device failure * reduce diffs Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): reset decoder when retaining compatible playback * fix(audio): integrate playback retention and Windows capture wakeups * revert(audio): remove Windows capture-event notification changes * docs(audio): explain Windows 7 capture limitations * docs(audio): clarify capture changes introduced by #16095 * fix(audio): preserve playback through asynchronous Windows startup Keep a compatible active output until the replacement callback confirms startup, preserving decoder progress on promotion or rollback. Handle superseding formats and simultaneous output failures without losing recovery state. Pin the scoped CPAL WASAPI event-ownership fix and add deterministic and native regressions. * fix(audio): retain ready output across superseding formats * fix(audio): update CPAL teardown recovery Pin the upstream-aligned WASAPI cleanup with shared event lifetime, self-join prevention and fallible destructor diagnostics. Preserve the existing dependency graph and audio implementation. * Use upstream-style CPAL stream teardown * Refact: remove low value test Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): retry playback when startup confirmation times out Signed-off-by: fufesou <linlong1266@gmail.com> * update cpal Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: fufesou <linlong1266@gmail.com> |
||
|
RustDeskandClaude Opus 5
|
851d2df88c |
fix(audio): three 100% CPU busy loops on the _pa path (#16229)
The Linux audio service in `--server` ignored the `Err` from `next_raw()`, so once the cm-side `_pa` peer closed, every iteration re-polled a dead socket: tokio-util's paused `Framed` issues one 0-byte read per poll and returns ready at once, never `Pending`. The thread never parked and burned a full core for the life of the process. Propagate instead, so `ServiceTmpl::run`'s existing backoff ends the inner loop and reconnects. Two sibling loops on the same audio path have the same shape: - `ipc::start_pa` (runs in `--cm`) ignored the `Err` from `psimple::Simple::read`, so a dead pulse handle spins there instead. - `start_voice_call`'s forwarding thread polls two channels with `try_recv` and has no blocking primitive at all: measured 99.8% of a core for the whole call, against 1.0% with a 1 ms pause (audio packets arrive every 10 ms). fix https://github.com/rustdesk/rustdesk/issues/16226 Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
21pages
|
39d4f1854b | chore(qos): remove verbose diagnostics while retaining trace logs (#16214) | ||
|
fufesou
|
9b5f342839 |
fix(audio): throttled debug logs (#16172)
* fix(audio): throttled debug logs Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): preserve contention counts across throttled reports Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: fufesou <linlong1266@gmail.com> |
||
|
21pages
|
e82dd12350 | Lower QoS sample logging to trace (#16161) | ||
|
fufesou
|
c4221469d8 |
Fix/audio stream continuity (#16095)
* fix(audio): add streaming resampler * fix(audio): preserve stream resampling state * fix(audio): keep playback callback nonblocking * fix(audio): decouple capture conversion from dasp * fix(audio): support stateful samplerate backend * refactor(audio): isolate stream callback state * refactor(audio): group capture output options * fix(audio): clear stale playback state after startup failure Reset non-Linux playback state when stream startup fails to prevent new-format audio from using the previous stream or resampler. Add regression tests for failed format changes and successful playback. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): honor capture resampler selection and reuse buffers Use the selected resampling backend for fixed-frame capture. Convert samples directly into the input queue and reuse the PCM frame buffer. Add tests for anti-aliasing, thread transfer, and partial-frame draining. Signed-off-by: fufesou <linlong1266@gmail.com> * refact: reduce diffs Signed-off-by: fufesou <linlong1266@gmail.com> * test(audio): check resampler output count and passband energy Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): reset incompatible Linux playback state on startup failure Preserve compatible output streams when replacement startup fails. Clear state when no compatible stream exists and cover both paths in tests. Signed-off-by: fufesou <linlong1266@gmail.com> * perf(audio): reuse PCM buffers in the capture pipeline - Reuse capture framing, resampling, and channel conversion buffers - Deliver borrowed packets and write Sinc output into reusable storage - Add allocation and output-equivalence regression tests Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): smooth buffer discard discontinuities Signal receiver PCM discards and fade from the current playback output when the callback reaches the new timeline. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): add missing Cargo.toml Signed-off-by: fufesou <linlong1266@gmail.com> * perf(audio): move capture encoding off the CPAL callback Move Opus encoding and service delivery to a dedicated worker. Use a preallocated bounded PCM queue with explicit loss reporting. Add tests for callback allocations and queue saturation. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): smooth capture gaps and report losses during backlog Signed-off-by: fufesou <linlong1266@gmail.com> * feat(audio): report capture queue high-water mark Track peak queued PCM packets and log the approximate queued audio duration alongside capture loss statistics. Signed-off-by: fufesou <linlong1266@gmail.com> * refact(audio): reduce diffs Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): avoid blocking capture on encoder queue contention Use preallocated queues with try_lock in the capture callback. Count and drop the current packet on contention, preserving drop-oldest behavior on overflow. Add regressions for paused workers, buffer reuse, and sequence wrap. Signed-off-by: fufesou <linlong1266@gmail.com> * fix: add the missing files Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): isolate zero-gate state per encoder Signed-off-by: fufesou <linlong1266@gmail.com> * refact: reduce diffs Signed-off-by: fufesou <linlong1266@gmail.com> * refact(audio): simple refactor Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): avoid waiting on playback callback locks Use one PCM try_lock attempt and preserve queued samples during contention. Replace readiness locking with per-stream atomic status and report callback errors from the receiving thread. Cover callback progress, retained audio, recovery, and poisoned-buffer handling. * fix(audio): restart capture after processing errors Stop further processing until the service recreates the stream. Document the guard as defensive recovery for an unconfirmed failure. Group capture and resampler submodules under their parent directories. Signed-off-by: fufesou <linlong1266@gmail.com> * audio: report capture queue contention drops separately - Add contention_dropped to loss reports while preserving total drop counts - Document packet rejection on contention even when buffers are available - Extend existing contention and saturation test assertions Signed-off-by: fufesou <linlong1266@gmail.com> * refact unit tests Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: fufesou <linlong1266@gmail.com> |
||
|
fufesou
|
978e2e28b9 |
fix(audio): restart capture when the device is unavailable (#16142)
* fix(audio): restart capture when the device is unavailable * refact: remove low-value test Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: fufesou <linlong1266@gmail.com> |
||
|
fufesou
|
65edf214b9 |
fix(macos): recover system-stopped audio capture streams (#16123)
* fix(macos): recreate system-stopped audio capture streams Pin CPAL's ScreenCaptureKit stop notifications and retain interruption state with each capture stream. Recreate an interrupted stream through the existing service restart path, outside the backend error callback, and resend its audio format. Late callbacks cannot restart a replacement. A natural -3821 stop was observed with the remote connection still open. Its OS trigger remains unknown and it has no deterministic natural reproducer. Controlled verification stops the real SCStream and delivers an explicitly marked -3821 notification; this is not a natural failure. Dependency: https://github.com/rustdesk-org/cpal/pull/5 Validation: requested macOS Rust and Flutter debug builds; three full-crate regression tests; build check without ScreenCaptureKit; two controlled recreations on one connection with independently recorded receiver audio. * chore(macos): log audio capture startup and resumed samples * Update deps, cpal Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: fufesou <linlong1266@gmail.com> |
||
|
RustDeskandClaude Opus 5
|
bac8323e5d |
Wayland portal staged errors (#16118)
* wayland: say which step of the portal handshake failed
The XDG portal handshake is four sequential requests, and every way it can end
badly -- the user declining, the request being dismissed, a timeout, the portal
being absent or dying mid-handshake, the stream list coming back empty -- left
`request_remote_desktop` through one `bail!` carrying one string.
`map_err_scrap` then guessed a cause by looking for "dbus" or "pipewire" in
that string. Since that string always mentions "PipeWire library", a decline
and a three-minute timeout both came out as "Wayland requires higher version of
linux distro. Please try X11 desktop or change your OS." On Ubuntu 21+, where
the mapping passes the text through untouched, they came out as raw English
pointing at an unrelated GitHub issue.
The response code and the D-Bus error were in hand at the moment of failure and
were being dropped: `handle_response` collapsed all of it into one
`AtomicBool`. Record it instead, tagged with the stage that produced it, and
let the app side look the tag up. `map_err_scrap` gains one leading branch;
anything untagged -- which is everything the capture loop reports -- takes the
existing path unchanged.
What the peer is told is chosen from the tag, and only from facts the tag
actually carries:
- A decline and an interaction that ended some other way are separate outcomes
and say so. The Request spec defines response 1 as the user cancelling, and
guarantees nothing more about 2 than that it ended -- libportal treats 2 as a
plain failure -- so 2 says the request ended without completing and does not
guess who ended it or why.
- A timeout says it timed out. It does not say nobody answered: RustDesk passes
a saved `restore_token` with `persist_mode` 2, and a restored session is
exactly the case where the portal shows no picker at all, so there may have
been no dialog for anyone to answer.
- Not reaching the session bus, a portal that answers but does not implement
what was called, and a grant that fails only when the PipeWire connection is
handed over, each get their own message. None of the three is fixed by
restarting the portal, so none of them is told to. Each says only what its
evidence supports: failing to open the session bus does not prove nobody is
logged in, and `UnknownMethod` on RemoteDesktop does not prove the portal
cannot capture a screen. Which interface was called is in the D-Bus message
that goes to the log; the message to the peer does not claim one.
- What is left -- the portal absent, silent, or failing mid-handshake -- keeps
the existing `xdp-portal-unavailable`, which is already translated everywhere
and carries the one remedy that fits: `systemctl --user restart
xdg-desktop-portal`.
- The Ubuntu-before-21 branch keeps every outcome that says something about the
machine and yields the three that say what happened to the request.
Two more say less than they could, for the same reason. `streams_from_response`
comes back empty when the response cannot be parsed as well as when there is
nothing in it, so the message says RustDesk did not obtain a usable screen
rather than that the portal offered none. `ElementFactory::make` fails the same
way for a plugin that is absent as for one that will not load, so the message
says the component could not be loaded rather than that it is missing.
The D-Bus error name and message, the portal response code and the GStreamer
factory's own error go to the log. Only the element name also reaches the peer,
because it is the one detail that says which package to look at.
`fill_displays` needs the tag resolved at its own call site: it opens a second
portal session for cursor-based display disambiguation, and its error returns
straight up `check_init` without passing through `map_err_scrap`, so a tag
would otherwise reach the peer verbatim.
Two existing paths change, both necessarily:
- `check_init` no longer wraps `Capturer::new` in `with_context`. The peer is
shown `format!("{}", err)` (connection.rs), which renders only the outermost
layer, so that context was replacing the mapped code with "Failed to create
capturer for display 0".
- The `std::process::exit(-1)` on libdbus' no-reply text is now reached only by
the capture loop, which is what that self-heal was written for. Every D-Bus
call in the handshake -- opening the session bus, `get_request_path`, the
`add_match` inside `handle_response`, `create_session`, and `conn.process` in
the wait loop -- carries a tag, so a no-reply there is reported rather than
fatal. It is worth saying plainly what that branch did before: the portal
proxy has a one-second timeout, so a portal slow to activate could take the
whole service down.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab
* wayland: lang keys for the staged portal failures
Eight keys, appended to `template.rs` and to every `src/lang/*.rs`. `it.rs`
gets empty values, as AGENTS.md requires -- it is maintained by hand by its
translator. No `en.rs` entries: each key is already its own English display
text, which is also what an older peer falls back to.
One carries a `{}`, the name of the GStreamer element that could not be created
-- the one detail that tells a user which package to look at. `lang.rs`'s
`extract_placeholder` resolves a key by replacing the first `{...}` with `{}`,
which is why the server sends the value still inside the braces and why the
scrap side strips braces out of any detail before it gets there. Everything
else technical stays in the log: a D-Bus error name or a portal response code
in a dialog is noise to the person reading it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
||
|
|
080211ff36 |
improve qos (#16082)
* first improve Signed-off-by: 21pages <sunboeasy@gmail.com> * fix(qos): avoid reducing FPS for transient network jitter Require consecutive bad samples to confirm congestion before normal FPS reductions. Prefer bitrate reduction when ABR is available and allow an outstanding probe to complete before evaluating its effect. Recover FPS faster on fresh good samples while preserving severe-delay and timeout protection. Add regression coverage for jitter, bandwidth changes, and multiple viewers. Signed-off-by: 21pages <sunboeasy@gmail.com> * test(qos): virtual clock and a closed-loop link simulation Tests drove time by moving `Instant`s into the past, which panics on a host that booted less than two minutes ago, and the ABR smoke had to detect ratio changes to keep its fake clock consistent. `VideoQoS` now reads the clock through `now()`; tests set a virtual instant and advance it. `tests/sim.rs` drives the controller the way `Connection` does, over a link with variable frame sizes, wobbling capacity, heavy-tailed jitter, retransmission stalls and link stalls, with both a bitrate-targeted (VP8/VP9/AV1) and a fixed-rate (hardware) encoder model. It prints one table row per scenario; the assertions arrive with the controller changes. The short-stall smoke sweeps the stall phase instead of three fixed values. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): keep jittery but healthy links fast, drain congestion with bitrate A weak home Wi-Fi with plenty of capacity but frequent jitter and the odd stall ended up at about 10 fps: single bad replies, the two second probe timeout and a slow climb back each took their share. The controller now treats a transient stall and a saturated link differently. - The probe timeout no longer slams the frame rate to 2. Every second the probe stays out beyond the first halves it instead, and the late reply that finally closes the probe does not reduce again. - After a reduction, good replies return halfway, then fully, to the level held before it. A restored level that congests within five replies becomes a lower ceiling, so a real capacity drop converges instead of oscillating. - VP8, VP9 and AV1 run CBR against timestamps: fewer frames only means bigger frames. While the bitrate can still be reduced the frame rate keeps its floor, and three bad replies in a row confirm congestion and halve the bitrate instead of stepping it down by a fifth every three seconds. - `bitrate_first` now means the bitrate can actually still drop; at the floor, congestion during the adjustment cooldown reduces the frame rate (Greptile). - `avg_delay()` subtracts the baseline with `saturating_sub`; at exactly the baseline it returned the whole delay, which kept the bitrate of a stable high-RTT link from ever recovering. - `HISTORY_DELAY_LEN` kept three samples, not two. - Every ratio adjustment resets the dynamic screen counters, so a long congestion episode cannot make a static screen look dynamic (CodeRabbit). - One `qos_trace` debug line per probe reply and per timeout, for replay through `tests/sim.rs`. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): adapt each viewer from its own target, not the shared minimum `user_network_delay` started every viewer's adaptation from `self.fps`, the minimum over all viewers. One congested viewer therefore pulled the others' targets down with it, and when it recovered the stream stayed low until the others had climbed back on their own. The per-viewer memory added for restores made the coupling worse: a viewer recorded another viewer's low rate as its own pre-congestion level (Greptile). Each viewer now adapts from its own `delay.fps`, falling back to the shared value only for its first reply; `adjust_fps` keeps aggregating the minimum. The replay test now fails on a malformed trace value instead of dropping it (CodeRabbit). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * test(qos): paired network trace, bitrate-conserving encoder, twenty seeds The simulator drew every random quantity from one stream, so two controllers with the same seed saw different links as soon as they produced a different number of frames; the A/B was not paired. The link trace (capacity wobble, stalls, loss events) is now generated before the run from a network stream of its own, and encoder noise and probe jitter have separate streams. The CBR model let a scene change add three frames' worth of data every five seconds without clawing it back, which raised the offered load of any controller that lowered the frame rate (up to +27% at 2 fps). The encoder now repays the surplus over the following frames and the size spread has mean one, so the long-term load no longer depends on the frame rate. Every scenario runs over twenty seeds and the assertions bound the distribution: median of the mean target, worst p10, p90 of the time below half the limit and of the queue p95. The bounds state what the product needs, not what one seed produced. New columns: produced and delivered frames per second, delivered frame age, sustained recovery (target at the limit and queue under 200 ms held for five seconds), cold-start minimum and time to 90% of the limit. The replay advances by recorded `t=` deltas when present and is labelled as the open-loop, FPS-only diagnostic it is. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): baseline from the first reply, bitrate cuts on confirmation only Two findings from the design re-check. The baseline needed ten replies before it was used, so a stable 180 or 300 ms link spent its first ten seconds read as congested: the frame rate fell to 5 and the bitrate was cut before either recovered. The running minimum is the baseline from the first reply on; the smoothed estimate takes over once the window is full. A single reply a second above the baseline, or a single timer tick with the probe out for two seconds, cut the bitrate by a fifth. A static screen never earns an increase back, so repeated stalls ratcheted its ratio down and the next dynamic episode started from there. Bitrate cuts now need two bad replies in a row, or a probe still outstanding at the second tick past two seconds; the frame rate brake and the severe-reply rule are unchanged. An elevated but unconfirmed delay no longer restarts the ratio cooldown, so a confirmation on the next reply is acted on at once. `qos_trace` lines carry a millisecond timestamp for the replay test. The simulator asserts the intercontinental cold start: minimum target at INIT_FPS and 90% of the limit within ten seconds. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * test(qos): held-out seeds and parameter sensitivity as guards against tuning The scenario bounds now live in one function shared by the CI run over seeds 1 to 20 and by `robustness.rs`, whose two ignored tests apply the same bounds to seeds 21 to 120 in blocks of twenty and halve or double each scenario parameter in turn. Anyone changing a controller constant or a bound runs them; a bound that fails on unseen seeds was fitted to the CI seeds. At this head every held-out block passes, with medians within a few percent of the CI seeds, while master fails five of five blocks in every home Wi-Fi row. The sweep keeps the lead over master in all fourteen variants for the frame-rate metrics and shows two limits worth knowing: at 6 Mbps of capacity both controllers hold about 2.4 s of queue p95, and at a drop to 1.5 Mbps both are poor because the 1 Mbps bitrate floor leaves little to drain with. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * test(qos): frame age bounds, wall-clock scene changes, time-indexed probe jitter The queue metric divides the queued bytes by the nominal capacity, so during a link stall it reports how long the backlog takes to drain afterwards, not how long the frame at the head has already waited. Frame age, the time a delivered frame spent in the shared path, was computed but not bounded. It is now bounded per scenario, as a regression bound set from the scenario rather than from a run: 1.5 s on the home Wi-Fi rows (isolated stalls of up to 2.5 s are tolerated, a sustained multi-second backlog is not), 100 ms on a clean link, 150 ms on a stable high-RTT link (frame age excludes the round trip, so RTT earns no allowance), and the same bound as the queue on the bandwidth-drop and mobile rows. Two residual couplings between controller decisions and the exogenous inputs are removed: scene changes follow the wall clock instead of the frame count, and probe jitter is a per-second table drawn before the run, so two controllers with the same seed meet the same content timeline and the same jitter. The moderate-congestion smoke profile now asserts that the frame rate actually drops, and the held-out test builds its combined summary from the block reports instead of simulating every seed twice. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * test(qos): remove the placeholder viewer from trace replay Clear the synthetic viewer created by smoke::session so it cannot cap replayed FPS at 15 when the recorded connection ID differs from 1. Add a regression test verifying identical FPS sequences for connection IDs 1 and 1652, both recovering to 30 FPS. Signed-off-by: 21pages <sunboeasy@gmail.com> * fix(qos): cap each viewer by its own limit, judge bitrate steps per viewer Two places still let one viewer's state leak into another's. The per-viewer target was clamped by `highest_fps()`, the minimum of every viewer's limit, before being stored, and a new viewer started from the shared stream rate. A viewer that lowered its limit dragged the others' targets down with it, and when it left the stream stayed there until the others had climbed back; a viewer joining a congested session started at the congested rate. Each viewer now starts at INIT_FPS, is capped by its own limit only, and `adjust_fps` keeps applying the shared limit to the aggregate. `adjust_ratio` paired the maximum delay over viewers with any viewer's confirmation, so one viewer's unconfirmed 1200 ms spike and another viewer's two 200 ms replies produced a 20% cut, and a third mild reply a halving, when each viewer on its own called for five percent. Each viewer's own delay and confirmation now decide the step it calls for, and the stream takes the most conservative one; increases still need every viewer below the threshold. Single-viewer behaviour is unchanged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * test(qos): replay advances by the wall clock across connections The replay kept a last timestamp per connection id, so a log with several viewers each writing once a second advanced the virtual clock once per line and replayed several times slower than it was recorded. It now advances by the delta between consecutive lines whatever their connection. The replay is a plain function over the log text, with the environment-driven test as its entry point, so the time axis can be tested directly. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): first reply keeps the ratio cooldown, closing a viewer re-aggregates A viewer's first TestDelay reply called `adjust_ratio` with no cooldown check. With the per-viewer steps, that scan finds the other viewers' still confirmed evidence, so a viewer joining right after a cut halved the bitrate a second time inside the three seconds the cut is meant to be observed for. The first reply is now one more trigger of the periodic adjustment and keeps its cooldown; a fresh session still adjusts on its first reply, since its controller was created long before. Linux was never on this path. `on_connection_close` removed the viewer without re-aggregating, so the stream stayed at the departed viewer's rate until the next tick; the remaining viewers are aggregated at once. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): the newcomer guard belongs to the viewer that joined Re-aggregating on close applied the one-second INIT_FPS guard that the departing viewer had set when it joined, so a viewer that connected and dropped within a second throttled the others to 15 fps for the rest of that second. The guard now records which viewer set it and is cleared when that viewer leaves; a genuinely new viewer is still capped for its first second. The first-reply ratio adjustment's platform switch is a field instead of a `cfg!` inside the condition, so the cooldown regression test exercises the path on Linux CI as well. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): every newcomer carries its own start-up guard The start-up guard had one slot, so a second viewer joining within a second overwrote the first one's join time, and when the second viewer left the first one's window was released early. The join time now lives in the viewer's own entry, `adjust_fps` caps the stream while any viewer is inside its first second, and a departed viewer takes its guard with its entry; no clearing logic is needed (Greptile). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): adapt delay baselines and speed up FPS recovery - Relearn stable baseline increases from recent fresh replies. - Require fresh congestion confirmation between ordinary FPS reductions. - Keep automatic FPS reductions above a 5 FPS floor, respecting lower caps. - Restore FPS after two good replies, with rollback on renewed congestion. - Add regression tests for baseline changes, jitter, and FPS recovery. Signed-off-by: 21pages <sunboeasy@gmail.com> * test(qos): align FPS floor tests with the 5 FPS minimum - Remove the unregistered sustained tests with outdated expectations. - Test severe delays and timeouts independently, including lower user caps and recovery. - Move the 700 kbps scenario into active adaptation tests, checking the FPS floor and recovery after bandwidth returns. Signed-off-by: 21pages <sunboeasy@gmail.com> * fix(qos): a timeout never lifts a target, and the invariants as property tests The timeout brake floored its output at MIN_FPS + 1, so a viewer whose target had already reached 1 fps was lifted to 2 by the next tick past two seconds: bad evidence raising the frame rate. Inherited from master, where the timeout set the whole stream to MIN_FPS + 1 outright. The brake now never exceeds the target it found, whatever the elapsed time it is told. The controller's six invariants become property tests over random sessions (150 seeds, 300 steps, one to three viewers, ABR on and off): a viewer's target is independent of other viewers; bad evidence never raises a target or the ratio; joins and leaves only change the aggregation; a bitrate cut is owned by a viewer's own evidence and not spent again by a newcomer; targets stay within their caps and the stream is their aggregation; a braked probe's late reply does not brake again. The timeout case is also pinned exhaustively over every target and a range of elapsed times. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * feat(qos): log the encode and send pipeline behind RUSTDESK_QOS_VERBOSE The controller's target frame rate is neither the rate the encoder produced nor the rate the send path accepted, and two facts kept that gap invisible. libvpx drops frames on its own when the bitrate cannot carry them, so a capture round is not a delivered frame. The video send is inline in the connection's message loop, so a slow write stalls capture and the delay probe alike, and the recorded delay cannot tell the two apart. `qos_video` reports, per second and per display, the capture rounds, the frames that actually reached a connection, and the longest wait for the previous frame to be picked up. `qos_send` reports, per second and per connection, how long `stream.send().await` blocked and how deep the video queue is. Both carry `t=`, so they join with `qos_trace` offline; `replay` filters on `qos_trace` and ignores them. The default log level is `debug`, so an unconditional line would land in every user's log file once a second forever. Neither line is emitted unless `RUSTDESK_QOS_VERBOSE` is set, nothing enables it implicitly, and without it the timing calls are skipped as well. TestDelay, the controller and every threshold are untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): speed up FPS ramp-up on clean connections Double startup FPS after every two fresh low-excess-delay replies, up to the viewer's cap. End acceleration on queue growth, timeout, or FPS reduction. Add regression tests for startup speed, viewer caps, congestion, timeouts, and multiple viewers. Signed-off-by: 21pages <sunboeasy@gmail.com> --------- Signed-off-by: 21pages <sunboeasy@gmail.com> Co-authored-by: RustDesk <71636191+rustdesk@users.noreply.github.com> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> |
||
|
RustDeskandClaude Opus 5
|
01dbb76499 |
server: do not lock the screen for a connection a reconnect replaced (#16124)
A controlling peer whose link dies without a close reconnects, while the
connection it left behind runs on here until its own 30s inactivity timeout.
That one then ends with `on_close("Timeout", true)`, and the lock is gated
only on `lock_after_session_end` and this connection's own `keyboard` - both
set by the very controller that is at that moment working in the session its
reconnect re-established. Nothing anywhere asks whether the session is still
being controlled, so the screen locks under a peer that came back twenty-odd
seconds earlier, and the operator's desk locks itself in front of them.
The lock now also requires that no newer remote control connection of this
session is authorized.
Newer, not merely other. A connection stays in `AUTHED_CONNS` until its
`AuthedConnID` drops, which is well after `on_close` returns, so a symmetric
test would have two of one session ending together each see the other and
neither lock. Ids come from a counter, so `>` orders them: of a session's
connections the last still locks, whether they end one after another or at
once.
Remote control only, and this session only. The other kinds do not keep a
screen in use, and `send_logon_response` clears `keyboard` for a file
transfer, a terminal and a camera view, so none of those reaches the gate at
all - a port forward keeps it, and is kept out only by the client not sending
`lock_after_session_end` on one. Another peer's
session is left exactly as it is: whether its ending locks the screen while
this one is connected is a separate question, and not one a timeout on this
side should start answering.
Every close that asked to lock, not only the timeout. A connection its own
peer has already replaced should not lock the session that replaced it
however it ends, and singling out one reason would leave the same race
reachable through the others.
Two things it does not cover. A reconnect that has not authorized yet is not
in `AUTHED_CONNS`, so a timeout landing while one waits at the accept prompt
or on 2FA locks as before. And the lock is skipped, not handed on: if the
connection that replaced this one later ends through a path that asks not to
lock - a failed send, a stopped service - nothing locks. That is what those
paths already choose for a connection dying of a network error, on the
assumption that the peer will retry, and it is the same assumption this makes.
Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
||
|
RustDeskandClaude Opus 5
|
b50fde6910 |
add the base crate and repoint the moved modules at it (#16107)
* add the base crate and repoint the moved modules at it `libs/base` (crate `base`) takes the parts of hbb_common that only this app uses: `fs`, `platform`, `keyboard`, `message.proto`, and 145 of the 177 `config::keys` constants. hbb_common keeps what the server names, and the 32 keys it reads itself are re-exported from `base::config::keys` so call sites still see the full set through one path. Sources move verbatim. The only edits inside them are `crate::` prefixes that now have to say `hbb_common::`; `keyboard.rs` and `platform/windows.rs` are byte-identical. The crate stays on edition 2018, the edition the moved code was written under. `log`, `lazy_static` and `anyhow` become direct dependencies so the bare paths in that code resolve exactly as before, and its winapi features are spelled out rather than left to feature unification. Two call sites outside Rust and Cargo had to follow the move: the Android protobuf source dir, which still pointed at hbb_common/protos for message.proto, and the three AGENTS.md entries that named hbb_common for options, protos and file transfer. `scrap`'s `drm` feature now forwards to `base/wayland_probe`. Left pointing at hbb_common it would still have compiled, silently dropping the Wayland socket-probe fallback, so that forward is verified by a build with and without the feature. `config::keys` carries a test asserting its names stay disjoint from the ones hbb_common kept: the glob re-export and the local constants share a namespace, and Rust prefers the local item silently, so a name added to both sides would otherwise let client and server disagree with no diagnostic. Verified: macOS and Linux, debug and release, `--all-targets`; the 177 key constants diffed name-for-name and value-for-value; the generated protobuf types compared before and after; every `#[cfg]` gate on a moved import checked against its original; and every file that was `rustfmt`-clean before this change still is, compared against master file by file. Windows is checked by inspection only -- it cannot be compiled here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * one `use` per crate, and write the rule down `fs.rs` came out of the move with two ungated `use hbb_common::` statements, because the original single `use crate::{...}` had to give up `message_proto` to the new crate and the rest was left in a second block. Fold it back into one. A scan of the whole tree for the same shape finds nothing else: every other file with more than one top-level `use base::` or `use hbb_common::` is split by a `#[cfg]` that does not cover the whole block, or by `pub use` next to `use`. Those are the cases that cannot merge, so AGENTS.md now states both the rule and the exemption. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
RustDeskandClaude Fable 5.1
|
3fc11c0f81 |
port forward shared conn (#16062)
* hbb_common: bump to the port-forward-mux proto Also latches PortForward.multiplex into login_scope_digest, which destructures PortForward's fields exhaustively by design (a new field must be latched or deliberately ignored to compile). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port_forward_mux: window accounting and channel frame builders Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port_forward_mux: fix RecvWindow counter overflow on long transfers Replace cumulative accounting (granted/received) with remaining credit tracking to prevent u32 overflow after 4 GiB of data on a single channel. Wire behavior is identical, but the fix allows large file transfers without mid-stream channel closure. Add regression test for 8 GiB transfer to verify fix. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port_forward_mux: credit-windowed relay halves and channel coordinator Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * server: PortForwardMux channel table and per-channel tasks Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * server: multiplexed port-forward connections stay in the protobuf loop Wire PortForwardMux into Connection: take the multiplexed path at login when the controller sets PortForward.multiplex, route PortForwardChannel frames to it from on_message, sweep the channel table's targets after open/close, and clean it up on connection close. Introduce is_port_forward() (socket-based or multiplexed) and use it at the four sites that classify the connection, so a multiplexed connection stays in the message loop, gets TestDelay keepalives, and reports features.port_forward_mux in PeerInfo. The three sites that break into the raw pipe loop or gate the keepalive still check port_forward_socket specifically, since a multiplexed connection must not take that path. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * cm: update a port-forward row's targets as tunnel channels come and go Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port_forward_mux: controller tunnel with a single-writer stream loop Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port_forward_mux: publish Muxed before spawning the tunnel loop Publishing after spawn let a loop that dies immediately reset the state first, so the later publish pinned it at Muxed with a dead handle forever. Also adds a test pinning open-before-data ordering across many concurrently opened channels, and drops an unused Clone derive. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: share one multiplexed tunnel across a window's listeners Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: fix round 1 review findings Drop the mux default-false assignment now that definite-assignment proves every path that reads it has set it; the enable-port-forward-mux config commit picks up the missing attribution trailers; the default-on test pins the enable- prefix itself rather than option2bool's weaker fallback. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port_forward_mux: end-to-end tests over a loopback tunnel Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port_forward_mux: fix bulk test's premature half-close, pin the half-close limitation many_channels_echo_concurrently_and_a_bulk_one_does_not_starve_them dropped its bulk write half as soon as writing finished, which shuts down the write side of the socket and, by design (see the design doc's TCP half-close non-goal; today's run_forward does the same), ends the whole channel. Keep the write half alive until the reader is done so the test measures starvation, not half-close. Add a_local_half_close_ends_the_whole_channel to pin that limitation in code. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port_forward_mux: cap send credit and other final review fixes Fix 1 (critical): clamp SendCredit to MAX_SEND_CREDIT (= CHANNEL_WINDOW) in both new() and add(), so a peer with tunnel permission can no longer advertise an unbounded window and force the controlled side's unbounded FrameSink::Direct sink to buffer unlimited target data per channel. Fix 2: rename the "starve" test to many_channels_echo_concurrently and drop its (untrue) starvation claim, since it opens every channel before the bulk transfer starts. Add a_channel_opened_during_a_bulk_transfer_ is_served_promptly, which opens the small channel while the bulk one is demonstrably mid-flight. Fix 3: only look up the tunnel permission for `open` frames in the PortForwardChannel arm of on_message, instead of once per data frame. Fix 4: two rustfmt deviations in connection.rs (matches! wrapping and a tuple literal), fixed by hand without a blanket cargo fmt run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port_forward_mux: report a refused channel's reason as an error dialog The controlled side already answers a refused port-forward channel with opened { success: false, message }; on the multiplexed path TunnelHandle:: on_frame only logged that message at debug and closed the channel, so the user saw a closed connection with no explanation, worst on the RDP path where only the RDP client's own error remained. on_frame now returns the message the window should show, deduplicated per distinct reason (capped at MAX_REPORTED_OPEN_ERRORS) so one page load's dozen refused connections surface one dialog per reason instead of a dozen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * Use on_error for refused-channel dialog in tunnel_loop Redirect the refused-channel error through the standard on_error path instead of calling msgbox directly, for consistency with other errors in the port-forward flow. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: apply the whole-branch review Correctness: - listen(): the Legacy arm is merged with the Claimed arm. On its own it ignored outcome.local_eof, so a client that hung up during login still got a target connect, an audit record and a CM row on the controlled side, and ignored outcome.mux, so a peer upgraded while a legacy window stayed open answered as a tunnel while the controller went raw. - Refusal dialogs are deduplicated per quiet spell (10 s) rather than per tunnel lifetime; the lifetime set went silent for the rest of a long-lived window after the first burst. - Android's CM listener handles UpdatePortForward; it fell into `_ => {}`. - relay_socket_to_tunnel reads into one scratch buffer per channel and sends an exact-size copy. A frame owning its 64 KiB read allocation pinned it until sent, once per byte on interactive traffic. Consistency and cleanups: - The controlled side's refusal text is the raw pipe's wording, RDP substitution included. - connection.rs: the PortForwardChannel arm is a one-line hook, the CM label is pushed from the 1 s tick alone, and the unreachable inner.tx fall-through is gone. - The Ready enum is removed; wait_ready() returns Option<Claim>. - SendCredit::add wakes with notify_one alone. - on_ui_command() replaces the two ui_receiver handlers in listen(). - TunnelHandle is no longer re-exported (unused-import warning). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: a legacy window stays legacy until it is reopened Review: the merged `Claimed | Legacy` arm gave a legacy window a hot transition to a tunnel — every accept re-negotiated, and a peer upgraded while the window stayed open was promoted underneath live connections. The product does not need a mode switch inside a window's lifetime, and the transition was extra state-machine surface for nothing: reopening the window picks up an upgraded peer. The two arms are separate again. `Claimed` negotiates once and the peer's answer fixes the window's mode. `Legacy` logs in for every accept as before, asks for no tunnel — `LoginConfigHandler::port_forward_mux` carries the request per login, so the raw pipe never has to talk to a peer that thinks it agreed to multiplex — and ignores what the peer reports. Both arms keep skipping a local socket that hung up during login. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * hbb_common: bump to main with rustdesk/hbb_common#594 merged Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * server: admit only INITIAL_WINDOW on a channel before opened The demultiplexer accepted CHANNEL_WINDOW into a pending channel's unbounded queue, four times the bound the channel task enforces once it polls. The window now starts at INITIAL_WINDOW and is widened right before `opened` advertises the rest. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port_forward_mux: a tunnel ends when its window drops the Tunnel The loop held its own handle and state sender, so once the window closed nothing was left to stop it: it kept answering TestDelay and the peer connection, CM row included, lived on until the peer went away. `Tunnel` now owns a watch sender nobody sends on; the loop's receiver errors when the last `Tunnel` drops, and the loop ends. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: one tunnel per mapping, bound to the authenticated target The login latches `PortForward.host`/`port` into the session scope and approval is shown that target, but a window-wide tunnel let any later `open` name another target with only `enable-tunnel` rechecked. A tunnel now belongs to one listener and serves the one target its login authenticated: the controlled side refuses an `open` for any other target, and a window with several targets uses one connection each, approved on its own. With one owner per tunnel the claim needs no waiters: `Establishing`, `Claim::Wait` and `wait_ready` go, and `try_claim` becomes a plain read. The CM label that followed a tunnel's targets goes with them; a row shows its mapping's target, as before. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: the legacy comment names the mapping, not the window Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port_forward_mux: a window violation drops the channel on the spot Both demultiplexers only queued a `Violation` and left the entry until the channel task woke and exited, so a peer that kept sending past the window queued one more entry per frame in the meantime, bounded by nothing. The entry now goes the moment `accept` fails; later frames for that id are unknown-channel noise. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: the login's target travels with the accept, not the handler `listen()` wrote `lc.port_forward` (and, on this branch, `port_forward_mux`) into the window's shared `LoginConfigHandler` before connecting, and `create_login_msg` read them back only when the peer's `Hash` arrived. Two mappings logging in at the same time could therefore swap targets: on master that bridged a local socket to the wrong target, and with a tunnel bound to its login's target it also left the mapping refusing every later accept until it was recreated. The target is now a `PortForward` carried by the interface clone that handles one accept, passed explicitly down to `create_login_msg`; the handler no longer has a field to race on. No lock spans the login. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port_forward_mux: pin permission revocation and whole-tunnel failure in tests Both already hold; the review asked for them to be stated. `enable-tunnel` turned off mid-session refuses the next `open` while the live channel keeps relaying, and a dead tunnel ends every channel on it together, after which the next accept establishes again on the same `Tunnel`. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: the legacy comment names re-adding the mapping only Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: the raw pipe runs the code it always ran The multiplexed login had replaced `connect_and_login`, so a mapping with the setting off, a peer without the feature, or a listener latched `Legacy` still went through the tunnel's state machine, the capped pre-read and the changed local-EOF rule. Feature off now means the old code: `listen()` keeps its accept arm and `connect_and_login` as they were, and the tunnel is a branch taken only when the setting is on, in `establish_tunnel` with its own `connect_and_login_mux`. The one line the raw path does differently is the target riding with the accept's interface clone instead of the shared handler. `get_port_forward_mux_enabled` had one caller and moves in here, so `common.rs` is untouched. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: a UI login answers the challenge its own connection was given `handle_login_from_ui` hashed the typed password against `lc.hash`, the window's shared handler field, and the window's password prompt is broadcast to every listener. With two mappings both waiting on that prompt, the `Hash` that arrived last had overwritten the other's, so one of the two answered the wrong challenge and failed to log in. Master shares the same state and broadcasts the same way. The `Hash` is now a parameter of the login; `Session` keeps it beside the connection it belongs to, and the per-accept clone that `with_port_forward` makes gets a slot of its own. `lc.hash` stays for `handle_peer_info`, which only needs the salt, and that is per peer. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: a mapping without its hash waits for it before answering the prompt The window's password prompt is broadcast to every mapping, and can reach one whose own connection has not received its `Hash` yet. That mapping used to answer anyway, with a digest over an empty challenge: the peer refused it and counted a failed attempt, and the empty-salt result was written into the shared `lc.password`, where the mapping that prompted had just stored the right one and the next `handle_peer_info` would persist whatever was there. The connection's challenge is now `Option<Hash>`, `None` until `handle_hash` runs, and `handle_login_from_ui` sends nothing without it. The mapping that prompted stores the salted password in the shared handler, and the waiting one logs in with that against its own challenge when its `Hash` arrives, without prompting again. Test: A answers its prompt, the same broadcast reaches B before its hash, B sends nothing, B's hash arrives and its login carries B's challenge and B's target with no dialog. It runs the real `handle_hash` for B. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: the tunnel's login is the raw pipe's, asked for by a window flag Master's fix for the shared login slots (#16069) keeps the target and the challenge in the window's `LoginConfigHandler` and serializes the mappings' logins with a turn lock, all inside `port_forward.rs`. This branch had carried a broader shape of the same fix, a `with_port_forward` on `Interface` and the target and `Hash` as parameters through the login functions, which every caller had to follow. That is gone: `Interface`, `Session`, `create_login_msg`, `send_login`, `handle_hash` and `handle_login_from_ui` are as on master. What the tunnel needs on top is one bit in the login, `multiplex`. It is a window flag beside `port_forward` in the handler, set once in `io_loop` before the window's mappings start, so an accept's claim and its login read the same value; the setting takes effect for windows opened after it changes. `connect_and_login_mux` is now master's `connect_and_login` with the tunnel's three differences and the same `hash_arrived` and `login_from_ui` calls. The raw pipe is master's, line for line. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * hbb_common: bump to main with rustdesk/hbb_common#595 merged 840c8ec..f94e3fe is that one merge: the five local settings custom clients could not preset. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: the off switch gets a checkbox in Settings → General `enable-port-forward-mux` was readable only by editing the config file. It is a local setting of the controlling side, so it sits with the other outgoing ones, after "Open connection in new tab", with a tooltip saying what it does. The two new keys are translated in every language. The three that the mobile file manager added, "Export", "Export Logs" and "Import Folder", were empty everywhere but five languages; they are filled in too, and Korean's "xdp-portal-unavailable" with them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * Urdu: fill the backlog of empty and missing translations ur.rs had fallen behind: 104 keys carried an empty value and 35 keys the other languages have were absent altogether. Both are filled in, the missing ones in the order template.rs lists them. Eight entries stay empty on purpose. They are keys that only ur.rs still carries, absent from template.rs and from every other language, so their English source cannot be recovered and nothing reads them: remember_account_tip, os_account_desk_tip, another_user_login_*_tip, xorg_not_found_*_tip and no_desktop_*_tip. Twelve more dead keys keep the values they have; removing either group is a separate decision. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * Urdu: drop the keys template.rs no longer lists The twenty keys removed here are absent from template.rs and from every other language file; ur.rs was the only one still carrying them, eight of them with no value at all. They are leftovers of features that are gone: the plugin menu, the OS-account login prompts, the Xorg and no-desktop errors. ur.rs now holds exactly the template's key set, all of it translated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: closing the tunnel reaches channels parked on their socket A channel whose far end neither reads nor writes has both relays parked on the socket, not on the inbound queue, so `close_all` dropping the queue's sender woke neither: the socket and both tasks lived on until the far end hung up. Both sides now hold a per-tunnel teardown signal that `run_channel` selects on beside its own cancel, and `close_all` sends it after clearing the map. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: a mapping latched to the raw pipe logs in without asking for the tunnel The login copied the window's `port_forward_mux` into `multiplex`, so a mapping that had latched to the raw pipe on an old peer kept asking for the tunnel. Once that peer was upgraded it answered with a tunnel while the controller switched to raw framing, and every later connection on the mapping was dead until it was re-added. The login now carries its own `port_forward_multiplex`, filled with the target under the turn lock: the probe asks, the raw pipe does not. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: a channel opened as its tunnel closes still gets the teardown `open` can straddle `close_all`: the claim passed, the frame receiver was still alive, and the channel subscribed after the signal had gone out. `watch::subscribe` marks earlier sends as seen, and the entry sits in a map that was already cleared, so nothing would ever end it. The signal is now a level: `close_all` raises it with `send_replace`, which stores even with no channel live, and `run_channel` waits for the value rather than for a change. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: the connect guard counts a live tunnel as connected `connect_port_forward_if_needed` returned early only for a raw-pipe socket; called again with a tunnel up it would have built a second `PortForwardMux` and dropped every channel of the first. Not reachable today, since the logon response is sent once, but the other checks in this change already read `is_port_forward()`. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * Urdu: the two terminal clipboard keys master added Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: a tunnel's TCP stream refuses packets over twice MAX_FRAME The codec takes a header declaring up to 1 GiB and hands the packet up only once it has all arrived, so the channel window bounded what the peer may send, not what this side buffers. Both sides now cap the codec at 2 * MAX_FRAME as soon as multiplexing is agreed: a data frame with its envelope and MAC fits with room to spare, and a header over the cap ends the tunnel before a byte of payload is read. TCP only; the WebSocket and WebRTC codecs carry caps of their own. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * port forward: a channel id still live when the counter comes round is skipped The controller handed out `next_id` unchecked. 2^32 opens later it lands on a channel still up: the entry here was replaced, while the peer, which ignores an `open` for a live id, kept routing that id to the old socket, so the new local connection's bytes went into the old target connection. The id is now taken under the map's lock and advanced past any id in use. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
RustDeskandClaude Fable 5.1
|
50c4e435de |
connection: apply the non-video send timeout once the type is known (#16063)
* connection: apply the non-video send timeout once the type is known `Connection::start` set the send timeout before the login request had arrived, when `file_transfer`, `port_forward_socket` and `terminal` were all still unset, so every connection got `SEND_TIMEOUT_VIDEO` (12 s) and the `SEND_TIMEOUT_OTHER` branch never ran. A file transfer, terminal or port forward whose peer stopped draining for 12 s — a Wi-Fi roam, a VPN reconnect — was dropped. The type-specific timeout is now set in `on_message` right after the login request's union has been matched; `start` keeps the video figure for the login phase. `SEND_TIMEOUT_OTHER` also drops from 120 s to 30 s, the same horizon as the 30 s read timeout: the timeout wraps a single `send`, so it only fires when the peer makes no progress at all for that long, and beyond 30 s the read check would declare the same peer dead anyway. The raw port-forward pipe's write to its local target shares the constant and moves with it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * connection: keep the raw port-forward local write at 120 s `SEND_TIMEOUT_OTHER` also bounded `forward.send` in `try_port_forward_loop`, the write to the local target, whose own idle timeout is an hour. Lowering it to 30 s made a target that stops draining for half a minute drop the whole tunnel. That write gets its own constant at the value it always had. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * connection: keep the non-video send timeout at its long-standing 120 s Lowering `SEND_TIMEOUT_OTHER` to 30 s was a policy change on top of the bug fix, argued from the 30 s read timeout, which measures something else and cannot even run while a send is blocked. The constant goes back to `SEND_TIMEOUT_VIDEO * 10`, where it has been since 2021, and the raw port-forward loop's local write shares it again. What remains is the fix alone: the type-specific timeout is chosen once the login request has said what the connection is. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> |
||
|
|
3f93005be2 |
fix(drm): deliver a rotated output upright (#15886) (#15889)
* fix(drm): deliver a rotated output upright instead of sideways (#15886) the compositor draws a rotated desktop sideways into the landscape scanout and the physically turned monitor straightens it locally, so the raw scanout the drm path ships reads sideways in the viewer, and nothing rebroadcasts on rotation because the framebuffer size never changes. the capturer now resolves the output transform once per session from the wayland enumeration, turns accepted frames upright into its own buffer, and sizes the session in rotated dimensions. the advertised list swaps width and height for 90/270 outputs, which also makes a mid-session rotation a topology change that restarts the service, and computes scale from the post-swap width so a rotated 1:1 monitor no longer advertises scale 16/9. a non 4-byte format on a rotated session is a hard error and degrades through the existing health path. the greeter path where no compositor answers keeps today's behavior: there is no transform source there. hbb_common carries the new transform field (submodule bump). * fix(drm): drop the wayland snapshot when the live layout drifts (#15886) the advertised list is augmented from the cached wayland snapshot and nothing invalidated it mid-session, so a rotation the 1.5 s live poll plainly saw never reached check_changed: the poll reads live, the advertise kept serving the pre-rotation snapshot. measured before this commit: transform applied and held, 'desktop layout changed' logged, zero new encoders. cleared only when the poll saw an actual change, so the probe cost stays tied to real layout events; after it, the same stimulus rebuilds into a 1080x1920 encoder within a poll turn. * refactor: trim comment density to the file norm * chore: bump hbb_common to the transform field from rustdesk/hbb_common#586 pinned to the #586 commits atop the current pin rather than main tip: main also carries an unrelated config-keys refactor the app has not adopted yet, and both #586 commits are reachable upstream through the merge. * fix: advertise a lone rotated output at delivered size, one snapshot per session review findings, both real: the 90/270 swap sat below the origin-only cut, so a single rotated output advertised unrotated dimensions while the capturer delivered rotated frames; and transform and origin came from two get_displays() reads that could straddle a cache invalidation. the swap now precedes the cut (logical-scale adoption stays multi output), and new() resolves one snapshot for transform, origin and the session size, with tests for both. comments trimmed to the three-line guideline. * fix(drm): rotate every space the rotation touches, not just the pixels review findings on #15889, all verified against the code first. the uinput rect's single-display branches now serve the delivered orientation, so the pointer reaches the whole of a rotated screen (1). DisplayRect carries the transform, making 0/180 and 90/270 flips visible to the drift comparison (5), and the drift poll is an edge on live-vs-previous rather than a level against the baseline, so the cache clear fires once per real layout event instead of every 300 ms forever (9). on the drm path the baseline promotes together with the clear, so the remap and the client rebase never correct the same origin delta twice (7), and the poll now runs above the login-screen return, which was the one place with no other invalidation trigger (6). a snapshot generation gives a rotation a rebuild path at last (3, 4): clears bump it, the capturer records it at build, and a stale generation asks for a rebuild without counting against display health. the cursor bitmap and hotspot turn with the same session transform the frames use (11). original_resolution follows the 90/270 swap (12). the transform comes only from an identity match, never the layout-order fallback (13), and a missing wayland snapshot at build logs the degrade instead of silently pinning an unrotated session (10). unrotate_bgra's body is now libyuv's ARGBRotate, which the existing direction tests pin to the measured anchor (14). 180 stays master behavior: i915 advertises hardware rotate-180 and wl_output cannot tell hardware from software rotation, so undoing it blind would invert an already-upright frame; it needs the plane rotation property on the wire (2). the pipewire fallback guard's comment now states the rotated reality it compares (8). * fix(drm): one owner for the layout generation, one identity rule for rotation adversarial pass over the previous commit, three structural findings. the generation bump rode on the cache clear, which every video-service start also executes, so any session init or restart tore down every other live capturer, with no damping against a ping-pong between two displays. the bump now has a single owner: the edge-detected layout change in the display-service poll. cache clears are side-effect free again, and a two-display session survives a third session's init with zero spurious rebuilds. the advertise side swapped dimensions for a layout-order-fallback match while the capturer's transform refused such matches, splitting advertised size from delivered frames into a black screen. both sides now key off the same identity-match pass (identity_matches), so a guessed assignment rotates nothing anywhere. an edge observed while the drm verdict was transiently non-available was consumed unpromoted, leaving a rotation sideways for the session; it now stays owed until the verdict returns. an enumeration that failed at build pinned transform 0 forever with a warn promising a retry that did not exist; a missing snapshot now makes the first successful poll an edge, so the degrade is bounded by the outage. the multi-display missing-logical-size fallback serves delivered orientation, stale docs zhou named are updated, and the resolutions list stays mode-space on purpose: resolution changes ride xrandr, which is inert on this path. * fix: transpose-tolerant fallback size check, log a rejected rotate geometry whether a portal stream's caps arrive rotated on a 90/270 output is unmeasured either way (pipewiresrc does not apply SPA_META_VideoTransform), and this guard has already broken two readers who reasoned from its comment - so the size half now accepts either orientation instead of gambling a permanent offline on one. a source stride shorter than a row logs the rejected geometry instead of publishing a silent black frame. comments trimmed to the guideline and the stale sole-test claim updated. * fix(wayland): never serve a transposed PipeWire stream The fallback accepted a stream whose dimensions were the advertised display's transposed, but CapturerInfo keeps the stream dimensions, nothing on the wayland side ever reconciles the client afterwards, and the flutter renderer drops every frame whose size differs from the advertised display - a permanently blank fallback. Accept only the exact orientation; a transposed pair now falls into the existing bail, the display is advertised offline, and the client recovers by re-enumerating. * fix(drm): keep the cursor consistent with the session transform Two holes from the same review pass. The wire cursor id hashes only the plane pixels and geometry, so a stream rebuilt under a new transform resent the SAME id and the client's by-id cursor cache kept the old orientation until the shape itself changed; fold the session transform into the served id. And a cursor racing new()'s transform store was processed with transform 0 and never corrected, since the producer resends only on a shape change; hold that cursor and replay it once the transform is in - the receive loop wakes at least every 200 ms, so the replay is prompt even on an idle wire. * fix(wayland): the single-display carve-out must not forgive a transposed stream The carve-out forgives a size difference (a Full Workspace stream may report the workspace rather than the mode), but a transposed pair is the same served-vs-advertised orientation split the previous commit rejects, and it blanks the client the same way. * fix(drm): a lone display with a rejected fallback is honestly offline The transposed rejection promised 'advertised offline', but the lone-display carve-out in mark_demoted_displays kept the display online on the grounds that the whole-desktop fallback remains usable - which is exactly what the rejection just refuted. The video service then restart-looped against a stream nothing can serve, rebuilding the portal session about once a second, while the client saw a display list that lied. Record the geometry rejection in the display health and let it end the carve-out; a delivered frame or the demote-cooldown re-arm clears it, so a recovered output comes back on its own. * ci: retrigger, the previous run died in the actions outage (all root jobs at exactly 8m) * fix(drm): a blind capturer owes a rebuild, and name matches reserve globally Two of the review's findings. A capturer built during a failed wayland enumeration recorded nothing durable: a later successful enumeration refills the cache, wayland_snapshot_missing goes false, and the first live poll sees no edge - the session stays sideways until an unrelated change. The build now latches that it ran blind and the layout poll consumes the latch into the existing owed-promotion machinery. And the identity matcher ran per-connector, so a resolution guess for an earlier connector could steal a later connector's exact name match and pin its rotation on the wrong output. Names now reserve in a global first pass; resolution pairing runs on the remainder only when forced - one free output and one unmatched connector at that size. * fix(drm): consume the blind-build latch even on a live-changed poll Adversarial pass on the previous commit: the short-circuit left the latch set on exactly the poll where live_changed fired (the common blind-recovery ordering, since a failed enumeration is not cached and failed_init makes the first successful poll an edge), and the stale latch then bought a second, spurious promotion one poll later, tearing down the freshly rebuilt capturer. The latch is now taken unconditionally so both edge sources merge into one promotion. * fix(wayland): hand over a layout change the poll has not seen yet set_wayland_layout_baseline clears live, which is the edge detector's only memory of the previous layout. ensure_inited calls it at the top of every video service start, so a second monitor service starting between a rotation and the next 1.5s poll recorded the rotated layout as the baseline: the poll then found baseline == live_rects, owed no promotion, and the first capturer kept its old transform. Under mutter's software rotation the framebuffer size does not change and the wayland display-change check is disabled, so the stream stayed sideways until the next layout event. The setter now arms the promotion itself when the outgoing live differs from the incoming baseline, which is the one choke point every caller goes through. An empty incoming baseline is the DRM-union fallback and proves nothing. * fix(wayland): the edge detector needs a memory a session init cannot erase The baseline reset was also the edge detector's memory, so two session inits straddling a rotation left nothing to compare the next poll against. Keep the observed layout separate from the per-session input baseline; before the first poll the outgoing baseline seeds it. * fix(wayland): a capturer records the layout it was built on ensure_inited() runs the wayland query before the capturer exists, and a failure there saves an empty baseline. The capturer's own retry can succeed a moment later and build on that layout, and because the build was not blind nothing latched it, so a rotation before the first poll had no memory to be an edge against and the stream stayed at the old transform. The build now seeds the edge detector when nothing else has, and only then, so a capturer built later cannot overwrite what the poll is keeping. * fix(wayland): keep a capturer record that lost the race with the first poll The constructor reads its wayland snapshot and records it in the edge detector in two steps, and the layout poll can land between them. After a failed session init (empty baseline) the constructor takes layout A and publishes it, the output rotates, and the poll reads B live: nothing is recorded yet and the snapshot is present, so it is no edge, and observe() sets seen=B. The late note_capturer(A) then met a non-empty memory and was dropped, so the capturer showed A while the detector held B, and B against B never bumped the generation. note_capturer now flags a build layout that disagrees with the poll's memory instead of dropping it (overwriting is still wrong: on a multi-display session that memory is what the other capturers were built against). edge() reports the flag as an edge whatever the live layout is, observe() consumes it right after, and a session init's baseline reset leaves it alone. Regression test for the interleaving, with the promotion consuming it, a baseline reset in between, and an agreeing late record as the control. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011ZwSrP3DFA6ZiPKVHkU5dL * fix(wayland): a late capturer record from a promoted generation is not a second edge The record can also land after the poll consumed an edge but before the bump it promotes, or after the bump with a snapshot taken before it. That capturer is stale by generation and rebuilds on its own, but the flag it raised survived the promotion, and the next poll spent a second promotion on the freshly rebuilt capturers. Tag the record with the generation the capturer read before taking its snapshot and count it as an edge only while that generation is current; the newest generation wins when two records land. Regression test for the consumed-edge interleaving, with a disagreeing record at the promoted generation and a stale record after a fresh one as controls. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011ZwSrP3DFA6ZiPKVHkU5dL * chore: bump hbb_common to main tip dc95b4f -> 05ed68f, a fast-forward: the flipped-transform warning and the wlroots xdg-output positions (rustdesk/hbb_common#591, #592), 90-day logs, the webrtc session cleanup deadlock fix and the hide-general-settings option. No public API changes and no dependency changes. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011ZwSrP3DFA6ZiPKVHkU5dL --------- Co-authored-by: rustdesk <71636191+rustdesk@users.noreply.github.com> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> |
||
|
Michael Clarkandfufesou
|
d4b06a6c5c |
fix: android: replace all-files access with scoped storage (#15602)
* fix: android: replace all-files access with scoped storage + system picker Remove MANAGE_EXTERNAL_STORAGE, READ_EXTERNAL_STORAGE, and WRITE_EXTERNAL_STORAGE from the Android manifest. Remove requestLegacyExternalStorage. Replace broad external storage with app-scoped external storage for the file-transfer workspace. File import uses the system file_picker. File export uses Android's SAF ACTION_CREATE_DOCUMENT with path validation that restricts export sources to app-owned directories. Remove the external_path dependency. Signed-off-by: michaeljclarkk <104532890+michaeljclarkk@users.noreply.github.com> * fix: android: refine file import feedback Signed-off-by: michaeljclarkk <104532890+michaeljclarkk@users.noreply.github.com> * fix: android: use SAF for file imports Replace file_picker imports with Android's Storage Access Framework to avoid legacy storage permissions, stale cached files, and duplicate staging of large imports. Stream selected documents into app-scoped storage with failure-safe replacement, keep exports restricted to validated app storage roots, use filesDir for the internal fallback workspace, and remove legacy permissions contributed during manifest merging. Signed-off-by: michaeljclarkk <104532890+michaeljclarkk@users.noreply.github.com> * fix: android: keep file imports in the selected directory Signed-off-by: michaeljclarkk <104532890+michaeljclarkk@users.noreply.github.com> * fix: android: reset projection and constrain file workspace Release capture resources when media projection is revoked externally. Keep Android local file navigation within the app-scoped workspace. Signed-off-by: michaeljclarkk <104532890+michaeljclarkk@users.noreply.github.com> * fix: android: handle scoped storage start-up regressions. Allow zero digits in POSIX filenames by rejecting NUL explicitly, and initialise the app-specific home directory before the Android service starts the native server. Signed-off-by: michaeljclarkk <104532890+michaeljclarkk@users.noreply.github.com> * fix: update content resolver mode to use 'wt' instead of 'w' to prevent trailing bytes from old document whilst reporting sucess Signed-off-by: michaeljclarkk <104532890+michaeljclarkk@users.noreply.github.com> * fix: android, enforce file workspace boundary on the server, and unblock the ui thread. Signed-off-by: michaeljclarkk <104532890+michaeljclarkk@users.noreply.github.com> * fix: android: validate rename destinations against the app workspace bound file-operation paths. report rename failures, general import failures, and unregister / reregister projection when its onStop callback fires. Signed-off-by: michaeljclarkk <104532890+michaeljclarkk@users.noreply.github.com> * fix: reconnect was refreshing the directory with net entry instances, while selected items retained the old instances, it was reporting a selected item, but checkbox statue used object identity, and appeared unchecked. Fixed by reconciling by path and entry type before replacing the directory snapshot, rebinding valid selections, and dropping missing ones. Signed-off-by: michaeljclarkk <104532890+michaeljclarkk@users.noreply.github.com> * fix: (android) add SAF folder import and multi item export - import directories using ACTION_OPEN_DOCUMENT_TREE. Export multiple files, logs, and screen recordings via export buttons, add localisation keys for new actions Signed-off-by: michaeljclarkk <104532890+michaeljclarkk@users.noreply.github.com> * fix(android): harden scoped storage file handling - create new SAF documents instead of overwriting export sources - reject empty peer paths except for home directory reads - report directory backup restore and cleanup failures - resolve log export paths from the configured app name Signed-off-by: fufesou <linlong1266@gmail.com> * fix(android): harden scoped-storage file operations - snapshot directory exports before writing to the destination - query document provider metadata off the main thread - reject invalid remote directories without read timeouts Signed-off-by: fufesou <linlong1266@gmail.com> * fix(android): handle SAF directory name collisions - reject dot-segment folder names during import - fail imports with duplicate document display names - only reuse matching directories during export Signed-off-by: fufesou <linlong1266@gmail.com> * fix(android): handle SAF folder import collisions Reject filesystem-equivalent destination names and avoid showing a failure when folder overwrite is skipped. Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: michaeljclarkk <104532890+michaeljclarkk@users.noreply.github.com> Signed-off-by: fufesou <linlong1266@gmail.com> Co-authored-by: fufesou <linlong1266@gmail.com> |
||
|
Mariano Abad
|
3f207e91f6 |
fix(linux): a session logout should hand the peer to the login screen (#15905)
* fix(linux): a session logout should hand the peer to the login screen Logging out closes every window in the session, the connection manager's included, and its close handler kicks every peer with the reason a person gets when they disconnect one by hand. That reason is the one thing the client never retries on, so the remote session dies on a frozen frame instead of reconnecting to the greeter that is already there. The close carries nothing to tell the two apart: measured on KDE, the CM receives no signal and logind still reports the session active at that instant, and the server is killed within a few hundred ms either way, so neither a state check nor a grace period can decide it. What is distinguishable is the ACTION: disconnecting a peer is not the same event as this window going away. So the window-close path now says so, and the server ends the session without poisoning the retry; the Disconnect button and the app's own close control keep kicking exactly as before. Linux only, since that is where a logout closes the window. Verified on plasma/sddm with a client attached: a logout now reconnects to the greeter with no dialog, while closing the manager window still shows Closed manually by the peer. * fix(linux): close the tunnel too, and keep the web build compiling Three seams the first pass missed. The web bridge is hand written, not generated, so the new call needs its stub there or flutter build web stops compiling - and that job is disabled in CI, so it would have gone green. try_port_forward_loop is a second consumer of the same channel and only knew Close, so a forwarded tunnel outlived the window it was supposed to die with. And the variant had landed inside the DRM section, whose comment says everything below it is drm-gated. |
||
|
fufesou
|
b0008edcb5 |
refact: remove linux headless (#15866)
* refact: remove linux headless Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): probe DRM availability asynchronously on login Signed-off-by: fufesou <linlong1266@gmail.com> * revert changes in drm_capturer.rs Signed-off-by: fufesou <linlong1266@gmail.com> * Update submodule hbb_common Signed-off-by: fufesou <linlong1266@gmail.com> * docs(linux): clarify DRM availability comments Remove stale headless and unauthenticated-request wording, and document the Available-only login-screen gate. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(linux): remove unreachable session cleanup branch Remove the obsolete empty-session path and clarify the intended use of cached DRM availability. Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: fufesou <linlong1266@gmail.com> |
||
|
RustDeskandClaude Fable 5
|
6a27910f34 |
fix(wayland): back off the polling display lookups after a failure (drm) (#15865)
* fix(wayland): back off the polling display lookups after a failure (drm) In drm builds an enumeration that fails with no endpoint named in the environment falls back to the socket probe, which forks a child bounded by seconds, and the display service asks again every 300 ms -- at a greeter with no reachable compositor that is a probe child per turn, forever. Such a failure now stamps a shared 5 s backoff, and only the polling callers honor it: the 300 ms displays-changed check skips its turn and the 1.5 s live layout poll returns no answer for that turn. Only the failure that would fork stamps. A session server is spawned with WAYLAND_DISPLAY set, so its failed connect bails in-process before any fork; stamping there would buy nothing and cost recovery latency, so live sessions keep master's behavior exactly. The stamp also survives clear_wayland_displays_cache: it describes the seat, not the cache, and the ~1/s capturer rebuild loop clears on every teardown -- dropping the stamp with the cache would let that loop defeat the backoff and would turn every post-hotplug failure into a "first" one forever. The displays-changed check weighs the backoff against what is already published. With nothing synced yet it always populates -- an unaugmented DRM list beats the empty broadcast the send path would otherwise emit. With a synced layout, a suppressed turn keeps it, and a fresh first failure keeps it too; only a failure that persists across a backoff replaces it with the DRM stack, so a hotplug at a failing seat converges within one backoff while a transient failure never tears down a good layout. One-shot callers -- session init, pipewire stream setup, capturer info -- keep probing fresh through get_displays, whose failure semantics are unchanged: replaying a transient failure there would latch an empty answer into session-long state. Non-drm builds compile none of this. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(wayland): log DRM lookup failure once * fix(wayland): reset lookup warning after recovery --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
7aa98d43cf |
Refact/plugin removal leftovers (#15864)
* fix(flutter): dispose the settings PageController and order dispose() correctly `dispose()` began with `super.dispose()`, so the mixin chain marked the State defunct before the WidgetsBindingObserver registration and the periodic timer were released. The `PageController` was never disposed at all: `Get.delete` only runs `onDelete()` for a `GetLifeCycleBase`, and a plain `ChangeNotifier` is not one, so every open/close of the Settings tab leaked one controller with its listener still attached. Also guard `switch2page` on the `Rx<SettingsTabKey>` registration it actually reads rather than only the `PageController` — now that both are really deleted, a partial teardown would throw into the catch and silently open the wrong tab — and re-check `mounted` after the await in the `_videoConnTimer` tick, which `Timer::cancel` cannot stop once the body has started. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * refact: finish the plugin-framework removal sweep #15854 removed the feature but stopped short of its leftovers: - `Uninstall`, `Enable`, `Disable`, `Options` and `Please install plugins` were consumed only by the deleted `flutter/lib/plugin/**`; drop them from template.rs and the 50 locale files (250 dead entries). `Update` and `Install` stay, still used by desktop_home_page.dart. - The server no longer sends `PrvOnFailedPlugin`, and the client no longer offers to install plugins when privacy mode fails to turn on. - Drop the MSI `F_Client_Plugins` / `F_Server_Plugins` localization strings; no `.wxs` references them. - `_DisplayMenu`'s constructor became a pure pass-through once `pluginItem` was removed, and the cfg inside `handle_input` repeats the one on the function itself. - Normalize `src/lang/sl.rs` to 0644, the only executable file under src/. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(client): handle legacy privacy mode plugin failures Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: fufesou <linlong1266@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: fufesou <linlong1266@gmail.com> |
||
|
fufesou
|
d1da05c4db |
refact: remove feature plugin-framework (#15854)
* refact: remove feature plugin-framework Signed-off-by: fufesou <linlong1266@gmail.com> * refact: remove unused translations Signed-off-by: fufesou <linlong1266@gmail.com> * fix: delete settings tab observable with correct type Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: fufesou <linlong1266@gmail.com> |
||
|
|
d829d1410a |
fix(linux): serve the Wayland login screen the DRM backend was built for (#15792)
* fix(linux): serve the Wayland login screen the DRM backend was built for The login screen support in #15420 never worked on a real greeter. fufesou found it: the session is refused, and with the refusal commented out the client gets a failed connection instead of a screen. One premise under all of it. `get_values_of_seat0` is `_get_values_of_seat0(.., ignore_gdm_wayland = true)`, so a gdm/sddm Wayland session is skipped by construction and `get_display_server` falls back to x11. That was correct while the portal was the only backend, since the portal cannot serve a greeter at all. The DRM path never talks to the compositor, which is precisely why it can serve one, so the premise stops holding there and every x11-vs-Wayland decision in the tree answers x11 at a login screen. The central change is the memoised `IS_X11`: when it reads x11 and seat0 is a Wayland greeter, answer Wayland. That covers fifteen routing sites at once, and it is under `cfg(feature = "drm")`, so a build without the backend keeps the current answer exactly. `is_x11_for_drm` is the unmemoised form for the two retry loops that must keep asking while a boot is still naming the session, and the memoised accessor is scoped to per-frame callers in the per-session `--server`, which the service only spawns once it has identified the session. Input was the last layer and lived outside all of that. `Enigo` decides x11-vs-Wayland once in `Default::default()`, from the same seat0 lookup, and on "x11" routes every key and mouse event to xdo; with no X server that context is null and libxdo drops them without an error. So the uinput devices were created, the compositor opened them, and nothing was ever written to them. `set_is_x11` is now called where the custom devices are installed, which is only reached once `!is_x11()` is already established. The unit test pins both directions, since a one-directional test passes against the bug. With no compositor reachable, the uinput desktop rect comes from the DRM display list instead: those are the same displays being captured, so the coordinate space matches by construction. Telling the truth about a greeter also makes four compositor-probing paths reachable where the probe cannot answer; all four already treat an empty output list as "nothing to do", so they skip it and 11818 "Could not find wayland compositor" warnings in one session became 1. Tested on an sddm Plasma Wayland greeter, MacBook T2, 2880x1800: the greeter renders, typing from the client enters characters in the password field, a click at an absolute coordinate opens the greeter session combo, the service pre-warm primes in 994 us instead of timing out, and the privileged service maps no EGL during a live capture. Not proven on gdm under Wayland. Known limitations: non-ASCII characters cannot be typed at a greeter, because that path goes through the clipboard and the clipboard here is X11 only; and at a multi-monitor greeter the pointer reaches the first display only, since every DRM output reports origin (0,0) on Wayland and there is no arrangement to derive without the compositor. * fix(linux): a Wayland greeter the DRM backend can serve is not headless fufesou reported the login screen still failing on Ubuntu 24.04 with gdm3, with the client asking for OS credentials to start an X session instead of showing the greeter. Reproduced on a real gdm greeter here. Same premise as the rest of the branch, one more consumer. `DesktopManager::new` reads seat0 through `get_values_of_seat0`, which skips a gdm/sddm Wayland session by construction, so at a greeter it finds no session at all and `get_supported_display_seat0_username` returns None from its empty-username arm. That makes `is_headless()` true, so the service advertises headless and `try_start_desktop` answers `LOGIN_MSG_DESKTOP_SESSION_NOT_READY`. The corrected `IS_X11` does not reach this one: it asks who owns seat0, not which display server is running. So ask again, with the greeter visible, when the DRM backend can capture and inject into it. At query time rather than in `new()`, because the DRM probe has not necessarily settled when the desktop manager is constructed, and the answer would latch for the process lifetime. In a normal session the latched username is a real user and the extra read is skipped. * chore: drop the hbb_common bump, this branch does not need it The bump carried rustdesk/hbb_common#580, the compositor-socket fallback. Nothing here depends on it: the greeter paths in this branch are the ones that run when compositor data is unavailable, which is what the commit before this one states as a known limitation. Keeping the bump would only block the greeter fix behind a review of a separate change, and would import that change's blocking review items into this path. * fix(linux): let the uinput uid gate see the greeter that owns seat0 Input at a real greeter was rejected by our own authorization. Measured on Ubuntu 24.04 with gdm3: the root service logs Rejected unauthorized connection on uinput ipc channel: postfix=_uinput_control, peer_uid=Some(120), active_uid=None and the greeter's `--server` gets ECONNRESET out of `setup_uinput`, so no uinput device is ever created and neither keyboard nor mouse reaches the greeter. uid 120 is gdm, the owner of the only active seat0 session. `active_uid` is None because the uinput authorizer deliberately bypasses the service-loop cache and takes a fresh seat0 lookup, and the fresh read hides a Wayland greeter by construction. The cache-based gates do not have the problem: `Desktop::refresh` fills it through the greeter-visible read, which is also why capture and config sync work at a greeter while input does not. So make the fresh read agree with the cache. It keeps the property the uinput gate wants, a lookup that cannot be stale, and it still compares the peer against the uid of the session that owns seat0 -- which at a greeter is the greeter. * fix: settle the DRM probe before routing login to X11, and read seat0 fresh Two findings from the #15792 review, both verified against the code: - drm_login_screen_seat0_username asked the cached probe, so a client arriving before warm_availability publishes its verdict read "no DRM" and, with allow-linux-headless=Y, try_start_x_session could start Xorg over a live Wayland greeter. Ask the probing form instead, and only after the cheap seat0 read says a Wayland greeter is actually there: a bounded definitive verdict is affordable on a login-time path. - get_supported_display_seat0_username trusted the seat0 values cached in DesktopManager::new(), which go stale across a logout or a fast user switch: a stale non-greeter name skipped the greeter probe and was returned as the supported display owner. Read seat0 fresh on every query; every call site is connection-time, so the extra loginctl read is cheap. Regression-tested on a real sddm Wayland greeter: capture streams the greeter, the RustDesk password dialog is the only prompt, and five typed characters appeared in the greeter password field over uinput with zero "Rejected unauthorized connection" lines in the service log. * fix: ask the greeter compositor for the multi-monitor layout The display arrangement and the pointer mapping were wrong at a multi-monitor login screen, and the mechanism is measured on a two-head virtio VM: DRM has no origins, so every display was advertised at (0,0) (a stacked arrangement on the client), and the uinput range was taken from the union of the DRM modes while the compositor had arranged the outputs side by side. Both came from the same premise, written before the hbb_common socket fallback existed: "a login screen has no compositor to ask". wayland_outputs_askable() skipped the wl_output augmentation at any greeter, and update_uinput_resolution took the DRM union directly. The premise is false now: a greeter runs a compositor, and the socket fallback reaches it with no environment variables, measured answering two outputs at the VM greeter while the old gate was still routing around it. Drop the gate and take the compositor-first path everywhere. Where the fallback cannot answer, the output list comes back empty and both call sites degrade to exactly the old behavior, so a build against an older hbb_common is unchanged. * fix: augment a single display too, and probe the desktop rect off the executor Two follow-ups from the automated re-review of |
||
|
|
d407db9fae |
fix(client): allow switch-sides back-connection in incoming-only mode (#15780)
* fix(client): allow switch-sides back-connection in incoming-only mode "Switch sides" makes the controlled client run `--connect <peer> --switch_uuid <uuid>`, which Client::_start rejected outright in incoming-only custom clients, so the feature silently dropped the session and never switched. Exempt exactly that back-connection: a default-conn session carrying a switch uuid may proceed. The uuid is then verified against the local server process in handle_hash(); if it is missing there (forged or expired), an incoming-only client now aborts with an error instead of falling through to password login, so the outgoing-connection restriction cannot be bypassed with a crafted --switch_uuid. Fixes rustdesk/rustdesk#11200 (discussion) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(client): validate switch-back grants before connecting - check pending peer/UUID grants before bypassing incoming-only mode - close rejected switch-back connections and suppress retries - keep grant consumption in handle_hash and test non-consuming checks Signed-off-by: 21pages <sunboeasy@gmail.com> * fix(client): prevent switch-back UUID reuse - claim pending switch-back grants before connecting - retain claimed grants to reject duplicate requests - bind authorization to the peer ID and UUID - use a shared TTL for switch-back grants Signed-off-by: 21pages <sunboeasy@gmail.com> * fix(client): defer switch UUID consumption until authentication Signed-off-by: 21pages <sunboeasy@gmail.com> * fix(client): reject repeated hash login in incoming-only mode Signed-off-by: 21pages <sunboeasy@gmail.com> --------- Signed-off-by: 21pages <sunboeasy@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: 21pages <sunboeasy@gmail.com> |
||
|
rustdesk
|
594e63805c | harden login request retry |