7" Touchscreen Happenstance

Now, obviously, we build and play zynthian’s for no other reason than personal aggrandisement and the riveting view it provides of our towering intellects . . .

But even as we stare across the endless vista’s, considering our own peerless view, there are still small irritating parts of the world that refuse to resolve.
Take for instance a touch screen…

Simple enough in itself, once you have a fair ability to harvest some peculiar elements and refine a exceedingly precise manufacturing base. And yet, as soon as one let’s loose the slightest degree of manufactured intelligence into the beast, questions arise.

Question like, Why is the designers considered orientation of the device in default, completely at odds with my interpretation of up & down?
Why when one turns the lower left encoder of a remote controller it moves in a select list but won’t adjust a parameter, not even in the new wonder audio player. . .?

But these minor irritations pail into insignificance when faced with the perennial touchscreen problem.


Now it sounds like a small issue. The sort of thing that needs little more than a handy on-off switch in line with the whole device to address? well yes, that’s where you go first, but, and it’s important this one, you know that this isn’t really the correct solution. The real solution is to get the software reboot to work, like , well, it should…
These are after all raspberry designated products and have, presumably, been introduced at whatever passes for a passing out ball at Raspberry central. And yet it resolutely refuses. and it’s simply that in a zynthian role this renders the device largely untrustworthy on stage cos, to protect the simple frail brain of the zynthian. Rather than reboot a crashed zynthian from a conveniently placed browser, an event that happens rarely but can occur during the testing of testing to test some testing before trusting and such like, means that the what to do if it stops changes from.

1/ select system Reboot.
2/ say you are sure…
3/ Wait
4/ see screen doing it’s start up dance.
5/ reach Mixer screen
6/ Press keys on MIDI keyboard as advised by musical score playing on rosegarden screen…

1/ select system Shutdown.
2/ say you are sure…
3/ Wait for shutdown to complete.
4/ Get no indication shutdown is complete cos it’s shutting down…
5/ Stare over top of zynthian at the Pi’s LED’s to see the 8 fast beeps that meant file system written back in the Pi 2 days . . . wait and watch.
6/ Decide it’s all shut down.
7/ Turn off power to touchcscreen and Pi
8/ Wait
9/ see screen doing it’s start up dance.
10/ reach Mixer screen
11/ Press keys on MIDI keyboard as advised by musical score playing on rosegarden screen…

An interesting user journey, I hope you agree.

So the lack of a clean screen start was proving to be a real pain. So I tried playing around electrically . driven It’s powered from the GPIO 5V at the moment and doesn’t seem to require the OV connection, and connecting that makes no difference to the reset issue, reboot the Pi, No screen.

This problem occurred on the pedalboard but mysteriously went away when I accidentally broke the screen and substituted a screen I had in stick at home.

I didn’t really investigate further and just assumed that the poor brain of the screen had had it’s reset facilities blown away in some hideous wyleu experiment involving angularity accelerated crows smashing into ravens or similar, and though little more about it.

Until it occurred on zynthian -rack again. Exactly the same, and yet it wasn’t a problem on the screen next door running the OS…when I realised I was replacing a version 1.0 touchscreen with a 1.1…



Truely a heartwarming modern tale of overcoming all odds.

1 Like

So, are you saying it is fixed or are you looking for a band of merry gentlemen to go fishing in the undergrowth for solutions? If the latter you may wish to identify the screen type, manufacturer, type, connection, etc.

Thank you for your heartfelt concern…

I suspect that the 1.1 components address the problem so there is no need for you to slip into your galoushes and overly tight sou-wester to scrabble about in anyone’s undergrowth for solutions,. However, if such a thought was merely a heartfelt desire that saw an opportunity in my plight, then I will report back any further upheavals so you can still dream . . . .

Course there is a whole chapter I’ve left out and it’s about headers on boards…

Once again we are staring at the 7" screen with it’s strange air of authority and irritating inability to restart when asked ,politely, by the software to do so…
So , obviously I revisit the issue once in a while just to see if some update in the general raspberry/zynthian infrastructure has addressed the issue, and of course it doesn’t. But these revisits are accompanied by increasingly bizarre hardware solutions that need sometime surgical soldering to provide some newly derived power line that might kick the screen into life.

And in the end it happened. The accursed pin connector on the Pi screen PCB failed under the repeated reconnecting .
Whole thing sheered off. But I’ve got thru so many screens, only one actually broken, but other destroyed by heat & mounting glue failures and any other number of processes. So I have bits and pieces. And that’s when I noticed the component I was removing ran a version 1.0 Board and the incoming thingy was a version 1.1.
And as anyone who has followed this sorry saga knows, that’s were we stand/sit. So We have a working zynthian -rack.local.

I will probably be turning this into a three lp gatefold so anyone up for doing the artwork…?

When testing and debugging I will often run Zynthian using a debugger, launching the python script directly rather than via the bash script. Before doing this I stop Zynthian service using systemctl which blanks the screen and enables screensaver. To turn the screen back on I must:

echo 0 > /sys/class/backlight/*/bl_power

To disable 10 minute screensaver:

DISPLAY=:0 xset s off
DISPLAY=:0 xset -dpms
DISPLAY=:0 xset s noblank

Spotting a version 1.0 screen…