KGI connects APIs of different kind. One of them (which is part of the KgiAPI) is known as KgiDevice API.

A KGI device is not what we are used to think of e.g a peripheral or anything related to HW. Instead, a KGI device is a piece of code and data using / sharing KgiResources with other KGI devices. Everything that uses the HW resources of a KgiDisplay (mode setting, framebuffer, HW pointers, palettes...) must register itself as a KGI device.

Maybe this layer of KGI was wrongly called devices because /dev/graphic and /dev/event which are the general KGI and KII user entrypoints are from Unix point of view called devices...

Different KGI devices are known currently:

KgiGraphic, the kernel/user limit for the support of userland ioctl's including mode setting

The visible effect of mapping a KgiDevice to a KgiDisplay is the change of mode on that display. Before mapping a device, a mode must have been negociated with its display. When the device is mapped, the display is requested by KGI to set the mode previously negociated. When the device is unmapped, the display is asked to unset the mode before another device is mapped and so on.

Device mapping / unmapping is performed typically when:

console events occur (special key hit for example) on the KgiFocus the device's display is attached to

an application sets a mode, it is supposed to take control of the screen: the device, allocated when opening the /dev/graphic Unix device, is then mapped with the mode just negociated

the console enters DDB (the debugger), the currently mapped KGI device (graphic app or whatelse) is unmapped and the console's KGI device is mapped

The device methods (hooks) enable the device for example to redraw the screen when mapped or to block anything being performed on the display when unmapped.