Skip to content

fix: guard ARM-specific code behind NORNS_DESKTOP for x86 desktop builds#1876

Open
blainemotsinger wants to merge 1 commit into
monome:mainfrom
blainemotsinger:fix-desktop-build
Open

fix: guard ARM-specific code behind NORNS_DESKTOP for x86 desktop builds#1876
blainemotsinger wants to merge 1 commit into
monome:mainfrom
blainemotsinger:fix-desktop-build

Conversation

@blainemotsinger
Copy link
Copy Markdown

The --desktop build mode was incomplete: ssd1322.c (NEON intrinsics), gpio.c, and -mfpu=neon were always compiled, breaking x86_64 builds. Properly exclude ARM hardware drivers and flags when building for desktop.

The --desktop build mode was incomplete: ssd1322.c (NEON intrinsics),
gpio.c, and -mfpu=neon were always compiled, breaking x86_64 builds.
Properly exclude ARM hardware drivers and flags when building for desktop.
Copy link
Copy Markdown
Member

@tehn tehn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for looking into this.

Would it not be simpler and cleaner to instead put all of the defines inside of ssd1322.c? So all the includes could stay, functions could get called but they'd just be returned.

Have you had success running the desktop build?

@blainemotsinger
Copy link
Copy Markdown
Author

Thanks for looking into this.

Would it not be simpler and cleaner to instead put all of the defines inside of ssd1322.c? So all the includes could stay, functions could get called but they'd just be returned.

yeah, happy to work on those changes. I'll try to get into it over this coming weekend.

Have you had success running the desktop build?

yup, it seems to have built fine.

I'm not entirely sure my hacky attempt at enabling the keyboard controls were correct, so didn't get to test it out extensively. I got the interface to load and could move around, minimally. as for manipulating input sound, I didn't get that far.

@Dewb
Copy link
Copy Markdown
Member

Dewb commented Feb 23, 2026

I did a little riffing on this topic over here but some specific comments that apply here:

It would be good to move away from NORNS_DESKTOP directly in source because what "desktop mode" is and means has not really been defined yet. As @tehn says, lines of code that use ARM NEON intrinsics should be individually guarded by an architecture flag; ssd1322 features should be gated by what displays are enabled. (This display-enabling may be already handled by matronrc, so should we let it be buildable regardless or platform? For example, what if someone wants to run norns on an Intel NUC with a ssd1322 attached? With the proper flagging they'd just need to implement the non-NEON vector ops.)

Similarly the GPIO stuff can be gated by a "has gpiod" flag, the key stuff by an SDL flag, etc.

Then the current NORNS_DESKTOP can be an expression that sets the appropriate architecture/feature defines for the user's desktop platform.

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.

3 participants