Re: [AD] Progress report on Linux console Allegro

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

George Foot <george.foot@xxxxxxxxxx> writes:
> I've been copying code from the old Linux Allegro, rearranging it to fit 
> the new structure. 

Sounds like you are making great progress. It's good to have you back on 
board!

> 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. 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.

> 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.

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

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.

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?

> I also moved Michael's timer driver to the `unix' directory, which may 
> clash with changes of his own. Urgh, I hate large patches. :)

Me too.

Has anyone here used CVS in a net-based environment before? I've been toying 
with it a bit, but not yet used it for serious work even locally. Stefan has 
been using it on his machine, and said it worked very well, but I'd be 
interested to hear from anyone who can comment on the merits of setting up 
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, 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 :-)

> Speaking of which, the 3.9.19 patch is awkward to apply, on Linux. 
> Some of the files in it are text files which `fixunix' does not touch, 
> these come from other platforms. Also, the files `AUTHORS', `CHANGES' and 
> `README' (IIRC) are capitalised in the ZIP but not in the patch.

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.

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 :-)
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.

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.

> Anyway, I hope this is of interest; I'll upload the patch tonight. Most of 
> the work was already done by Marek and Tim, of course; I've just moved 
> their code around.

My favorite way to program...

> 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.



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