VideoGuard

Introduction

The VideoGuard module provides protection against the user being left with no display due to an absent display driver. In normal use the system is actively displaying graphics on a display that is currently present. Under some circumstances, however, it is possible for the system to be using a display device which is absent. The two circumstances under which this can occur are :

System startup

If the system has been configured to use a display device but no such device is yet present there is no useful display to use. This is the case during the early system initialisation before the display driver has initialised. Such cases will not usually be visible to users. More commonly, however, the system may be configured to use device 1, which is present on an expansion card but the card has been removed. Usually this can be over-ridden by holding the '0' key during system startup (see the ResetTypes document for more details).

Device driver removal

If the display driver for the current display is killed then the display no longer exists. This is uncommon, but may occur during testing. Future device drivers may be dynamic and thus may provide devices which come and go as necessary.

When the current display driver is removed, or not present during the system startup, the graphics system takes no additional action except to mark the frame buffer as absent. The address of the screen will be read as 0. Graphics drivers should check for this case.

The VideoGuard module will recover from these circumstances by selecting the native (display 0) device.

Technical Details

The VideoGuard module monitors the display services (see the Display changes document) in order to detect the removal of a device. When a device is removed, or started, the VideoGuard module will restart its checks for the current display being valid. If the display is not valid the VideoGuard module will become active. If the display is valid, the VideoGuard module will deactivate itself.

When active, the module monitors the keyboard input routines (OS_Byte &79, &7A, &81 and OS_ReadC) and the Wimp error box service. If these are called and the display is valid, the module will become inactive. Alternatively if they are called in a manner which indicates that the system will be waiting for user input the system will attempt to switch to the native device.

In order to be deemed to be waiting for a user input one of the following conditions must be true :

This will trap the majority of cases where the system is idle waiting for user input and no driver is present whilst allowing activity to take place (such as may occur during the boot sequence) where the system is expecting a driver to be loaded.

Once the VideoGuard module has detected a case where the system is waiting for input in this way it will attempt to force the display to the native driver. How this is achieved depends on whether the desktop is active or not :

The recovery from a failed display driver is never going to be ideal, but this behaviour has been determined from user feedback and regular use. It has been found to be suitable for most cases where the video driver is not present, particularly with regard to the absent expansion card.