I’m considering a custom build, possibly in a master keyboard, to get a more self-contained “zynthesizer”.
For this purpose, I bought a 5" touchscreen:
https://www.amazon.co.uk/dp/B07ZD4QGQJ?ref=ppx_yo2ov_dt_b_fed_asin_title
with HDMI+USB, as I figure I might have to mount the screen some way away from the Raspberry Pi (which is an RPi 5 by the way). Downloaded the latest oram-2504-stable image (which had some issues in itself, see Headless RPi5 boot issue).
The screen works fine … mostly, except that touch doesn’t work out of boot. If I unplug and replug the USB connector (which also powers the screen), it works fine.
Looking at /var/log/Xorg.0.log, I can’t really see anything that looks wrong.
After some digging, I found that
DISPLAY=:0 xinput enable 6
brings touch back to life. And running
xinput
after boot gives me:
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ pwr_button id=7 [slave keyboard (3)]
∼ wch.cn USB2IIC_CTP_CONTROL id=6 [floating slave]
whereas after replugging, or executing the xinput enable command above gives me
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ wch.cn USB2IIC_CTP_CONTROL id=6 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ pwr_button
‘floating slave’ apparently means that it is not associated with the master device.
I tried adding a rule in /etc/X11/xorg.conf.d/ to disable “Floating” when the screen is found. According to /var/log/Xorg.0.log, the rule is found and executed, but it doesn’t seem to make a difference.
Anyone else have a similar problem? I get the feeling that something is disabling the touch feature at some point after boot, but I can’t figure out how or why. Like I said, replugging the USB device or issuing the xinput enable command causes it to work fine, so it’s not a question of the device itself not working.
One thing I’m going to try is to add a systemd rule that tries to enable the display just before starting the zynthian service.