Skip to content

Add multi-profile support + LCD display for spacemouse enterprise#134

Open
jl1990 wants to merge 2 commits intoFreeSpacenav:masterfrom
jl1990:master
Open

Add multi-profile support + LCD display for spacemouse enterprise#134
jl1990 wants to merge 2 commits intoFreeSpacenav:masterfrom
jl1990:master

Conversation

@jl1990
Copy link
Copy Markdown

@jl1990 jl1990 commented Mar 16, 2026

Hi,

Some time ago I opened this issue: #119

I am by no means a c expert, but I've been playing with AI to try to solve my issue and create a branch that could be used (at least as an experiment) to make screen work for spacemouse enterprise.

I know there are other PRs open for multi-profile support (if they are better this can be used as an experiment or just used to integrate the LCD functionality).

This is in line with the ideas discussed in the issue mentioned before where the application will need to identify itself (otherwise we have no way to detect the application in wayland). The application will have to send a REQ_SET_APP_ID message over the Unix socket. As I understand, this will also require adding an spnav_set_app_id() function to libspnav so applications can report their identity.

Please have a look and let me know what you think

Thanks!

image image

jl1990 added 2 commits March 16, 2026 17:48
Per-application configuration profiles that auto-switch based on WM_CLASS
(X11 polling) or client-reported app_id (Wayland-compatible). Each profile
stores a full cfg copy so switching is transparent to existing code.

New protocol requests: SET_APP_ID, SET_PROFILE, GET_PROFILE for client-side
profile detection and manual override.

LCD support renders profile name and button mappings as SVG, converts to
RGB565 bitmap, compresses with zlib, and sends via USB to the SpaceMouse
Enterprise screen. Enabled with --enable-spacelcd (requires librsvg, libusb,
zlib).

Config syntax: profile "Name" class=match ... end blocks in spnavrc.
@jtsiomb
Copy link
Copy Markdown
Contributor

jtsiomb commented Mar 16, 2026

Thank you for taking a stab at the LCD issue. There are multiple reasons why I'm not going to merge this version of the code, but it's still going to be useful as an example and starting point for a different implementation. So I'll leave this pull request open, as a reminder, to hopefully set aside some time and get this done.

The most important reasons for not merging this pull request at this point are:

  • dependency to cairo is unacceptable.
  • dependency to zlib is probably ok, but I'd like to investigate if it's really necessary.
  • application profiles is a subject fraught with corner cases, and I have not figured out a good way to approach it yet.
  • any code produced by LLMs would need extremely careful line by line review, which I can't do right now. And when I find that time, I'd rather just spend it writing it from scratch, instead of trying to find all the insanity the LLM imbued it with.

Thanks again for the effort though. And feel free to post here to remind me again in the future, in case I forget to get back to this, which is very likely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants