Development work for 0.0.2, merged into develop through PR #52. Physical Linux-to-Mac input sharing remains unqualified.
The local Linux checkout had fallen behind the integration branch. Before adding more code, I recovered the work already merged into develop: portal lifecycle supervision, reader initialization before capture enablement, and an explicit pinned-TLS gate. A pending native-reader PR still had a useful warning attached: its changed C code had only been checked from Windows.
That gap is now closed. The ABI v2 bridge and its isolated EIS fixture compile on Linux with strict warnings, and the reader decodes button press/release and both smooth-scroll axes. PR #48 passed its executed Linux, Windows and macOS hosted checks and is merged. That establishes software checks; it does not establish cursor movement between two computers.
A decoded click still needs somewhere to go
The next missing connection was small but consequential: the capture interface only returned movement. Buttons and scrolling could reach the native reader and then disappear before the sender. A mouse that can travel but cannot click is a remarkably elaborate laser pointer.
The new canonical capture stream carries movement, buttons and two-axis scroll together, with one increasing sequence. Linux left/right/middle codes map to the protocol's three buttons. Extra buttons are ignored rather than guessed. Existing motion-only adapters keep working through a compatibility adapter, and the 10,000-event simulator keeps its exact delivery behavior.
The portal runner uses the existing bounded sender with motion coalescing enabled. Adjacent movement can combine under pressure; button and scroll transitions keep their ordering and wait for space. No new cleartext network path is exposed.
The awkward test: stop while pressed
An isolated native EIS fixture now sends ten movements, a left press and a two-axis scroll into the actual libei bridge. The canonical stream crosses a real loopback TCP connection protected by mutually authenticated TLS 1.3 and explicit peer pins, then reaches a recording receiver.
One case sends an explicit release. Another stops emulation while the button is still down. The receiver verifies the event order and sequences, and its final cleanup releases the held button. The original caller-owned descriptor remains open until its owner closes it.
The mixed stream also stops if a separate active button or scroll device stops, pauses or disappears. Continuing movement after losing the device that owns a press would leave the receiver waiting for a release that can no longer arrive. The legacy motion-only view retains its narrower behavior.
What the checks actually prove
On the Zorin Linux x64 development host, using SDK 10.0.402 and libei/libeis 1.2.1:
- Native bridge and fixture: strict C compilation passed.
- Restore and Release CI-style build: passed, zero warnings/errors.
- .NET suite: 113 passed, zero skips, including both native EIS-to-pinned-TLS cases.
- Formatting and tracking checks: passed; nine Python tooling tests passed.
- CLI smoke: 10,000 ordered simulated movements transferred between separate processes.
The fixture uses private sockets. It never captures compositor input or moves a desktop cursor. No screenshot of a cross-machine pointer session exists from this work. The diagram above describes the verified test route rather than presenting a product interface.
What still blocks the desk-to-desk demo
First Pointer remains open. Native display bindings and consented GNOME capture need qualification. The local emergency shortcut is not implemented. macOS still needs a compatible TLS 1.3 server backend, receiver wiring and on-device injection tests. Physical buttons, scroll direction/scaling, repeated edge crossings, recovery and latency all need their own evidence.
The September hosted-CI deferral has expired. PR #52 passed its executed Linux, Windows and macOS hosted checks; the exact Foundation tag was checked separately: macOS passed, Linux stopped because the newer workflow expects a native fixture absent from the tag, and Windows failed its pinned-TLS test. That older release remains unqualified by the complete hosted matrix. A green check on today's code cannot silently qualify an older release.
The next useful milestone is a repeatable, consented physical route with an emergency exit—not a higher test count by itself.
When a shared mouse loses its connection during a drag, which recovery behavior would you expect: cancel the drag immediately, or show a brief reconnect state after releasing the button?