fix(esp32_p4_function_ev_board): make touch init non-fatal in bsp_display_start_with_config

[vikramdattu]

Problem

bsp_display_start_with_config() currently early-returns NULL if bsp_display_indev_init() fails to initialize the GT911 touch controller:

BSP_NULL_CHECK(disp_indev = bsp_display_indev_init(disp), NULL);

On board variants that ship the EK79007 / ILI9881C display without a wired GT911, or where the GT911 I2C probe fails for any other reason (bus contention, bad reset timing, etc.), this reports the entire display path as broken even though LVGL + LCD + brightness have already been brought up successfully. bsp_display_lcd_init() registers the display with LVGL before touch init runs, so the LCD is fully usable; only touch input is missing.

In practice, applications that consume this BSP for a camera preview / video player path have no way to opt out of the touch requirement — they get an ESP_ERR_INVALID_STATE from bsp_touch_new() and lose the entire display.

Fix

Demote the touch-init failure to a warning and return the LCD display. Callers that need touch can check the returned lv_indev_t * (or the file-static disp_indev) and bail; callers that only need the display keep working.

disp_indev = bsp_display_indev_init(disp);
if (disp_indev == NULL) {
    ESP_LOGW(TAG, "Touch input init failed; continuing with display-only "
                  "(GT911 not detected or I2C probe failed)");
}

Tested

• ESP32-P4 Function EV Board v1.2 + EK79007 display, GT911 I2C probe failing → before this patch, app aborts with ESP_ERROR_CHECK failed: esp_err_t 0x103 (ESP_ERR_INVALID_STATE) from bsp_display_indev_init. With CONFIG_BSP_ERROR_CHECK=n the abort goes away but bsp_display_start_with_config still returns NULL → caller can't use the display. With this patch the function returns the LCD display and the app can render normally.
• Board with working GT911 (unchanged path): touch still initialized as before, no behaviour change.

Bumps

bsp/esp32_p4_function_ev_board 5.2.3 → 5.2.4.

[espzav]

Hi, thank you for this proposal. I am not sure if this is right. When you will use this BSP inside real project, you cannot detect touch failure.
I think, there will be better to use KConfig option to disable initialization input device.

[vikramdattu]

I have seen this bit me on EV Function board V1.2. And hence the proposal. I think even in doubtful cases where failure is captured OR not, it is still better to log the error and continue treating it benign.
Can add a Kconfig option to treat this a error return OR keep-going if you like. Serves both, you either deny moving forward or just keep going with just the display.