A build without displayif now has no JPEG decoder at all, and nothing says so

[bdbarnett]

Consequence of jpegio Phase 2 (2026-09-03), filed so it is not discovered by a user.

Since lvgl-bindings aa6c6bc, LV_USE_TJPGD is 0 on MicroPython, so LVGL's built-in JPEG decoder is not compiled into lv_init. The replacement is displayif's jpegio, which registers its own TJpgDec with LVGL through lv_image_decoder_create when the two usermods are built together. That was the point: one TJpgDec per firmware instead of two, without carrying a fork of LVGL.

The gap: lvgl-micropython built alone (no displayif in USER_C_MODULES) now decodes PNG (lodepng) and LVGL's own BIN format, and silently does nothing with a JPEG. lv.image simply draws nothing. Before this change such a build decoded JPEGs. Nothing in the build output or the README says the decoder moved.

This is exactly what lvgl-bindings' own linux-integration.yml micropython job builds, so our CI builds the JPEG-less configuration and is happy with it.

Options, in rough order of preference:

1. A README section: "JPEG images need the displayif usermod (it owns the TJpgDec decoder); without it lv.image will not draw a JPEG." Cheapest, honest, no build-system change.
2. A build-time note printed by micropython.mk/micropython.cmake when no displayif sibling is present.
3. Nothing, on the grounds that anyone wanting images already builds displayif. Weakest: the failure is silent at runtime, not at build time.

Related: PyDevices/displayif#23, PyDevices/lvgl-bindings#14. displayif's side of the same seam is already covered: jpegio.register_lvgl_decoder() and jpegio.lvgl_decoders() exist on every build and say what happened when the decoder was not compiled in.