Hi @tunagenes ,
Maybe there’s an easiest way To do it now.
1 Like
In that aspect, it worked out of the box. The things that need to be fixed are related only to the external hardware: the LCD panel, buttons, touchscreen…
1 Like
Hey guys, I’ve finished the guide. I was not sure to where should I put it, so I created a github repo and placed it there:
Hope you find it useful! In case of error, please tell me here, and I’ll try to fix it as soon as posible.
Happy Synthing! 
4 Likes
Very nice documentation !
And even with the button config ! Very very cool Thanks !
1 Like
Good morning!
I found an issue when updating to testing (I would like to write a module to integrate my MIDI controller). The thing is that, in stable, everything works flawlessly, but in testing, the touchscreen does not work.
Is not a problem of the UI (I can control it using the buttons), nor the driver of the touch panel (as xinput shows it and evtest logs the correct numbers when I touch it). The log of Xorg does not show any error (I’ve compared both logs, testing and stable, and are basically the same, just some minor changes in the device numbers).
Also, /proc/bus/input/devices shows the TP, sometimes as event3 and others as event2, didn’t see it as event0 yet (could this be the problem?). [UPDATE: I’ve seen it as event0, but without any change in its behaviour]
Moreover, every now and then it seems to work at first, but just only during 2 or 3 seconds.
I’m out of ideas 
Does anyone have had a similar problem? Or has any clue? Every idea is welcomed! Thanks! 
UPDATE 2: Ok, things are getting stranger… It seems that it works OK at the beginning, on every boot, and when I kill the Xorg process (which Zynthian restarts). BUT, when I touch the lower part of the screen (higher Y axis), it stops working. 
I don’t think that is a faulty device, as in Zynthian stable it works perfectly.
More stranger things: with the TP working, if I print its xinput properties, it says that the device is not enabled (even though it is working):
xinput list-props seeed-tp
Device 'seeed-tp':
Device Enabled (145): 0
[...]
Then, I can ‘break’ it touching the lower Y axis part, and it stops working, as always. BUT, I can enable it again, using:
xinput enable seeed-tp
xinput list-props seeed-tp
Device 'seeed-tp':
Device Enabled (145): 1
[...]
And then, it works again, and I can use the whole screen! 
It won’t stop working until the next reboot, when the device is disabled again. I need to check why is it disabled in the first instance, but at least, the problem is easy to workaround.
UPDATE: For those wondering, I ended up adding the following systemd service to fix the problem:
# cat /etc/systemd/system/xinput-enable-tp.service
[Unit]
Description=Run xinput to enable seeed-tp device
After=zynthian.service
[Service]
Environment=DISPLAY=:0
Environment=XAUTHORITY=/root/.Xauthority
Type=oneshot
ExecStart=/bin/bash -c 'while ! $(xset q > /dev/null 2>&1); do sleep 2; done; sleep 5; xinput enable seeed-tp'
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
It waits until Zynthian and Xorg are running, and then, after 5 seconds, it does the xinput trick. It’s not the most elegant solution, but as X is handled by Zynthian, and I don’t want to loose the hack on the next update, I couldn’t come up with a better solution
3 Likes
This is a great write-up easy to follow.
Long time lurker and recently joined. I hade a determination collecting dust and followed these instructions. Thank you works great!
2 Likes
Great to meet you @Hans_JB. I am glad you have managed to build a working Zynthian. We look forward to hearing it… 
1 Like
@riban thank you. When I signed up I did a lot of discourse reading to get ready. I also got an ORAM version kind of working on a waveshare CM4-DISP-BASE-5A (https://www.waveshare.com/wiki/CM4-DISP-BASE-5A) with NVME SSD but a bit buggy. For that project I’ll patiently wait because some of the issues I have had already been mentioned here and getting worked on.
I just got my new RPi5 + NVMe working but there is an issue with webconf we need to fix.
2 Likes
I saw your post I. Oram/Pi5 Boot from NVMe? - #57 by riban
I will ask a question there.
@oscaracena
I decided to do a fresh flash of zynthian in the ReTerminal. Running the latest stable https://os.zynthian.org/zynthianos-last-stable.img.xz dated 4-10-2025
I’ve followed your instructions like before using the last 32 bit stable zynthianOS and everything was working great but now getting different results.
- Screen rotation is incorrect
- nano /usr/share/X11/xorg.conf.d/40-libinput.conf Is an empty file.
I did not get a chance to read the ReTerminal forum yet to see what changed on their side but wanted to check here and let you know. Do you still have your ReTerminal and do you have it running the latest ORAM. Let me know
Thanks.
Hi @Hans_JB
I still have the reTerminal, but I’m not using it anymore with Zynthian (I now have a V5), so I can not tell you what may happen. Anyway, it will be interesting to know if you manage to get it working again… 
1 Like
Ok no problem. I will try later on after work and post my finding
looks like lately I haven’t had the best luck with getting zynthian to display correctly with pieces I have that use to work before without issues by doing a clean install to ORAM from 32 bit OS.
I tried different things to get the ReTerminal display to be correct but it’s always portrait.
I’ve tried modifying wayfire.ini as described in ReTerminal forum which works with a fresh install of bookworm and getting the drivers but no luck with zynthian and the drivers.
Wayfire.ini—- [output:DSI-1]
mode = 720x1280@60
transform = 270
I’ve tried transform =0,90,180…no change at all
I’ve even tried modifying cmdline.txt and adding “video=DSI-1:800x480@60,rotate=180”, I can see the scrolling text change when I change rotate but ORAM lady and GUi always goes to portrait.
Frustrating!!!
This is just a shot in the dark, but you might be better off with Vangelis, or it might be even more frustrating.
Thanks for the suggestion but not gonna lie, I have not paid attention to Vangelis. Is there a big enough difference between ORAM and vangelis? If so what is it?
I don’t know what the current difference is, I have found in the past that sometimes switching to the test version (Vangelis) will get some new fixes and make Zynthian work when the latest stable did not work. So I thought it might be worth a try - your call.
You can search on Vangelis in the forum, or look at “Activity” for the major parts of Zynthian to get an idea of whats been done to Vangelis. It looks to me like the last time Vangelis was merged into Oram was Feb 2025, at least for zynthian-sys.
And, actually, now that I think about it, you might not be able to try Vangelis if you can’t get Oram running to update it to Vangelis.
Sure I might give it a try.
I can get ORAM working. The display orientation is incorrect.
I doubt that this is my issue with the screen rotation but can someone please tell me what this means
@jofemodo @riban
(venv) root@zynthian:~# systemctl status usb-gadget.service
× usb-gadget.service - USB gadget service
Loaded: loaded (/etc/systemd/system/usb-gadget.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Thu 2025-05-08 00:56:24 BST; 33min ago
Process: 720 ExecStart=/zynthian/zynthian-sys/sbin/setup_usb_gadget.sh (code=exited, status=1/FAILURE)
Main PID: 720 (code=exited, status=1/FAILURE)
CPU: 30ms
May 08 00:56:24 zynthian systemd[1]: Starting usb-gadget.service - USB gadget service…
May 08 00:56:24 zynthian setup_usb_gadget.sh[720]: /zynthian/zynthian-sys/sbin/setup_usb_gadget.sh: line 33: echo: writ>
May 08 00:56:24 zynthian systemd[1]: usb-gadget.service: Main process exited, code=exited, status=1/FAILURE
May 08 00:56:24 zynthian systemd[1]: usb-gadget.service: Failed with result ‘exit-code’.
May 08 00:56:24 zynthian systemd[1]: Failed to start usb-gadget.service - USB gadget service.