Still to be done
Linux Kernel 2.6 port
KGI is only available for max Linux 2.4.27. Work is in progress on 2.6, plus separation with KII.
Memory allocation API
In order to match the services of something like AGP, KGI has to design and implement its memory management API.
KGIM multihead management
Currently multihead is managed at KGI level with displays. How to handle multiple heads at KGIM level, e.g in graphic drivers?
The overlay resource
How to design overlay management? As a resource? Providing what API?
Monitor hotplug
Unpluging / hotpluging monitors. Currently, monitor driver is statically linked to the board drivers, preventing hotplug management.
Threading inside KGI
What about a command execution model that would take full advantage of kernel threading?
Bus management
Currently, nothing abstracts the bus management of the target OS to the graphic drivers. HW allocation to KGI resources is handled statically. For example, when you load a module, you specify the KGI display id it should work with thus preventing from using multiple boards of the same kind (same PCI id for example). This is not much a limitiation on AGP systems since only one graphic board is often managed. But with later PCI specifications (PCIe?) it will be more easy to find configs with 2 or 3 graphic boards...
Implement PCIExpress specification
Once the bus abstraction layer will be ready, let's try it with PCIExpress!
API backward compatibility
Propose a strategy to manage backward compatibility of KGIM API.
Improve kgi4BSD console...
...especially keymap support.
Add graphic console to kgi4Linux
Port the kgi4BSD one?!
Document APIs
Ah! Documentation, always more.