Service_DisplayChanged (Rev #2, changes)
Showing changes from revision #1 to #2:
Added | Removed | Changed
Service Calls
» Service_DisplayChanged
Service_DisplayChanged
(Service &DE)
| Entry | |
|---|---|
| R0 | Reason |
| R1 | 222 (&DE) |
| R2 | New display number |
| R3 | |
| 0 = Mode will be changed | |
| 128 = Mode will not be changed |
Reason Codes
| # | Hex # | Action |
|---|---|---|
| 0 | &00 | Display is in process of being changed |
| 1 | &01 | Display change complete |
| 128 | &80 | Display change about to begin |
Use
This service call is issued by OS_ScreenMode 11 when the OS is switching to a different video driver. driver, Reason or 0 when will be issued at the start kernel of receives the a operation, in order to allow components which handle screen mode processing (e.g. ScreenModes Service_DisplayStatus ) to ‘configuration prepare changing’ themselves. service Once the call is complete the kernel will attempt to select a screen mode for the new current display. If this succeeds reason code 1 will be issued in order to notify software that the change is complete. If the mode change fails the kernel will attempt to restore the previous driver, which will result in reason code 0 being issued again.GraphicsV driver.
Under RISC OS 5 the service call is issued three times, for three different stages of the operation:
- The first call will be made with reason 128 (change about to begin). At this point in time the VDU state will not have changed in any way. Programs should cease any interrupt-driven VDU output or direct screen access, as the VDU state is about to become indeterminate.
- The second call will be made with reason 0 (change in progress), after the kernel has updated VDU variable 192 to contain the new driver number. However the rest of the VDU state will not have been updated yet. Software which deals with screen mode selection (e.g. the ScreenModes module) should recache its mode lists for the new driver.
- The third call will be made with reason 1 (change complete), once the kernel has fully switched over to the new driver and selected a new screen mode. At this point the VDU is stable again and it is safe for interrupt-driven VDU output to resume.
For all the stages, R2 contains the new display number (i.e. GraphicsV driver number).
If activation of the new driver fails for any reason, the kernel will attempt to restore the previous driver. This will result in a sequence of four service calls instead of the usual three; reasons 128 and 0 will be issued with R2 set to the new driver, followed by 0 and 1 for the original driver.
Notes
The value of R3 is a sub-reason code. The Sub-reason value code 0 indicates is that used the from mode within has been reselected. Other values may indicate alternate behaviour in future.OS_ScreenMode 11 to indicate that the operation is going to result in the screen mode being changed. Sub-reason code 128 is used from within Service_DisplayStatus to indicate that the screen mode isn’t going to change. Other sub-reason codes may be defined in future.
Under RISC OS 5, the display number in R2 corresponds to the GraphicsV driver number. Additionally,VDU variable 192 will have already been updated with the new driver number at the time reason code 0 is issued.
Under RISC OS Select, the display number in R2 corresponds to the VideoV? driver number.
See Also
Social
and
ROOL Store
Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.