Proposed Multiple Display implementation (Rev #1)

Goals

Existing documentation

Detail

Kernel awareness

GraphicsV extensions

Overview

Update GraphicsV and other OS components to allow a driver to have multiple heads active at once.

Proposed changes

All existing GraphicsV calls will be updated to accept a head number in bits 16-23 of R4, with the exception of GraphicsV 15 (select head), which will become obsolete. Additionally, some new calls are needed:

GraphicsV DriverFeatures

A call to read the number of available heads, and any other driver-global features.

GraphicsV HeadFeatures

A call to read the features of an individual head. In particular, it’s expected that it will need to return a bitmask indicating which other heads cannot be active at the same time as this head. For example, the Pandora TV-out cable offers S-Video and Composite as two separate connectors (and therefore separate heads from the user’s perspective), but it’s impossible to use both at once.

This call should also return a localised string containing the name of the head, suitable for display to the user, e.g. in the display manager. A head ID suitable for use in configuration files may also be desirable, however it’s expected that simply using the head number will be sufficient (as the head numbers should remain stable, at least until the user swaps the video card for another)

GraphicsV ClaimOS

The OS will issue this call when it begins to use a head for the VDU driver. The driver should use this call as a hint that it should give this head preferential treatment over other heads, e.g. ensuring a hardware cursor overlay is available.

GraphicsV ReleaseOS

The counterpart to ClaimOS, this call will be issued when the OS stops using a head.

Other changes

The display manager and screen setup plugin will need updating to allow selection of the head to use. Rather than end up with two new drop downs (one for driver, one for head) it’ll probably make sense to combine them into one list.

Similar to with multiple driver support, consideration will be needed for how the default selection is stored in CMOS.

As most machines will be able to support multiple heads out of the box, display detection support will be required in order to ensure the OS picks the right head on startup.

Potential future enhancements

Once multiple head support is implemented it’s worth considering implementing a Geminus-style app to allow for multiple monitor use within the desktop. There are, broadly speaking, four ways of providing multiple monitor support, each with differing level of implementation complexity:

1. For drivers which are flexible in terms of their memory allocation (NVidia, OMAP) it should be possible to specify a memory layout where two or more framebuffers are placed side-by-side to create one framebuffer at the physical memory level. The OS will see this conjoined framebuffer, while the driver(s) will see two framebuffers with large stride values (specified using the ‘extra bytes’ control list item. However this technique will only work if the same pixel format is available across all heads. It’s expected that this approach would be implemented by creating a GraphicsV driver which acts as a man in the middle, so that the OS only directly talks to one driver but that driver organises things with the other two.
2. For drivers with inflexible memory, allocate the driver framebuffers as normal, but restrict the line length to a multiple of the page size. Then utilise the MMU to create a conjoined logical mapping of the two buffers. This will require the driver to have greater control over memory management than is currently possible, so the “improved memory management” task will need implementing first. As above, this approach is expected to be implemented in the form of a man-in-the-middle GraphicsV driver, and is also subject to the pixel format limitations.
3. For other situations, implement a GraphicsV driver which allocates its own framebuffer from ordinary RAM, marks it as read-only, and uses an abort handler to trap writes. Then at regular intervals copy the contents of any changed pages to the buffers which are managed by the real drivers. This approach will allow any size or configuration of screen geometry to be used, and can also allow for transformation between different pixel formats (within reason – the driver would probably want to ensure the hardware isn’t using a lower colour depth than the user requested). However performance will be worse than the other approaches.

Dealing with monitors in the arrangement that have differing resolutions, therefore there are ‘holes’ in the combined display.

ScreenModes support

User interface

Concept of a preferred/primary head

The Window Manager

The Toolbox

Screen setup plug-in

Display Manager

Document history

v1.00 – 31-Jan-2021

• Outline added