HDMI to DVI output possibly broken

[dhowdy]

Hello,

I've found that using a passive HDMI to DVI adapter/cable does not work on the Pi 2 starting at commit 03b4437 (May 13, 2015). I've tested this across multiple Pi 2s, montiors, and cables/adapters. The behavior that I see is that omxplayer is able to display output video, but nothing else (including the X session) is visible. If I use the previous commit everything works just fine.

Hot-swapping monitors yields the same results; HDMI works, DVI does not.

I've tried about every combination of hdmi_drive, hmdi_group, hdmi_mode, hdmi_boost and the like to attempt to work around this issue. Right now the only thing that I've found that works is using rpi-update 8521fd34c8f66b6d109acce943f6e25ec93ec005

Thanks.

[popcornmix]

Any non-default settings in config.txt? cmdline.txt?
Are you using a standard raspbian install?
What does tvservice -s report in the working and non-working cases?

Can you confirm that TV is completely blank on boot with recent firmware?
But if you launch omxplayer (I assume through ssh?) you see the video?

[dhowdy]

Default cmdline.txt and config.txt. Latest Raspbian image (05-05-15) fully updated, latest firmware.
tvservice -s currently reports:
state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive
on straight HDMI monitor (working) and
state 0x120006 [DVI DMT (47) RGB full 16:10], 1440x900 @ 60.00Hz, progressive
(or whatever the actual resolution is) on a non-working HDMI->DVI display.
Hot-swapping the cables between monitors keeps the same output, but works every time on HDMI and never on DVI.

omxplayer is launched via a script on the system. I'm rebuilding a Pi 2 now to test older firmware. I'll report back with results.

I've concocted a "boot animation" with omxplayer so that as soon as the kernel loads it displays a video while the rest of the system boots. It plays the video and any others just fine but doesn't appear to display any output from X11. I see identical behavior on a clean Raspbian install.

For what it's worth, it seems to behave exactly the same way if I run tvservice -o and then tvservice -p on a monitor connected over DVI; it will power the display off and then power it back on but display nothing except the output of omxplayer. I have to power cycle the Pi 2 to fix it.

I'm eager to try a variety of things to debug this because I want to help you all fix the issue.

Thanks!

[popcornmix]

Are you making omxplayer adjust the refresh rate (e.g. with -r)? That might explain why omxplayer can produce an image.
I'd like to know what tvservice -s reports on the older firmware that does work with HDMI->DVI display.

[dhowdy]

As I test on more and more displays, I'm finding that this is actually only an issue on a few Dell monitors (that aren't made anymore) but works on other Dell monitors. At this point, I'm content with considering this a non-issue since we can simply assume that certain models of monitors are not compatible with the new firmware. If you are interested in chasing down this bug, I'll happily provide the results of any tests, but we can consider this issue moot to free up your time to chase down more important issues.

The answers to your questions are below.

I'm only running omxplayer /path/to/file.mp4.

Firmware version: 8521fd34c8f66b6d109acce943f6e25ec93ec005 (with a reboot between switching displays)
DVI: state 0x120016 [DVI DMT (47) RGB full 16:10], 1440x900 @ 60.00Hz, progressive
HDMI: state 0x12001a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive
Everything works.

Firmware version: cacc0a7989178d5f4aa9333820bc92dd1771419c
DVI: state 0x120006 [DVI DMT (47) RGB full 16:10], 1440x900 @ 60.00Hz, progressive
HDMI: state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive

[popcornmix]

I would like to understand this in case it is affecting other users.
Can we narrow down the firmware version a bit more.
I have a suspicion where it is. Can you test:
sudo rpi-update 5cd044a2c5996e38fdeeb11ec4a47d1b131a7579
sudo rpi-update cacc0a7989178d5f4aa9333820bc92dd1771419c
Hopefully one of those will work and one will fail.

[dhowdy]

I'll continue to see this through. I'm coming down with something and I'll get back to you in a few days.

[popcornmix]

Have you had a chance to do the test I suggested?

[dhowdy]

Sorry, not yet. Just getting back to work. I will try to get you some results tomorrow.

[dhowdy]

Both of those commits behave the same way. Here's what I'm seeing:
rpi-update 8521fd34c8f66b6d109acce943f6e25ec93ec005
state 0x120016 [DVI DMT (57) RGB full 16:10], 1680x1050 @ 60.00Hz, progressive
Everything works.

sudo rpi-update 5cd044a2c5996e38fdeeb11ec4a47d1b131a7579
state 0x120016 [DVI DMT (57) RGB full 16:10], 1680x1050 @ 60.00Hz, progressive
Only omxplayer output.

sudo rpi-update cacc0a7989178d5f4aa9333820bc92dd1771419c
state 0x120006 [DVI DMT (57) RGB full 16:10], 1680x1050 @ 60.00Hz, progressive
Only omxplayer output.

On any commit newer than 8521fd3 (even the very next one 03b4437) I get nothing but omxplayer output. Even the 4 raspberries in the splash screen are not visible.

Please advise on what you'd like to see next.

[popcornmix]

I've tried forcing that mode (with latest firmware):

