Messages in this thread | | | Date | Mon, 6 Apr 1998 23:47:55 -0400 (EDT) | From | MenTaLboY <> | Subject | Re: fbdev & KGI. |
| |
On Mon, 6 Apr 1998, David Woodhouse wrote: > I apologise for continuing the GGI thread, but... > > Could someone (Geert?) outline the main conceptual and actual differences > between fbdev and KGI?
The only real differences I've been able to see so far are:
- KGI is supposed to export short strings describing the hardware, so that hardware abstraction can be done by a userspace library (strings instead of numbers for the same reason devfs uses strings instead of device numbers)
- in cases where direct register access on the graphics hardware could be used to break security/hardware, or simply disable the system, KGI wraps the register/accel command very thinly in some sanity-checking code, and exports them via card-specific ioctl()s or other, faster user<->kernel communication mechanisms. In cases where the hardware was designed securely, it could just mmap() the registers through like fbcon does.
- KGI is very heavily oriented towards using separate drivers for the individual card components, so mixing and matching them to support new hardware is easier. fbcon is also modular, though, although maybe not quite as much. I'm looking at code now to try and make a good comparison.
- KGI is constructed in a fairly os-independent (although still sort of Unix-centric) way, so that if {Open,Free}BSD accept KGI as it looks like they eventually might, it would mean that KGI drivers for those OSes should also compile under Linux ... there's also been some preliminary work on doing a Solaris KGI as well. Some lunatic has also been suggesting BeOS :)
Otherwise, KGI and fbcon seem to do more or less the same thing.
-=MenTaLboY=-
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |