Screen issues since RC15

I tried out RC15 as well as ROM from 2017-06-08 on my Pi3.
Compared to my 2016-10-07 setup I noticed the followinf issues:

- DigitalCD plugins are flickering. After analysis it turns out that I can’t get tripple buffering of 1920×1080 in 256 colours (even thought that uses less memory than 1920×1080 in 16M colours). Using 800×600 instead is ok, so I guess the changed calculation fails to take bit depth into account.
- physical mode changes interrupts the sound while the change occur, but I guess that issue is hardware related (monitor?/no hdmi output during change?).
- on ROM of 2017-06-08 (RC15 one is OK) the screen remains black with a large hourglass in the middle.

- DigitalCD plugins are flickering. After analysis it turns out that I can’t get tripple buffering of 1920×1080 in 256 colours (even thought that uses less memory than 1920×1080 in 16M colours). Using 800×600 instead is ok, so I guess the changed calculation fails to take bit depth into account.

The limiting factor here will be the framebuffer height. To support multiple screen banks on the Pi, we allocate a framebuffer which is N times taller than a single screen, and then scroll it vertically (the framebuffer is a 2D texture which we can display a subrectangle of). But, the firmware has a limit on how large it will allow the framebuffer to be – the width and height are limited to twice the max_framebuffer_width and max_framebuffer_height values specified in config.txt. So for three screen banks in a 1080 tall mode you’d have to specify a max_framebuffer_height of 1080*3/2 = 1620 or higher (default max_framebuffer_height is 1200, width is 1920).

- physical mode changes interrupts the sound while the change occur, but I guess that issue is hardware related (monitor?/no hdmi output during change?).

Yeah, that’ll be down to how HDMI audio works at the hardware level. It’s transmitted during the video blanking periods, using the video clock as the timing source. So if the video clock has its rate adjusted then you’ll typically lose audio for a short period while the PLL re-locks to the new rate. And even after the mode change has finished it may still take a second or two for your monitor to lock on to the new signal.

One of the things on my todo list is to fix the driver to avoid redundant mode changes, which should improve things a bit.

- on ROM of 2017-06-08 (RC15 one is OK) the screen remains black with a large hourglass in the middle.

Hmm, there is definitely something a bit fishy going on when upgrading from RC15 to the latest ROM. I don’t get the exact problem you describe, but my monitor does refuse to display anything until the desktop is reached. I’ll take a closer look.

So for three screen banks in a 1080 tall mode you’d have to specify a max_framebuffer_height of 1080*3/2 = 1620 or higher (default max_framebuffer_height is 1200, width is 1920).

That solved the issue.

- on ROM of 2017-06-08 (RC15 one is OK) the screen remains black with a large hourglass in the middle.

Hmm, there is definitely something a bit fishy going on when upgrading from RC15 to the latest ROM. I don’t get the exact problem you describe, but my monitor does refuse to display anything until the desktop is reached. I’ll take a closer look.

I think this should be fixed with ScreenModes 0.66 (my problem is fixed, at least). Keep an eye out for it in tomorrow’s ROMs.

The new ROM fixed the boot issue.

With the new RC15 I can’t get a picture at all. There is activity on the Pi and the monitor indicator flashes, showing a conversation but it didn’t result in a picture. The monitor has a DVI input and I use a DVI-HDMI cable to connect. It works fine in Raspian and RC14 although the picture is a bit letterbox like unless I use 800×600 mode. On the new image, there is not even a flicker of a picture.

There are a couple of things you can try:

• Try using the latest development ROM image; there are a few fixes which have been made since RC15 (e.g. support for some unusual screen resolutions)
• Try creating a cmdline.txt file in the FAT/loader partition, containing the text disable_mode_changes. This should get you back to RC14-style behaviour, but since the underlying bug still exists, it would be useful to have a copy of you monitor’s EDID so that we can investigate further. The EDID should appear as a file at Resources:$.Resources.ScreenMode.Monitors (you can get to Resources by clicking menu on the Apps icon on the iconbar). Either upload it somewhere, post it here (after converting to hex), or email it to me and we can hopefully get to the bottom of why things aren’t working right.