$ tvservice -s
state 0x120006 [DVI DMT (57) RGB full 16:10], 1680x1050 @ 60.00Hz, progressive

And my monitor displays an image fine. What does fbset report for you?
Might need to produce a few test firmware builds to identify exactly what part of that firmware update caused the issue.

[dhowdy]

mode "1920x1080" geometry 1920 1080 1920 1080 16 timings 0 0 0 0 0 0 0 rgba 5/11,6/5,5/0,0/16 endmode

Just in case it was a problem with the FB being set to 1920x1080, I changed it to the screen's native resolution and rebooted. Same symptoms, but fbset reports the following with no change to tvservice -s

mode "1680x1050" geometry 1680 1050 1680 1050 16 timings 0 0 0 0 0 0 0 rgba 5/11,6/5,5/0,0/16 endmode

[popcornmix]

What does vcgencmd get_config int report?

[dhowdy]

On cacc0a7989178d5f4aa9333820bc92dd1771419c it reports:
arm_freq=900
config_hdmi_boost=5
disable_commandline_tags=2
disable_l2cache=1
emmc_pll_core=1
force_eeprom_read=1
force_pwm_open=1
framebuffer_height=1050
framebuffer_ignore_alpha=1
framebuffer_swap=1
framebuffer_width=1680
hdmi_force_cec_address=65535
over_voltage_avs=0x1b774
overscan_bottom=-64
overscan_left=-64
overscan_right=-64
overscan_top=-64
pause_burst_frames=1
program_serial_random=1
sdram_freq=450
temp_limit=85

Version 8521fd34c8f66b6d109acce943f6e25ec93ec005 reports:
reports:
arm_control=0xa5800010
arm_freq=900
avoid_fix_ts=1
config_hdmi_boost=2
disable_commandline_tags=2
disable_l2cache=1
emmc_pll_core=1
force_eeprom_read=1
force_pwm_open=1
framebuffer_height=1050
framebuffer_ignore_alpha=1
framebuffer_swap=1
framebuffer_width=1680
hdmi_force_cec_address=65535
over_voltage_avs=0x1b774
overscan_bottom=-64
overscan_left=-64
overscan_right=-64
overscan_top=-64
pause_burst_frames=1
program_serial_random=1
sdram_freq=450
temp_limit=85

[popcornmix]

Hmmm. I did ask in the second post if you had any non-default config.txt settings.
It appears you are setting in config.txt:

framebuffer_height=1050
framebuffer_width=1680
overscan_bottom=-64
overscan_left=-64
overscan_right=-64
overscan_top=-64

which may well be relevant. I'll see if I can reproduce the issue with those added.

[dhowdy]

Sorry about that. I should have checked over that more thoroughly.

[popcornmix]

Can you say why you have those settings? They look nonsensical to me.
How does it behave with those six settings removed?

[dhowdy]

The overscan setting is critical on many displays in order to get images to fill the entire screen. However, on these particular displays it looks like it is ok without them. The professional Samsung LFDs are bad about this.

The framebuffer setting is being set by a script. We have found several displays that default to 1280x720 without that line so I created a script that will configure that setting automatically.

It turns out that removing the overscan setting corrects the issue. The frambuffer setting has no apparent effect on the problem.

Thank you again very much for your time and effort in to looking in to this.

[popcornmix]

Overscan only makes sense on CEA (TV) modes, not DMT (monitor modes).
By default we set 48 pixels of overscan on each side for CEA modes (which can be adjusted with disable_overscan or overscan_bottom/overscan_top/overscan_bottom/overscan_left/overscan_right).
For DMT modes we don't add any overscan settings by default.

So, for you, with a DMT mode with no default overscan, you are setting the values to a negative value. A positive settings would increase the black border around your framebuffer, a negative value will actually zoom the framebuffer in so it will be impossible to see the edges of the framebuffer.

Even with a CEA mode, it never makes sense to set overscan values below -48, which will effectively disable the overscan adjustment.

I'd suggest you start with disable_overscan=1, and then use positive values for overscan_bottom/overscan_top/overscan_bottom/overscan_left/overscan_right. That will give more consistent behaviour for CEA and DMT modes. E.g.

disable_overscan=1
overscan_bottom=16
overscan_left=16
overscan_right=16
overscan_top=16

I wouldn't recommend specifying frame_buffer_width/frame_buffer_height without a very good reason. It will introduce a scaling of the framebuffer and so make the text more blurry.

There was a change in behaviour with the identified firmware when specifying overscan coordinates that end up negative that wasn't intended. I will fix that. However anyone who is hitting that issue has unwanted settings and would be better correcting them.

[dhowdy]

Absolutely excellent. I agree that these settings should have been more thoroughly thought through.

Thanks for the info regarding overscan below -48. That actually explains some of the behavior that we were seeing.

Again, thank you very much for you time and effort in this. We can consider the issue resolved.

[popcornmix]

No problem. I've included a fix in latest rpi-update code that gets the old behaviour back with too negative overscan. I think pixels lost off the edge is better than black screen, so it's useful to fix it anyway, even if the best solution is to change config.txt.

[dhowdy]

Thanks! I can confirm that the latest firmware reverts that behavior. I appreciate it.

Don