Tauri desktop build via a Hardware Abstraction Layer - #97
Open
KeyboardNoMouse wants to merge 4 commits into
Open
Tauri desktop build via a Hardware Abstraction Layer#97KeyboardNoMouse wants to merge 4 commits into
KeyboardNoMouse wants to merge 4 commits into
Conversation
Author
|
Close the PR if u dont like the changes |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Desktop app (Tauri)
src-tauri/ wraps the frontend in a Tauri shell so DPI/polling-rate control works outside Chrome/Edge — where navigator.hid doesn't exist at all (Firefox, Safari) or is blocked (most embedded webviews, including Tauri's own). Hardware access goes through src/hardware/:
bridge.ts picks a transport once at startup by checking for window.TAURI_INTERNALS.
webHID.ts wraps navigator.hid directly (browser build).
native.ts proxies the same HIDDevice/HID shape over Tauri invoke() to src-tauri/src/hid/commands.rs, which talks to hardware via the hidapi crate.
Everywhere else in the app — every *-hid.ts driver, control.ts — reads hid from bridge.ts instead of touching navigator.hid. Adding a new mouse profile only ever means writing -hid.ts against the HIDDevice interface, same as before; it runs on both targets without change.
npm install
npm run desktop:dev # tauri dev — spawns vite, opens a native window
npm run desktop:build # tauri build — produces an installer in src-tauri/target
Desktop build prerequisites (not needed for npm run dev/npm run build):
A Rust toolchain (rustup) — see tauri.app/start/prerequisites.
Linux only: libudev-dev (hidapi's hidraw backend links against it) plus Tauri's own webview/build dependencies from the prerequisites page above.
macOS: the first time the app opens a mouse, macOS may prompt for Input Monitoring access under System Settings → Privacy & Security — this is an OS-level prompt, not something this app controls.
Known gap: control-app.html (the actual control panel) is currently gated by functions/_middleware.js, a Cloudflare Pages Function that checks a Supabase session cookie. That function doesn't run inside the Tauri webview — there's no Cloudflare edge runtime locally — so the desktop build as configured serves control-app.html unconditionally, bypassing the license check entirely. Decide how the desktop build should handle licensing (e.g. call /api/license/activate directly over the network and cache the resulting session) before shipping a build.
Known gap: src-tauri/src/hid/descriptor.rs parses the raw HID report descriptor into the same collections tree HIDDevice.collections exposes in a browser, since several drivers' isSupported() checks walk that tree. It was written without a Rust toolchain available to compile or test it — review it against a real descriptor dump for each supported mouse before relying on it.