GraphicsV

Programmer's Reference Manuals

» Vectors

» Software Vector Numbers

» GraphicsV

Graphics Vector (42)

Use

This vector is used by the RISC OS 5 kernel to communicate with the video driver.

User software should always aim to use the appropriate OS SWI instead of calling GraphicsV directly. The information presented here is mainly of use to OS maintainers and video driver developers.

R4 is used by all GraphicsV calls to store both the reason code and to indicate whether the call has been claimed (i.e. acted upon by a driver). When a driver claims a call it will set R4 to zero. By checking R4 after calling GraphicsV it is possible to determine whether the driver supports that call or not.

Reason Codes

Notes

Driver registration and deregistration

GraphicsV based video drivers should perform the following sequence of events on startup:

1. Call OS_ScreenMode 64 to request a driver number
2. Store the number, for use by their GraphicsV handler
3. Call OS_Claim to install their GraphicsV handler
4. Start generating VSync calls if possible
5. Perform any other initialisation that’s required to prepare the driver/hardware
6. Call OS_ScreenMode 65 to let the OS know that the driver is ready for use

Once OS_ScreenMode 65 is called the driver should expect to start receiving GraphicsV calls from the OS and from other software. Before that point no calls should be received, and if they are then it’s a bug in someone else’s code and not yours.

On shutdown drivers should use the following sequence:

1. Call OS_ScreenMode 66 to indicate that the driver is stopping. Once this call returns the driver should no longer receive GraphicsV calls.
2. Halt generation of VSync calls
3. Call OS_Release to release the GraphicsV handler
4. Call OS_ScreenMode 67 to release the driver number and allow it to be allocated for use by other drivers.

Note that OS_ScreenMode reasons 64-67 must only be called from the foreground.

See also HAL Video API for details on how the OS translates GraphicsV calls to HAL calls for systems which contain a video driver in their HAL.

¹ Calling contexts

GraphicsV drivers can be called under a variety of different situations. Consult the table above, and the list below, to determine the situations in which each entry point may be called and how the implementation is allowed to behave.

• FG – These calls must only made from the foreground, with interrupts enabled. Background calls may occur while a foreground call is in progress, but no other foreground calls should occur. Foreground calls are allowed to block for long periods of time, and are allowed to enable/disable interrupts at will.
• BG – These calls must only be made from the background, i.e. from within an interrupt handler. The implementation must execute quickly in a non-blocking manner. On entry, interrupt state is undefined. Drivers may disable interrupts as required, but should not enable them if they were disabled on entry. The implementation must also be fully re-entrant, as the same (or a different) background call may be made while the first is in progress.
• FG/BG – These calls may be made from the foreground or the background. The same execution rules as background calls apply – the implementation must be fast, non-blocking, must not enable interrupts if they were disabled on entry, and must be re-entrant with other driver calls.
• SVC – These calls are only made from supervisor mode.
• SVC/IRQ – The kernel may call these entries from SVC or IRQ mode. Therefore care must be taken to preserve R14_svc around any SWI calls.

² GraphicsV 2

As an addition to the above rules, drivers are free to ignore any background calls they receive while they are in the middle of processing a mode change.

³ GraphicsV 3

This call is deprecated. Interlace settings should be specified via the VIDC list and associated control list items given to GraphicsV 2/7.

See also

• Software Vector Numbers
• OS_ScreenMode
• HAL Video API