Skip to content
This repository was archived by the owner on Oct 19, 2026. It is now read-only.

jpegio builds without LVGL - #47

Merged
bdbarnett merged 1 commit into
mainfrom
fix/jpegio-without-lvgl
Oct 6, 2026
Merged

bdbarnett merged 1 commit into
mainfrom
fix/jpegio-without-lvgl

Conversation

@bdbarnett

Copy link
Copy Markdown
Contributor

displayif's CMake glue turned on jpegio's LVGL decoder whenever an lvgl-micropython checkout existed beside displayif on disk, not when LVGL was in the build. A build of displayif without LVGL therefore linked code calling lv_*, and failed: on an RP2040 with displayif,pygraphics,palettes,pdwidgets, 18 undefined references to lv_is_initialized, lv_image_decoder_get_next, lv_fs_read and others. jpegio was split out of LVGL to be usable without it.

  • CMake decides from this build's USER_C_MODULES, the way the make glue already did. -DJPEGIO_LVGL=ON/OFF still overrides.
  • lvgl_decoder.c includes lvgl/lvgl.h and lvgl/src/…. Those resolve through the bindings path lvgl-micropython already exports, so neither glue derives a bindings path of its own. That path was wrong whenever lvgl-micropython uses its own fetched bindings (PyDevices/lvgl-micropython, fetch_bindings.sh).

Proven 2026-10-05: unix displayif,pygraphics builds. The RP2040 set above now links. Unix with displayif,lvgl-micropython (decoder forced on) compiles the decoder against fetched bindings and imports lvgl and jpegio. An RP2350 build with displayif,lvgl-micropython builds with the decoder on.

…s modules, not by what's on disk, and includes LVGL through the bindings path lvgl-micropython already exports
@bdbarnett
bdbarnett merged commit cd6f82c into main Oct 6, 2026
2 checks passed
@bdbarnett
bdbarnett deleted the fix/jpegio-without-lvgl branch October 6, 2026 04:10
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant