A button like the ogg functionality but on the IU options page?
Will be better on Display config screen I guess. It just need to invoke sh script somewhere. Meanwhile I have received another display, now 4". Having head in hands since morning. This is a mine-field I regret stepping in.
- waveshare4c works as display driver, but reports strange values to libinput, Transform Matrix was very strange, with values like -720, -250, etc. and touch screen was not working, as it was way off and cursor stayed only in corner.
- thought that I’ll use separate ads7846 driver overlay for touch screen, but it won’t work as WS4C drivers lock SPI access for itself
- realized piscreen2r-notouch (PiScreen 3.5 V2) with ads7846 driver works, but again, touch values seems strange, touch pressure in range of 65000, nothing to work around
- now I’m playing with piscreen2r (without notouch option), this works, but have very strange issue, when holding and dragging value widgets sometimes (too often for my taste) it select different item within middle list-box, even when I don’t cross, even far away from it with finger. Values from evtest doesn’t seem to hit middle section according to X/Y coordinates. What it seems to me, that middle list-box control is receiving (and unfortunately processing) events, which doesn’t belong to it’s screen section. I had this strangeness on other driver combinations also, so this is probably zynth issue.
Event: time 1594125797.266497, -------------- SYN_REPORT ------------
Event: time 1594125797.306426, type 3 (EV_ABS), code 0 (ABS_X), value 3400
Event: time 1594125797.306426, type 3 (EV_ABS), code 1 (ABS_Y), value 1740
Event: time 1594125797.306426, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 108
Event: time 1594125797.306426, -------------- SYN_REPORT ------------
Event: time 1594125797.326495, type 3 (EV_ABS), code 0 (ABS_X), value 3399
Event: time 1594125797.326495, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 113
Event: time 1594125797.326495, -------------- SYN_REPORT ------------
Event: time 1594125797.346538, type 3 (EV_ABS), code 0 (ABS_X), value 3382
Event: time 1594125797.346538, type 3 (EV_ABS), code 1 (ABS_Y), value 1739
Event: time 1594125797.346538, -------------- SYN_REPORT ------------
Event: time 1594125797.372984, type 3 (EV_ABS), code 0 (ABS_X), value 3373
Event: time 1594125797.372984, type 3 (EV_ABS), code 1 (ABS_Y), value 1754
Event: time 1594125797.372984, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 107
Event: time 1594125797.372984, -------------- SYN_REPORT ------------
Event: time 1594125797.386496, type 3 (EV_ABS), code 0 (ABS_X), value 3377
Event: time 1594125797.386496, type 3 (EV_ABS), code 1 (ABS_Y), value 1751
Event: time 1594125797.386496, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 99
Event: time 1594125797.386496, -------------- SYN_REPORT ------------
Event: time 1594125797.406539, type 3 (EV_ABS), code 0 (ABS_X), value 3396
Event: time 1594125797.406539, type 3 (EV_ABS), code 1 (ABS_Y), value 1740
Event: time 1594125797.406539, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 41
> !!! -------------------------- !!!
> HERE I THINK PROBLEM IS. X COORDINATE DOESN"T CHANGE TO EXTEND IT SHOULD HIT MIDDLE SECTION
> Event: time 1594125797.406539, -------------- SYN_REPORT ------------
> Event: time 1594125797.426359, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
> Event: time 1594125797.426359, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 0
> Event: time 1594125797.426359, -------------- SYN_REPORT ------------
> Event: time 1594125797.456516, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
> Event: time 1594125797.456516, type 3 (EV_ABS), code 0 (ABS_X), value 3391
> Event: time 1594125797.456516, type 3 (EV_ABS), code 1 (ABS_Y), value 1925
> Event: time 1594125797.456516, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 35
> !!! -------------------------- !!!
Event: time 1594125797.456516, -------------- SYN_REPORT ------------
Event: time 1594125797.491510, type 3 (EV_ABS), code 0 (ABS_X), value 3415
Event: time 1594125797.491510, type 3 (EV_ABS), code 1 (ABS_Y), value 1935
Event: time 1594125797.491510, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 86
Event: time 1594125797.491510, -------------- SYN_REPORT ------------
Event: time 1594125797.506498, type 3 (EV_ABS), code 0 (ABS_X), value 3423
Event: time 1594125797.506498, type 3 (EV_ABS), code 1 (ABS_Y), value 1939
Event: time 1594125797.506498, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 87
Event: time 1594125797.506498, -------------- SYN_REPORT ------------
Event: time 1594125797.526532, type 3 (EV_ABS), code 0 (ABS_X), value 3411
Event: time 1594125797.526532, type 3 (EV_ABS), code 1 (ABS_Y), value 1938
For selector class switch_select and click_listbox methods are called withou cb_listbox_push.
EDIT: OK, I’ve got it. Short press on controller value subscreen emits Rotary Encoder push according to position. Time to comment out some lines in cb_canvas_release.
EDIT2: Aaaah. what a relief on UI using touch. No more crazy UI screen switches under fingers.
EDIT3: Ended up with this in zynthian_gui_controller.py. Now onlyquick swipes to sides selects next controller set and if so, origin value of control is restored not accounting eventual swipe in Y axis. Maybe someone could come (I’m sure someone will) with solution with swipe right → down, swipe left → up.
def cb_canvas_push(self,event):
self.canvas_push_ts=datetime.now()
self.canvas_motion_y0=event.y
self.canvas_motion_x0=event.x
self.canvas_motion_dy=0
self.canvas_motion_dx=0
self.canvas_motion_count=0
self.ctrl_pvalue=self.value
def cb_canvas_release(self,event):
if self.canvas_push_ts:
dts=(datetime.now()-self.canvas_push_ts).total_seconds()
deltax=event.x-self.canvas_motion_x0
if dts<0.5:
if abs(deltax)>10:
self.set_value(self.ctrl_pvalue, True)
self.zyngui.zynswitch_defered('S',3)
1 Like
Worked like a charme here with 4.1 kit
2 Likes
I have written a python script to implement this. I will submit a pull request to add this to zynthian… but now to bed!
5 Likes
Any brave souls out there may wish to check out the feature/touchscreen_calibration branch and test native touchscreen calibration within Zynthian admin menu. It took quite a while (2 days) to figure out the maths etc. but it seems to work for me on two different touchscreens.
When the view opens it detects all the touch interfaces available. The view should close if none are detected (but I suspect there may be an issue where it goes grey - BACK button will close). It configures all touch interfaces to use their default settings. This may change the orientation of the touch display during calibration. Touching the first target crosshair will attempt to detect which of these interfaces you are using and display its name at the bottom of the screen. Touching the second target crosshair will calibrate the screen and close the view. After 7s of inactivity the view closes, resetting touchscreen configuration for each interface to the state when the screen was opened.
In theory the configuration should be persistent but I am struggling to get it to stick with the official zynscreen. My other (USB) touchscreen works fine. I suspect it relates to udev loading its configuration then later attempt to load fails. There is a suggestion that evdev may be affecting it too. Any suggestions gratefully recieved.
[Edit] Grrr… that was a wasted few hours when I could (and should) have been sleeping! There is a script that zynthian runs to configure its touch device which overrides any xserver configuration. I will look at how to resolve this tomorrow (maybe). I reckon we could loose all the scripts and replace them with a single xserver configuration file. I can modify my calibration code to update (rather than overwrite) such a file hence allowing us to supply a default configuration that should make each card work then allow users to calibrate to remove errors.
3 Likes
@jofemodo I will need your help…
I have updated the code so that it searches /etc/X11/xorg.conf.d/99-calibration.conf for a configuration for the touch interface and updates if exists or creates a new one if missing. This seems to be working quite well. For this scheme to work we should;
- Remove the custom scripts that set calibration for each type of screen
- Add default xorg configuration for each known screen type to /etc/X11/xorg.conf.d/99-calibration.conf (where the config differs from the default)
- Merge this branch
I would like to see a bit of user testing before submitting a pull request. I have tested with the official v4.1 kit and with a Fondar USB Touch device as well as no touch interface. These all perform as expected (with the exception of v4.1 config currently updated during application startup by custom script).
The Python code could be tidied up, e.g. regexp could replace swathes of code but I am no regexpert! There could also be some error handling improvements but it does seem to work quite well for me.
[Edit] Be aware that the device detection is not currently working. I need to do some more low-level (evdev) tests.
1 Like
Hello,
Tested on a V2 kit.
Calibration itself works well.
Effectively it seem not to be persistent after power cycling on the official V2 kit screen.
Maybe it worth extending 7s tempo to a slightly longer time. It currently pushes the user to touch crosshairs rapidely which is a bit antagonist with the necessity to touch them precisely.
Yep! My test dummy here said the same. I will extend to 15s and also stop countdown whilst touching screen.
1 Like
I’m reading your code … 
location /etc/X11…99-… doesn’t work sometimes I think. I have ended up in /var/…98-… to make it permanent. Had to make it 98 as 99 wasnt working. Haven’t investigated deeper why tho…
It’s always been about making it permanent 
Different setups seem to use different file orders, or something similar.
Zynthian’s xserver configuration looks in both locations so we should only use one to avoid conflict.
But which one it is? What about injecting calibration values into running X11 from some single location script, as somehow calibration app is able to do after clicking those four points? Avoiding 98/99/etc/var static conf locations altogether? Just an idea. Seems that as wyleu and others here (count me in, as I had to change location also) had issues with which one file works for them.
We can certainly configure it live and that is what the new calibration screen does as well as the initial config that is currently stopping persistent storage from working. I wonder if it was that script that caused you so much angst. (I certainly kept me up late last night!) I would prefer to do it the right way and put the configurations for each screen into the xorg config in the base build than modify them from the calibration tool. Once we have that working we can more simply diagnose individual cases.
If I can recommend, make calibration mandatory step during setup. Even same screens from same manufacturers could need different calibration values. I wouldn’t rely on manufacturing “perfection”. Especially in the era of clones.
1 Like
Hi @riban!!
I just tested the new tool and i must say it works perfectly for me, excluding persistence.of course. Really Big Thanks, mate!!
I think we should have a default/initial calibration for every supported display, or at less for the most used ones, like the ZynScreen, that it’s quite usable with the current included default calibration.
So … let’s do it!! We simply have to put this calibrations on the “custom” directory on zynthian-sys repository:
I will tune the config script for “applying” this default calibration when the display is changed from the config system.
In such a way, the calibration will be persistent until the display config is changed. Of course, we could make things a little bit more complex … but i think this would be enough given that calibrating the touchscreen is really simple with the tool and display config is not changed frequently on a working zynthian.
Regards,
I considered mandatory calibration at first boot but there are issues:
- Some builds don’t have touchscreens
- Some builds take several boots before they are working
- We should be able to configure most screens to provide good enough calibration out of the box
I would prefer to add a CUIA to trigger the calibration. This could be launched from webconf, OSC, etc.
@jofemodo I have refactored a lot of the code to simplify and improve device detection. I am just testing it then will commit.
I am not sure we should be applying a configuration via script at start-up. I would prefer to see the xorg calibration file populated with default settings. The calibration tool will modify that file so we can have the configs for all the known touchscreens in it and users may use the tool to calibrate as required.
@jofemodo I have pushed some updates but they require package python3-evdev. Can you add this dependency to an update?
YIKES - I have bust it! Too late to fix now. I will sort it in the morning.
Hi @riban!
Done!!
BTW, i also commited some changes to zynthian-sys that should fix the calibration persistence problem. But you should save the calibration file to the config dir like this:
$ZYNTHIAN_CONFIG_DIR/touchscreen/$DISPLAY_NAME
instead of wrting directly to the:
/etc/X11/xorg.conf.d/99-calibration.conf
The update_sys script will take care of copying the calibration when needed, allowing default configs and restoring of generated calibration files when changing the display from webconf.
Regards
I just tested the new changes and calibration doesn’t work very well now. I get bad calibrations, including bizarre effects like reversed axis. Before the last “pull”, it was working like a charm in my v4.
Regards,