Re: [AD] GGI patch for 3.9.21

[George Foot <mert0407@xxxxxxxxxx>]

On Tue, Jul 06, 1999 at 11:14:36PM +0100, Shawn Hargreaves wrote:
> What do people think? Perhaps we need two levels of GFX_SAFE, one which asks 
> for an ok mode in the current color depth, and one which is totally 
> desperate and will accept absolutely anything the driver can provide?

Maybe we can just make a convention that requesting a zero-sized
mode in any driver will make it attempt to set whatever modes it
thinks might work, only returning failure if it absolutely can't
set any of its (safe) modes.  Would this make the existing
GFX_SAFE system redundant?

Similarly, then, a zero colour depth would cause it to try again
with whatever colour depths it can.  So when GFX_SAFE is
requested, we'd first pretend it said GFX_AUTODETECT; if that
fails, do autodetect again with zero width and height; if that
also fails, use zero colour depth too.

> > The problem with using the current console driver is that it assumes 
> > you're using the vga driver (correct me if I'm wrong), and sets up console 
> > switching, etc. This is not required as libggi automatically does this for 
> > you (and is conflicting). It also wants root privileges.  The problem with 
> > the X driver is that is pops up a window, which ggi also does. 
> 
> Is there really any benefit to using GGI under X, given that we will soon 
> have our own native X code?

The problem here is that the GGI driver shouldn't be part of the
X port, I don't think.  If you leave it out of there, then build a
library without X support or sort out the allegro.cfg to force
the Linux console system driver into play, I'd hope that your
GGI driver works as you'd expect.  But you'd have to persuade it
to coexist with the rest of the Linux console driver first...

> I think this is really a more general issue: to what extent do we overlap 
> with GGI, versus to what extent do we sit on top of it.

Personally I think we just need to use its drivers; its ability
to run on all sorts of other platforms isn't terribly useful if
we're already supporting them anyway.  In the end it probably
depends upon what the implementor is willing to code though --
it's no use deciding we want it to support everything if nobody
wants to implement it. :)

> I suppose the real question is whether there is any way to bypass the GGI 
> console switching mechanism. If so, I think we should do that and use the 
> existing system driver routines instead. If it can't be avoided, though, we 
> obviously have no choice but to find some way to work around it.

Maybe we could wrap the sigaction function and intercept
everyone else's calls to it.  Hmm, then we'd also probaby want
to intercept the VT_GETSTATE/VT_SETSTATE ioctls...  it's getting
messier.

-- 
George