Skip to content

config-manager: allow helixscreen as screen_ui value#145

Open
prestonbrown wants to merge 1 commit intoOpenCentauri:mainfrom
prestonbrown:helixscreen-allowlist
Open

config-manager: allow helixscreen as screen_ui value#145
prestonbrown wants to merge 1 commit intoOpenCentauri:mainfrom
prestonbrown:helixscreen-allowlist

Conversation

@prestonbrown
Copy link
Copy Markdown

@prestonbrown prestonbrown commented Apr 15, 2026

Summary

Adds helixscreen to the VALIDATORS['ui']['screen_ui'] allowlist in config-manager so it can be selected like the other UIs already shipped in the COSMOS image.

Background

HelixScreen (https://github.com/prestonbrown/helixscreen) is already packaged as a recipe in this layer at meta-opencentauri/recipes-apps/helixscreen/ and ships in COSMOS images. However, the boot-time UI selection path is:

gui-switcher (S96) → config-manager ui screen_ui → /etc/init.d/<value> start

config-manager's hardcoded validator rejects helixscreen as an invalid value, deletes it from the parsed config, and falls back to the default (grumpyscreen). Net effect: even when an installer or the user sets screen_ui = helixscreen in /etc/klipper/config/cosmos.conf, the edit is silently dropped at validation time and grumpyscreen launches.

I noticed this while building installer support for HelixScreen on COSMOS. Without this change, the only way to get HelixScreen to auto-launch is to monkey-patch config-manager on the device — which is what our installer is currently doing as a workaround.

Test plan

  • On a CC1 running COSMOS, edit cosmos.conf to set screen_ui = helixscreen
  • Confirmed config-manager ui screen_ui reports grumpyscreen (validator deleted the value) before this change
  • After patching config-manager to add helixscreen to the allowlist, config-manager ui screen_ui reports helixscreen and gui-switcher launches HelixScreen at boot

@prestonbrown
config-manager: allow helixscreen as a screen_ui value
5b20d4d 
HelixScreen (https://github.com/prestonbrown/helixscreen) is already
packaged as a recipe in this layer (recipes-apps/helixscreen) and ships
in COSMOS images. However, gui-switcher delegates UI selection to
`config-manager ui screen_ui`, whose hardcoded VALIDATORS allowlist
rejects 'helixscreen' as an invalid value and falls back to grumpyscreen.

The result: even when an installer (or the user) sets
`screen_ui = helixscreen` in /etc/klipper/config/cosmos.conf, the
edit is silently dropped at validation time and grumpyscreen launches
at boot.

This change adds 'helixscreen' to the allowlist so it can be selected
the same way as the other shipped UIs.
prestonbrown added a commit to prestonbrown/helixscreen that referenced this pull request Apr 15, 2026
@prestonbrown
fix(installer): work around COSMOS config-manager screen_ui allowlist…
941de68 
… on CC1

The Centauri Carbon's COSMOS firmware ships /usr/bin/config-manager with
a hardcoded allowlist [grumpyscreen, guppyscreen, atomscreen] for the
screen_ui value. When an installer (or operator) sets it to 'helixscreen'
in /etc/klipper/config/cosmos.conf, the validator silently deletes the
value and falls back to grumpyscreen — meaning gui-switcher launches
grumpyscreen at every boot regardless of what we install.

Patching config-manager directly is not an option: /usr/bin lives on a
read-only squashfs (only /etc, /var/lib, and a few other paths are on
overlays). So instead, substitute /etc/init.d/grumpyscreen (writable, on
the overlay) with a thin wrapper that exec's /etc/init.d/helixscreen.
gui-switcher reads config-manager → "grumpyscreen" → runs our wrapper
→ HelixScreen launches. The original is preserved at
/etc/init.d/grumpyscreen.helix-bak and restored by the uninstaller, so
removing HelixScreen leaves a clean COSMOS install.

Upstream fix tracked at OpenCentauri/cosmos#145 — once that ships in
users' firmware, this workaround becomes a no-op (the wrapper still
works, but config-manager would also accept 'helixscreen' directly).

Also:
- Add 'unzip' to the restricted-PATH tests in test_requirements.bats —
  these regressed when commit 9d7b92f (snapmaker-u1 WiFi fix) made
  unzip a hard requirement but didn't update the curl-vs-wget tests.
- Add test_cc1_competing_uis.bats covering the wrapper substitution
  (idempotency, backup, gui-switcher delegation, missing-init no-op).
- Add test_cc1_uninstall.bats covering the restore path (.helix-bak
  rollback, cosmos.conf revert, manual override preservation).
- Re-bundle install.sh + uninstall.sh.
jamesturton
jamesturton requested changes Apr 15, 2026
View reviewed changes
Copy link
Copy Markdown
Collaborator

@jamesturton jamesturton left a comment

Choose a reason for hiding this comment

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

HelixScreen is already packaged as a recipe in this layer and ships in COSMOS images

... No doesn't, so I'm not sure what you have been testing. Helixscreen is currently unbuildable from yocto due to limitations in helixscreens build system. That needs to be fixed first before helixscreen gets added to the valid UI list.

@prestonbrown
Copy link
Copy Markdown
Author

prestonbrown commented Apr 15, 2026

image

@prestonbrown
Copy link
Copy Markdown
Author

prestonbrown commented Apr 15, 2026

You're right, that was a mistake — the recipe isn't in the layer. Withdrawing this PR.

Plan: get helixscreen yocto-buildable so it can ship in COSMOS, then re-propose the allowlist change as a follow-up.

Two questions:

  1. What specific build-system limitations did you hit? Want to fix them on the helixscreen end.
  2. Recipe in meta-opencentauri, or a separate meta-helixscreen layer we maintain?

@jamesturton
Copy link
Copy Markdown
Collaborator

jamesturton commented Apr 15, 2026

What specific build-system limitations did you hit? Want to fix them on the helixscreen end.

Yocto, or more specifically yoctos build system bitbake, sets up a cross-build environment to build apps with a highly tuned compiler. The makefile overrides a lot of what bitbake sets up, hence the build fails. You can check the specific error by trying to compile helixscreen with bitbake helixscreen.

Recipe in meta-opencentauri, or a separate meta-helixscreen layer we maintain?

Are there other projects using yocto to build their FW? The only other ones I know use buildroot. If not then it seems a bit excessive to make a new layer just for one recipe, but either option will work.

prestonbrown added a commit to prestonbrown/cosmos that referenced this pull request Apr 15, 2026
@prestonbrown
meta-opencentauri: flesh out helixscreen recipe + add libhv support
565d86e 
Replaces the 9-line helixscreen stub with a full recipe that builds, links
against system libraries (libhv, openssl, spdlog, fmt, alsa-lib, libusb1,
wpa-supplicant, libnl), and installs a runnable .ipk with SysV init hook.

Recipe files:
  - recipes-support/libhv/libhv_1.3.4.bb
      cmake-inherit recipe for ithewei/libhv tagged release. Applies a
      dns-resolver fallback patch helixscreen requires (provides
      dns_resolv_resolve symbol for statically-linked edge cases).
      SOVERSION fixup in do_install:append renames the unversioned
      libhv.so so it lands in the runtime package with proper symlinks.

  - recipes-connectivity/wpa-supplicant/wpa-supplicant_%.bbappend
      Clears DISABLE_STATIC so upstream wpa-supplicant_2.10.bb actually
      builds libwpa_client.a. Without this, any screen UI that links
      wpa_ctrl (helixscreen, guppyscreen) fails at link time with
      'cannot find -lwpa_client'. Only changes one variable, no other
      recipe behavior touched.

  - recipes-apps/helixscreen/helixscreen_0.99.bb (replaces _0.1.bb)
      DEPENDS on system libs + EXTRA_OEMAKE wires PLATFORM_TARGET=yocto
      into helixscreen's Makefile. do_install places the binary +
      supervisor helpers + runtime assets under /usr/share/helixscreen/,
      with /usr/bin/helix-screen symlink and /etc/init.d/helixscreen
      hooked via update-rc.d (S80/S20). Matches the sibling-recipe
      convention used by guppyscreen/grumpyscreen.

  - recipes-apps/helixscreen/files/helixscreen.init
      SysV init script from helixscreen's tree with HELIX_CONFIG_DIR
      export added up-front so user settings persist into klipper's
      ~/printer_data/config/helixscreen regardless of the RO squashfs
      install tree. DAEMON_DIR is sed-rewritten to the packaged path
      at install time.

Tested: bitbake helixscreen produces a clean .ipk (~93 MB) for
cortexa7t2hf-neon-vfpv4 with GNU_HASH present and split-debug extraction
working. Recipe CFLAGS/LDFLAGS flow through from bitbake into the
Makefile's YOCTO_BUILD path, which requires helixscreen@1b263444a or
newer (merging to main shortly).

Closes OpenCentauri#145 (helixscreen recipe is now present in the layer).
prestonbrown added a commit to prestonbrown/cosmos that referenced this pull request Apr 15, 2026
@prestonbrown
meta-opencentauri: flesh out helixscreen recipe + add libhv support
1397574 
Replaces the 9-line helixscreen stub with a full recipe that builds, links
against system libraries (libhv, openssl, spdlog, fmt, alsa-lib, libusb1,
wpa-supplicant, libnl), and installs a runnable .ipk with SysV init hook.

Recipe files:
  - recipes-support/libhv/libhv_1.3.4.bb
      cmake-inherit recipe for ithewei/libhv tagged release. Applies a
      dns-resolver fallback patch helixscreen requires (provides
      dns_resolv_resolve symbol for statically-linked edge cases).
      SOVERSION fixup in do_install:append renames the unversioned
      libhv.so so it lands in the runtime package with proper symlinks.

  - recipes-connectivity/wpa-supplicant/wpa-supplicant_%.bbappend
      Clears DISABLE_STATIC so upstream wpa-supplicant_2.10.bb actually
      builds libwpa_client.a. Without this, any screen UI that links
      wpa_ctrl (helixscreen, guppyscreen) fails at link time with
      'cannot find -lwpa_client'. Only changes one variable, no other
      recipe behavior touched.

  - recipes-apps/helixscreen/helixscreen_0.99.bb (replaces _0.1.bb)
      DEPENDS on system libs + EXTRA_OEMAKE wires PLATFORM_TARGET=yocto
      into helixscreen's Makefile. do_install places the binary +
      supervisor helpers + runtime assets under /usr/share/helixscreen/,
      with /usr/bin/helix-screen symlink and /etc/init.d/helixscreen
      hooked via update-rc.d (S80/S20). Matches the sibling-recipe
      convention used by guppyscreen/grumpyscreen.

  - recipes-apps/helixscreen/files/helixscreen.init
      SysV init script from helixscreen's tree with HELIX_CONFIG_DIR
      export added up-front so user settings persist into klipper's
      ~/printer_data/config/helixscreen regardless of the RO squashfs
      install tree. DAEMON_DIR is sed-rewritten to the packaged path
      at install time.

Tested: bitbake helixscreen produces a clean .ipk (~93 MB) for
cortexa7t2hf-neon-vfpv4 with GNU_HASH present and split-debug extraction
working. Recipe CFLAGS/LDFLAGS flow through from bitbake into the
Makefile's YOCTO_BUILD path, which requires helixscreen main at
ea728a294 or newer.

Refs OpenCentauri#145.
@prestonbrown prestonbrown mentioned this pull request Apr 15, 2026
Open
3 tasks
prestonbrown added a commit to prestonbrown/cosmos that referenced this pull request Apr 15, 2026
@prestonbrown
meta-opencentauri: flesh out helixscreen recipe + add libhv support
bb77853 
Replaces the 9-line helixscreen stub with a full recipe that builds, links
against system libraries (libhv, openssl, spdlog, fmt, alsa-lib, libusb1,
wpa-supplicant, libnl), and installs a runnable .ipk with SysV init hook.

Recipe files:
  - recipes-support/libhv/libhv_1.3.4.bb
      cmake-inherit recipe for ithewei/libhv tagged release. Applies a
      dns-resolver fallback patch helixscreen requires (provides
      dns_resolv_resolve symbol for statically-linked edge cases).
      SOVERSION fixup in do_install:append renames the unversioned
      libhv.so so it lands in the runtime package with proper symlinks.

  - recipes-connectivity/wpa-supplicant/wpa-supplicant_%.bbappend
      Clears DISABLE_STATIC so upstream wpa-supplicant_2.10.bb actually
      builds libwpa_client.a. Without this, any screen UI that links
      wpa_ctrl (helixscreen, guppyscreen) fails at link time with
      'cannot find -lwpa_client'. Only changes one variable, no other
      recipe behavior touched.

  - recipes-apps/helixscreen/helixscreen_0.99.bb (replaces _0.1.bb)
      DEPENDS on system libs + EXTRA_OEMAKE wires PLATFORM_TARGET=yocto
      into helixscreen's Makefile. do_install places the binary +
      supervisor helpers + runtime assets under /usr/share/helixscreen/,
      with /usr/bin/helix-screen symlink and /etc/init.d/helixscreen
      hooked via update-rc.d (S80/S20). Matches the sibling-recipe
      convention used by guppyscreen/grumpyscreen.

  - recipes-apps/helixscreen/files/helixscreen.init
      SysV init script from helixscreen's tree with HELIX_CONFIG_DIR
      export added up-front so user settings persist into klipper's
      ~/printer_data/config/helixscreen regardless of the RO squashfs
      install tree. DAEMON_DIR is sed-rewritten to the packaged path
      at install time.

Tested: bitbake helixscreen produces a clean .ipk (~93 MB) for
cortexa7t2hf-neon-vfpv4 with GNU_HASH present and split-debug extraction
working. Recipe CFLAGS/LDFLAGS flow through from bitbake into the
Makefile's YOCTO_BUILD path, which requires helixscreen main at
ea728a294 or newer.

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

Reviewers

@jamesturton jamesturton jamesturton requested changes

Requested changes must be addressed to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@prestonbrown @jamesturton