Read time: 10+ minutes – check the Table of Contents for overview. Hint – this full article is available as well as a PDF here.

Part 1. Part 2. Part 3.

I hope you have payed attention ;). Until now we learned why Manjaro, what is the HW, constraints, installation and basic operation. If you reached this point – you will learn next about my successful adventure with the Kuman RPI4 7 Inch Capacitive Touch screen. I hope it will be helpful for you.

Kernel Modules related to Touchscreen – investigation, simple help, experiments and calibration

The 7 inch LCD and the touchscreen

Changing the display to the 7 inch

 My LCD is: Kuman 7 inch capacitive touch screen display, with USB for touch communication and power, bought via amazon.de. Characteristics from the official page:

        – Capacitive touch control: This Raspberry Pi Screen resolution is 800×480, It also has vertical and Horizontal image flip function. Image 4: 3/ 16: 9 display format conversion.

        – Operating voltage: The touch screen 5V 1a power supply current requirements within the above 2a, on board 400mA DC-DC Boost Regulator to provide power supply to LCD backlight.

        – Multifunctional: when the 7 inch touch screen work with the Raspberry Pi, it supports the Raspbian, Ubuntu, Win10 IoT, single-touch and free drive. When using as a computer monitor, It supports Windows 10/ 8.1/ 8/ 7, five point touch and free drive.

        – With protective case: The Raspberry Pi Display comes with the protective case stand, which is made with black acrylic. Raspberry Pi board can be installed on the back of the case.

Switching directly did not help as for the big monitor Manjaro ARM succeeded to provide me resolution of 1920×1200. So – I changed it manually to 800×600 on the big monitor, and then switched and it worked. By the way – RPI4 was faster responsive with 800×600. This means most probably the big resolution was increasing the HW needs.

How to switch the Display Resolution – simply open the main menu, type Display and you will see the given GUI.

Initial tests show that it supports so far more than the advertised: 800×600, 1024×768, 1280×720. The 1280×1024 – no. When I try not supported resolution – the display flashes with freq. ~0,5 Hz. I kept the 1280×720 (as it was the best) and increased the terminal symbols Font size to 20. Later I’ve tried few different resolutions and some of them worked.

The official documentation on my display looked quite a lot, but not very much helpful.

Documents provided from Kuman:

About SW Keyboard:      How to install matchbox-keyboard(En).pdf

Touch screen:           How to calibrate the touch screen(En).pdf

Driver installation instruction

How to modify the display orientation

All of them are located here. Download and check them if you want, but I recommend reading the article till the end before spending too much time on then.

————————–

Starting the touchscreen

Simply by connecting it to one of the USB2 ports of the RPI4 worked.

Another interesting point – when I switched the HDMI back to the 24 inch monitor, but kept the Touchscreen connected to the board – as expected it continues to work and transfers the coordinates coverage correct – no matter that the screen is bigger, rotated and so on. How I understood this? When using the touchscreen – the left / right / top and bottom close-to-edge positions correspond on the touchscreen with the 24 inch rotated widescreen monitor.

Important point:

As I work with two displays I have configured the Display to have two profiles – one for HP24 and one for the 7 inch. Having such presets can help faster switch when changing between the displays.

Screenshot:

Drivers (the Linux term – Kernel Modules) – first steps to understand more about which works for some USB and how to track a Kernel Module version and source

As it feels like the touchscreen is not perfectly accurate (like e.g. on my Samsung android phone) I would like to calibrate it. And this required identifying which Kernel Modules are used and later find out what is possible to do with them.

FIRST – About the USB, as the Touchscreen is connected via USB.

Let’s inspect the running processes with “ps -ef“. Using grep to find occurunce of any of the words “usb” or touch didn’t help. Reminder – “ps -ef” lists all the processes running on the system, showing also whether they are started from root or from some other user.

Then let’s inspect the USB “HID” devices. HID stands for Human Interface Device – i.e. mouse, touchscreen, usb, keyboard, etc.

