Feature #1038
closed
Integrate touchscreen support for new displays.
100%
Description
RM #948 added support for two 5" inch HDMI touchscreens. However, their touch drivers are not supported yet.
See comment 10 in that issue for how to implement this.
Related issues
Updated by Hammel 7 months ago
- Status changed from New to In Progress
- % Done changed from 0 to 20
Using the TSLIB_TSDEVICE environment variable doesn't work because it is expected to be a device file name, which we don't know yet. That's why there is a search of device files for the name of the device it supports.
The solution is this:- Firsboot writes the EDID Manufacturer+Model (such as MPI17) to a file: /etc/ts/edid
- piboxTouchInit()
- reads /etc/ts/edid if it exists
- Searches for a match in /etc/ts/ts_devices, which is a list of supported touchscreen devices (such as ADA14=ILITEK ILITEK-TP for GeeekPi 5" HDMI)
- Sets ts_name=<match>, if found
- ts_setup() uses ts_name, if not null, for search before searching ts_name_default[]
Updated by Hammel 7 months ago
- % Done changed from 20 to 50
libpibox is updated to use the edid data from firstboot to do a lookup on which input device-by-name to use. This works for launcher which means touch works for that app.
But there are side affects that need to be understood.- pipics doesn't recognize touch events. Not sure why it's different than launcher since both use a shared version of libpibox.
- picam works on the display and the touch to exit works, but when launcher comes back it's about 1/4 to 1/3 the size of the display, and touch events are not quite in the right locations.
- Other apps might start (if you hit the correct location) but may not exit with a touch event.
This all might be due to the apps not being recompiled against the updated libpibox. So the thing to do is commit libpibox, rebuild the staging tree and then rebuild the apps and see how they behave.
Updated by Hammel 7 months ago
The problem with picam is that omxplayer switches display modes on the HDMI display. The only way to get it back is to do something like this.
#!/bin/bash
cd /opt/vc/bin
./tvservice --off # turn off tv service
./tvservice -e "DMT 87 DVI" # set it on (you will see a black screen)
chvt 5 # change to different virtual terminal
chvt 2 # change back to the previous virtual terminal
fbset -g 800 480 800 480 32 # adjust the size of the framebuffer
xrefresh -d unix:0.0
Be aware that running this generated the following.
$ ./fixit.sh
Powering off HDMI
Powering on HDMI with explicit settings (DMT mode 87)
ioctl FBIOPUT_VSCREENINFO: Invalid argument
I tested this and it works to get the display resolution back and the launcher's touch support is working as expected. However, for the Media system on the 5" the splash image is not redrawn. That's probably an easy fix in the launcher and is basically a bug anyway. Fixing this will require identifying a generic way of getting the edid data to use in this script and then calling the script (or programming it) from picam on exit. Maybe like this?
$ /opt/vc/bin/tvservice -s
state 0x6 [DVI DMT (87) RGB full 15:9], 800x480 @ 59.00Hz, progressive
I also rebuild the rootfs and apps but they are not responding to touch events as I expect. It's possible that many of them don't support touch events. I need to test this with pisentry, where all the apps should support touch events.
Updated by Hammel 7 months ago
Verified with pisentry - the Elecrow 5" needs to be calibrated (ts_calibrate, which writes to /etc/pointercal). Once that's done then the touchscreen works correctly, save for the problem that omxplayer raises. Note that PiNet worked perfectly out of the box, even without calibration, because it used regions instead of ABS touches (launcher requires ABS to identify specific icons).
I can add the calibration file to /usr/share/pibox/calibrate/EDID and use firstboot to install it, much like was done with the display and board configs.
What's left- Save the Elecrow and GeeekPi calibration files to the dev system skeleton.
- Update functions:optimizeDisplay() to grab the calibration file, if any.
The problem with omxplayer will be tracked separately in RM #1039.