Showing changes from revision #7 to #8:
Added | Removed | Changed
Entry | |
---|---|
R4 | Bits 0-23: 8 (reason code) |
Bits 24-31: Driver number |
Exit | |
---|---|
R0 | Feature flags: |
Bit 0: Supports hardware scroll | |
Bit 1: Supports hardware pointer | |
Bit 2: Supports interlace with progressive framestore | |
Bit 3: Uses seperate framestore (GraphicsV 9 implemented) | |
Bit 4: No VSyncs generated | |
Bit 5: Framestore address changes on mode change (bit 2 must be set) | |
R1 | Mask of supported pixel formats: |
Bit 0: 1bpp palettised | |
Bit 1: 2bpp palettised | |
Bit 2: 4bpp palettised | |
Bit 3: 8bpp palettised | |
Bit 4: 16bpp RGB (C32K LTBGR) | |
Bit 5: 32bpp RGB (C16M LTBGR) | |
R2 | Display buffer alignment requirement in bytes (power of 2) |
R4 | 0 |
- | All other registers preserved |
The kernel issues this to determine the available features of a driver. The appropriate driver should respond by setting R4 to 0 to claim the call, and setting R0-R2 to the appropriate values.
Using this call to read the supported pixel formats is deprecated. Instead, software should prefer to use GraphicsV 17 to read the supported formats, only falling back to this call if that call is unimplemented.
Additionally, bits 4 and 5 of R1 should reflect the availability of those exact formats indicated – bit 4 should only be set if traditional VIDC20 32K colour modes are supported, and bit 5 should only be set if traditional VIDC20 16M colour modes are supported.