One way is to list the /dev directory with and without the touch USB connected, then compare the results:

$ ls -l /dev > listWith.txt

$ ls -l /dev > listWithout.txt

$ diff listWith.txt listWithout.txt

One potential line drew my attention: the “hidraw2 30c29”

This might be my device but no further info was presented. So simply use (again with and without the device connected):

    $ lsusb    

My Device is Bus 001 Device 006: ID 1a86:e5e3 QinHeng Electronics

The other option is “usb-devices” command: It shows more detailed description and I recommend trying it, but no other significant information.

More detailed examples: here.

SECOND – About the system log via dmesg command.

In short from its help says: Display or control the kernel ring buffer. From our perspective regarding the display part: practically it shows a sequence of commands and events of what happened on our system since the last boot – i.e. system log messages. And as I have connected and disconnected the USB device 2 times while trying the previous commands – it shows those actions.

So – my touchscreen really is:         Bus 001 Device 006: ID 1a86:e5e3 QinHeng Electronics

1a86 is Vendor ID, e5e3 is the Product ID. The USB kernel module used is hidraw, the instance in particular – hidraw2.

I tried to see it in my list of processes with “ps -ef | grep hidraw2“. I did this over 15 times and it always came out with different PID! I didn’t get any grep result for hidraw2 only 2 times out of 15 tries. This means that this process doesn’t run permanently, and thus each time when it is ran – it has different PID. I’ve obviously hit moments when the process was not running.  So keep this in mind when checking some processes on your system.

Unfortunately this doesn’t provide me with information on which/what touchscreen Kernel Module is used!

THIRD – How to track a Kernel Module to a source.

In order to understand a bit more – first our Kernel is 4.19.97. We check this via:

$ uname -srm          ->     result :         Linux 4.19.97-1 MANJARO-ARM aarch64

$ lsb_release -a      ->     shows the OS:          Manjaro-ARM Linux version 20.03

The basic information about the release from the Manjaro Forum is here. And just for reference here is the Manjaro Wiki. To support the Manjaro cause you can donate here :).

The Linux Kernel information here shows:  Major revision 4, version 19, with subversion 111, an LTS (Long Term Support):

    22 October 2018     4.19.111    Greg Kroah-Hartman & Sasha Levin   19th LTS release, maintained from October 2018 to December 2020. Used in Debian 10 “Buster”. Second SLTS release with support for ARM64 platform.

I downloaded from https://www.kernel.org/  the long-term release 4.19.112 from 2020-03-20 [a tarball archive]

And this is the general documentation of hidraw on kernel.org for hidraw.txt from 13-May-2017 and hidraw.rst from 21-Jul-2019.

So – this is our hidraw Kernel Module. The purpose was to show you how to track a given Kernel Module related to your release when you need to see the source.

Calibration of the Touchscreen – first steps and xinput_calibrator

This chapter is here because:

• xinput_calibrator was pointed in the official Kuman touchscreen documentation as the library to use for the touchscreen calibration
• It explains how digging about it pointed me to the right and simple solution later, it also explains where to look when investigating a library
• People who would like to know why xinput_calibrator is not a solution will have the full information here (as such was not present on the Internet, no matter how much I searched).

ON XINPUT_CALIBRATOR:

Obviously the Touchscreen works. So I thought I may use the proposed open source calibration application from the Kuman Documents. The calibration instruction speaks of few commands that do not exist on my system:

xinput_calibrator

DISPLAY

X11

sudonano /etc/X11/xorg.conf.d/99-calibration.conf

The path /etc/X11/xorg.conf.d/ exists, but the 99-calibration.conf doesn’t.

About X11 – it is the X Window System. It is used widely in different graphical environments in the Linux world. It is platform independent, and requires a Window Manager on top of it. It is developed by X.Org and there is a reference implementation of X11 from them named X.Org Server. So – if you see some sources on your machine which include some “x.org” in their path or name  – it is quite probable those are related to X11.

