Big Resolutions

Thanks especially to Dave Pitt for help getting a recent build of RISCOS working on my Pi B 2, which means that the pointer doesn’t disappear at x = 2048.

I’ve found a mode definition for 1920×1200 in one of the monitor definitions, that works absolutely fine, and displays on my Philips 4K monitor okay.

I’ve written a mode definition for 3840×2160@30 Hz, which sort of works: it produces a nice stable picture on the monitor, and the pointer can be moved around the screen exactly to the edges of the screen, but the backdrop doesn’t extend to the top or bottom of the screen, and the iconbar is nowhere to be seen. If I leave windows high enough on the screen from a working mode, they’re there on the screen when I change to the big mode, but shifted down, and I can’t click the mouse on them (maybe I could if I could guess where the pointer was really pointing to). If I hit f12, the command line appears a fair way from the top of the screen (below even the top of the backdrop), and I can use it to return to a sensible mode.

I’ve found a mode definition for 2560×1440 in one of the monitor definitions, and that behaves similarly, except that the displacement of everything on the screen is different. You can’t see the command line when you hit f12, but it’s down there off the bottom of the screen and working normally – once it scrolls up you can see it.

I’ve found a mode definition for 2560×1440 in one of the monitor definitions

Does EDID not help with MDF creation :-

*Help ScreenModes
==> Help on keyword ScreenModes
Module is: Screen Modes    0.57 (06 Aug 2016)

Commands provided:
LoadModeFile    ReadEDID        CreateModeFile
*Help ReadEDID
==> Help on keyword ReadEDID
*ReadEDID reads screen mode definitions from the monitor and makes these the current screen modes set.
Syntax: *ReadEDID
*Help CreateModeFile
==> Help on keyword CreateModeFile
*CreateModeFile <path> reads screen mode definitions from the monitor and saves them to <path>.<monitorname>.
Syntax: *CreateModeFile <path>
*

It is probably necessary to tell the GPU what to do via lines in config.txt

I only have 1680×1050 so no real expertise. HTH.

Aha! the link to config.txt documentation DEFINITELY helps!

I used to write mode definition files way back in the early 90s, for analog monitors driven by the VIDC…we were using 1600×1200 monitors for publishing academic journals on A540s and A5000s… they’re still remarkably similar, but the GPU is a different beast.

Clive: In a Pi’s MDF only resolution is used. e.g.

1. 1920 × 1200 (50Hz)
   startmode
   mode_name:1920 × 1200
   x_res:1920
   y_res:1200
   pixel_rate:121500
   h_timings:0,0,0,1920,0,0
   v_timings:0,0,0,1200,0,0

should work!

Either a Pi’s GPU automatically will set its own resolution or use config.txt see: Here , Here & Here

1920×1200 works no problem.

Yup, I guessed that only resolution (and pixel rate) would be used, because the GPU won’t listen to any other information anyway – it’s not a VIDC. And the GPU appears to do exactly as it’s told, right up to 3840×2160, in the sense that the monitor is seeing a signal with the expected number of pixels in each direction, at the expected frequency. But the image isn’t in the right place – it’s there, lovely and sharp, but offset. The pointer is also there, but offset differently. You can work out the offset by dragging a rectangle on the screen, which drags beautifully from a point offset from where the pointer is; once you’ve worked out the offset, with a bit of care you can click things – of those that are visible at all!

Very strange.

This happens even with resolutions in the hdmi_group 2, such as 2560×1600.

And it’s not that I’m exceeding the pixel rate limit – I’m doing all this at 30Hz or 24Hz.

I seem to remember that I had this problem when overscan was set incorrectly.
Have you tried chris halls scrhelp http://www.svrsig.org/software/ScrHelp.zip

but offset

@Clive. The minimal CONFIG/TXT in my write up had disable_overscan=1 to get rid of a black border around the desktop display. That issue no longer exists here with the current firmware. The line could be deleted. On my monitor it doesn’t now matter whether it is there or not. The write up has been amended.

Yup. I already tried that. Sadly it makes no difference at all – I’ve not yet tried putting overscan values in – but would that alter the fact that the visible pointer is displaced relative to where its effects are occurring?

