mirror of
https://github.com/rustdesk/rustdesk.git
synced 2026-10-15 16:31:07 +00:00
Mariano Abad
e6103daea8
`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.