Pi3 video issue

When booting my Pi3 based Pi-top on builds after the 10th Dec (11th and 14th tested), the following happens:

https://www.youtube.com/watch?v=DlDXfPFr4uw

5th Dec build is okay, so it could be related to the change to BCMVideo on the 10th.

The Pi-Top just uses HDMI and doesn’t require anything special in the config.txt, right? The problem will be that the OS will be trying to drive it at 640×480 (or whatever), but it’s just a dumb LCD panel so it’s only going to work properly when used at its native resolution + timings.

If there’s no easy way for the OS to tell that a Pi-Top (or similar) is in use then the best solution might be for me to add a ‘disable_mode_changes’ option so that people can opt-out of the GPU mode change support.

Supposedly the EDID bounty is due for completion soon, at which point the OS might be able to deal with this case automatically (although I suspect the 1366×768 resolution will cause issues – so I should probably also start thinking about how to get the OS to cope with any padding the GPU adds to the framebuffer)

I don’t have anything video related in config.txt, however forcing the video in it to 1360×768 appears to resolve the issue:

hdmi_group=2
hdmi_mode=39

I’m not entirely sure what the issue is here, it’s not the lack of video settings in config.txt as it worked on a Pi2 running off a TV and a Pi1 running off a monitor. As you say, it could be the odd resolution of the Pi-Top screen, having a knock on effect, or the screen driver that the Pi-Top uses.

Anyhow, the repro is to remove hdmi_group / hdmi_mode from config.txt

That is a bit odd – if you are on the latest firmware version then it should stick with that mode for the first second or two of boot before RISC OS comes in and tells it to switch to a different mode.

Anyway, I’ve now added some basic command line parsing to BCMVideo, so if you have ‘disable_mode_changes’ in your cmdline.txt file then that will cause it to not do any GPU mode changes and just stick to the old behaviour of letting the GPU rescale everything.

https://www.riscosopen.org/viewer/revisions/logs?ident=1481831034-730505.html

if you are on the latest firmware version then it should stick with that mode for the first second or two of boot before RISC OS comes in and tells it to switch to a different mode

Yes, I updated to the latest firmware to see if there was any difference and that’s where the video came from.

Daft question, but if this change passes through mode changes to the GPU avoiding the scaling – shouldn’t overscan modes break? I’ve tested on both a Pi2 and a Pi3 and they’re still doing GPU scaling. In the case of the Pi2 it stayed at 1280×720 regardless of the mode I was in and the Pi3 stays at 1360×768....or am I misunderstanding what this change does?

It should pass the mode timings through to the GPU. Is it just overscan modes which are broken, or all modes? I’ve just checked today’s firmware + ROM with my Pi 3 and it seems to be working OK.

If you check the word at offset &A8 into BCMVideo’s workspace then it should be non-zero if the GPU mode changes are enabled. However it’s still possible for individual mode change requests to fail (e.g. error returned when setting the timings), which will cause it to stick with the current mode timings and just resize the framebuffer like before.

If the GPU mode changes are enabled but aren’t working, it would be good to know what the mode timings are that you’re trying, and what the output of “*vcgencmd hdmi_timings” is (after the failed attempt).

Should the latest versions work correctly on a 2560 × 1080 display?

When working with high resolutions the main thing you’ll need to do is make sure you tweak the GPU limits in config.txt:

• max_framebuffer_width – default is 1920
• max_framebuffer_height – default is 1200
• hdmi_pixel_freq_limit – default is 162000000 (note that this is in Hz, MDF files use kHz)

BCMVideo is now able to check what limits have been set and will use them to limit the set of modes that will be available via the display manager (previously if you selected a mode which was outside the GPU limits you’d get a weird cropped display)

With 2560×1080 in particular, you’ll have to manually specify eigen values of EX1 EY1 otherwise the kernel will treat it as a rectangular-pixel EX1 EY2 mode.

(edit) Found a previous post of yours where you gave the mode timings – those seem to work OK on my 2560×1440 monitor (although the monitor always seems to stretch to the image to fill the screen – not sure if that’s just the behaviour of the monitor or an issue with how we’re specifying the aspect ratio)

It should pass the mode timings through to the GPU. Is it just overscan modes which are broken, or all modes?

Turns out I was testing the wrong ROM build :/

Testing with yesterday’s build, the only way to get any display on the Pi-Top is by using disable_mode_changes in cmdline.txt. I’ve yet to retest on a TV or Monitor, but will do so and report back.

The problem I had with using the full mode was the mouse not tracking. The display was the correct resolution, and if I switched to regular 1920 it was pillar boxed and worked fine (on an older ROM at 1920 the mouse vanished on the right of the screen with the same config.txt). (But still 2560 to the screen).

Basically I was asking if the mouse thing has been worked on, i.e should I give it a try?

I haven’t made any changes to the mouse handling in the past few months, but it seemed to work OK when I tested it. (The last time I made any mouse changes was in March, where the position would be wrong if you had asymmetric overscan settings)

The firmware version can also have an impact on things – to get the mouse position right RISC OS needs to mimic the coordinate space conversion that the firmware uses for positioning & scaling the main framebuffer (the change in March was in response to a change that had been made to the firmware a few months earlier).

My screen is a resolution that they seem to have omitted from their list.

My screen is a resolution that they seem to have omitted from their list.

You can create a custom resolution, although I’ve never tested it:

hdmi_cvt=<width> <height> <framerate> <aspect> <margins> <interlace> <rb>
width        width in pixels
height       height in pixels
framerate    framerate in Hz
aspect       aspect ratio 1=4:3, 2=14:9, 3=16:9, 4=5:4, 5=16:10, 6=15:9, 7=21:9, 8=64:27
margins      0=margins disabled, 1=margins enabled
interlace    0=progressive, 1=interlaced
rb           0=normal, 1=reduced blanking

My screen is a resolution that they seem to have omitted from their list.

Surely that’s a perfect reason to try the latest ROM + firmware? If you set the correct limits in config.txt you should be able to *ReadEDID and then let RISC OS tell the GPU which mode timings to use.

You can create a custom resolution, although I’ve never tested it:

I have, and it works, but Jess’s screen aspect ratio (64:27) isn’t in that list of possible aspect ratios.

It’s not even approximately equal to any of them.

Seems I missed the two relevant ratios off the list, now corrected.

However, I don’t believe a Pi is capable of supporting this resolution without overdriving the pixel rate via hdmi_pixel_freq_limit.

Surely that depends how slow the vertical frequency can go on the monitor? I’m running 3840×2160 no problem – at 24 Hz, in 256 colours. Absolutely magic for !Draw.

That is interesting. the original list was what I remembered, they must have updated it.

My Pi could generate that resolution smoothly at 50Hz, but not stable at 60Hz. It is an original Pi (256MB, no screw hole, old pin out.)

Will packman update it to the correct versions to give it a try?