vc_dispmanx_display_open failed! (Pi Zero W - Raspbian Buster)

[h3r0n]

I successfully got a 2.8" ili9341 to work a Raspberry Pi 3B+. Now I'm trying the sam display with a Raspberry Pi Zero W. The screen flashes briefly and then i get this error:

pi@raspberrypi:~/fbcp-ili9341/build $ sudo ./fbcp-ili9341
bcm_host_get_peripheral_address: 0x20000000, bcm_host_get_peripheral_size: 33554432, bcm_host_get_sdram_address: 0x40000000
BCM core speed: current: 250000000hz, max turbo: 400000000hz. SPI CDIV: 30, SPI max frequency: 13333333hz
Allocated DMA channel 7
Allocated DMA channel 1
Enabling DMA channels Tx:7 and Rx:1
DMA hardware register file is at ptr: 0xb4b70000, using DMA TX channel: 7 and DMA RX channel: 1
DMA hardware TX channel register file is at ptr: 0xb4b70700, DMA RX channel register file is at ptr: 0xb4b70100
Resetting DMA channels for use
DMA all set up
Initializing display
Resetting display at reset GPIO pin 27
Setting TFT backlight on at pin 17
InitSPI done
vc_dispmanx_display_open failed!

Am I doing something wrong?

Configuration:

cmake -DILI9341=ON -DGPIO_TFT_DATA_CONTROL=22 -DGPIO_TFT_RESET_PIN=27 -DGPIO_TFT_BACKLIGHT=17 -DSPI_BUS_CLOCK_DIVISOR=30 -DBACKLIGHT_CONTROL=ON -DSTATISTICS=0 ..

Wiring:

Display | Raspberry
MISO | 21
LED | 11
SCK | 23
MOSI | 19
DC | 15
RESET | 13
CS | 24
GND | GND
VCC | 5V

Setup:

[juj]

If DispmanX cannot be loaded, then it is not a wiring nor a fbcp-ili9341 config/build issue, but something is going wrong with the display driver load. The only reason I have observed that to happen is mentioned in issue #75, when hardware VC4 KMS GL driver is used (dtoverlay=vc4-kms-v3d in /boot/config.txt) instead of the default driver. Try double-checking if that might be the reason here?

[h3r0n]

Thanks for the quick reply. 😃
Unfortunately I haven't touched the /boot/config.txt file and dtoverlay=vc4-kms-v3d is commented

pi@raspberrypi:~ $ sudo cat /boot/config.txt
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

[all]
#dtoverlay=vc4-fkms-v3d

Even if I comment out the pi4 section I get the same error.

[juj]

Oh, this is on the new Raspbian Buster? It looks like there are some changes on Buster.

Briefly googling, https://www.raspberrypi.org/forums/viewtopic.php?t=243429 suggests "Dispmanx is still there with FKMS (or legacy)." Perhaps raspi-config needs a specific GL driver config line to enable FKMS or legacy driver - not exactly sure, haven't yet updated to Buster, but worth a shot.

[h3r0n]

I tried all the three options without luck. I'll go back to Stretch

[juj]

Hmm, no immediate idea either, I'm afraid. Reading raspberrypi/firmware#1154 suggests that DispmanX should work on Buster, at least when used on a Pi 4. Did the same Raspbian Buster image work on a Pi 3B+? (or was the successful Pi 3B+ test on Stretch?)

In absence of better ideas, downgrading to Stretch should fix the issue.

[h3r0n]

The successful test on the Pi 3B+ was on Stretch.

I've just downgraded the Pi Zero W to Stretch too and it works now. Thank you for your support!

[unphased]

What i'm observing is that with Buster, if HDMI is connected to the Pi, vc_dispmanx_display_open does not fail.

If no HDMI is attached, then this reliably happens.

I'm currently evaluating if forcing HDMI will cause it to work.

[juj]

Thanks for the important info! If it turns out to be not fixable/configurable in software, an appropriate action may be to raise the issue in https://github.com/raspberrypi/firmware/

[unphased]

I configured

hdmi_group=2
hdmi_mode=87
hdmi_cvt=640 480 60 1 0 0 0
hdmi_force_hotplug=1

for my config.txt and the display is working fine under buster on a Pi 3B. Those settings seem to be enough to force the HDMI to be on (as well as set to an almost-readable resolution for the TFT).

[unphased]

btw, for some reason, on the buster image that i have been testing, without enabling SPI, fbcp-ili9341 still works, with my ST7789 display.

[juj]

Yeah, that is expected - fbcp-ili9341 does not use the kernel spi driver but directly accesses the spi peripheral for fastest performance. This can actually conflict with the kernel spi driver so it is best to disable the kernel spi option altogether so that they will not try to simultaneously access spi.

[unphased]

Awesome, thanks for explaining that!

[juj]

Confirmed trying out locally on Raspbian Buster with a Pi 4B, setting hdmi_force_hotplug=1 enables dispmanx API to work. (either with dtoverlay=vc4-fkms-v3d or without). I'll close this as resolved.

[trigger7]

I encountered the same issue while trying to run fbcp-ili9341 on a Pi Zero using DietPi (based on Raspbian Lite Buster).

hdmi_force_hotplug=1 wouldn't do any good.

What I found is, I had a GPU memory split set at 16MB in /boot/config.txt (gpu_mem_512=16).
This, somehow, caused vc_dispmanx_display_open to fail.
Removing the line (defaults to 64MB I think), or setting it to 32MB (haven't tried other options) solved the issue.

[drawlerr]

Figured I'd put up what fixed this problem for me, in the hopes that it helps someone else in the future:
Check sudo tvservice -s. If you get:

state 0x2 [TV is off]

you will need to make sure the "tv is on" before running ./fbcp-ili9341 like so:
sudo tvservice -p
to turn it on with "preferred" settings. If you see something like

Powering on HDMI with preferred settings

you should be good to go!