KernelGraphicsInterface [FreeBSD WIKI]

This is an old revision of the document!

Kernel Graphics Interface (KGI) is the kernel side of the General Graphics Interface (GGI).

History

KGI was initially a Linux project with the goal of being a multi-OS subsystem. GGI was aiming to be the new generation Linux console subsystem alone. As GGI was progressing, it became clear that an explicit separation between kernel and user spaces was necessary. Steffen Seeger was maybe the most convinced of this: he rewrote KGI in 1998/1999 resulting in the version we have today both under Linux and FreeBSD.

KGI Project Website

It is being ported to FreeBSD in the kgi4BSD Project.

The KGI project aims at providing the kernel of modern Unixes with general purpose APIs (grouped as KgiAPI) for the implementation of:

high-level graphic clients (KgiDevice)
low-level graphic backends (KgiDisplay)
a graphic driver framework (KGIM)
an input system (KII) with:
- input drivers (KgiInput)
- keyboard / mouse multiplexing (KgiFocus)
- keymap support (not yet)

a console (KGC) with:
- text (not yet) and graphic modes
- multi-head (HW multi input and output)
- virtual terminals (KgiFocus)
- TERM emulation (KgcXterm)
- font support (not yet)

kgi4BSD is a port of KGI for FreeBSD.

After the port of GGI to FreeBSD vgl(4) library at the of 2000, I decided to port KGI. Actually, KGI was my original challenge but what to do with KGI without GGI?

Before the kgi4BSD site was created, KGI/FreeBSD was a private project shared among KGI developers. Now kgi4BSD becomes more popular and this is a good thing. kgi4BSD is currently the only kernel graphic solution for the BSDs. It currently targets only FreeBSD but DragonfyBSD, OpenBSD and NetBSD (for its VM) could be planned.

It's a dual-licensed MIT-X / GPL project made 100% on spare time by very few people. If you like kernel development and graphics it's definitely a project for you ;)

We use the concept of condvar(9) with mutex(9) to implement something like the wait_event I found in KGI. I wonder why the condvar API is not part of the mutex one since a cv is nothing else than a mutex with a waitqueue. So I decided to merge FreeBSD condvar and mutexes in the KgiMutex implementation.

In KGI Linux code, page mapping is performed for a set of pages and not only on pagefault occurrence. I have to check whether this is also possible with FreeBSD VM. This is certainly possible using something like vm_fault_additional_pages() which is currently bypassed when getting OBJT_DEVICE or OBJT_KGI pages.

For KgiAccel, we have to change the protection of pages to provoke pagefaults on them. But pagefaults on resident pages is only expected to happen on COW pages. getpages is only used to allocation non resident pages and no flag in the prototype of getpages allow passing some flag. Faults on resident pages shall occur typically when a process being not mapped anymore attempts to access an KgiMmio or KgiAccel. By the way, pages must not be FICTITIOUS otherwise they have no corresponding PTE and thus the MMU entries can't be release by any means other than through pmaps! Currently I use my own page allocator and don't use the paging one. FreeBSD VM implementation seems completely inappropriate to alternative VM policies other than the paging one :(

What about adding a new method to pagers: .pgo_checkpages to handle faults on resident pages?

About SMP, I think excluding concurrent access to the kgi device structure could be a first attempt. Especially to manage atomic map / unmap of devices.

I'm wondering how to block a process performing graphics on a device that is unmapped. I'm not happy with any signal scheme and would really prefer a blocking thread. This implies some programming style, threading oriented with for example a thread for drawing (I mean accessing the HW resources) and others do the rest of the application. The main drawback is that programmers may not be aware of this and existing applications may not fit…