| « 3 - Kernel Driver | :: TOC :: | 5 - Flags » |
The accelerant portion of the video card driver resides in user space. The accelerant makes available the necessary functions needed by the oprating system (app_server), and any applications, to control the video card. These functions could be merely informative in nature, or could be used to set refresh rate, display size, and so forth.
The separation of the video card driver into two components, a kernel driver component, and a user space accelerant, is done for a few different reasons:
Hooks which are not implemented are not exported. The accelerant will return a nullpointer instead. Beware: except where pointed out, the hooks won't be requested again after a modeswitch!
When either of the two hooks B_INIT_ACCELERANT and B_CLONE_ACCELERANT are requested by the app_server, they are executed before any other hook can be requested. All other hooks are declared and assigned as per appointed variables during the accelerant initialisation process and of course the availability of that function.
The BeOS R5 supported hooks are:
Initialisation:
This hook is called first. This hook will request the shared_info from the already loaded kernel driver and make a clone of it for its own use. If the kernel driver doesn't belong to the accelerant, it will be reported as such and stopped. If successful, the card will be initialised, and either a 'cold start' or 'hot start' will be executed. The video RAM location and visible framebuffer and cursor data is determined next. The needed semaphores are made, and all variables are initialised.
The accelerant creates a mode list of the available modes that the card supports. This list is made accessible through the shared_info structure. The maximum possible modes listed is integrated in the code of the accelerant, and is validated through the PROPOSE_DISPLAY_MODE. That means that a model is created for the currently controlled card. As such, the maximum DAC speed and the ammount of video RAM are of big influence for the supporting modes.
The app_server in BeOS requires that for each supported resolution in the BeOS screen preferences panel at least one mode is in the list. If the resolutions are not provided they will be greyed out. It's possible to have multiple modes per resolution, and they can have different colordepths, refresh rates, and monitor timings (different relative place and length of the horizontal and vertical sync signals).
The mode list can later be requested by a hook that will use it as a reference. In this way the app_server also can obtain the list.
Remarks:
As stated in the R4 graphics driver kit, during the creation of the display_mode list in the internal function create_mode_list() two things have to be done different:
frame_buffer_config.bytes_per_row. Only in this way will the app_server
correctly use the 'slopspace'. In other cases a virtual screen is created which can be
panned.PROPOSE_DISPLAY_MODE as pointed out isn't correct. While in the
correct way a margin is given to PROPOSE_DISPLAY_MODE for the asked for pixel
clock, it is not considered if the mode can be made within the given limits. Instead of
taking over the mode if PROPOSE_DISPLAY_MODE doesn't return a
B_ERROR, the mode only can be taken over if the function returns a
B_OK status.When the driver and accelerant is running and another application wants to load the accelerant, it must
be done through the CLONE_ACCELERANT hook. Because the card is already initialised there's
not much to be done.
First, the hook will open the kernel driver (for the 2nd or 3rd, etc). After this SHARED_INFO
is requested and cloned. After that the previously made list will be cloned as well.
When the current accelerant is the original accelerant this function destroys the semaphores that the accelerant uses, and also the cloned shared_info and mode_list. When it's a clone accelerant, the cloned shared_info and mode_list will be destroyed and the kernel driver will be closed.
This hook only returns the semaphore that the kernel driver made for synching with the vertical retrace, which is important for interference free displaying of video (as example). If there's a need for synchronisation by an application, a semaphore lock is required. This will not succeed until the kernel driver releases it during the retrace interupt routine.
ACCELERANT_MODE_COUNT returns the number of modes that are in the MODE_LIST
(made during the 'original' accelerant initialisation). The application (or app_server) which wants
requests the MODE_LIST has to allocate enough space for the accelerant to make a copy of
the list which is returned via GET_MODE_LIST.
| « 3 - Kernel Driver | :: TOC :: | 5 - Flags » |