Generic support for arbitrary screen resolutions

One of the nice features of the Raspberry Pi version of RISC OS is that it can support arbitrary resolutions beyond what’s supported by the monitor when mode changes are disabled. As I understand it, this is accomplished by configuring the monitor to use its native resolution and creating a Dispmanx layer in the resolution that RISC OS requests. Given that the necessary functionality seems to be exposed by the overlay API, is this something that could be provided in a generic way for other video drivers with overlay support?

How nice to see this request.
Old games can use weird screen modes and i wondered the same thing.
My monitor is 2560×1440 and does not like the older low res modes.
In my case i’d like we keep the video mode at 2560×1440 but use an overlay with the resolution of the older low res screen mode. The Video hardware can rescale that to 2560×1440 keeping the monitor happy and it probably will even look great.

I think this relies on the presence of Any Mode which, it has been said, works only on Pi and RPCemu.

The Raspberry Pi will (if disable_mode_changes is in CMDLINE/TXT) use the GPU to talk to the monitor at its native resolution and scale whatever RISC OS is producing.

disable_mode_changes is in CMDLINE/TXT does work.
It does a linear interpolation.
Would it be possible to have the GPU use ‘nearest’ as the overlay setting?
That will give old screen modes a more crisp visual appearance.

One of the nice features of the Raspberry Pi version of RISC OS is that it can support arbitrary resolutions beyond what’s supported by the monitor … Given that the necessary functionality seems to be exposed by the overlay API, is this something that could be provided in a generic way for other video drivers with overlay support?

Yes, its how the ADFFS 2.84 public beta GraphicsV driver upscales legacy modes. The caveat is that Overlay support isn’t in all the drivers and the ones that do have it cause all kinds of issues like stuck overlays and hard-locks when bank-switching.

disable_mode_changes is in CMDLINE/TXT does work. It does a linear interpolation. Would it be possible to have the GPU use ‘nearest’ as the overlay setting?

Overlays don’t offer much in the way of configuration, I’m not even sure if the GPU supports scaling methods on layers. You can switch the screen upscaler method though:

Add “scaling_kernel=8” to CONFIG/TXT for nearest neighbour.

- or just use any old CRT Multisynch monitors which can handle them no problemo.

@Jon: Thanks for the “scaling_kernel=8” tip!

@Sveinung: Not sure which old CRT Multi-sync monitor would have HDMI input. My old multi-sync actually has RGB analog input. Do you use a HDMI to RGB analog converter or something like that?

There are multisync LCD monitors too. They can be made to work with an HDMI to DVI adapter.

or just use any old CRT Multisynch monitors

Most monitors claiming to be multisync are actually only capable of synchronising to a specific number of different signals (such as VGA, SVGA, etc). This differentiates them from the older monitors that worked with a fixed sync rate (such as those 50Hz monitors for MODE 12, 13, 15 etc).

It does not mean the monitors will cope with whatever crap you throw at them.
Generally speaking, the 2:4 modes plain won’t work, they don’t understand interlacing.
If I recall, back in the day RISC OS used to switch MODEs 12 and 15 for 20 and 21, which worked so long as you could tolerate letterboxing.

So a multisync monitor isn’t that different to a modern LCD monitor, except that it will have a smaller set of supported resolutions because of its age, and may or may not be fussier about the timing of the signals that it accepts.

The situation is much better with the Pi, as you can get the GPU to output a nice stable signal to your monitor always in its native resolution, and then scale everything to fit it. This is useful for operating systems such as RISC OS that have a long history of offering weird resolutions due to extremely programmable video hardware. By adding solutions such as AnyMode, it’ll even bash those older interlaced modes into something that’ll fit, though as has been noted, there’s not a lot of chance of getting 2, 4, and 16 colour modes properly working on hardware that plain doesn’t support such a thing.

They can be made to work with an HDMI to DVI adapter.

Don’t you mean HDMI to VGA? That’s what I use here with my Pi devices and a couple of boot sale flat panel displays (both being 1280×1024).

My 27" AOC 1440p monitor has 2x HDMI, Display Port and VGA inputs, and because of that it will handle a range of resolutions. I tried it with my old Iyonix just before I sold it, using VGA port because that would be the last machine I had with a VGA interface. I’d expected to have to set RISC OS to a pretty standard resolution for it to work, but it was still using the MDF up for my old 24" Iiyama CRT at 2048×1536. I was very surprised to find it not only displayed a picture but it was the correct 4:3 aspect ratio, and was readable despite the odd scaling. Oh and incidentally the Iyonix could also drive it at it’s proper resolution of 2560×1440 in 16M colours.

What’s the Max res the Iyonix could run too?

That would depend on what the graphics card was used. I only had the VGA drivers and the highest I could go was 2560×1920 with my monitor. You don’t normally get such high resolutions with VGA output, it just goes to show they artificially limit the Windows drivers.