From: Alexander Larsson <alla@lysator.liu.se>
  To  : ggi-develop@eskimo.com
  Date: Thu, 10 Sep 1998 08:23:45 +0200

Re: kgi vs. fbcon

> I feel silly commenting on my own message, but the more I think about it,
> the more I think maybe that really should be pursued in fbcon.  I dunno.
> Geert, what do you think?

 I was thinking a bit about this too. Wouldn't it be possible to add a 
/dev/graphic like the old kgi device that used fbcon/kgicon to set modes etc. 
This way people could get the benefits of the kgi way even when they are using 
fbcon.

 I assume that now the console works like this:

 Abstract console (terminal emulation, rendering in device, vc switching)
    |
 FB device (modesetting, framebuffer, user exported device)


 We could implement a new graphics device like this:

 Abstract console (terminal emulation, rendering in vc)
    |
 /dev/graphics device (one device per vc, vc switching, user exported device)
    |
 FB device (modesetting, framebuffer) 

 Of course /dev/fb could still exist for compatibility reasons, but if it's 
open /dev graphics won't work.

 Would this be possible?

> We'd still need a login that'll appropriately change modes.  Too bad we
> don't typically have something as configurable in that regard as I
> understand the BSD login is... BSD has some really nice stuff (on the system
> software side) that is worthy of adoption, or at least imitation.

 You wouldn't really need it. Only a process running on a specific vc could 
open that device.
 Of course, X would still have to be setuid root if it wants to be able to 
open on a NEW vc.

/ Alex