Some more info from my tests.
I installed recent image https://os.zynthian.org/2020-05-25-zynthianos-buster-lite-1.0.0.zip on my official kit V2, with rpi 4, official PiScreen 3.5 (V2). So I would say my configuration is rather standard, nothing special.
Touchscreen calibration is still unsatisfying, as I do not find a way to make calibration matrix permanent. The file 98-screen-calibration.conf has no effect, neither in /usr/share/X11/xorg.conf.d nor in /etc/X11/xorg.conf.d.
Changing the calibration matrix numbers in /zynthian/config/zynthian_custom_config.sh survives reboot, but does not survive a software update; they are reset back to -1 0 1 0 -1 1 0 0 1.
here is my configuration:
I’m running out of ideas…
I ran with a shell script that set it, from the command line which wasn’t ideal but it, at least, meant you could get it up and running without too much precise cut and paste work . . .
first post instructions worked great for me, even inverted my axis correctly on waveshare 3.5a … thanks! … now what is the touchscreen for “back” ?
Touch the Title Bar for “back”.
…but not the text in the title bar nor the status area on the far right hand side, unless you are in the sequencer in which case touching the titlebar (including text but not including status area) will show a menu with BACK option. Yes, it is sub-optimal but we are improving this…
Ah… I did wonder why it was unresponsive sometimes… Thanks for letting me know what “the rules” are!
Just went through all the steps and wow… my screen calibration is super accurate now.
Excellent. Thank you.
It survives reboots, but not software updates. No real fuss though. It’s easy to SSH back in and update the /zynthian/config/zynthian_custom_config.sh file.
Seems to be the only file I can find that makes any difference.
Would be amazing if this was part of the Zynthian OS to help those doing custom builds.
Kind regards
James.
Needs a menu entry to solve the ash and then it’s gold
Hi again,
after browsing some discussion forums, I think I have found a solution for the non-persistent calibration values.
As I understand it, there are two interface layers for touch screen devices, evdev (older) and libinput (newer, but also uses evdev). The calibration procedure (calib, xinput_calibrator) relies on evdev and thus there can be cases where the calibration is in conflict with libinput.
Here is what I did to make it work, i.e. to make changes persistent. It survives reboot and software update.
ssh -X root@yourraspberry
apt-get install xserver-xorg-input-evdev
apt-get install xinput-calibrator
export DISPLAY=:0.0
xinput set-prop “ADS7846 Touchscreen” ‘Coordinate Transformation Matrix’ -1 0 1 0 -1 1 0 0 1
Do the actual calibration:
xinput_calibrator
Rename 10-evdev.conf in /usr/share/X11/xorg.conf.d/ such that it is executed after 40-libinput.conf
mv /usr/share/X11/xorg.conf.d/10-evdev.conf /usr/share/X11/xorg.conf.d/45-evdev.conf
Open 45-evdev.conf and add the two lines from the output of the xinput_calibrator at the section which has “evdev touchscreen catchall” in it.
These are values that work fine for my touchscreen:
Section "InputClass"
Identifier "evdev touchscreen catchall"
MatchIsTouchscreen "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
#Custom Options below
Option "Calibration" "135 3804 207 3867"
Option "SwapAxes" "0"
EndSection
Additionally, rename any (calibration.)conf file in \etc\X11\xorg.conf.d\ to *.conf~.
Also, deactivate 98-screen-calibration.conf in \usr\share\X11\xorg.conf.d\ by renaming conf to conf~ (or whatever you prefer).
I have tested it on my zynthian (image from 2020-05-25) where I already tried some other attempts described in this thread. Could someone confirm if it works with a fresh image?
Good luck 
As I undesrtand, evdev is phasing out replaced with libinput. Though helped in your case, I would see this as risk for future compatibility and display infrastructure maintenance in the future. I guess there should be way how to make it work with libinput transform matrix without this evdev tricks. I dont know how, but any chance you could log complete xorg init and maybe search there for configuration steps finding those which are conflicting? But I’m not expert on this in any way.
Yes, I agree, it would be better to stick with the future-proof libinput driver.
When following your original recipe, I can read in Xorg.0.log that the transformation matrix is applied but the last lines in the log file are error messages regarding ADS7846 Touchscreen. But I’m no expert on that either…
I’m posting my /var/log/Xorg.0.log.
Xorg.0.log (10.6 KB)
It would be really helpful if someone with Kit V2 and PiScreen 3.5 (V2) and working touchscreen calibration could post his/her Xorg.0.log file, too.
The matrix itself is working, it can be applied with:
ssh -X root@yourraspberry
export DISPLAY=:0.0
xinput set-prop “ADS7846 Touchscreen” --type=float “Coordinate Transformation Matrix” -1.11 0 1.04 0 -1.12 1.05 0 0 1
OK, I reread your posts and as I understand it, your issue is that calibration doesn’t survive updates when transform matrix is entered into zynthian_custom_config.sh. You’ve created /usr/share/X11/xorg.conf.d/98-screen-calibration.conf which seems to be part of standard files updates. What if you instead put script output into !!99!!-screen-calibration.conf? Maybe this won’t be overwritten by update and as higher numbered config will supersede overwritten 98-screen-calibration.conf. I’m using PiScreeen (V1), which doesn’t have any zynthian_custom_config.sh, so there is not conflict with 9(8/9)-screen-calibration. Any chance you could try it with your setup (from fresh image)?
[use PiScreen 3.5 (V1) and calibration script output into 99-screen-calibration.conf, chceck if survives reboot, then if survives update]
Thank you for your suggestion @sailort, I have some progress now with the following steps:
a) renamed 98- to 99-. The calibration matrix in that file contains -1.11 0 1.04 0 -1.12 1.05 0 0 1.
and b) I entered these floats in /zynthian/config/zynthian_custom_config.sh (there was the sequence -0 1 0 1 0 -1 0 0 1 before).
Now I can reboot and update the software and calibration is still there 
.
The strange thing is however, that after the update, numbers in zynthian_custom_config.sh are reset to -0 1 0 1 0 -1 0 0 1. But calibration is still there and also survives successive reboots and updates. And If I just do a) or b) - no success. I mean if the matrix is reset anyway, why does it still make a difference if I enter the precise values in zynthian_custom_config.sh? 
Seems that they are read from that file and stored somewhere else.
And: selecting PiScreen V1 did not work, touch was not working at all and GUI froze. So I changed it back to PiScreen V2.
I’ll retry all these things with a fresh install in the next days. But on the other hand, I had these problems already right after installing image from 2020-05-25.
EDIT: Oh no, problems are back… It survived at least one update but maybe the 3rd or 4th update broke it. Strange that the recipe seems to work for anyone else. What might be the difference, maybe Kit V3 vs. Kit V2?
Lets try this:
- select PiScreen 3.5 (V2)
- copy configuration settings
- select PiScreen 3.5 (V1)
- paste configuration settings
- do the calibration (as 99-…conf) [ ignore zynthian_custom_script.sh ]
- report
1 Like
ah, now I got your point what you meant with PiScreen V1. it works 
Big thanks!
storing configuration in 98- or 99- does not make a difference.
Maybe it is not exactly what I meant, but if it works as should, then it’s good news. Anyway, if it works this way, it says something about nondeterministic behavior of zynthian_custom_script.h. And that could be a lead for nice and working systematic solution.
For the sake of clarity, could someone reiterate the calibration steps? I’m having trouble following along. Thanks!
(Hmm… should we make a wiki page for this?)
2 Likes
I’ve started something here . . .
https://wiki.zynthian.org/index.php/Aligning_Zynthian_Touchscreens
OK, I’ll commit to prepare bash script which would automate this process if someone knowledgable will make button for invocation from webconfig. Just let me know desired location and name for testing purposes.
- chceck if needed x tools are installed, if not, install
- run calibration
- output to both known working locations
- if I will find a way to identify current display name, disable custom…config.sh to avoid interference
4 Likes
That’s great!
Presumably there is a proscribed Xwindows order to the config files?
I’ll set up a branch @mheidt How & Where might this be implemented or is it a GUI feature ?