[andrewleech]

Summary

MicroPython 1.29 renamed mp_obj_int_to_bytes_impl() to mp_obj_int_to_bytes() and changed its signature. The generated LVGL binding still called the old helper, so it no longer builds against current MicroPython. This updates the generated call while retaining the older API path for MicroPython versions before 1.29.

lv_micropython#106 upgrades the pinned MicroPython from v1.24.1 to v1.29.0 and needs this fix for its LVGL Unix build. The guard keeps the existing helper for the current v1.24.1 pin and selects the new API at v1.29.0, so #411 can merge before the pin is upgraded.

Testing

Built the binding into an i.MX RT1176 firmware against MicroPython v1.29.0; it links. The pre-v1.29 branch was checked against a v1.24 header and selects the old call. Reviewers also built the Unix usermodule against a current MicroPython checkout reporting sys.implementation.version == (1, 29, 0, 'preview') and exercised imports, object creation and event callbacks. The current API test workflow still has three failures because lv.is_initialized is missing, which this PR does not add.

Generative AI

I used generative AI tools when creating this PR, but a human has checked the code and is responsible for the code and the description above.

[o-murphy]

Confirming independent testing on the unix port (you noted you hadn't tried it): rebuilt ports/unix against current MicroPython master (5aaa6d17) via USER_C_MODULES with this exact fix applied - builds clean, import lvgl works, and a smoke test creating obj/button/label with add_event_cb/send_event runs correctly end to end. The #if MICROPY_VERSION >= MICROPY_MAKE_VERSION(1, 29, 0) guard is the right call - I'd independently landed on the same mp_obj_int_to_bytes(obj, sizeof(val), (byte*)&val, big_endian, false, false) replacement call but without the backward-compat guard, so this version is the better fix.

Side note: this is very likely also why the tests/api CI jobs (basic.py, basic_indev.py, basic_slider.py) have been failing on master since run 28447459670 (2026-06-30, six days after the breaking MicroPython commit) - same root cause, worth a rebase/rerun once this merges to confirm.

[o-murphy]

@andrewleech @pi-anl

Confirming this also fixes the unix port, since the description notes it wasn't tested there.

Applied the same guard to gen/gen_mpy.py and gen/lv_mpy_example.c and built ports/unix as a USER_C_MODULES usermod against a current MicroPython checkout (sys.implementation.version == (1, 29, 0, 'preview')), which is right at the MICROPY_VERSION >= MICROPY_MAKE_VERSION(1, 29, 0) boundary this PR adds, so the new mp_obj_int_to_bytes() branch is the one actually compiled and exercised, not the old one.

Built and ran it repeatedly (dozens of rebuilds over the last day), including live LVGL UI code -- buttons, labels, style colors, indev state -- that routes through mp_obj_get_ull() in the generated binding. No link errors, no runtime issues.

So: confirmed working on unix in addition to the mimxrt testing already in the description.

[o-murphy]

Confirming this also fixes the unix port (the description notes it wasn't tested there): built ports/unix as a USER_C_MODULES usermod against a current MicroPython checkout (sys.implementation.version == (1, 29, 0, 'preview')), right at the MICROPY_VERSION >= MICROPY_MAKE_VERSION(1, 29, 0) boundary this PR adds, so the new mp_obj_int_to_bytes() branch is the one actually compiled and exercised. Built and ran it repeatedly over the last few days, including real LVGL UI code (buttons, labels, style colors, indev state) that routes through mp_obj_get_ull() in the generated binding - no link errors, no runtime issues.

Worth calling out how live this bug currently is: CI on master is failing this exact way on all four ports right now - run 30154151496, 4 days ago, unix/stm32/rp2/esp32 all hit implicit declaration of function 'mp_obj_int_to_bytes'; did you mean 'mp_obj_int_to_bytes_impl'?. That run was even built against 7ee268e ("fix: update mp_obj_int_to_bytes implementation for correct byte conversion"), a different attempt at this same problem - it doesn't actually resolve it, same error either way. None of this shows up as red because the workflow sets continue-on-error: true per job.

We've got a follow-up PR (#413) building on top of this one - adds LVGL's native Wayland driver, and separately fixes a regression that's kept every desktop window driver (SDL included) out of the Python bindings since May. Rebasing that once this lands.

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[cubic-dev-ai]

2 issues found across 4 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="micropython.mk">

<violation number="1" location="micropython.mk:93">
P2: This switches the generator input from `lvgl_private.h` to `lvgl.h`, so private LVGL symbols are now only generated when `LV_USE_PRIVATE_API` is enabled. The default `lv_conf.h` enables it, so the default build is fine, but a user config that disables it will silently drop those bindings. Please note this change in the PR description, since it is not covered by the stated purpose of the PR.</violation>
</file>

<file name=".github/workflows/micropython_lvgl_ci.yml">

<violation number="1" location=".github/workflows/micropython_lvgl_ci.yml:91">
P2: This removes the LVGL user module from the ESP32 build, so the job no longer compiles the binding. Restore the `USER_C_MODULES=../../user_modules/lv_binding_micropython/micropython.cmake` argument or include the module another way.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: This switches the generator input from lvgl_private.h to lvgl.h, so private LVGL symbols are now only generated when LV_USE_PRIVATE_API is enabled. The default lv_conf.h enables it, so the default build is fine, but a user config that disables it will silently drop those bindings. Please note this change in the PR description, since it is not covered by the stated purpose of the PR.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At micropython.mk, line 93:

<comment>This switches the generator input from `lvgl_private.h` to `lvgl.h`, so private LVGL symbols are now only generated when `LV_USE_PRIVATE_API` is enabled. The default `lv_conf.h` enables it, so the default build is fine, but a user config that disables it will silently drop those bindings. Please note this change in the PR description, since it is not covered by the stated purpose of the PR.</comment>

<file context>
@@ -90,7 +90,7 @@ $(LVGL_MPY): $(ALL_LVGL_SRC) $(LVGL_BINDING_DIR)/gen/gen_mpy.py
 		-I $(LVGL_BINDING_DIR)/stubs/include \
 		$(CFLAGS_USERMOD) \
-		$(LVGL_DIR)/lvgl_private.h | $(LV_PP_FILTER) > $(LVGL_PP)
+		$(LVGL_DIR)/lvgl.h | $(LV_PP_FILTER) > $(LVGL_PP)
 	$(Q)$(PYTHON) $(LVGL_BINDING_DIR)/gen/gen_mpy.py -M lvgl -MP lv -MD $(LVGL_MPY_METADATA) -E $(LVGL_PP) $(LVGL_DIR)/lvgl.h > $@
 
</file context>

[cubic-dev-ai]

P2: This removes the LVGL user module from the ESP32 build, so the job no longer compiles the binding. Restore the USER_C_MODULES=../../user_modules/lv_binding_micropython/micropython.cmake argument or include the module another way.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At .github/workflows/micropython_lvgl_ci.yml, line 91:

<comment>This removes the LVGL user module from the ESP32 build, so the job no longer compiles the binding. Restore the `USER_C_MODULES=../../user_modules/lv_binding_micropython/micropython.cmake` argument or include the module another way.</comment>

<file context>
@@ -88,7 +88,7 @@ jobs:
         source tools/ci.sh && ci_esp32_idf_setup
         source tools/ci.sh && ci_esp32_build_common
-        make -C ports/esp32 BOARD=ESP32_GENERIC_S3 USER_C_MODULES=../../user_modules/lv_binding_micropython/micropython.cmake
+        make -C ports/esp32 BOARD=ESP32_GENERIC_S3
 
     # Unix port
</file context>

Suggested change

	make -C ports/esp32 BOARD=ESP32_GENERIC_S3
	make -C ports/esp32 BOARD=ESP32_GENERIC_S3 USER_C_MODULES=../../user_modules/lv_binding_micropython/micropython.cmake