LSUIElement processes are prime App Nap candidates when idle, and
once App-Napped macOS throttles user-space timers. The ping_pong
keepalive loop in src/connect.rs uses tokio sleeps with a 2 s
ping cycle; if those sleeps slip past the peer's 1 s grace the
peer's watchdog tears down the DTLS connection and the daemon
reconnects from a fresh ephemeral port on the next event — the
"silence-then-new-source-port" pattern visible in the peer's logs
after long idle.
Setting NSAppSleepDisabled keeps the timers running on schedule
across long idle windows. No code-side changes; the key is
honored by macOS for the lifetime of the process.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The kernel disables a session-level CGEventTap when its callback
runs longer than ~1 s on a single event — typical causes are heavy
load, scheduler contention, or the process being briefly suspended
(App Nap on a long idle, debugger pause). It is not a fatal
condition: Apple's documented recovery is to call CGEventTapEnable
and resume processing. Before this change the tap stayed dead until
the user manually clicked Re-enable from the menubar.
Stash the tap's mach port pointer in an Arc<OnceLock<usize>> set
immediately after CGEventTap::new returns, and on
TapDisabledByTimeout call CGEventTapEnable from the callback to
revive the tap while preserving capture state — the user doesn't
see the cursor pop back to the local screen mid-session for a
transient slow callback.
TapDisabledByUserInput keeps the existing teardown path: those
causes (TCC Accessibility revoked mid-session, secure-input mode,
explicit kill) are not safely recoverable from inside the
callback, and the existing fallthrough-fix from
59d9e45 / d1e963e still applies there.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
When the user pressed the release-bind chord (typically all four
modifiers) the down events for the chord were forwarded to the peer
while capture was active, but the matching up events arrived after
the local tap flipped to passthrough and were never forwarded. The
peer was left with phantom held modifiers until either its watchdog
ran (1+ s) or the Leave message was processed — and Leave is sent
over UDP/DTLS and can be lost.
Drain the capture's pressed_keys set in release_capture and emit a
KeyboardEvent::Key{state: 0} for every still-held key, plus a
zeroed KeyboardEvent::Modifiers, before sending Leave. The receiver
already maintains pressed_keys per handle and processes these
key-up events through its normal path, so no protocol change is
required and an unmodified peer picks up the fix automatically.
The receiver-side release_keys safety net stays in place for the
genuine packet-loss / disconnect-without-Leave cases.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replaces the narrow LAN_MOUSE_RELAUNCHED signal with an inverted
opt-out: present the main window on every macOS launch unless
LAN_MOUSE_HIDDEN=1 is in the environment.
User feedback: on any manual launch (Dock, Finder, `open`, post-
grant relaunch) the window should come up so the user has a visible
confirmation the app is alive and can see its current state. A
hidden-to-menu-bar-only launch should be opt-in for a LaunchAgent /
login-item configuration, not the default.
LaunchAgent plists can set the env via `EnvironmentVariables` and
`RunAtLoad=true` for a quiet boot launch.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After the user clicks Relaunch on the warning row, the new instance
started hidden in the menu bar — no visible confirmation that the
relaunch actually worked. Present the window on that specific
launch so the user sees the app come up healthy.
Mechanism: relaunch_bundle() sets LAN_MOUSE_RELAUNCHED=1 via
`open --env` when spawning the new instance. build_ui reads the
env var and calls window.present() only when it's set. Normal
fresh launches (from Finder / Dock / Launchpad / any other
Launch Services path) continue to start hidden in the menu bar.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Even with the earlier event-tap-callback cleanup fix, revoking
Accessibility in System Settings while Lan Mouse was running with
an active capture tap could still leave system input wedged — clicks
and keypresses silently dropped until the app was force-quit.
The reliable fix is to not rely on in-process tap teardown at all.
When AX is revoked:
- The kernel guarantees an active CGEventTap is dismantled when the
owning process exits.
- SIGINT+wait on the daemon child (main.rs already does this on
GUI exit) drops the daemon's tap and restores the cursor.
So: continuously poll AX state (1-second GLib timer, replacing the
one-shot grant watcher), and on a revoke transition call
`app.quit()`. Input is restored within ~1-2 seconds regardless of
capture state — no force-quit required, no stuck cursor, no silently
consumed events beyond the brief window until the poller fires.
The grant-transition case is preserved: on a 0→1 flip the warning
row swaps to its "relaunch required" state, same as before.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
When the user revokes Accessibility in System Settings while Lan
Mouse is in a captured session (cursor on a remote client), the
session-level event tap receives `TapDisabledByUserInput`. The
previous flow was:
1. Callback sends `ProducerEvent::EventTapDisabled` to notify_tx.
2. Callback falls through the `current_pos.is_some()` branch and
returns `CallbackResult::Drop` — *this very event*, plus any
racing callback still in flight, get `set_type(Null)`'d and
consumed.
3. Outer task calls `handle_producer_event(..).unwrap_or_else(|e|
log::error!(..))` — the `EventTapDisabled` error is just logged,
the loop keeps running, `current_pos` stays `Some`, cursor
stays hidden.
Net effect for the user: mouse motion keeps working (pass-through
when the tap is fully dead), but clicks and keypresses in the brief
disable window silently disappear, and the cursor is still hidden
where the captured session left it. Input looks broken until the
app is force-quit.
Fix:
- In the callback, when `TapDisabled*` fires, clear `current_pos`
and `CGDisplay::show_cursor` synchronously, then return
`CallbackResult::Keep` so this event (and any subsequent racing
one) can't hit the drop branch.
- Mirror the cleanup in `handle_producer_event`'s
`EventTapDisabled` arm so even if the outer task only logs the
error, state is still released.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The cut-off toast UX ("Accessibility granted. Relaunch Lan Mouse so
capture and emulat…") was unreadable in a compact window and split
the "grant" and "relaunch" flows into two disconnected surfaces. Fold
everything into the existing warning row with state-dependent content:
- AX missing:
title = "input capture is disabled"
subtitle = "grant Accessibility permission to enable"
button = "Grant" → opens System Settings → Accessibility
- AX granted, daemon still bailed:
title = "relaunch required"
subtitle = "Accessibility granted — restart to activate capture
and emulation"
button = "Relaunch" → spawns a fresh bundle via `open` after
a 1s delay, then quits.
- Both active: row hidden.
The emulation_status_row is kept hidden on macOS because capture and
emulation share the same TCC gate — a single row is sufficient and
two identical-looking warnings were noisy. `handle_emulation` still
exists for the non-macOS platforms where the rows are distinct.
Side effects:
- `relaunch_bundle` moved from lib.rs to macos_privacy so imp.rs can
call it from the row button handler.
- AX watcher callback shrinks to `window.present()` +
`refresh_capture_emulation_status()`; the toast-based dialog is
gone along with its helper.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The yellow "input capture is disabled" / "input emulation is disabled"
rows were showing simultaneously with the Relaunch toast after a
live AX grant, double-prompting the user for the same action.
Gate the warning row visibility on Accessibility actually being
missing: when AX is granted but capture/emulation remain inactive,
we're in the pending-relaunch state and the Relaunch toast is the
authoritative prompt. Trigger a status refresh from the AX watcher
so the rows hide the instant AX flips to granted, not when the
daemon next reports status.
On non-macOS platforms the visibility logic is unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Now that we always route Reenable clicks to the Accessibility pane on
macOS 13+ (AX transitively covers Input Monitoring listen-only and
Post Event, and the bundle isn't listed in the separate panes anyway),
the CapturePane / EmulationPane enums and their non-Accessibility
variants are dead weight. Remove them along with:
- `missing_capture_pane` / `missing_emulation_pane`
- `open_input_monitoring_settings` / `open_post_event_settings`
- `input_monitoring_granted` / `post_event_granted` preflight wrappers
- the `CGPreflightListenEventAccess` / `CGPreflightPostEventAccess`
FFI declarations in lan-mouse-gtk (the daemon crates keep their own)
`handle_capture` / `handle_emulation` collapse to a single helper that
opens the Accessibility pane if AX is missing, otherwise just retries.
`ensure_listed_in_input_monitoring` is kept because it still has a
side effect on macOS 13/14, where Input Monitoring is a separately-
granted category.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The daemon subprocess initializes at startup and bails immediately if
Accessibility is missing ("accessibility permission is required"). If
the user then grants AX mid-session via the system prompt, the daemon
has no way to retry from its bailed state — capture and emulation
stay dead until the next restart. Make the GUI watch for the AX
transition and surface a toast with a "Relaunch" button that quits
the app and spawns a fresh instance via Launch Services.
While here:
- Route capture/emulation "missing pane" fallback to the Accessibility
pane instead of the Input Monitoring / Post Event panes when AX is
already granted. On macOS 13+ those separate grants auto-confer via
Accessibility and the bundle typically isn't listed in the IM pane
at all, so the old navigation was a dead end.
- Reword the status-row subtitles so the action is clearer: the user
now sees "click Reenable to grant permission" instead of a generic
"required for outgoing connections".
- Bump libadwaita feature flag to v1_2 for AdwToast button signals.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The previous fix created the config directory but left config.toml
absent on a first launch, which surfaced as two "No such file or
directory (os error 2)" warnings (one from the main process, one
from the spawned daemon child) and left the app starting up with
config_toml=None until the GUI persisted something.
Write ConfigToml::default() to the path if it doesn't exist, so
every entry point — GUI main, spawned daemon, CLI, test commands
— gets a concrete file to read, and first-launch logs stay clean.
Also reorders Config::new() so both the directory creation and the
file bootstrap run before the first read attempt, eliminating the
warning at the source rather than hiding it.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
On macOS the three TCC grants (Accessibility, Input Monitoring, Post
Event) live in separate Privacy panes. Before this change the
"Reenable" row sent the user to Accessibility regardless of which
grant was actually missing, and the daemon's own permission checks
re-fired the Accessibility prompt on every retry.
- lan-mouse-gtk/src/macos_privacy.rs: new module that exposes silent
preflight checks (AXIsProcessTrusted, CGPreflightListenEventAccess,
CGPreflightPostEventAccess), per-pane URL-scheme navigation, and
a Once-guarded fire_initial_prompts() called from build_ui. The
initial-prompt path only fires the Accessibility prompt if AX is
missing and then returns; secondary registrations run only after
AX is granted, which prevents a double Accessibility alert on
Sequoia where Post Event is nested under Accessibility.
- Input Monitoring registration attempts CGEventTapCreate at
kCGSessionEventTap (not kCGHIDEventTap) so a failure surfaces as
an Input Monitoring signal rather than triggering an Accessibility
prompt as a side effect.
- lan-mouse-gtk/src/window/imp.rs: handle_capture / handle_emulation
switch on the missing-pane enum and navigate to the specific pane
via x-apple.systempreferences:... URLs before re-requesting.
- lan-mouse-gtk/resources/window.ui: pill class on the Reenable
buttons so the hover padding matches the rest of libadwaita.
- input-capture/src/macos.rs, input-emulation/src/macos.rs: make
request_*_permission() a silent preflight (AXIsProcessTrusted /
CGPreflightListenEventAccess / CGPreflightPostEventAccess), so the
daemon no longer fires TCC prompts on retry — all prompting is
owned by the GUI.
- input-capture/src/error.rs, input-emulation/src/error.rs: new
error variants so the GUI can distinguish missing-AX from
missing-IM / missing-PostEvent for pane routing.
Verified on macOS 15.5: first launch fires a single AX prompt;
second launch (AX granted) registers under Input Monitoring via the
session-tap attempt and requests Post Event. Sequoia auto-grants the
listen-only path via AX so the IM list may stay empty, which is the
intended OS behavior and no longer blocks capture.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Ship Lan Mouse on macOS as an accessory app (no Dock icon, no main
window on launch) with a status-bar item for show/quit. Closing the
window hides it instead of quitting so the menu bar stays the primary
surface.
- build-aux/macos-lsui-element.plist: LSUIElement=true plus
NSInputMonitoringUsageDescription and NSAppleEventsUsageDescription
(merged into Info.plist via cargo-bundle's osx_info_plist_exts).
- lan-mouse-gtk/src/macos_status_item.rs: NSStatusItem setup via raw
objc_msgSend FFI. Loads a bundled 22pt PNG as a template image so
it auto-tints for light/dark menu bars.
- scripts/makeicns.sh: emit Contents/Resources/menubar-template.png
from the existing SVG.
- scripts/copy-macos-dylib.sh: flatten cargo-bundle's preserved
target/ subdir under Resources so NSBundle pathForResource: finds
the template image.
- lan-mouse-gtk/src/lib.rs: register the new modules, set up a
Cmd+Q-wired quit action, configure bundle env vars (schemas,
XDG_DATA_DIRS, GTK_DATA_PREFIX) when running from inside the .app,
and filter the known upstream Gtk theme-parser warning spam.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
notify::Watcher fails on macOS if the config directory doesn't
exist. Create it with create_dir_all before calling config.watch().
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The previous script generated a 1024x1024 icon from the SVG with no
squircle background and no transparent padding, which caused macOS
to render the Dock/Finder icon noticeably larger than first-party
apps and without the rounded-square shape users expect.
Rewrite the script to follow Apple's Big Sur+ icon template:
- 1024x1024 canvas
- 824x824 white squircle, centered (100px transparent padding outside)
- Artwork rendered at 560x560, centered inside the squircle
- Squircle corner radius ~22.5% of the squircle size
Use rsvg-convert to rasterize the SVG (ImageMagick crops this
particular SVG when rendering directly), then composite onto the
squircle background in two steps for reliability.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
On macOS the Adwaita icon theme is not installed by default, so
symbolic icons (edit-copy, auth-fingerprint, network-wired,
dialog-warning, etc.) render as the "image-missing" placeholder.
Bundle the symbolic SVGs used by the GTK frontend into the embedded
gresource so the app is self-contained and doesn't depend on any
system-installed icon theme. The existing
`IconTheme::add_resource_path("/de/feschber/LanMouse/icons")` call
already tells GTK to search this prefix, so no code changes are
needed.
Icons are sourced from Adwaita and placed under the standard
`scalable/{actions,devices,places,status}/` hicolor layout.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(macos): forward back/forward mouse buttons in capture and emulation
OtherMouseDown/Up events on macOS carry a button number field that
distinguishes middle (2), back (3), and forward (4) buttons. The
capture backend was unconditionally mapping all OtherMouse events to
BTN_MIDDLE, silently dropping back/forward. The emulation backend had
no match arms for BTN_BACK/BTN_FORWARD, causing them to be dropped
with a warning.
Fix capture by reading MOUSE_EVENT_BUTTON_NUMBER and mapping 3->BTN_BACK,
4->BTN_FORWARD. Fix emulation by adding match arms for BTN_BACK/BTN_FORWARD
and setting MOUSE_EVENT_BUTTON_NUMBER on the emitted CGEvent so macOS
apps receive the correct button identity.
* fix(macos): track button state and double-clicks by evdev code instead of CGMouseButton
Back, forward, and middle buttons all map to CGMouseButton::Center on
macOS, which caused them to share a single pressed-state boolean and
alias in double-click detection. Replace the ButtonState struct with a
HashSet<u32> keyed by evdev button code so each button is tracked
independently.
---------
Co-authored-by: Ferdinand Schober <ferdinandschober20@gmail.com>
For a session to actually persist, we need to request a persistence mode
which we already do. The portal then returns a restore-token (in the
form of an uuid) to us as part of the response to Start.
This token must then be passed into the *next* session during
SelectDevices to restore the previous session.
The token is officially a single-use token, so we need to overwrite it
every time. In practise the current XDP implementation may re-use the
token but we cannot rely on that.
Reading and writing the token is not async since we expect them to be
uuid-length.
Closes#74.
