Re: [AD] Linux console

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

Peter Wang <tjaden@xxxxxxxxxx> writes:
> Would it be possible to move the `__al_linux_init_console' call (and
> related stuff) out of the Linux system driver, and into the specific
> graphics drivers that need them?

The trouble with doing that per driver, rather than per program run, is that 
the console system would then need to be shut down every time you change 
video modes. One result of this would be that if you ran say the demo game 
from your Gnome application menu, it would try to switch back to X while 
changing resolution on the way from the intro to the title screen...

> The reason I ask is because the SVGAlib and GGI drivers both do this bit 
> of work themselves (finding the tty fd, etc.) and I think Allegro is 
> conflicting with them. 

To be honest I'm amazed that it works at all, given that we haven't done 
anything to resolve those conflicts :-)

But rather than not initialising the Allegro console system at all, I think 
it would be better to add functions so that when setting a GGI or SVGAlib 
mode, the driver can temporarily suspend the Allegro console management, but 
without shutting it down altogether, and then resume our stuff when that 
driver is finished. It should be possible to unhook the switch events, etc, 
but leave our console selected rather than going all the way back to 
wherever we were before the program started, so that the GGI or SVGAlib 
systems will see they are already in a usable console, and work with that.

I don't know anything about GGI or SVGAlib, and very little about the 
Allegro console management (I hacked on it a bit, but George wrote most of 
it), but even if you end up having to totally shut down this system, I think 
it would be better for the drivers that require this to shut it down as the 
exceptional case, rather than for only the drivers that want it to enable 
it. It's possible that you may be able to leave most of our console 
management in place, depending on exactly which areas turn out to conflict. 
It would be especially nice if it was possible to keep enough of our stuff 
in place that the display switch callbacks, etc, could go on working.

When I briefly looked at SVGAlib, it seemed like it was hooking almost all 
the signals, in which case it may be getting all tangled up with the 
shutdown code, rather than the console management itself. Allegro hooks a 
lot of signals to ensure a clean shutdown if it crashes, and it looks like 
SVGAlib does the same thing, so I'm not sure what will happen with regard to 
it chaining to our handlers, or our handlers calling the SVGAlib shutdown 
code, etc. Plenty of room for confusion there :-)

Also, both SVGAlib and GGI provide their own input functions, which it would 
be a bit pointless to use as our keyboard code already works nicely, but 
this is another chance for conflicts if they were expecting switches to be 
initiated by their own key handlers, and have hooked parts of the switch 
management into that.

I'm rambling now though, so I'll stop. Basically what I'm saying is that if 
you can't convince SVGAlib to stay our of our way, you are welcome to push 
aside whatever parts of the Allegro system are conflicting with it, but I'd 
rather have it be pushed aside than not installed at all.


--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."