The touchscreen hardware itself seems to work correctly, but LVGL/launcher input does not.

[Zarfiks]

Title: [Bug] MaixCAM Pro: Touchscreen works in direct MaixPy test but fails in Launcher/LVGL menu

Describe the bug

On the MaixCAM Pro, the touchscreen hardware works perfectly when accessed directly via MaixPy, but fails to register inputs correctly within the standard launcher/LVGL menu UI.

Taps do not trigger expected actions, and the UI appears non-responsive. However, further investigation suggests this is not a hardware issue, but rather an integration bug involving LVGL input handling, specifically related to the read0() vs. read() methods in the pointing device driver.

Environment

• Board: MaixCAM Pro
• MaixPy version: 4.12.4
• MaixCDK: Custom build from source
• Affected UI: Launcher / Menu

Expected Behavior

• The launcher/menu should respond to touch normally.
• Touch press/release should map correctly into LVGL pointer events.
• Behavior in the launcher should be consistent with direct touchscreen tests.

Actual Behavior

• The standard launcher/menu does not handle touch correctly.
• A direct touch script works flawlessly (coordinates, press detection, display updates).
• Interesting Edge Case: When working on a custom folder/category UI, I noticed that if I kill the active menu process while the custom UI remains visible, touch input suddenly starts working. This strongly points to an event routing or state handling conflict in the main process.

Working Direct Test (MaixPy)

This simple test works correctly, confirming the hardware and basic driver are fine:

from maix import touchscreen, app, time, display, image

ts = touchscreen.TouchScreen()
disp = display.Display()

img = image.Image(disp.width(), disp.height())

# draw exit button
exit_label = "< Exit"
size = image.string_size(exit_label)
exit_btn_pos = [0, 0, 8*2 + size.width(), 12 * 2 + size.height()]
img.draw_string(8, 12, exit_label, image.COLOR_WHITE)
img.draw_rect(exit_btn_pos[0], exit_btn_pos[1], exit_btn_pos[2], exit_btn_pos[3], image.COLOR_WHITE, 2)

def is_in_button(x, y, btn_pos):
    return x > btn_pos[0] and x < btn_pos[0] + btn_pos[2] and y > btn_pos[1] and y < btn_pos[1] + btn_pos[3]

while not app.need_exit():
    x, y, pressed = ts.read()
    if is_in_button(x, y, exit_btn_pos):
        app.set_exit_flag(True)
    img.draw_circle(x, y, 1, image.Color.from_rgb(255, 255, 255), 2)
    disp.show(img)

Investigation & Hypothesis

I traced the LVGL touch input path to components/3rd_party/lvgl/driver/pointing_device.cpp.

I noticed that the LVGL input code uses read0(), whereas my working direct script uses read().

• Hypothesis: read0() may expose a raw/lower-level state, potentially updating coordinates before the pressed state is stable. As a result, LVGL receives coordinates without a correct PRESSED state, causing the menu logic (which relies on stable press/release transitions) to fail.
• Local Fix: I locally patched pointing_device.cpp to use read() instead of read0(), and the UI behavior seemed correct.

Questions for Maintainers

1. Is read0() specifically intended to be the correct API for LVGL touch input on the MaixCAM Pro, or is this an oversight?
2. What is the exact semantic difference between read0() and read()? (e.g., raw vs. processed/stable state).
3. Is it a known issue that the launcher/menu process might consume or mishandle touch events, given that killing it restores touch functionality in a background UI?
4. Would you accept a PR changing the LVGL input from read0() to read(), or does the LVGL bridge need to cache the last valid coordinates/state differently?

Data I can provide upon request

• Exact base firmware image name/date and commit hashes (MaixPy & MaixCDK).
• My patched pointing_device.cpp.
• Debug logs comparing read0() and read().
• Video demonstrating the direct script working, the normal launcher failing, and the custom UI working after the menu process is killed.