About XFCE – some general points from XFCE Wikipedia Page: Like GNOME, Xfce is based on the GTK toolkit, but it is not a GNOME fork. It uses the Xfwm window manager, described below. Its configuration is entirely mouse-driven, with the configuration files hidden from the casual user. Xfce does not feature any desktop animations, but Xfwm supports compositing.

The official xinput_calibrator  page is here. The GitHub project repo page says it is a generic touchscreen calibration program for X.Org. 1st red flag – the latest updates are from 6 years ago! Still – I go till the end!

So we check with pamac and pacman and neither xinput_calibrator nor xinput-calibrator can be found. Then we check the AUR and here is the package.

With yay I got the xinput_calibrator package:

    $ yay -Ss xinput_calibrator  – provided me information on the aur package.

And I tried to install it:

    $ yay –S xinput_calibrator           

It was a long log with one final crucial point – the xinput_calibrator is not compatible with my architecture! Or at least yay reported so.

—   —   —   —   —   —   —

I thought I should try to download and compile it myself: It’s written in pure C++. It turned out that there are some “errors” as aarch64 and Manjaro Linux are not recognized from the build scripts of the package. This meant for me – I need to look the source and find out what was happening inside.

—   —   —   —   —   —   —

When a package build suite reports that your architecture or OS is not supported you have to find where in the compilation scripts are listed the supported architectures. Compilation scripts are normally bash scripts, make related files, and not sources like hpp, cpp, c, h, etc. For our package these are config.guess and config.sub. This is a pair of generic scripts for detecting the architecture and OS. I found online their latest version here and here.

And it turned out that those inside xinput_calibrator are from 2010, whereas the newest versions are from 2019/2020. 2nd red flag – I realized this might not work at all.

Then – before trying more and out of curiosity – I checked the opened and closed Issues (Tickets, Bug Reports, etc.) for xinput_calibrator (on GitHub here).

The most interesting was from a guy who contacted the author of xinput_calibrator. This is an issue initially from 2015 asking for an update release, and in 2017 we have this comment (a bit clarified from me):

—   —   —   —   —   —   —

“I contacted tias (the author) about maintenance of this project (the xinput_calibrator) and he wrote: I’m maintaining and developing tslib and xf86-input-tslib and would happily help out here – even if most probably more passively than my other projects.“

—   —   —   —   —   —   —

Considering this and the fact that xinput_calibrator was not updated in the last 10 years – tslib with its ts_calibrate tool should actually be the current newer alternative to xinput-calibrator.

A bit more digging revealed that using tslib became more generic and easy on Linux. It supports multitouch, and with it, besides “calibration” (which is a linear transformation filter), you get many other filters to play with.

This meant I had to check more on tslib.

You see now how important is sometimes to check Tickets, Issues, Logs and even mailing listings of open source packages. Most of the time you might find some or even more useful information.

Some old guru might say – of course xinput_calibrator will bring up issues – since 2010 the Kernel has changed so much that a module that old will positively not work, and might even cause some damage. And he will be right.

Nevertheless – I wanted to place the whole info here, so that you see for yourself what digging for sources, revisions and information means. If you want to go on with Linux – you will have to do it from time to time. Finally the community will have now written somewhere that the official Kuman information is now obsolete :).

Calibration – second step – and with tslib

I’ve checked with pacman -Qs and pamac info and the version which I have – tslib 1.21-1 – is actually in the official Arch Repository and also the Arch Arm Repo. Here is the official tslib page: https://github.com/libts/tslib.

The question was now – is this used on my system?

—   —   —   —   —   —   —

A basic point on Linux Kernel Modules (drivers):           

Linux doesn’t have separate entity as “device drivers”, Linux has kernel modules which could be called “drivers” for real or virtual hardware depending on their functionality. I thought I have to check them and here is how we do it:

Use lsmod or cat /proc/modules to see list of loaded kernel modules. Also you can see list of all available (installed) kernel modules in system using:

$ ls -R /lib/modules/`uname -r`/kernel/

