Showing changes from revision #1 to #2:
Added | Removed | Changed
Entry | |
---|---|
R0 | Item |
R1 | Pointer to word-aligned buffer for result (if R2 > 0) |
R2 | Buffer length |
R4 | Bits 0-23: 18 (reason code) |
Bits 24-31: Driver number |
Exit | |
---|---|
R2 | R2 on entry, minus required buffer length |
R4 | 0 |
Buffer contents updated | |
All other registers preserved |
This call is used to read assorted pieces of information about a driver into a user-supplied buffer. On exit from the call, R2 will have been decreased by the required buffer length; therefore to determine the required buffer length you should first call with R2=0.
The supported items are as follows:
# | |
---|---|
0 | Driver version number as a binary coded decimal integer. If the driver is implemented as a module then this should be the module version number. |
1 | Module name, including instance if necessary (e.g. ‘NVidia%1’). This item should not be implemented if the driver is not a module. |
2 | Driver name, for display to the user. Often the module name will suffice |
3 | Hardware name, for display to the user. E.g. the PCI card or USB device name |
4 | List of known VIDC control list items, as a series of words, terminated by -1. Drivers will ignore control list items which are not listed here – it is the clients responsibility to check that any critical control list items are supported by the driver when preparing a VIDC list for the mode set or vet calls. |
5 | Maximum number of overlays supported. Reading this item may return zero or be ignored by drivers which do not support overlays. |
All text items are returned as null-terminated ASCII strings.
If R2 is smaller than the required buffer size, only the first R2 bytes of the value will be copied to the buffer.