In the 3840×2160 mode, I’ve got a black border top and bottom (both same width) – but the pointer can go into them. It can go anywhere on the screen, and stops exactly at the limits of the screen (I can tell it stops at the right and bottom edges, because if I take it off the edge and keep going, as soon as I reverse, it reappears). When I press f12, the command line appears a couple of hundred pixels down from the top, nicely at the left hand edge of the screen – on top of the backdrop, which hasn’t moved. Indeed the backdrop (and any windows on it) don’t move at all as I enter more and more lines of command line on top of it.

I can see the displacement of the pointer relative to where it’s acting by left-button dragging a selection box across the backdrop – it varies across the screen, least at the top left. Easiest to see what I mean from this video: https://youtu.be/INw9ogMBgt8

Variations on this theme in other modes beyond 1920×1200. Very similar in 2560×1440, slightly different in 2560×1600 in that while I’ve still got black borders the pointer can enter top and bottom, I’ve got a “border” left and right the pointer can’t enter, although the backdrop is present there.

Clive: What mode does the monitor think it is receiving?
It is normally displayed on a menu.
Things can go very awry if the monitor, the GPU and RISC OS are at variance.

Ah – you have it by the nose. When it’s displaying the Mac at 3840×2160, it says UHD 30p; with all those big resolutions on the Pi (including 1920×1200, which seems to work very nicely, and 3840×2160) it says 1080p.

Presumably it’s telling the Pi what it thinks it’s showing, causing mismatches between GPU and RISC OS, otherwise I’m puzzled how the relationship between the pointer and the desktop gets out of sync.

How’s it getting the 1920×1200 right? I think the 3840×2160 looks as though it’s got more than 1080p resolution, too – I’ll check later.

Variations on this theme in other modes beyond 1920×1200. Very similar in 2560×1440, slightly different in 2560×1600 in that while I’ve still got black borders the pointer can enter top and bottom, I’ve got a “border” left and right the pointer can’t enter, although the backdrop is present there.

Try adding max_framebuffer_width and max_framebuffer_height lines to the config.txt, e.g. as here. If RISC OS tries using a mode which exceeds the width/height limit specified in the config file (default width limit is 2048, I’m not sure about the height limit) then the GPU will end up cropping the display and throwing off the coordinate space conversion that’s used for positioning the mouse pointer image.

It’s either that or they’ve changed the way scaling/overscan is applied again (you are using recent GPU firmware, right?)

I should probably check to see if there’s a way of querying the GPU to find out what its limits are, so that the OS can be a bit smarter and refuse to switch to a mode that exceeds those limits (plus I still need to look into getting the GPU to change mode)

Will do. Will report as soon as I’ve done it.

I’ve discovered that I can get the monitor to report what it’s getting slightly differently, by telling it it’s looking at a computer, not a TV. But it still reports that it’s getting 1920×1080 when it’s actually getting 1920×1200 – and I’ve checked that it really is getting, and beautifully displaying, 1920×1200. But the change in “input type” makes no difference to the behaviour.

I’ve tried that with both 2560×1440 and 3840×2160. Boots up nae problem in 1920×1200, try to change to either 256×1440 at 30Hz or 3840×2160 at 25Hz and I now get “No Signal” on the monitor, rather than a duff (but lovely and sharp!) desktop. Try to go to Wimpmode 87 on the command line, and it reports “This mode is unsuitable for displaying the desktop.”

I’ve tried that with both 2560×1440 and 3840×2160. Boots up nae problem in 1920×1200, try to change to either 256×1440 at 30Hz or 3840×2160 at 25Hz and I now get “No Signal” on the monitor, rather than a duff (but lovely and sharp!) desktop.

Can you post the full contents of your config.txt?

Try to go to Wimpmode 87 on the command line, and it reports “This mode is unsuitable for displaying the desktop.”

The mode numbers the GPU uses are different to the mode numbers RISC OS uses.

The mode numbers the GPU uses are different to the mode numbers RISC OS uses.

Ah – that explains that!

Can you post the full contents of your config.txt?

