Waveshare 18.5" HDMI capacitive touch (1920×1080) on Pi 5 – works, but display power needs wlopm instead of ddcutil

[junky84]

Hardware

• Display: Waveshare 18.5inch FHD LCD – 18.5" IPS, 1920×1080, 10-point capacitive touch, optical bonding, HDMI (video) + USB-C (touch), DDC/CI brightness
• Board: Raspberry Pi 5 Model B, 4 GB
• Mounting: adhesive mirror hangers on the back of the display, which simply hangs on two hooks on the wall
• Frame: custom-made wooden floater frame (shadow-gap frame). Besides the look, the gap between frame and display has a practical benefit: warm air can escape, so the panel doesn't build up heat
• OS: Debian 13 (Trixie), labwc (Wayland)
• TouchKio: 1.5.0 → 1.6.0

What works out of the box

• ✅ Touch input via USB-C (HID, no driver needed, multi-touch)
• ✅ Native 1920×1080 resolution
• ✅ Brightness via DDC/CI (ddcutil, VCP 0x10) – controllable from HA, e.g. 5 % / 80 %
• ✅ On-screen keyboard (squeekboard) for the one-time HA login

What doesn't: display power via DDC/CI

The panel advertises DDC/CI feature 0xD6 (power mode), so TouchKio picks ddcutil for the display status – it's tried before wlopm in getDisplayStatusCommand (js/hardware.js). But the panel ignores setvcp 0xD6 4: the backlight stays on. The log shows Set Display Status: OFF followed by Update Display Status: null, and the screen never goes dark.

wlopm --off '*' blanks the panel correctly (DPMS off), and wlopm --on '*' brings it back.

Workaround: in the Wayland block of getDisplayStatusCommand, try wlopm before ddcutil – for the status only. Brightness is handled separately in getDisplayBrightnessCommand and should stay on ddcutil, since that works fine on this panel. After the change the log shows:

Display Status [...]: ON (wlopm)
Display Brightness [...]: 5 (ddcutil)

Since app updates overwrite hardware.js, I re-apply the change automatically with a small idempotent script run via ExecStartPre in a systemd user drop-in for touchkio.service. (1.6.0 changed the desktops list in that block, so a fixed-string patch broke silently – a regex-based swap has been more robust.)

Suggestion

@leukipp, would it be possible to make the power backend configurable (e.g. --display-status-command=wlopm), or to fall back to wlopm when ddcutil reports success but the panel doesn't actually turn off? I'd guess other HDMI panels that advertise 0xD6 without honouring it are affected too. Happy to test anything on this hardware.

[leukipp]

Did you have a look at the ddcci-* apt packages mentioned in the FAQ?

Display brightness can't be controlled through MQTT.

• Have a look at the features section to check if all requirements are fulfilled.
  • The Display MQTT control is a light entity with brightness support. So make sure to click on the entity to test the brightness slider.
  • The brightness slider is also only available if the display status control (on/off) is functional and the user has permissions to modify the brightness value.
• HDMI screens typically do not offer brightness control out of the box, so additional setup steps are required.
  • It's recommended to install ddcci-driver-linux or ddcci-dkms, since this will create the necessary /sys/class/backlight/* folder structure.
  • Additional brightness support using ddcutil is built-in and checked on application startup, but it's really slow and unreliable.
• Make sure that one of these works for your display when you run it directly on the terminal, otherwise the MQTT switch will not show the brightness control.
  • sudo cat /sys/class/backlight/*/brightness returns some numeric value.
  • sudo ddcutil setvcp 10 42 changes the brightness to 42% without asking for a password.

Using ddcutil is more or less Plan C (the fallback of the fallback). So I encourage users to use wlopm for status control and /sys/class/backlight/*/brightness for brightness control, since these have proven to be the most reliable solutions so far.