SYNOPSIS

int ggiCheckMode(ggi_visual_t visual, ggi_mode *tm);
int ggiCheckTextMode(ggi_visual_t visual, int cols, int rows,
int vcols, int vrows, int fontx, int fonty,
ggi_graphtype type, ggi_mode *suggested_mode);
int ggiCheckGraphMode(ggi_visual_t visual, int x, int y,
int xv, int yv, ggi_graphtype type,
ggi_mode *suggested_mode);
int ggiCheckSimpleMode(ggi_visual_t visual, int xsize, int ysize,
int frames, ggi_graphtype type, ggi_mode *md);

DESCRIPTION

ggiCheckMode checks whether or not the given mode will work on the visual. If it does not work, it will modify the values of passed ggi_mode(3) structure so that the mode works. This mode negotiation allows the application to discover modes that are both supported by the visual and suitable to the application.

ggiCheckTextMode checks whether the text mode with the given visible and virtual dimensions and the font size is supported.

ggiCheckGraphMode checks whether the graphics mode with the given visible and virtual dimensions and type is supported.

ggiCheckSimpleMode checks whether the graphics mode with the given visible dimensions, type, and number of buffers is supported. This is used in lieu of ggiCheckGraphMode if multiple buffering is desired.

For ggiCheckTextMode, ggiCheckGraphMode and ggiCheckSimpleMode, suggested_mode is either NULL or a pointer to a ggi_mode(3) which will be filled in with the negotiated mode parameters.

RETURN VALUE

For ggiCheckTextMode and ggiCheckGraphMode, a return of 0 means that the corresponding set mode call for this mode would succeed. Otherwise, the mode given cannot be set. In this case, suggested_mode is changed to the suggested mode.

If the only modifications made to the structure is replacing GGI_AUTO or GT_AUTO value, the functions return success.

RULES FOR MODE NEGOTIATION

First, if GGI_AUTO (or GT_AUTO for the graphtype) is specified for any of the members of tm, these are filled in with the recommended values. The values could be to a maximum, preferred, or GGI_DEFMODE resolution, and will be compatible with any other constraints.

An application that does not care about a specific parameter should always specify GGI_AUTO or GT_AUTO for it.

The resulting mode is guaranteed to be valid; if not, the application can assume that it cannot set any mode on the given visual and give up.

The suggested mode is derived as follows:

1

Resolutions are always adjusted up. If you want the next lower, start out at 1x1 (or somewhere else reasonable) and jump up the ladder.

Only if the maximum resolution would be exceeded, resolutions are adjusted down to the maximum.

The above applies to visible and virtual size. If there is interference between them, the visible size is satisfied first if possible, then the virtual size.

The adjustment of one value do not normally affect other values. For example, if (visible) 320x100 (virtual 320x200) is requested, the visible size may be adjusted to 320x200, but virtual size will be left alone. Of course, if the virtual size becomes less than visible size, then it will be adjusted as well.

2

Font sizes are handled the other way round: they are adjusted down except when there is nothing below.

3

A specific graphtype is changed only if the card does not support it at all. If the maximum resolution is exceeded, then that is adjusted down and not the graphtype. This assumes, that if you request true-color, you really want that and not so badly the resolution you requested. If this is not the case, you can still retry with another graphtype or GT_AUTO.

If graphtype is changed, it is adjusted in ascending order if possible: e.g. 1->4->8->15->16->24/32 bit. So you always get a mode which can do more than you requested. Only when no better modes are available, the type is adjusted down.

EXAMPLES

Try a 320x200x8 mode:

ggi_mode sug_mode;
err = ggiCheckGraphMode(vis, 320, 200, GGI_AUTO, GGI_AUTO, GT_8BIT, 
                      &sug_mode);
if(err) {
      /* Check if returned mode is ok... */
}
else {
      ggiSetMode(vis, &sug_mode);
}