Thank you @nerd
That is very clear and I will revert to version 3 pending release of 4.100.
The PSU I’m using, although not a Rasp Pi model, is supposed to supply 2.5A. Clearly it doesn’t! I shall replace it immediately.
Many thanks again.
Well ok…no answers or solutions here…
Downgraded to Volumio 3.907 so touch display and peppymeter work again…
Hoping for a better update then…
How do you expect that we can support you, when posting a one-liner?
What we know so far:
I get an error message: ENOENT: no such file or directory, stat ‘/tmp/.X11-unix/X0’
No logs, no HW info, No version info, No explanation when this happens
I was replying to my own topic posted a while ago:
I guess that reply went wrong, but I did post all my info in that topic.
Maybe no one paid attention…
I don’t have any useful information available right now, but have the same problem. Had some problems with my screen at installation, solved it, installed most recent stable version (I’ve been using it for some weeks, but checked for update yesterday without any updated, but don’t have the number in top of my head, think it is 4.096). No output from touch display plugin, but warnings about bad power supply and also volumio logo at startup, so the display is working but not X11. From web interface I see the exact same message as above ENOENT: no such file or directory, stat ‘/tmp/.X11-unix/X0’
I’m runing on a pi3B+ from SD-card.
Not much information to fault trace at al, I know, just an indication that you are not the only one facing this issue. I maybe get the logs this evening if more data is needed to track down the issue.
So far I see, you’ve added the same to /boot/config.txt as /boot/userconfig.txt
You should NOT add settings to /boot/config.txt, as mentioned in the header.
# cat /boot/config.txt ---------------
### DO NOT EDIT THIS FILE ###
### APPLY CUSTOM PARAMETERS TO userconfig.txt ###
It seems you tried to install/update multiple packages simultanious, causing multiple errors:
Feb 14 19:36:50 volumio volumio[1382]: dpkg: error: dpkg frontend lock was locked by another process with pid 2356
Feb 14 19:36:50 volumio volumio[1382]: Note: removing the lock file is always wrong, can damage the locked area
Feb 14 19:36:50 volumio volumio[1382]: and the entire system. See .
Feb 14 19:36:50 volumio volumio[1382]: rm: cannot remove '/usr/bin/chromium-browser': No such file or directory
Feb 14 19:36:50 volumio volumio[1382]: E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2356 (apt-get)
Feb 14 19:36:50 volumio volumio[1382]: E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
Feb 14 19:36:50 volumio volumio[1382]: E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2356 (apt-get)
Feb 14 19:36:50 volumio volumio[1382]: E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
Feb 14 19:36:50 volumio volumio[1382]: E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2356 (apt-get)
Feb 14 19:36:50 volumio volumio[1382]: E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
Feb 14 19:36:50 volumio volumio[1382]: rm: cannot remove '/opt/volumiokiosk.sh': No such file or directory
To avoid running into orphaned issues:
- perform a factory reset
- Don’t do things simultanious but one by one
- Don’t add anything to
/boot/config.txt, but use/boot/userconfig.txt - There is a plugin for your screen setup, called:
Pi Screen Setup. Use that to configure your screen - Reboot
- wait untill it’s fully booted and install
Touch Displayplugin
Thnx,
I already changed that after my post.
Did fresh install, new image, tried several solutions found here and everywhere, but the X server fault stays or comes back in different shapes…
So far the only thing where my touch display actually works is with a downgrade to Vol.3.
Display works, peppymeter works, si I will just wait for an update on either Volumio itself or the plugin…
Hey @Barfo,
Thanks for providing the log and the details. I have gone through the log (JO6G3ky) thoroughly and there are several problems visible in it. I will break them down below.
What the log shows:
- /boot/config.txt was directly edited
As @Wheaten already pointed out - despite the “DO NOT EDIT” header, config.txt contains manual additions below the include directives: gpio-shutdown, enable_uart, hdmi_group, hdmi_mode, hdmi_cvt, hdmi_drive, and dtoverlay=hifiberry-dac (twice). The same parameters also appear in /boot/userconfig.txt. This double-loading creates unpredictable behaviour as the firmware processes the same directives multiple times.
- Touch Display plugin never installed successfully
As @Wheaten already pointed out - the log shows three consecutive install attempts within approximately one minute (19:35:42, 19:35:56, 19:36:17). The first attempt started an apt-get update which took the package lock. The second and third attempts ran into that lock and failed with “Unable to locate package openbox”, “Unable to locate package xinit”, “Unable to locate package x11-utils” - not because the packages do not exist, but because apt-get update never completed for those attempts. The plugin was rolled back and removed each time. At the time of logging, Touch Display was NOT installed - meaning there was no X server, no Chromium kiosk, nothing to display after the boot splash. Screen going dark after the Volumio logo is the expected result with no display plugin installed.
- DAC overlay conflict
/boot/userconfig.txt contains dtoverlay=hifiberry-dacplus, but /boot/config.txt contains dtoverlay=hifiberry-dac (twice). These are different hardware drivers:
- hifiberry-dac = PCM5102A (no I2C control)
- hifiberry-dacplus = PCM512x (requires I2C)
The kernel log confirms: “pcm512x 1-004d: Failed to reset device: -121” - this is an I2C communication failure. If your DAC is actually a HiFiBerry DAC (not DAC Plus), the dacplus overlay is wrong and will fail. If it is a DAC Plus, the duplicate hifiberry-dac overlays loaded from config.txt may be interfering.
- HDMI disabled by firmware
The kernel command line shows the firmware injected snd_bcm2835.enable_hdmi=0 (twice) and snd_bcm2835.enable_headphones=0 at the front of the boot parameters. This is a direct consequence of hdmi_drive=1 being set, which forces DVI mode (no audio). The firmware detects DVI and disables HDMI audio. More importantly, the display configuration being processed twice from both config.txt and userconfig.txt is causing the firmware to react in ways that may affect display initialisation.
What is needed now:
The log above is from BEFORE any remediation. You mention having done a fresh install since then and that the problem persists. I cannot work with the old log to diagnose the current state - too much has changed (or should have changed) between then and now.
Please provide:
- A fresh log from the current system, retrieved from http://volumio.local/dev or http://192.168.1.166/dev (use whichever works from a browser on another device on the same network)
- Do NOT reboot before sending the log - I need to see the current running state
- Confirm what you mean by “fresh install” - did you reflash the SD card with a new Volumio 4 image, or did you use the factory reset option?
- Confirm your exact DAC model - is it a HiFiBerry DAC or HiFiBerry DAC Plus?
Once I have the current logs, I can see whether the config.txt contamination is cleared, whether the Touch Display plugin installed correctly, and what the firmware is doing with the display configuration.
Kind Regards,
Well, like i said in previous post after fresh install, new image (and sdcard) problems still where there, hence the downgrade to 3.907.
So I can’t give you any other logs than provided. 4.096 works fine btw, it’s just the display that doesn’t work…
I’ll keep a look out for new updates. Thnx for trying!
Hey @Frisk,
Your post confirms you see the same ENOENT error as @Barfo, but contains nothing that can be investigated. You acknowledge this yourself, so I will use this response to set expectations clearly.
First - a point that applies to everyone in this thread, not just you.
Volumio 4 has gone through rapid iterative development. Versions have moved from 4.067 through 4.096 in a matter of months, each with kernel changes, networking rewrites, plugin updates, and hardware handling modifications. Expecting community volunteers to track hundreds of users’ individual DIY configurations across scattered posts, different hardware, different versions, and different plugin combinations is unrealistic. It is not possible and it is not going to happen.
The burden of accuracy and containment sits with the person asking for help. That means: one post, one problem, all required information present, self-contained. Volunteers should not need to cross-reference your December post about the RASPDAC Mini on a Pi 4B, your January post about the Primo, and this February post about a Pi 3B+ to piece together what you are running and where. Each report must stand on its own.
Now - the specific problems with this post.
Display type - critical ambiguity
You say “No output from touch display plugin.” You own an Audiophonics RASPDAC Mini LCD. That unit uses a small SPI/I2C LCD driven by the RaspDacMini LCD plugin - which is a completely different plugin from the Touch Display plugin. These are not interchangeable. The Touch Display plugin drives HDMI or DSI touchscreens via X11 and Chromium. The RaspDacMini LCD plugin drives the small built-in case display via a Python compositor.
Which display are you actually trying to use on this Pi 3B+? What type is it? How is it connected? Is this the RASPDAC Mini unit or a different setup entirely?
Version
“think it is 4.096” is not acceptable. Open the web interface, go to System Information, and confirm the exact version number. 4.096 is the current stable release (10 February 2026), but guessing is not confirming.
Plugin version
Which version of the Touch Display plugin is installed? This is visible in the plugin settings page.
Power supply
You mention “warnings about bad power supply.” This is a kernel undervoltage detection event. On a Pi 3B+, undervoltage causes CPU throttling and can cause process startup failures - including X11. If the power supply cannot maintain stable 5V under load, X11 may fail to start, and that failure produces exactly the ENOENT /tmp/.X11-unix/X0 error you describe. This is potentially a hardware problem, not a software problem. What power supply are you using? Rating? Cable type and length?
Log link
You said you might get logs this evening. Do that. The log link from http://volumio.local/dev is mandatory. Without it there is no investigation.
userconfig.txt
Paste the complete contents of /boot/userconfig.txt.
Pattern note
AT254585 reported the same ENOENT error on Pi 3B with V4.073 and Touch Display 3.6.0 in the Touch Display plugin thread (post 1787). That user resolved the problem following instructions from the plugin maintainer. I recommend reading that thread for context:
To summarise what is needed before any investigation can begin:
- Confirm exact Volumio version from System Information
- Confirm which display type, model, and connection method
- Confirm which plugin (Touch Display or RaspDacMini LCD)
- Touch Display plugin version
- Log link from http://volumio.local/dev
- Complete /boot/userconfig.txt contents
- Power supply make, rating, cable details
- Pi 3B+ revision code per: [GUIDE] Identifying Your Raspberry Pi Board on Volumio: A Comprehensive Guide to Revision Codes
Please also review the help request guidelines:
Kind Regards,
Hey @Barfo,
Understood - since you are back on 3.907 there is nothing more to diagnose right now.
For when you decide to try Volumio 4 again, here is what the old log showed went wrong and what to do differently:
-
Do NOT touch /boot/config.txt - ever. All custom parameters go exclusively in /boot/userconfig.txt. The old log showed both files contained the same hdmi and overlay entries, which caused double-loading and firmware conflicts.
-
Install the Touch Display plugin ONCE and WAIT. The old log showed three install attempts fired within one minute. Each attempt fought the previous one for the package manager lock, and all three failed. After a fresh boot, install the plugin once and give it several minutes to complete. Do not click install again if it appears slow.
-
Clarify your DAC model. The old log had dtoverlay=hifiberry-dac in config.txt and dtoverlay=hifiberry-dacplus in userconfig.txt. These are different drivers for different hardware. If your DAC is a HiFiBerry DAC (PCM5102A), select that in Volumio’s playback settings. If it is a DAC Plus (PCM512x), select that instead. Do not manually add dtoverlay lines - let Volumio manage the DAC overlay through the I2S DAC selection in Settings.
-
Use the Pi Screen Setup plugin for display configuration. It manages /boot/videoconfig.txt and handles display parameters properly. Do not manually add hdmi_group, hdmi_mode, hdmi_cvt, or hdmi_drive to userconfig.txt.
-
Keep userconfig.txt minimal. On a clean install, only add what is not managed by Volumio itself. For your setup, that would be gpio-shutdown and enable_uart if you need those. The DAC overlay and display settings should be managed by Volumio and the respective plugins.
If you try V4 again and it still does not work after following the above, send a log from http://volumio.local/dev BEFORE rebooting or making any changes, and I will take another look.
Kind Regards,
1 Like
Thanks for your reply @nerd I wasn’t really expected any reply at my post, just wanted to confirm that more people hade seen similar behavior. I haven’t had time to do any investigation or take any logs, why I neither haven’t asked about it previously. But got some really good input from the latest replies now so I’ll try to do some investigation. Maybe first step is to change the power supply. I’m a bit short of micro USB ones. Right now I just used a HD-fury adapter I found in top of the drawer, probably maximum 1A together with a Blitzwolf flat cable.
All to little information to do any investigation on. I’ll try some own fault tracing and might ask for help later on if I can’t find anything myself.
1 Like
Now I might have some better information, thug kind of messy logs.
Arrived home for a really short time. Changed power supply from HDfury supply, showed up to be 2A to a Deltaco supply which was deliverd together with an used Audiophonics raspiplayer: (AUDIOPHONICS RASPDAC MINI LCD Kit DIY Streamer for Raspberry Pi 4 & DAC ES9038Q2M - Audiophonics) rated 2,4A (but showed up to still give warnings)
Didn’t had any plans/time to play any music so didn’t start neither DAC nor amplifiers.
Started uninstall of touch display plugin from cellphone web browser, display went black and any installation progress disappeared.
Started an computer to have some better progress feedback, clicked install and left home.
Back home I started installation of touch display 3.6.0 which instead uninstalled it.
Let it take some time and after again installed it. Progress went on and finally stated successfully installation.
Started the plugin but still didn’t got any HMI on the screen.
The hardware in this instance is raspberry pi3B+ with some more or less generic 1024 x 600 3,5" HDMI screen connected at the pi 40 pin header for SPI touch screen interface.
The pi is running from an SD-card at 16GB. Power supply 2,4A Deltaco.
It was working at last stable release, which I haven’t noted down the version number of (4.088?). Now I’m running 4.096.
Logs are here:
https://logs.volumio.org/volumio/pBRtvgN.html
Now when the DAC is powered off it correctly tells playback isn’t possible and doesn’t show and time process. Neither any stop button. But there’s still some progress in background where it goes through the playlist which can be clearly seen with a lot of warnings in the logs.
Hey @Frisk,
Thank you for the log. It reveals several problems, some of which interact with each other.
Confirmed from the log
- Volumio 4.096 (build date 5 February 2026)
- Raspberry Pi 3 Model B Plus Rev 1.3
- Kernel 6.12.47-v7+
- Touch Display plugin 3.6.0 - enabled, status reports STARTED but Xorg is dead
- Pi Screen Setup plugin 0.7.4 - enabled, active
- 16GB SD card
- 2.4A Deltaco power supply
- No USB devices connected other than the Pi 3B+'s own onboard USB/Ethernet hub
- No I2S DAC overlay loaded
- Audio output configured for “Hugo M SCALER” which is not present
Problem 1 - Xorg fatal error (direct cause of your symptom)
The log shows Xorg crashing on startup, twice:
Line 2368:
(EE) Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices
Same error repeats at 17:13:43 on the second attempt. The sequence is: Xorg crashes, xinit gives up with “unable to connect to X server: Connection refused”, volumio-kiosk.service fails, touch_display plugin then reports “Xserver unix domain socket cannot be determined” - which is the ENOENT error you see in the web interface.
The KMS driver IS loaded at kernel level (line 1231: “Initialized vc4 0.0.0 for soc:gpu on minor 0”). The problem is not the kernel driver. The problem is Xorg cannot use the modesetting driver because of what is in your userconfig.txt.
Problem 2 - configuration conflict (this is why Xorg fails)
You have pi_screen_setup v0.7.4 installed and running. This plugin manages display configuration through /boot/videoconfig.txt. Your config.txt correctly includes videoconfig.txt.
But your userconfig.txt contains legacy pre-KMS HDMI parameters:
config_hdmi_boost=10
dtoverlay=ads7846,penirq=25,speed=10000,penirq_pull=2,xohms=150
hdmi_force_hotplug=1
config_hdmi_boost=10
hdmi_group=2
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0
Since config.txt includes files in this order - volumioconfig.txt, then videoconfig.txt, then userconfig.txt - your manual parameters override whatever pi_screen_setup configured. The plugin detects this and flags it on every boot:
pi_screen_setup: Boot validation - valid:false, drift_detected:true, config_mismatch:true, errors: ERR_CONFIG_MISMATCH
Use either plugin or manual setting, but not both.
The hdmi_group, hdmi_mode, and hdmi_cvt parameters are firmware-level framebuffer settings from the pre-KMS era. They conflict with the KMS video pipeline that both pi_screen_setup and the Touch Display plugin require. This is almost certainly why Xorg cannot start.
Additionally, config_hdmi_boost=10 appears twice in your userconfig.txt.
Additionally, dtparam=spi=on appears in config.txt AFTER the include block, outside any managed section. This should not be there - it belongs in userconfig.txt. Someone or something has edited config.txt directly, which must never be done.
Problem 3 - undervoltage (severe, recurring)
Line 1571:
hwmon hwmon2: Undervoltage detected!
From 15:49 onward, the kernel logs rapid cycling between “Undervoltage detected” and “Voltage normalised” every 2-10 seconds, continuously. The 2.4A Deltaco supply is not maintaining stable 5V under load.
I need a complete hardware inventory of everything physically connected to this Pi 3B+. Every port, every socket, every cable. Power starvation travels down the Pi’s circuitry and what looks like a software problem could be electrical.
Provide the following:
Physical connections - account for every port on the Pi 3B+:
- Power input: exact model from the Deltaco label, cable length, connector type (micro USB?), any extensions or adapters in the chain
- HDMI port: what is plugged in? Cable type and length? Where does it go - directly to the display or through any adapter/splitter?
- USB ports (4x on Pi 3B+): what is in each one? Account for all four. If empty, say empty
- Ethernet port: cable connected? To what?
- GPIO 40-pin header: what is physically attached? The display SPI touch interface? Anything else - DAC HAT, relay board, anything at all?
- CSI camera port: anything connected?
- DSI display port: anything connected?
Power chain specifically:
- Wall socket to power supply - any extension leads, power strips, surge protectors, multi-socket adapters in the path?
- Does the display draw power from the Pi (via GPIO 5V pins, via USB, via HDMI)? Or does it have its own separate power supply?
- Is anything else drawing power from the Pi’s 5V or 3.3V GPIO pins?
- When you say the DAC is powered off - is the DAC physically disconnected from the Pi, or just switched off at its own power switch? If it is still physically connected via I2S/GPIO, it may still draw parasitic current
This matters because a Pi 3B+ with a 2.4A supply has very little headroom. The Pi itself draws roughly 1.2-1.4A under moderate load. If the display draws power from the Pi’s GPIO 5V rail, and the SPI touch controller adds load on top of that, you may be right at the threshold where the supply cannot cope. The continuous undervoltage cycling in the log strongly suggests this is happening.
Problem 4 - audio output misconfiguration
The log shows:
warn: Unable to locate the audio output device Hugo M SCALER
MPD is configured to output to a Chord Hugo M Scaler which is not connected. No USB DAC is present in lsusb. No I2S DAC overlay is loaded. This generates continuous errors as MPD attempts to use a non-existent device. You mentioned the DAC is powered off - but Volumio is still configured to use it as the output device.
What you need to do
-
Provide the complete hardware inventory above. Every port, every socket, every cable, every power path
-
Clean up userconfig.txt. Remove all the legacy HDMI parameters. If pi_screen_setup is managing your display, let it manage it. Your userconfig.txt should contain only what pi_screen_setup does not handle. Right now the two are fighting each other
-
Fix config.txt. The dtparam=spi=on line that appears after the include block needs to be removed from config.txt and placed in userconfig.txt instead. config.txt must never be manually edited
-
Do not reboot or change anything else until you have provided the hardware inventory. If this is power starvation, software changes alone will not fix it
Kind Regards,
As always, thanks for a very detailed reply! Not just a solution but also very good explanations in an educational way! Very very appreciated and one of the reasons to stay at and value Volumio high.
I believe kind of the mess results of patches at patches to get things work without really taking the time to think things trough. First I had problems, kind of solved it after finding old notes how I solved it years back. After update got problems again, read about Pi screen setup and just installed it without thinking of other dependencies etc. etc.
The hardware is as you found an Hugo M SCALER connected trough USB but powered off (even the power chord disconnected) This goes to a Chord Hugo TT2 also powered off and without power. This is connected to the bottom right USB port, other side of ethernet port.
The other three USB ports has nothing connected.
Realized I didn’t answered for the other ports:
- CSI camera port: anything connected? Nothing connected.
- DSI display port: anything connected? Nothing connected.
The display is a pi hat is of this model: Amazon.com: 3.5 inch LCD Screen for Raspberry, 60fps 3.5 inch LCD Display for Raspberry with Black Acrylic Case, 320x480~1920x1080 Adjustable Resolution : Electronics Connected to the 40 pin header to power and communication. This also has an Micro USB port but this doesn’t have any power connected. Just connected trough the “HDMI-jumper”, no other cables.
Power adaptor right now is Deltaco USB-AC58 Rev 5. With cable. https://digitalzone2u.com.my/product/remax-full-speed-series-cable-quick-charger-data-1000mm/
No ethernet cable are connected just (a bit too weak) WiFi connection.
All connections:
40 pin header to display, nothing other connected at this.
One USB output to DAC/SCALER and one power cable. One Micro SD-card.
I turned off the screen with the on/off button but still see hwmon hwmon2: Undervoltage detected! errors in live log. Playback is stoped and nothing connected (other than powered off Hugo M SCALER.
Removed the line from config.txt and also removed duplicate configuration from userconfig.txt.
Here is the log. I’ll now power up MSCALER and restart:
http://logs.volumio.org/volumio/RfuBaxc.html
After power up MSCALER I don’t see any low voltage warnings. Didn’t expect the powered off USB device to drain current.
I added an USB power meter in the USB path from pi to M SCALER, When the scaler is off, disconnected from grid, it indicates 0.00A and when the scaler is on it measures 0.08A But I didn’t managed to play any music with the meter connected.
Log file after reboot:
http://logs.volumio.org/volumio/Y9nG4Em.html Still no HMI visible at screen.
Hey @Frisk,
Thank you for the follow-up logs and the hardware details. Good progress on two fronts, but the core display problem remains.
What improved
- Pi Screen Setup configuration conflict - resolved
The boot validation now passes clean (Y9nG4Em log, line 2608):
pi_screen_setup: Boot validation - valid:true, drift_detected:false, config_mismatch:false, errors: []
Commenting out the legacy HDMI parameters in userconfig.txt eliminated the conflict between your manual settings and pi_screen_setup’s managed configuration. The plugin is no longer fighting your userconfig.txt on every boot.
- Undervoltage - resolved
The first log (RfuBaxc) with the M SCALER powered off but physically connected showed 2253 undervoltage events. The latest log (Y9nG4Em) with the M SCALER powered on from mains shows exactly 1 undervoltage event during early boot, which is normal transient behaviour.
The Chord Hugo M SCALER was drawing enough parasitic current through the USB data lines to destabilise your 2.4A supply, even with its own power disconnected from the wall. USB devices can draw up to 500mA from VBUS on the host side even when their own main power supply is disconnected - the USB specification allows this for device enumeration and standby. In your case, with the display already drawing approximately 0.5A from the GPIO 5V rail, adding any USB parasitic draw pushed the Deltaco supply past its limits.
Going forward: either keep the M SCALER powered from mains whenever it is physically connected to the Pi, or physically disconnect the USB cable when the M SCALER is not in use.
What has NOT changed
Xorg still crashes with the identical fatal error (Y9nG4Em line 2674):
(EE) Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices
The full sequence is unchanged: Xorg starts, immediately hits this fatal error, xinit gives up with “unable to connect to X server: Connection refused”, volumio-kiosk.service fails, and the Touch Display plugin reports “Xserver unix domain socket cannot be determined”.
The KMS driver loads correctly at kernel level (line 1485: “Initialized vc4 0.0.0 for soc:gpu on minor 0”). The problem is in Xorg’s userspace configuration, not the kernel driver. But the journalctl log does not include the files Xorg reads at startup, so I cannot see why Xorg refuses to use the modesetting driver.
What I need next
Before rebooting (important - /var/log is tmpfs, meaning volatile RAM, contents are lost on every reboot), SSH into the Pi and run these commands. Paste the complete output of each one:
cat /boot/videoconfig.txt
This shows what pi_screen_setup actually wrote for your display configuration.
ls -la /etc/X11/xorg.conf.d/
This shows what Xorg configuration files exist.
cat /etc/X11/xorg.conf.d/99-vc4.conf
This shows what the Touch Display plugin configured for Xorg’s video driver.
ls -la /dev/dri/
This confirms the DRM device nodes exist and are accessible.
cat /sys/class/drm/card0-HDMI-A-1/status
This shows whether the KMS driver detects your display as connected.
cat /sys/class/drm/card0-HDMI-A-1/modes
This shows what display modes the KMS driver offers for your HDMI output.
cat /var/log/Xorg.0.log
This is the most important one. It contains the full Xorg startup trace - which driver it attempted, what hardware it found, and the complete diagnostic chain leading to the “Cannot run in framebuffer mode” error. The journalctl output only shows the final failure, not the reasoning.
Note on the display hardware
The Amazon listing is from “Sanpyl Store”, not Waveshare. Waveshare’s own wiki page includes an anti-piracy warning about clones. This display is almost certainly a third-party copy. For this investigation that does not change the approach - the HDMI video interface and ADS7846 SPI touch controller are standard components regardless of board manufacturer. If the Volumio logo appeared at boot, the HDMI path works at the firmware level.
Based on research into the display’s origins, the waveshare-ads7846.dtbo overlay from the Waveshare wiki is a standard ADS7846 touch controller overlay - decompilation confirms it only handles SPI touch input, not video. Touch is completely separate from the display problem and can be addressed after Xorg is working.
One thing at a time.
Kind Regards,
Thanks again for a very educational reply!
I’ll try to catch all data asked for.
Regarding the screen it looks just like the one in my link but I purchased it from some other seller. It was purchased long time ago so I don’t remember where, probably ebay, banggod or ali express or maybe dealextreme. The display itself has been working fine before so I believe the hardware is OK after all.
cat /boot/videoconfig.txt:
### pi_screen_setup managed - DO NOT EDIT ###
# Generated: 2026-02-23T17:44:46.076Z
# Model: Raspberry Pi 3 Model B Plus Rev 1.3
# KMS Display Driver
dtoverlay=vc4-kms-v3d,cma-64
# HDMI0 Configuration
hdmi_ignore_edid=0xa5000080
hdmi_group=2
hdmi_mode=87
hdmi_cvt=1024 600 60 6 0 0 0
hdmi_drive=1
ls -la /etc/X11/xorg.conf.d/:
total 8
drwxr-xr-x 1 root root 1024 Feb 28 11:58 .
drwxr-xr-x 1 root root 1024 Feb 27 17:01 ..
-rw-r--r-- 1 root root 546 Dec 21 17:30 10-volumio-fbdev.conf
-rw-r--r-- 1 root root 300 Feb 27 16:55 95-touch_display-plugin.conf
-rw-r--r-- 1 root root 187 Dec 21 19:46 99-calibration.conf
-rw-r--r-- 1 root root 124 Feb 28 11:58 99-v3d.conf
-rw-rw-rw- 1 root root 132 Feb 27 16:55 99-vc4.conf
cat /etc/X11/xorg.conf.d/99-vc4.conf:
Section "OutputClass"
Identifier "vc4"
MatchDriver "vc4"
Driver "modesetting"
Option "PrimaryGPU" "true"
EndSection
ls -la /dev/dri/:
total 0
drwxr-xr-x 3 root root 100 Feb 28 11:58 .
drwxr-xr-x 16 root root 3800 Feb 28 11:58 ..
drwxr-xr-x 2 root root 80 Feb 28 11:58 by-path
crw-rw---- 1 root video 226, 0 Feb 28 11:58 card0
crw-rw---- 1 root render 226, 128 Feb 28 11:58 renderD128
cat /sys/class/drm/card0-HDMI-A-1/status:
connected
cat /sys/class/drm/card0-HDMI-A-1/modes:
1280x720
1280x720
1280x720
1280x720
1280x720
800x600
800x600
800x600
800x600
720x576
720x576
720x576
720x576i
720x576i
720x480
720x480
720x480
720x480
720x480
720x480i
720x480i
720x480i
720x480i
640x480
640x480
640x480
640x480
720x400
cat /var/log/Xorg.0.log:
[ 130.047]
X.Org X Server 1.21.1.7
X Protocol Version 11, Revision 0
[ 130.047] Current Operating System: Linux volumiolivingroom 6.12.47-v7+ #1904 SMP Mon Sep 15 13:05:52 BST 2025 armv7l
[ 130.048] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_headphones=0 cgroup_disable=memory snd_bcm2835.enable_headphones=1 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_hdmi=0 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 splash plymouth.ignore-serial-consoles dwc_otg.fiq_enable=1 dwc_otg.fiq_fsm_enable=1 dwc_otg.fiq_fsm_mask=0xF dwc_otg.nak_holdoff=1 quiet console=ttyS0,115200 console=tty1 imgpart=UUID=dafa3844-b779-48cd-9b4c-01ecfd09e0f4 imgfile=/volumio_current.sqsh bootpart=UUID=3B89-0B23 datapart=UUID=752d19ad-b702-471d-847a-f79ae83515d0 uuidconfig=cmdline.txt rootwait bootdelay=7 logo.nologo vt.global_cursor_default=0 net.ifnames=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 loglevel=0 nodebug use_kmsg=no fbcon=rotate:0
[ 130.048] xorg-server 2:21.1.7-3+rpt3+deb12u11 (https://www.debian.org/support)
[ 130.048] Current version of pixman: 0.44.0
[ 130.048] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 130.048] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 130.048] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb 28 12:00:42 2026
[ 130.054] (==) Using config directory: "/etc/X11/xorg.conf.d"
[ 130.054] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 130.068] (==) No Layout section. Using the first Screen section.
[ 130.069] (**) |-->Screen "DefaultScreen" (0)
[ 130.069] (**) | |-->Monitor "DefaultMonitor"
[ 130.070] (**) | |-->Device "FBDEV"
[ 130.070] (**) | |-->GPUDevice "kms"
[ 130.071] (**) Option "AutoAddDevices" "true"
[ 130.071] (**) Option "AutoAddGPU" "true"
[ 130.071] (**) Automatically adding devices
[ 130.071] (==) Automatically enabling devices
[ 130.071] (**) Automatically adding GPU devices
[ 130.071] (==) Automatically binding GPU devices
[ 130.079] (==) Max clients allowed: 256, resource mask: 0x1fffff
[ 130.095] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 130.095] Entry deleted from font path.
[ 130.121] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 130.121] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 130.121] (II) The server relies on udev to provide the list of input devices.
If no devices become available, reconfigure udev or disable AutoAddDevices.
[ 130.121] (II) Loader magic: 0x215080
[ 130.121] (II) Module ABI versions:
[ 130.121] X.Org ANSI C Emulation: 0.4
[ 130.121] X.Org Video Driver: 25.2
[ 130.121] X.Org XInput driver : 24.4
[ 130.121] X.Org Server Extension : 10.0
[ 130.129] (--) using VT number 2
[ 130.129] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration
[ 130.133] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 130.134] (II) Platform probe for /sys/devices/platform/soc/soc:gpu/drm/card0
[ 130.149] (**) OutputClass "vc4" setting /dev/dri/card0 as PrimaryGPU
[ 130.149] (II) LoadModule: "glx"
[ 130.155] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 130.232] (II) Module glx: vendor="X.Org Foundation"
[ 130.232] compiled for 1.21.1.7, module version = 1.0.0
[ 130.232] ABI class: X.Org Server Extension, version 10.0
[ 130.232] (II) LoadModule: "fbdev"
[ 130.233] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[ 130.236] (II) Module fbdev: vendor="X.Org Foundation"
[ 130.236] compiled for 1.21.1.3, module version = 0.5.0
[ 130.236] Module class: X.Org Video Driver
[ 130.236] ABI class: X.Org Video Driver, version 25.2
[ 130.236] (II) LoadModule: "modesetting"
[ 130.237] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 130.492] (II) Module modesetting: vendor="X.Org Foundation"
[ 130.493] compiled for 1.21.1.7, module version = 1.21.1
[ 130.493] Module class: X.Org Video Driver
[ 130.493] ABI class: X.Org Video Driver, version 25.2
[ 130.493] (II) FBDEV: driver for framebuffer: fbdev
[ 130.493] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 130.510] (WW) Falling back to old probe method for fbdev
[ 130.510] (II) Loading sub module "fbdevhw"
[ 130.510] (II) LoadModule: "fbdevhw"
[ 130.511] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[ 130.514] (II) Module fbdevhw: vendor="X.Org Foundation"
[ 130.514] compiled for 1.21.1.7, module version = 0.0.2
[ 130.514] ABI class: X.Org Video Driver, version 25.2
[ 130.514] (II) FBDEV(0): using /dev/fb0
[ 130.531] (II) modeset(G0): using drv /dev/dri/card0
[ 130.531] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[ 130.532] (EE)
Fatal server error:
[ 130.532] (EE) Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices
[ 130.532] (EE)
[ 130.532] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 130.532] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 130.532] (EE)
[ 130.625] (EE) Server terminated with error (1). Closing log file.
Looks like my set resolution is not a part of modes listed at card0-HDMI-A-1.
Hey @Frisk,
Thank you for all those diagnostic outputs - they are very helpful.
Before diving into configuration fixes, I need to understand exactly what you see on the screen at each stage of boot. This matters because there are three separate display stages and the problem could be at any of them.
Please do a fresh reboot and watch the display carefully from power-on. Report exactly what you see and when:
-
Power on to logo - do you see the Volumio splash/logo? How long does it stay visible?
-
After the logo disappears - does the screen go black? Does it show a blinking cursor? Does it show any text (console messages)? Does the display show “no signal” or does the backlight stay on with a black image?
-
Does anything else appear at any point, or does the screen stay in whatever state you described in step 2?
Also, while you still have SSH access (before rebooting), I still need the contents of the remaining Xorg configuration files:
cat /etc/X11/xorg.conf.d/10-volumio-fbdev.conf
cat /etc/X11/xorg.conf.d/95-touch_display-plugin.conf
cat /etc/X11/xorg.conf.d/99-calibration.conf
cat /etc/X11/xorg.conf.d/99-v3d.conf
These will be needed once we get to fixing Xorg, but the screen observation during boot will tell us whether the problem starts earlier than Xorg.
Kind Regards,
cat /etc/X11/xorg.conf.d/10-volumio-fbdev.conf
Section "ServerFlags"
Option "AutoAddDevices" "true"
Option "AutoAddGPU" "true"
EndSection
Section "Device"
Identifier "FBDEV"
Driver "fbdev"
Option "fbdev" "/dev/fb0"
Option "ShadowFB" "true"
EndSection
Section "Screen"
Identifier "DefaultScreen"
Device "FBDEV"
Monitor "DefaultMonitor"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1024x600"
EndSubSection
EndSection
Section "Monitor"
Identifier "DefaultMonitor"
Option "DPMS" "false"
EndSection
cat /etc/X11/xorg.conf.d/95-touch_display-plugin.conf
# This file is managed by the Touch Display plugin: Do not alter!
# It will be deleted when the Touch Display plugin gets uninstalled.
Section "InputClass"
Identifier "Touch rotation"
MatchIsTouchscreen "on"
MatchDevicePath "/dev/input/event*"
MatchDriver "libinput|evdev"
cat /etc/X11/xorg.conf.d/99-calibration.conf
Section "InputClass"
Identifier "calibration"
MatchProduct "ADS7846 Touchscreen"
Option "Calibration" "3853 170 288 3796"
Option "SwapAxes" "1"
EndSection
cat /etc/X11/xorg.conf.d/99-v3d.conf
Section "OutputClass"
Identifier "vc4"
MatchDriver "vc4"
Driver "modesetting"
Option "PrimaryGPU" "true"
EndSection
First after restart this time I saw the spashscreen for like 4 sekonds than it went black for abvout 15 seconds and then came back doing some configuration ending with spashscreen with “volumio writing:the music player” and below player prepared, please wait for setup to finish. From first sign of spashscreen until the screen went black it took about 70 seconds.
After boot the screen goes black with no cursor. Right now it stays black. Previously in this state I got the undervoltage warnings prompted at screen.
edit:
From a cold start the display was black for about 15 seconds in beginning and later showed the splash screen for about 45 seconds before the screen went black again.
Hey @Frisk,
Thank you for the boot observations and the config file contents. That completes the picture.
What happens during boot
Your display works at the firmware level - the splash screen confirms this. The firmware configures HDMI at 1024x600 using the hdmi_cvt parameter in videoconfig.txt, and the simplefb framebuffer is registered at that resolution. Plymouth (the splash screen service) renders on this framebuffer successfully.
Then the KMS driver (vc4-kms-v3d) loads, takes over from the firmware framebuffer, and reads your display’s EDID to determine supported modes. Your display does not advertise 1024x600 in its EDID - the mode list from the KMS driver shows only standard modes (1280x720, 800x600, 640x480, etc). At this point the screen goes black.
After that, Xorg attempts to start but crashes because two video drivers are fighting over the hardware - fbdev trying to use /dev/fb0 and modesetting trying to use /dev/dri/card0 via KMS. This is a separate problem on top of the KMS mode problem.
What we want to test
For your hardware - a small HDMI panel with a custom firmware mode that is not in the display’s EDID, plus SPI touch which is completely independent of the video stack - KMS may not be needed at all. Without KMS, the firmware framebuffer persists through the entire boot, the console works, and Xorg uses fbdev on /dev/fb0 without any conflict.
SSH in and edit videoconfig.txt:
sudo nano /boot/videoconfig.txt
Comment out the KMS overlay line by adding a # at the start, so it looks like this:
# dtoverlay=vc4-kms-v3d,cma-64
Do not change anything else in that file. Save, exit, and reboot.
Watch the screen during boot and report what you see at each stage, same as before - when the splash appears, whether it goes black, and what happens after.
Kind Regards,