Re: [AD] Progress report on Linux console Allegro

[George Foot <george.foot@xxxxxxxxxx>]

On Wed, Jun 23, 1999 at 08:46:14PM +0100, Shawn Hargreaves wrote:
> > Currently I have a system driver, Michael's timer driver, and a VGA 
> > graphics driver (only supporting 320x200x8 at the moment, but that's 
> > trivial to change of course). 
> 
> The way I set things up with the DOS code, you should be able to use the 
> vga.c and modex.c files from the misc directory pretty much unchanged, and 
> just provide your own implementation of the _set_vga_mode() helper function, 
> plus whatever the console switching has to do.

Yes, I planned to look in to that based on the comments at the
top of the file.  First I wanted to get the Linux version doing
at least something, though, so I could test all the console
handling, VT switching, etc.  And so some examples would work.
:)

> In DOS, _set_vga_mode() just 
> calls int 0x10, but as long as you provide a Linux implementation that knows 
> how to set mode 13h (and mode 6Ah if you want the 400x mode-X resolutions to 
> work), we should be able to share all the rest of the driver setup and mode 
> tweaking code between platforms.

I didn't realise that you'd already made such an effort to make
this work.  Of course it's really simple to make that function;
I'll have to think about what to do with the stuff in lgraph.c
while we do this.

> > Unfortunately, I had to add fields to the GFX_DRIVER struct, which means 
> > I've had to modify all the other graphics drivers, which means I might 
> > have broken them and can't test to check. 
> 
> Fun. As these ports proliferate, I can see this becoming more and more of a 
> problem. We've already reached the point where it would be really hard to 
> make major changes to the core driver structures, beyond just adding new 
> fields.

Hmm.  One thing I considered was generating these things
automatically; have a list of fields in each struct and default
values, then definitions for each driver, and if a field is not
explicitly defined it defaults.  This could be
maintainer-generated, so it wouldn't often need changing.  The
only problem would be when a field is added that another driver
needs to set to a non-default value, but neither the author of
the driver nor the person adding the field realise this.  I'm
sure that wouldn't happen in practice though.

In fact a very simple program could do this; the input could
look like this:

GFX_DRIVER my_gfx_driver = {
    GFX_MY_DRIVER,
    empty_string, /* default */
...

Lines not containing `/* default */' would be the explicitly set
ones; those marked or omitted at the end of the struct would be
updated by the program.  Alternatively we could label the fields
with their names, and base the updating on that.

> I presume your new stuff consisted of the console save/restore hooks?

Yes, I put in three functions which were in the old Linux
Allegro -- save state (to supplied buffer), restore state (from
supplied buffer) and set clock rate.  The clock rate function is
unused at the moment, maybe I shouldn't have put it in; in fact
the save/restore state functions are also not needed by the VGA
driver.  They're just there to save nonstandard registers; in
some cases I can see that it might be better to save a mode ID
code instead, and cache things like screen scrolls, then make
the restorer use these rather than read register values.  It's
open-ended, anyway.

> Speaking of which, did you ever get any results from the VBE/AF under Linux 
> thing? I may soon have a TNT driver that runs under Linux, in which case 
> I'll be able to do some testing on it.

Sort of; I got the right function names being dumped to stdin
(oops, got the wrong fd number...) by my test driver.  Ivan
Baldo tried SET's TGUI driver, but it crashed; I think this is
because Linux Allegro didn't use iopl to get access to high
numbered ports.  The current system driver still doesn't, but it
ought to be easy to change; I'm not sure what number to pass
though, the default is 0 and numbers between 0 and 3 are valid.

> Speaking of which, it occured to me that unless we do it right, VBE/AF under 
> Linux could result in a massive security hole. The idea of a suid root 
> program loading and running a block of binary code from a file named in the 
> user-specified allegro.cfg, is not exactly hard for a cracker to abuse :-)
> Perhaps we should refuse to use a vbeaf.drv that is writable by anyone other 
> than root?

Good point. :)  Maybe root ownership and only being writable by
the owner.  I think that's what you meant anyway; I can
trivially make a file nobody can write to using `chmod'. :)
root ownership is enough to ensure that root knows the driver's
there.  To some extent I feel that anyone who leaves
world-writable files lying around is asking for trouble, so
maybe we only need to check ownership.

> Has anyone here used CVS in a net-based environment before?

Not personally, but I've heard good things from people who have.
Isn't djgpp's libc done over CVS now?

> an online, multi-user repository. My immediate fear is that this would be 
> very awkward for people with unreliable modem connections, and for anyone 
> using an OS that lacks a net-aware version of CVS,

And for people like me whose development machine isn't
internetted?  IP encapsulated in floppy disks would have rather
large latency, I fear. :)