The first two revealed the module hid_multitouch which might be interesting for me.

Important for a Kernel Module – to lists the dependences and exist:

$ modprobe hid_multitouch -D

Check it out. I also recommend checking the modprobe -h.

—   —   —   —   —   —   —

I thought then – considering that the touchscreen works – do I have some controls in the regular GUI based machine settings? So I opened the main menu (the whisker menu, aka the start Menu, the Manjaro Menu) and in the “Mouse and Touchpad” controls I have wch.cn USB2IIC_CTP_CONTROL

Again – dmesg – display or control the kernel ring buffer. Reminder – this showed that my Kernel Module hid_multitouch talks with hidraw via hidraw2 instance.

And as this didn’t lead me further I switched to check the tslib.

        ABOUT TSLIB:    http://tslib.org

tslib consists of the library _libts_ and tools that help you _calibrate_ and _use it_ in your environment.

tslib can be calibrated by the provided module (part of the library) called ts_calibrate.

It exists in our Manjaro-ARM-xfce-rpi4-20.02. I checked this by trying it via Autocomplete in the Terminal. Simply typing “ts_” and pressing twice the TAB from the Keyboard will show this list of available executables:

ts_calibrate; ts_finddev; ts_print; ts_print_raw; ts_test_mt; ts_verify; ts_conf; ts_harves; ts_print_mt; ts_test; ts_uinput

You will not need most of those; many are intended for internal system use, and not for the direct user interaction from the console.

The README.md of the tslib here says: for regular calibration we shall use ts_calibrate, and for test of the multitouch filters the ts_test_mt.

Then – the “man ts_calibrate” says I need to pay attention to the environmental variables and ts.conf – it says in ts.conf I shall obligatory have the linear module configured (i.e. uncommented).

ts.conf is actually a file in /etc. With cat or gedit we can read it. The last line in it is uncommented:

module linear

so we are free to go.

About the calibration – simply start “sudo ts_calibrate” and click on the given locations on the touchscreen, and yes – it is only this.

—   —   —   —   —   —   —

        Regarding the multitouch – pay attention if you start it because:

1. It blocked my system completely requiring hard reset as I couldn’t stop the application.
2. It shows that the multitouch works, but doesn’t calibrate or help in some similar way.
3. Still – if you want to see how the multitouch functionality monitors up to 10 fingertips at the same time – check it out.

Start it like this:

            $ sudo ts_test_mt

—   —   —   —   —   —   —

What I meant with “requiring hard reset”: I tried stopping the ts_test_mt – with Ctrl+c, q, del, esc or whatever. This didn’t work at all. I also couldn’t press the given GUI buttons on top of the screen. Finally I had to restart the power. The good thing is that ts_test_mt showed that the tslib kernel module with all its stuff successfully follows up to 10 fingers and the multitouch works :).

Some strange side effect: The Pi showed some boot problems. I had to try several times. I guess because it didn’t shut down normally. The observed behavior – the small Touchscreen HDMI panel was not working, saying “No HDMI signal”. Booting to the bigger screen showed that everything is OK.

    Final points after this chapter:

    We understood so far:

    USB module: hidraw, hid_multitouch

The used package: tslib, ts_calibrate

    Display: can show different resolutions via HDMI

    Touchscreen: USB Data Vendor ID 1a86, Product ID: e5e3 QinHeng Electronics

    Touchscreen sold by: Kuman

    Kernel: Version 4.19.97, my build in particular: Manjaro-ARM-xfce-rpi4-20.02

The Touchscreen showed in the “Mouse and Touchpad” controls: wch.cn USB2IIC_CTP_CONTROL

In order to go on further – we need to have some more information on the Linux Kernel Modules which I hope to prepare in the next few weeks.

Remember the purpose – shortly described – write some C++ based GUI SW which uses the Touchscreen. And probably see how it is possible to make full use of the multitouch. Then see how this can be transferred with Yocto on a custom trimmed build.

Prev: PART 3.