Touch detected correctly on-device, but not forwarded to server / page (no reaction at all)
Board / display setup
Board: Waveshare ESP32-S3-Touch-LCD-7B (1024x600, ESP32-S3-WROOM-1-N16R8)
Display driver: rpi_dpi_rgb (not mipi_rgb, since this board isn't a built-in supported model)
IO expander: waveshare_io_ch32v003 (from PR #10071, since this board uses the CH32V003 chip, not CH422G)
Touchscreen: gt911, address 0x5D, interrupt on GPIO4, reset via IO expander EXIO1
remote_webview version: latest from github://strange-v/RemoteWebViewClient@main
ESPHome version: 2026.7.0
What works
Display renders correctly, frames decode and update fine (confirmed via rwv_decode logs, tile sizes/timings all normal).
Touch is detected correctly at the hardware/ESPHome level. Using a temporary debug on_touch: handler on the touchscreen: block, tapping the same physical button consistently logs the same coordinates, e.g.:
TOUCH x=111 y=48
TOUCH x=115 y=46
TOUCH x=120 y=45
These coordinates correctly correspond to the on-screen button location (top-left menu area).
What doesn't work
Tapping the screen produces no reaction whatsoever on the remote page. No navigation, no highlight, nothing.
Confirmed via Chrome DevTools (chrome://inspect) connected to the RemoteWebViewServer's debug port while tapping the physical screen: zero visible reaction on the inspected tab (no element highlight, no click event, no navigation) at the moment of tapping.
This persists even with only one touchscreen: defined in the YAML (so implicit binding should apply), and also after explicitly setting touchscreen_id: <my_touchscreen_id> on the remote_webview: block — no change in behavior either way.
Ruled out a possible conflict from a custom on_touch: debug logger on the touchscreen component — removed it entirely, issue persists.
Ruled out a boot/rollback issue — confirmed clean successful boots (no "OTA rollback" warnings) with the current firmware, touch still not forwarded.
Config (relevant excerpts)
yamltouchscreen:
platform: gt911
id: waveshare_touch
interrupt_pin: GPIO4
i2c_id: bus_a
reset_pin:
waveshare_io_ch32v003: wave_io
number: 1
mode: OUTPUT
transform:
mirror_x: false
mirror_y: false
remote_webview:
id: bfl
touchscreen_id: waveshare_touch
server: SERVER
url: URL
full_frame_tile_count: 1
jpeg_quality: 65
max_bytes_per_msg: 131072
big_endian: 1
rotation: 0
Question
Is touch forwarding known to work on non-square / higher-resolution displays (this is 1024x600, versus the 480x480 panel used in the README example)? Or is there a known issue with touch coordinate scaling/forwarding on rpi_dpi_rgb-based setups specifically? Happy to provide more logs, try a patched build, or test anything else — display/frame streaming itself works perfectly, it's purely the touch-forwarding path that seems to be a no-op in this setup.
Touch detected correctly on-device, but not forwarded to server / page (no reaction at all)
Board / display setup
Board: Waveshare ESP32-S3-Touch-LCD-7B (1024x600, ESP32-S3-WROOM-1-N16R8)
Display driver: rpi_dpi_rgb (not mipi_rgb, since this board isn't a built-in supported model)
IO expander: waveshare_io_ch32v003 (from PR #10071, since this board uses the CH32V003 chip, not CH422G)
Touchscreen: gt911, address 0x5D, interrupt on GPIO4, reset via IO expander EXIO1
remote_webview version: latest from github://strange-v/RemoteWebViewClient@main
ESPHome version: 2026.7.0
What works
Display renders correctly, frames decode and update fine (confirmed via rwv_decode logs, tile sizes/timings all normal).
Touch is detected correctly at the hardware/ESPHome level. Using a temporary debug on_touch: handler on the touchscreen: block, tapping the same physical button consistently logs the same coordinates, e.g.:
TOUCH x=111 y=48
TOUCH x=115 y=46
TOUCH x=120 y=45
These coordinates correctly correspond to the on-screen button location (top-left menu area).
What doesn't work
Tapping the screen produces no reaction whatsoever on the remote page. No navigation, no highlight, nothing.
Confirmed via Chrome DevTools (chrome://inspect) connected to the RemoteWebViewServer's debug port while tapping the physical screen: zero visible reaction on the inspected tab (no element highlight, no click event, no navigation) at the moment of tapping.
This persists even with only one touchscreen: defined in the YAML (so implicit binding should apply), and also after explicitly setting touchscreen_id: <my_touchscreen_id> on the remote_webview: block — no change in behavior either way.
Ruled out a possible conflict from a custom on_touch: debug logger on the touchscreen component — removed it entirely, issue persists.
Ruled out a boot/rollback issue — confirmed clean successful boots (no "OTA rollback" warnings) with the current firmware, touch still not forwarded.
Config (relevant excerpts)
yamltouchscreen:
platform: gt911
id: waveshare_touch
interrupt_pin: GPIO4
i2c_id: bus_a
reset_pin:
waveshare_io_ch32v003: wave_io
number: 1
mode: OUTPUT
transform:
mirror_x: false
mirror_y: false
remote_webview:
id: bfl
touchscreen_id: waveshare_touch
server: SERVER
url: URL
full_frame_tile_count: 1
jpeg_quality: 65
max_bytes_per_msg: 131072
big_endian: 1
rotation: 0
Question
Is touch forwarding known to work on non-square / higher-resolution displays (this is 1024x600, versus the 480x480 panel used in the README example)? Or is there a known issue with touch coordinate scaling/forwarding on rpi_dpi_rgb-based setups specifically? Happy to provide more logs, try a patched build, or test anything else — display/frame streaming itself works perfectly, it's purely the touch-forwarding path that seems to be a no-op in this setup.