Cursor Support

Minidrivers for display adapters that do not support a hardware cursor can use the DIB engine cursor functions to set, move, and manage a software cursor. There is one DIB engine cursor function for each of the cursor functions a driver is required to export. In most cases, the driver simply passes the parameters received by its cursor function to the corresponding DIB engine function, adding the driver's PDEVICE as the first parameter. The following table maps the DIB engine cursor functions to the corresponding GDI cursor functions:

Color Cursors

The DIB Engine's software cursor supports color cursors. A color cursor consists of a monochrome AND mask followed by an XOR device dependent bitmap. For example, on an 8 bpp display, the color cursor passed to the display driver on the SetCursor call would look like:

csHotX        DW    ?
csHotY        DW    ?
csWidth       DW    ?
csHeight      DW    ?
csWidthBytes  DW    ?
csColor       DW    ?            ; 0101h = mono, 0801h = 8bpp, etc.
csANDBits     DB    4*8 dup (?)  ; 32x32 bit mask = 4 bytes/row 
                                 ; with 8 rows
csXORBitS     DB    32*8 dup (?)    ; 32x32 pixels = 32 bytes/row 
                                 ; with 8 rows

Note that the device dependent portion of the cursor is still XORed onto the screen.

A driver informs the system that it is color-cursor capable by setting the C1_COLORCURSOR bit in the dpCaps1 field of the GDIINFO structure passed back to GDI Enable is called to get the capability bits. The DIB engine does not set this bit even though it supports color cursors. Minidrivers must set this bit explicitly.

If the driver does not set this bit, it will never be passed a color cursor. If the driver sets this bit, it can receive either monochrome or color cursors.

Most minidrivers should just let the DIB Engine's software cursor code handle the drawing of the color cursor. This presents special problems for drivers that have hardware monochrome cursors. A driver has to dynamically "turn off" its hardware cursor and "turn on" the DIB Engine's software cursor.

Animated Cursors

There is little driver involvement to support animated cursors. If the driver sets the C1_COLORCURSOR bit in the dpCaps1 field of the GDIINFO structure, this also implies that the driver can handle an animated cursor. Windows 95 implements cursor animation by calling SetCursor with a new image at a set time interval. To handle cursor animation, a driver needs to insure that:

• SetCursor does not flicker.
• SetCursor can be called at an asynchronous time.

With previous versions of Windows, SetCursor could not interrupt MoveCursor or CheckCursor. This is no longer the case for animated cursors. SetCursor can now fail and return a 0 in the AX register. This is useful if, for example, the cursor is "busy" and the image cannot be changed.

Mouse Trails

The DIB Engine's software cursor supports mouse trails. To use this, a driver needs to make sure that it chains escape calls to the DIB Engine to allow activation and deactivation of mouse trails. In addition, drivers with hardware cursors need to know when to shift to the DIB Engine's cursor to make mouse trails visible. This is done by hooking the mouse trail escape call. On the mouse trails escape, the driver may need to switch from hardware to software cursor.