disable_overscan=1
hdmi_drive=2
fake_vsync_isr=1
gpu_mem=64
init_emmc_clock=100000000
kernel=RISCOS.IMG
hdmi_mode=87
hdmi_cvt=3840 2160 25 3 0 0 1
max_framebuffer_width=3840
max_framebuffer_height=2160
hdmi_pixel_freq_limit=400000000

This has fixed the pointer-desktop mismatch in every mode that works at all – and that seems to be something to do with pixel rates and/or frame frequencies that the GPU can support and/or my monitor can handle. I’ve got numerous modes working beautifully now, right up to 2160×1600 and 2048×1800. I’ve not pinned down the boundary, but it’s probably just a matter of my particular hardware. I can’t make 2560×1440 or 3840×2160 work, not even at 24, 25 or 30Hz, which the monitor claims to handle. It definitely handles 3840×2160 at 30 Hz – that’s what my Mac is giving it.

Many, many thanks to everyone – especially Dave Pitt and Jeffrey Lee.

I can get 2160×1800 at 60Hz. It’s got black bars either side, so the aspect ratio is correct. The pointer stops at all the edges. It’s visible in the black bar at the right, but stops once its point reaches the edge of the desktop. Nice.

I don’t appear to be able to get more than 2160 horizontally or 1800 vertically, regardless of how small the other dimension is.

But I’m very happy to have these bigger modes and retire the 1600×1200 monitor that used to sit next to the big monitor.

Is hdmi_group=2 also required? It is used in the example

(Straws, clutching, etc.)

Indeed – I don’t know what hdmi_drive means. Error? Did I cut and paste it, or miscopy it? I don’t know. Will see what the effect of fixing it is…

But the fact that bigger modes and pointers past 2048 now work is wondrous. And no mysteries remaining since Jeffrey’s last post.

All sorts of resolutions that aren’t even in Group 2 seem to be working fine anyway – up to 2160 horizontally and 1800 vertically. I might try 1856 – not a number I’d have picked, but it’s there in Group 2, albeit horizontally not vertically. But then I’m using 2160 horizontally successfully, which ain’t there in Group 2. It’s odd what it allows and what it doesn’t – it ignored a mode with 2100 in it altogether. Didn’t complain, like it does if parameters don’t match, but wouldn’t display it in Configure Screen or the Display Mode picker on the icon bar.

If the Pi is booting OK but then it’s failing when you change mode from within RISC OS, try increasing the gpu_mem value. 3840×2160 at 32bpp is almost 32MB, so although you’ve currently got 64MB allocated to the GPU chances are there’s some memory fragmentation in there which could cause it to fail to allocate the new framebuffer.

Is hdmi_group=2 also required? It is used in the example

Yes, hdmi_group=2 is needed when using custom modes (hdmi_mode=87 & hdmi_cvt). See the “custom mode” section of the linked page for more info.

It’s odd what it allows and what it doesn’t – it ignored a mode with 2100 in it altogether. Didn’t complain, like it does if parameters don’t match, but wouldn’t display it in Configure Screen or the Display Mode picker on the icon bar.

At the moment RISC OS on the Pi only allows you to use modes which have a width which is a multiple of 32 (other widths are supported by the GPU, but it results in padding being added to the rows, which RISC OS can’t deal with yet). Incompatible modes in an MDF or EDID are silently filtered out of the list shown to the user, the same as on other RISC OS machines.

Yes, hdmi_group=2 is needed when using custom modes

Interesting. Is it the default then? Or is that strange hdmi_drive=2 somehow a synonym for it? Because all my strange modes were working fine with that error in!

I’ll have a go at upping the gpu_mem – but it was falling over well below 3840×2160.

I’ve discovered what hdmi_drive=2 means, and where I got it from. It’s from Dave Pitt’s piece that got me started on a new nightly build:

For sound over HDMI add hdmi_drive=2 to CONFIG/TXT.

There’s hdmi_group=2 and hdmi_drive=2!

The default hdmi_group value will depend on your monitor, so maybe you were just getting lucky with that.

I don’t know. But whatever the route we came, we’ve arrived! I now have 3840×2160 at 25Hz, and a plethora of other modes, all running beautifully!

A million thanks both of you!