Overview of current plans for displays?

Is there an overview of how screens are expected to be managed by RO in the future?

In particular, does RO cope with multiple associated screens?

I’m going to write down here what I can identify so far from the GraphicsV documentation. If there are no objections, I’ll edit it as I go along to match my understanding.

There are: drivers, heads, overlays, banks, and planes, not to mention the ubiquitous modes.

There can be multiple drivers, with multiple (up to 32 – GraphicsV 20) heads. I’m not sure if a head is a screen, or just a potential screen.

The GraphicsV interface is two-way communication with the kernel, at least in that a driver may signal a VSync interrupt by calling the vector (I wonder how that works out with multiple drivers and/or VNC frame buffers). That seems to be the only communication in that direction.

If supported, there can be (up to 255 per driver) overlays, which are bitmaps associated with (owned by) a single driver. They may consist of multiple banks, configured using MinScreenBanks in the Mode Variable Numbers part of the Mode Selector Block passed to GraphicsV 20.

In addition to the resolution, overlays are associated with an aspect ratio and may be scaled. (There is something called TCK…)

An overlay can be mapped into logical memory with one or more planes. (Speculation: depending on the format of the bitmap, RGB/YUV/etc.?) Overlays retain their contents when mapped out and back in again.

The logical address where it will appear is owned by the driver and may be limited. (“…in Wimp situations, it’s recommended to unmap your overlay(s) before allowing the Wimp to swap out your task.”)

Overlays may be displayed on multiple heads simultaneously, at different coordinates (presumably, that’s so a window or image can be split over two adjacent screens). The overlay may be scaled (affecting all heads) and the displayed area limited to a rectangle.

The driver indicates if they may be ordered by Z-order (front to back of the display). I can’t imagine a situation where a given driver would allow some overlays to be ordered and some not, but that could be my lack of imagination.

If any head changes mode, all overlays associated with the driver will be destroyed during the mode change call. (There doesn’t seem to be a mechanism to inform the user of the overlay… Service_ModeChange, perhaps, but that doesn’t know which driver it’s coming from if there’s more than one.)

I’m not sure if banks are really necessary, the clipping rectangle could be used to choose parts of a double/triple height overlay, perhaps.

I’m not sure if banks are really necessary, there doesn’t seem to be any way to create them, and the clipping rectangle could be used to choose parts of a larger overlay, perhaps.

You can. KinoAmp uses multiple overlay banks to avoid tearing effects.

OK, but does that differ much from creating a double-height overlay and switching between showing the bottom and top halves (using GraphicsV 27) as needed?

I missed how you create them: “MinScreenBanks – Minimum number of screen banks” in the Mode Variable Numbers part of the Mode Selector Block passed to GraphicsV 20. Will update the OP.

BTW I found these:

https://www.riscosopen.org/wiki/documentation/show/Proposed%20GraphicsV%20enhancements

https://www.riscosopen.org/wiki/documentation/show/Proposed%20Multiple%20Display%20implementation