Showing changes from revision #4 to #5:
Added | Removed | Changed
For many years RISC OS has been running on platforms where either the base hardware supports attaching more than one monitor or, through the addition of expansion cards can do so (eg. the Iyonix PC). However, the operating system is unaware that this is the case and believes it is only ever plotting into a single screen being shown on a single monitor.
This proposal identifies a number of places where changes will be needed to add Multiple Display support, both at the lower driver level, presenting these displays for configuration, and defining user interface conventions so that applications can make effective use of them.
A driver is software, usually in a module, which presents heads and overlays to the rest of the operating system.
A screen is the logical framestore into which images are painted.
A head is the output of a graphics adapter (there are one or more of these per driver).
An overlay is a graphics plane in memory which is mixed with the default plane with the desktop on (there may be zero or more of these per head output).
A connection is the point where a monitor joins the head (a head may have more than one connection, for example different shaped sockets).
A display is the monitor or panel where the image is ultimately shown.
Update GraphicsV and other OS components to allow a driver to have multiple heads active at once.
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:
A call to read the number of available heads, and any other driver-global features.
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)
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.
The counterpart to ClaimOS, this call will be issued when the OS stops using a head.
Each display may be arranged in an imaginary grid, surrounded by up to 8 other displays.
For any reference display (the central one in this image) its position relative to its neighbours requires a table of 8×16 bit values for Top/Middle/Bottom, Left/Centre/Right. This allows for a theoretical 32 heads per driver, and up to 256 drivers, and the special value -1 to denote that there is no display in that space.
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.
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:
Dealing with monitors in the arrangement that have differing resolutions, therefore there are ‘holes’ in the combined display.
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.
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.
v1.00 – 31-Jan-2021