> but if it works as well 
> as I imagine it could, it is possible that this could save us lots of time. 
> I'd hate to waste lots of time trying it just in order to find out that it 
> is no good, though :-)

My problem above only exists because I'm too lazy to swap the
modems over so my mother gets the WinModem and I get the
SlowModem; it won't be a problem for long, as I'm getting more
and more fed up with reading mail in MS Telnet.  No arrow keys,
no scrolling (!), and random characters appearing all over the
place.  How on earth did they get it so wrong, it's only Telnet!

> This is a problem. At the moment I'm doing most of my coding in Linux, but I 
> build the diffs in DOS, mostly because I have to be in DOS in order to 
> generate current dependency files for the DOS and Windows compilers (I 
> figure that Unix people are smart enough to do this for themselves :-)
> The resulting patches apply fine from DOS, but as you say, Linux doesn't 
> like them much.

Is the reverse a problem too -- do Unix-generated patches not
apply properly on your machine?

> I've had no end of trouble with files changing from one text format to 
> another, even when I don't remember doing anything that ought to cause this. 
> What would be really nice, would be if the Linux version of patch could be 
> smart enough to deal with DOS-style text files. I wonder if the maintainers 
> would even consider a patch to make it do that? (patching patch, heh :-)

Hmm, IIRC there's a switch to `diff' telling it not to be
pedantic about whitespace -- so there must be a similar switch
to `patch' or it wouldn't be able to apply the resulting
patches.

> Failing that, I suppose we just need to make the fixup scripts be really 
> pedantic, and convert absolutely everything that isn't a binary file. I 
> would say to just apply the patch in DOSEMU, but that is a horrible idea, so 
> I won't suggest it.

Hmm, it would involve either ferrying files to my DOS partition
and back, or mounting my Linux partition in dosemu.  And it
involves using DOS.  Nah, not worth it. :)

I think the right thing to do is to make the fixup scripts
pedantic.  That's what they're for, after all. :)

> I don't know why the AUTHORS files would have been lowercased. They are 
> certainly uppercase on my DOS partition, so all I can think is that the 
> djgpp version of patch is for some reason deciding that it knows better, and 
> changing them for me. Yuck.

It might be djgpp itself, or Windows's LFN routines.

> > Oh, and a more general question.  In Linux, we get notified when there's a 
> > VC switch (=> the screen bitmap will be lost), and again when we switch 
> > back.  Is there a standard way to handle this in Allegro 4, like the lost 
> > bitmat callbacks in the old WinAllegro? 
> 
> The lost bitmap callback system is still in place, although I'm not sure if 
> the code currently implements it. It would almost certainly be better to 
> save the image automatically, though: that is the Right Thing to do, and the 
> only reason we don't on Windows is because DirectDraw is incapable of it.
> 
> I like your idea of saving the image automatically if no handler has been 
> installed, or letting the program deal with it if they've set up a lost 
> bitmap callback.

OK.  We need a consistent API though; the lost bitmap system
doesn't cover it at present.  The callback in the Linux version
(taken from the original Linux version) takes a parameter, which
tells it whether the app's console is begin switched to or from,
and whether the app will be (was being) suspended or
backgrounded.  Backgrounding isn't supported yet, and it
involves Linux-specific calls anyway.

I've been thinking that maybe we should have a `capabilities'
entry in the system driver, saying what Allegro can and can't do
on this platform or in this configuration.  For example, this
would tell the app, under Windows, that it won't be notified
before the screen is lost.


I looked at getting Allegro to use libgpm to read the mouse
(`info gpm' for details), but it seems gpm shuts itself down
when the console is in a graphics mode. :(  I don't really know
why; obviously the default `selection' behaviour of gpm is
inappropriate in graphics modes, but there's no reason to shut
down the services it provides to applications.

However, we still only need a MouseSystems driver, since we can
use /dev/gpmdata -- if we can rely on the user setting up gpm
that way.  I'm a bit wary of using the code from the old Linux
Allegro's mouse driver because bits of it come from SVGAlib,
according to the header of the file itself, and SVGAlib is
GPLed, isn't it?

-- 
george.foot@xxxxxxxxxx

ko cilre fi la lojban  --  http://xiron.pc.helsinki.fi/lojban/