Critical finding - the overlay IS loading. The dmesg shows:
/soc/dsi@7e700000: Fixed dependency cycle(s) with /soc/i2c0mux/i2c@1/panel_disp1@45
/soc/i2c0mux/i2c@1/panel_disp1@45: Fixed dependency cycle(s) with /soc/dsi@7e700000
Device tree has panel_disp1 at address 0x45 on i2c0mux. The vcgencmd output is misleading - overlays applied at device tree level do not always appear there.
The log was truncated before DSI initialization status. Need to see if the panel driver actually probed successfully.
Run these commands:
sudo dmesg | grep -iE "dsi|panel|drm"
ls -la /sys/class/drm/
cat /sys/class/drm/card1-DSI-1/status 2>/dev/null || echo "DSI-1 connector not found"
ls /dev/i2c-*
sudo i2cdetect -y 10
sudo i2cdetect -y 11
The i2cdetect you ran on bus 1 found address 0x30 - that is the Katana codec, correct. The Waveshare panel at 0x45 would be on the i2c0mux bus (i2c-10 or i2c-11 on Pi 4), not the main i2c-1.
Could there be the problem with this extra SDA / SCL cable, which is needed for touch-function? I didnāt plug these cable because i just need a display without touch. The Display is just connected with DSI-Cable, which runs at Volumio 3 without problems.
The I2C is working - those UU entries prove the panel is communicating. The DSI ribbon on newer Waveshare revisions carries I2C alongside the video signals.
volumio@volumio2:~$ DISPLAY=:0 xrandr
Screen 0: minimum 320 x 200, current 1280 x 400, maximum 7680 x 7680
HDMI-1 disconnected primary (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)
DSI-1 connected 1280x400+0+0 left (normal left inverted right x axis y axis) 0mm x 0mm
400x1280 73.71*+
All software diagnostics report working - DSI bound, backlight full, X outputting to DSI-1, mode active. Nothing in software explains why display is dark.
Working theory: Pi 4 Rev 1.4 may have issues with [pi4] section scope processing. Letās rule this out by moving everything under [pi4] to [all] scope. Also prevent HDMI initialization from potentially competing with DSI resources.
Edit your userconfig.txt:
# Add your custom config.txt options to this file, which will be preserved during updates
[pi4]
[all]
dtoverlay=vc4-kms-v3d-pi4,nohdmi
dtoverlay=vc4-kms-dsi-waveshare-panel,7_9_inch,rotation=270
hdmi_force_hotplug=0
disable_overscan=1
#### Touch Display rotation setting below: do not alter ####
display_lcd_rotate=3
display_hdmi_rotate=3
Save, then full power cycle (shutdown, disconnect power, wait 30 seconds, reconnect).
For future reference: the fix involved moving overlays from [pi4] scope to [all] scope and adding ,nohdmi to vc4-kms-v3d-pi4. Either or both may have contributed to the solution.
Conditional filters have documented edge cases, particularly with HDMI-related settings. GitHub Issue #1296 from 2019 reported āConfig.txt ignores conditional filters for hdmi settingsā and similar issues continue to surface. Not a single bug that was fixed - more like a class of edge cases in the boot chain.
I wonder if only revision 1.4 of Raspberry Pi 4 Model B boards are affected.
Your Volumio 3 setup worked because it used fkms (fake KMS) with different driver architecture. Volumio 4 uses full KMS where HDMI/DSI resource conflicts are more likely, making the ,nohdmi parameter important.
i just started my volumio-setup again and there is a dark display again. It was over night without power. I rebooted it again and the problem is still there. Any ideas what to do?
I think thereās still a problem with the hdmi-dsi boot order.
i tested it with a Raspberry Pi 4 B Rev. 1.2, too. Itās the same behavior as the rev. 1.4.
it seems i have to change back to Volumio 3 when i want to use my display. It started yesterday after the last change in the userconfig, but aber power-down overnight it didnāt start again. Thatās not usable for me.
By the way, if I want to install the Touch Display Plugin in Volumio 3, thereās an error at 70% with the mirror (raspbian.raspberrypi.org).
This is a significant regression. The fix worked initially but failed after overnight power-down - that suggests something beyond the [pi4] scope issue we addressed.
Before reverting to Volumio 3, I need to establish current state. Please provide:
The log link is critical - it shows the constructed cmdline.txt at boot, which lets me verify whether parameters are being truncated or modified during the boot process.
Also need to know:
Is the userconfig.txt still the working configuration we applied (with [all] scope and ,nohdmi)? Or did it revert?
Was anything else changed or updated between āworkingā and ānot workingā?
The overnight failure pattern could indicate cold boot initialization timing differs from warm reboot, or a hardware issue specific to this board. If the configuration is identical but behavior changed, that points to hardware. If configuration reverted, that is a different problem.
Regarding Volumio 3 Touch Display Plugin: the mirror error at raspbian.raspberrypi.org is expected - that repository was deprecated. The V3 plugin installation scripts reference outdated URLs. This is not fixable from user side without the Volumio OS v3 maintainer updating the code.
h ttp://logs.volumio.org/volumio/lWgPmXC.html (System donāt allow me to post this link. Just remove the space after āhā)
and the ssh outputs:
volumio@volumio2:~$ cat /boot/userconfig.txt
# Add your custom config.txt options to this file, which will be preserved during updates
[pi4]
[all]
dtoverlay=vc4-kms-v3d-pi4,nohdmi
dtoverlay=vc4-kms-dsi-waveshare-panel,7_9_inch,rotation=270
hdmi_force_hotplug=0
disable_overscan=1
#### Touch Display rotation setting below: do not alter ####
display_lcd_rotate=3
display_hdmi_rotate=3
The configuration in the userconfig.txt didnāt change, itās still the same.
I just tried different raspberry Revās and can say, at Rev. 1.2, 1.3, 1.4 and 1.5 itās all the same. Thereās no difference. When booting after power-down, the display stays dark. Rebooting didnāt change, the display stay dark. After some reboots the Display works, until a new reboot or power-down. Then it stays dark. I tested it with Rev. from 1.2 to 1.5 and 2GB /4GB versions. All the sameā¦
i just did a short power-down (5 sec.) and reboot again, the display ist actually on. Maybe itās useful to see the logs when the display works? Hereās hte link:
Excellent - comparing the two logs reveals exactly what is happening.
NOT WORKING log (dark display):
ws_touchscreen 10-0045: I2C write failed: -5
WORKING log (display on): This error is completely absent.
The panel controller chip at I2C address 0x45 fails to respond during boot initialization. Error -5 is EIO - the kernel attempted to send configuration commands to the Waveshare panel controller and received no response. When this happens, the panel never receives its initialization sequence, so it stays dark - even though DSI binding, backlight, and X server all report success because those are separate subsystems.
This explains everything:
Affects ALL Pi 4 revisions equally (not hardware-specific)
Short power cycle (5 seconds) more likely to succeed - capacitors retain charge, panel controller ready faster
Long power down (overnight) more likely to fail - true cold start, panel controller not ready when driver sends commands
Multiple reboots sometimes fixes it - eventually wins the timing race
This is not a Volumio problem and not a configuration problem. Your configuration is correct. The Waveshare panel driver (ws_touchscreen) attempts I2C communication before the panel controller hardware is ready to respond. This is a timing bug in the Waveshare driver code for kernel 6.x.
Action required: Contact Waveshare support directly with these findings. Provide them:
The two log links showing the difference (working vs not working)
The specific error: ws_touchscreen 10-0045: I2C write failed: -5
Platform: Raspberry Pi 4, kernel 6.12.47, Debian Bookworm
Behavior pattern: intermittent failure on cold boot, timing-dependent
Waveshare maintains the vc4-kms-dsi-waveshare-panel overlay and the ws_touchscreen driver. They need to add proper initialization delay or retry logic to handle cold boot timing on newer kernels.
I have exhausted all user-side configuration options. This requires a driver fix from the display manufacturer.
That sounds like the solution! I ran a test based on your theory:
The Raspberry is sitting directly on the display. The power supply is the same. In this configuration, the display only works sporadically.
I disconnected the Raspberry from the display and connected a second power supply. When the display receives power before the Raspberry, it starts up without any problems. This is the case both after a restart and after a power-down.
This underscores the theory of poor timing in the Waveshare driver. I will contact Waveshare support and describe the problem. Until then, I will simply use a second power source or switch on the Raspberry with a time delay.
Iām glad you discovered the root cause of the failure. Iāve been testing things from yesterday and finally I got a setup working with exactly the configuration you posted in the first message (Example 1 in my case). But it didnāt work on the first attempts. Last night it seemed stable and this morning it started up without any problem.
The solution found by Mustang65 looks good too. In my case I have even an OLED display connected to the same power supply, so it adds up to the problem.
As you know, I worked on this problem with WaveShare technicians, but after Chinese New Year they didnāt answer back any more.
Just for the record, these are the tests I carried yesterday:
4.073 New installation
Setup:
Raspberry Pi 4B Rev. 1.2 4GB
eMMC microSD card 32 GB
USB SATA HDD 4 TB
DAC AUDIOPHONICS I-Sabre DAC ES9023 TCXO
Display WaveShare DSI 11.9 LCD Display
0.96 OLED 128x64 SSD1306 Display (Not configured for tests)
1st Test
Added "video=DSI-1:320x1480@60,rotate=270" to /boot/cmdline.txt in PC, right after flashin 4.073. Added "Example 1: Raspberry Pi 4B+ with 11.9 inch display (Scenario 1)" userconfig configuration to /boot/userconfig.txt.
On boot userconfig.txt contents are deleted, but not cmdline.txt modifications.
1st boot: Black display. Added again "Example 1" config to /userconfig.txt. Reboot
2nd boot: Black display
2nd Test: Changed [Pi4] section contents to [All]
1st boot: Black Display
3rd Test: Reset to factory defaults. cmdline.txt not changed on factory reset. Userconfig.txt deleted, added "Example 1" configuration again.
1st boot: Display working, "Volumio The Music Player" shows on boot and on shutdown correctly rotated. Installed "Touch display" and main Volumio screen not rotated but working
2nd boot (7 hours after shutdown): Display not working
3rd boot (reboot right after last failed test): Display working, "Volumio The Music Player" shows on boot and on shutdown correctly rotated. Main Volumio screen not rotated but working. Rotation configured in Touch Display AddOn working
4th boot (reboot again after correct test): Everything still works
5th reboot (10 hours after last shutdown): Everything still works. It seems stable.
cmdline.txt and userconfig.txt exactly as in Example 1. fbset results are not:
Ps. As you can see, I even changed my RPi rev 1.5 2 GB for a rev 1.2 4GB to check if that was the cause of the error. As youāve found, itās not RPiās fault so it doesnāt matter the revision
Your testing confirms the pattern exactly - intermittent success/failure, more reliable after short power cycles, random failures after longer power-down periods. Same behavior across your Rev 1.2 as Mustang65 observed on Rev 1.4 and 1.5. This definitively rules out Pi revision as a factor.
Regarding your fbset output:
mode "320x1480"
geometry 320 1480 320 1480 16
This shows portrait mode (320x1480) instead of landscape (1480x320). The display is working but framebuffer rotation is not being applied. This is a separate issue from the I2C timing problem. Verify your cmdline.txt contains video=DSI-1:320x1480@60,rotate=270 at the very end, space-separated, on the single line.
I examined the Waveshare driver source in the Raspberry Pi kernel tree. The ws_touchscreen initialization code performs a single I2C write attempt with no startup delay and no retry logic on failure. When the panel controller is not ready - which happens on cold boot before capacitors stabilize - the driver fails immediately and the panel stays dark. This is a textbook initialization timing defect.
Although I have the relevant kernel development skills and the fix is trivial - adding an initialization delay or retry loop would resolve this - this work should be conducted by Waveshare. They collect revenue from every display sale specifically to provide a working product and maintain their drivers. It is not the responsibility of end users or community volunteers to fix manufacturer driver defects.
I totally agree with you, this is not something for end users to solve, but for the brand. They must solve their problems when they are being paid for it.
Iāll write them right now specifying what youāve found, if you donāt mind. But as Iām afraid they are just ignoring my messages, it would be good if @Mustang65 could write them too.
About the rotation issue, this is my cmdline.txt file:
Anyway, as there is an easy workaround for this, I would just leave it like that. Maybe stating somewhere that this could happen and that this is the solution would be enough. At least for me it would.
I will include this in my message to WaveShare anyway.