vc4: HDMI -> VGA blank screen: can't get 1024x768 75Hz to work with vc4, works fine in dispmanx
LeaseOnLife opened this issue · comments
latest firmware as of 8/21, display connected via cheap HDMI->VGA adapter
when not using 3D, it works out of the box:
tvservice -s shows:
state 0x12000a [HDMI DMT (18) RGB full 4:3], 1024x768 @ 75.00Hz, progressive
0x12000a = VC_SDTV_ATTACHED, VC_SDTV_CP_INACTIVE, VC_HDMI_ATTACHED, VC_HDMI_HDMI
explicitly setting the mode also works:
/opt/vc/bin/tvservice -e "DMT 18 HDMI"
Powering on HDMI with explicit settings (DMT mode 18)
with dtoverlay=vc4-kms-v3d, it shows the rainbow, but then shows blank screen during boot and also blank when X is started.
tvservice -s shows HDMI unplugged:
state 0x120009 [HDMI DMT (18) RGB full 4:3], 1024x768 @ 75.00Hz, progressive
0x120009 = VC_SDTV_ATTACHED, VC_SDTV_CP_INACTIVE, VC_HDMI_UNPLUGGED, VC_HDMI_HDMI
explicitly setting the mode fails:
/opt/vc/bin/tvservice -e "DMT 18 HDMI"
Powering on HDMI with explicit settings (DMT mode 18)
[E] Failed to power on HDMI with explicit settings (DMT mode 18)
So for I have added to the /boot/config.txt
avoid_warnings=2
hdmi_drive=2
hdmi_group=2 #1=CEA 2=DMT
hdmi_mode=18
gpu_mem=128
hdmi_force_hotplug=1 # Use HDMI mode even if no HDMI monitor is detected
Anything else I can try, or should report?
Dirk
add/edit: PS: The older kernel from 07/28/16 works better: it also shows a black screen during boot, but X works, accelerated, glxgears running smoothly.
tvservice -s
state 0x120009 [HDMI DMT (18) RGB full 4:3], 1024x768 @ 75.00Hz, progressive
The open source driver has nothing to do with config.txt knobs or tvservice (tvservice should be prevented from being run with current firmware). If you want to configure modes at boot time, take a look at https://www.kernel.org/doc/Documentation/fb/modedb.txt
I have heard we have problems with HDMI->VGA adapters -- it sounds like we lose EDID. I do need to get one of them and test.
Please attach (not paste) your full dmesg, and the output of xrandr --verbose while X is running.
will do, over the weekend!
attached dmesg and xrandr --verbose. with and without opensource driver (3d/2d)
It looks like your xrandr-3d.txt got cut off.
Looking at dmesg:
[ 4.677199] vc4-drm soc:gpu: No connectors reported connected with modes
[ 4.677238] [drm] Cannot find any crtc or sizes - going 1024x768
So either the DDC didn't work or the connection detect didn't work. Since you're on a Pi3, we don't have hotplug pin based connection detection. We fall back to a quick I2C probe against DDC, but presumably that's failing.
There's a correctness fix to the I2C for transactions like we do for DDC being settled for the upstream tree right now, but that will take a while to make it to the downstream tree. I'd say it's fairly low likelihood of fixing this. I also have a driver I started on to expose the hotplug pin on pi3 -- it got thoroughly bikeshedded upstream, but I should be able to merge it downstream easily. I think that might help, as X may be saying "it's disconnected, so I won't configure that output", but I can't tell from the truncated log.
I double checked, what's in xrandr-3d.txt is all I get. It does say HDMI-0 disconnected, which might cause that behavior?
pi@openplotter:~ $ xrandr --verbose --q12
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 2048
HDMI-0 disconnected (normal left inverted right x axis y axis)
Identifier: 0x42
Timestamp: 8020
Subpixel: unknown
Clones:
CRTCs: 2
Transform: 1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
filter:
pi@openplotter:~ $
pi@openplotter:~ $
pi@openplotter:~ $
OK, it looks like if the kernel doesn't attach any modes to the output (because we didn't get EDID), then X's attachment of "default" modes will not do anything. This is maybe a thing we should fix in X. But we should also figure out the topic of this bug: Why don't you get EDID?
I can only guess, edid is lost by the HDMI->VGA adapter, although the old 2D driver works.
I did try to add (actually precede) the cmdline with video=1024x768@75 which caused no harm with the 2D driver, but didn't help the 3D driver.
I do want to mention again, with the 3D driver the boot text is lost also, before X is started, black screen after the initial splash.
For now I switched to the the closed source vc4-fkms-v3d, thanks for that, it seems to work.
raspberry 3
Hi.. So.. How fix this problem?? - i can try two monitors - black screen.
dmesg -
[ 4.677199] vc4-drm soc:gpu: No connectors reported connected with modes
[ 4.677238] [drm] Cannot find any crtc or sizes - going 1024x768
what brunch from github i can use for fix this? Or any workaround?
Strange - i'm compile kernel 4.4-y from raspberry github - copy new kernel, modules, overlays , dtbs to sd and screen working good. Where problem? old kernel in raspbian image?
I bought a HDMI-VGA adapter and tried it out today on upstream 4.10-rc1 and downstream 4.9.5, and EDID has been solid on both.
@LeaseOnLife does vcdbg log msg show the firmware finding EDID for the monitor, or was the 1027x768@75 a mode that it defaulted to in the absence of EDID? Does your VGA cable have all the pins present? (Some older cables didn't). Does your VGA monitor show a correct set of modes when plugged directly into a computer with VGA out?
Also tried going back to rpi-4.4.y to see if it was i2c changes since then that fixed things, but it still worked.
Hmm, I've never seen vcdbg log message produce nothing. I'm really not sure what would be going on there, and getting the firmware's log of what it was doing with EDID was my best hope for this bug.
I am back in front of my Pi3.
vcdbg log msg
debug_sym: OpenVideoCoreMemoryFileWithOffset: Unable to open '/dev/vc-mem': Permission denied(13) Unable to open videocore memory access: -13
sudo vcdbg log msg
gives me 217 lines of:
debug_sym: vc_mem_copy: Failed to get memory size via ioctl: Inappropriate ioctl for device(25)
and
Failed to allocate 1462923504 bytes for message buffer
current dmesg.txt attached
Sorry, didn't mean to close the issue....
Huh, I have no idea what would be up with sudo vcdbg log msg there (since you're on a 32-bit kernel. I would expect 64 to be broken).
With the latest "BRANCH=next rpi-upate" to kernel 4.9.8 I have the HDMI output working, during boot as well as in X, for kms and for fkms.
Thanks!
Dirk