No problem. I don’t use this synth. Just thought I should mention the issue.
Image was fresh burned this morning, only config changes are keybindings. No changes in the synth settings. Other synths work fine.
Hi @harrylnorris, and probably @jofemodo
I ran into the same issue. Could you elaborate about this issue?
I have a custom zynthan with a PI5 an 8" Waveshare display on hdmi and my current display profile look like this:
#Display Config
export DISPLAY_NAME="Generic HDMI/DSI Display"
export DISPLAY_CONFIG="disable_overscan=1\nhdmi_force_hotplug=1\nhdmi_drive=1\nhdmi_group=2\nhdmi_mode=87\nhdmi_cvt=1280 800 60 6 0 0 0\ndtoverlay=vc4-kms-v3d-pi5,noaudio"
export DISPLAY_WIDTH="1280"
export DISPLAY_HEIGHT="800"
export FRAMEBUFFER="/dev/fb0"
export DISPLAY_KERNEL_OPTIONS=""
zynthian.sh outputs this:
X.Org X Server 1.21.1.16
X Protocol Version 11, Revision 0
Current Operating System: Linux zynthian 6.18.34+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.18.34-1+rpt1 (2026-06-09) aarch64
Kernel command line: reboot=w coherent_pool=1M 8250.nr_uarts=1 pci=pcie_bus_safe cgroup_disable=memory numa_policy=interleave nvme.max_host_mem_size_mb=32 numa=fake=8 system_heap.max_order=0 iommu_dma_numa_policy=interleave smsc95xx.macaddr=2C:CF:67:A9:28:14 vc_mem.mem_base=0x3fc00000 vc_mem.mem_size=0x40000000 root=PARTUUID=e249d476-02 rootfstype=ext4 fsck.repair=yes rootwait console=tty1 logo.nologo modules-load=dwc2,libcomposite
xorg-server 2:21.1.16-1.3+rpt1+deb13u2 (https://www.debian.org/support)
Current version of pixman: 0.46.4
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sat Aug 1 16:44:36 2026
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE)
Fatal server error:
(EE) Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices
(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
(venv) root@zynthian:~#
Another issue: Sometimes when shutting down zynthian, the background light of the physical buttons stays on, while the rest of the unit is off (Display, RasPi). Original V5 kit.
I (hopefully) solved it by installing gldriver-test like documented here:
1 Like
Please. We want to fix this. It’s important . Not using the synth doesn’t fix the issue. And believe me, it’s a great synth that you may want to use!!
What changes? Please, be detailed. Try to remember what did you change.
If not, please, fresh burn a SD with the image and try the Vaporizer. It should work out the box.
Then do your config changes, step by step, testing the vaporizer engine, until you can reproduce the error. This will be really helpful.
AFAIK, currently you are the only user with this issue so you are the only user that can help to reproduce and fix.
Thanks !
1 Like
Hi @travelrec !
Please, “sometimes” is not very precise. Could you be more specific?
And how are you powering off the device?
BTW, have you read my message above about reporting errors that we can reproduce and solve? Please, help us to fix things in a productive way for all of us!
Thanks!
Hi @jofemodo ,
sorry to be imprecise, but it happens sometimes and sometimes not. The unit was shut down in the last case with the Shutdown option on the power screen, where you can push on the soft buttons “Cancel”, “Shutdown” and “Reboot”. After several tests I think I have found 2 different ways the unit will go while powering down: There is an immediate shutdown after pushing the soft button “Shutdown”, the display gets empty, backlight goes off, button light goes off, then unit goes completely off. So far, so fine. The other way is: The same like above, but before the unit goes completely off, the vangelis screen with the message “Shutting down” appears for a short time. Then, the button light is activated again, then the vangelis screen disappears and the busy icon is visible for a short time, then the display and unit go off, but the button light stays on.
1 Like
Hi.
I had the same issue with a bare Pi5 and HDMI. It won’t work until the file is created as written in this post mentioned earlier.
Create 99-vc4.conf in /etc/X11/xorg.conf.d/ with the following content:
Section "OutputClass"
Identifier "vc4"
MatchDriver "vc4"
Driver "modesetting"
Option "PrimaryGPU" "true"
EndSection
With this little fix it booted and worked normally.
BTW: The autoconfig routine got even worse. It identified my Pi5 as a V4, essentially disabling all the nice parts, speed and benefits of Pi5. To get aroud this, I have to follow these steps:
- Burn the Zynthian Beta Image to MicroSD
- Put SD in Linux machine,
- Add the file in
/etc/X11/xorg.conf.d/as mentioned above - Connect bare Pi5 with HDMI+USB screen
- Connect Generic USB Audio – this is important to ever reach Webconf
- Insert the SD-Card in Pi5
- nothing else connected, especially nothing on i2s and i2c – nothing!
- Power supply
- Boot Pi5 with fresh modified image, let Zynthian’s autoconfig do havoc as intended
- In Webconf disable Last State – this is important, otherwise it will not work
- Reboot once more
- Power down via Admin menu or power button
- Connect HiFiBerry DAC+ADC 2 Pro or whatever sound card you want to use
- Connect V5 keypad via i2c and GPIO if you have this
- Power up
- Via Webconf setup the real hardware – do not reboot if Webconf asks to do so, just do all config as needed without rebooting
- Power down after everything is configured as intended
- Unplug Generic USB Audio
- Power up
- Enjoy
Over all a nasty fuss, but actually it does not look like this image is any better than an updated earlier image. How to identify? uname -r?
1 Like
Ohhh yes!! This is a lot better, @travelrec !!
Thanks for being precise and detailed. With this i can figure what is going on and try to solve it …
Regards
2 Likes
This should not be needed anymore. We solved this issue some time ago and now webconf should work without a sound interface.
Please, could you confirm we don’t have a regression with this?
Thanks!
I’ve tried without USB Audio, it counts Audio MIDI error until (11) and hangs forever. No Webconf reachable.
Same issue here. “Sometimes” is the best statement.
About 5 to 20 times the keypad LEDs turn off with shutdown, then they once stay lit after shutdown, then next time, without changing anything, they turn off again with shutdown.
The pattern is random with more chance to turn off the keypad LEDs when shut down.
It seems to get worse with overclock and WiFi active, or if a bag of rice tips over in China.
This is true if I understand correctly. Autoconfig regognized my custom PI5 as a V4.
The problem is solved.
It was caused by preset conflicts.
I have the zynthian-my-data directory separate from the rest of the installation, so that I can remove it during major updates.
There are gigabytes of samples, presets, captures and other stuff on it, so I don’t want major updates messing with that.
Apparently the presets directory that was found was in conflict with the new installation so the presets were shown, but not working for the engine. I regenerated them and now everything works.
It is difficult to make a strict distinction between system data and user data.
Obviously this is something I have to keep in mind for other instruments.
3 Likes
By the way, gldriver-test created a file named 99-v3d.conf with the exact content.
Maybe because I use
dtoverlay=vc4-kms-v3d-pi5,noaudio
Hi @fussl !
This seems to fix the issues with generic HDMI displays. I just pushed the change, so please, update to get the fixes. Thanks!
Although updating the BETA should fix things, I will upload a new BETA in the next days for those who want to get things working right on first boot.
Anyway, remember that you can reset the image to the factory state using this command:
set_first_boot.sh
So you can easily test the first boot process after updating the image as many times as you want. And you would help a lot by doing so 
Thanks for your patient and help.
Regards,
BTW: This Beta Image:
root@zynthian:~# uname --all
Linux zynthian 6.18.34+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.18.34-1+rpt1 (2026-06-09) aarch64 GNU/Linux
After apt update, apt full-upgrade, apt dist-upgrade, apt autoremove with reboots inbetween it is now:
root@zynthian:~# uname --all
Linux zynthian 6.18.39+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.18.39-1+rpt1 (2026-07-29) aarch64 GNU/Linux
and it seems to be snappier and everything seems to work as intended. Not found any new issue after this upgrade.
Is there a reason why the Beta Image is made on outdated Trixie?
No. I simply didn’t note it was outdated. I was focused in other subjects.
The final realease will be totally updated. Promise 
Regards!
2 Likes
Hi @HansR !
Nice that you managed to fix the issue.
This is a major tweak that you should ALWAYS note when reporting an issue.
Please, don’t forget it next time.
Thanks!
I don’t think this is anything I did, notice the Timestamp: 2027-07-27 in the login screen:
########################## ----------------------------------------
# # ZynthianOS Vangelis-2607-1
# ## # Timestamp: 2027-07-27
# ## # # ## # Built from RaspberryPiOS Trixie (aarch64)
# # # # # # # # ----------------------------------------
### # # # # # # ### Kit: Custom
# # # # # # # # # # Display: Raspberry Pi Touch Display 2 (7 inch)
# ## # # # # ## # Soundcard: Generic USB device
# ## ## # Wiring Layout: TOUCH_ONLY
# # ----------------------------------------
##########################
zynthian-ui: vangelis (921d9d)
zynthian-webconf: vangelis (61ef41)
zyncoder: vangelis (6528ec)
zynthian-sys: vangelis (8e07a4)
zynthian-data: vangelis (9ab25e)
---------------------------------------