Re: [AD] Progress report on Linux console Allegro

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

George Foot <george.foot@xxxxxxxxxx> writes:
> > 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;

Although now that I look at it, the drivers are all assuming that 
_set_vga_mode() can never fail. Which is very much not the case under Linux, 
especially since a couple of the tweaked modes are based on other VGA modes 
than just 13h. I'll change vga.c and modex.c to do a bit of error checking 
on this.

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

Adding new fields isn't really a problem: it only takes me 30 seconds to go 
through and add an extra NULL to each existing driver when a new field is 
added, and even if I miss one, the resulting compilation error is very 
obvious to fix.

The really awkward stuff comes when we want to change the behaviour of 
existing routines. The more drivers are being maintained by different people 
on a range of platforms, the harder this is to do.

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

It is. Although having looked into it a bit today, I find that the current 
djgpp port of CVS doesn't have any networking support. That wouldn't bother 
me, but I don't think we should standardise on a tool that not everyone will 
be able to use.

> And for people like me whose development machine isn't internetted? 

Another good point :-) This would only be useful if at least a large 
majority of the developers had a stable net connection from a machine that 
supported networked CVS. It sounds like both of us have the latter, but not 
the former. I'm far happier fixing up a broken patch by hand than I would be 
dealing with the mess after my line dropped in the middle of a CVS checkin!

But we should at least bear this in mind as a possible thing to investigate, 
if the patch merging becomes too much of an overhead. With the current 
system of people just sending things to me, the development speed is limited 
by how often I can get a new WIP version uploaded, which looks like being a 
weekly event (any more often than that, and I find myself spending all my 
free time merging patches with none left for writing code).

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

No problem on DOS, although for the last month I've actually been applying 
most patches from Linux at my end too. If the Linux diff and patch utilities 
would just ignore \r characters when reading their inputs, in the same way 
as the djgpp text file reading mode, this whole problem would go away. Since 
they already need special switches to handle binary files, that seems to me 
like it would be a sensible thing for them to do, if not by default then at 
least with a -dosmode option. Anyone fancy adding this? If not I might do it 
myself: it would save me a lot of hassle converting files back and forth...

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

The -b switch does this for diff, and -l for patch (consistency? who needs 
it :-) But I don't like using those for a major code change: they can miss 
important changes, eg. a block of code that used to be unconditional, but 
now only exists inside an "if (xxx)" block, and therefore ought to be 
indented by an extra level.

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

Just put "install=x:\lredir.exe l: LINUX\FS" in your DOSEMU config.sys.

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

I tried to duplicate this with a couple of simple tests, and couldn't get 
patch to go wrong. The closest I came is that when trying to generate a diff 
between "OLDFILE" and "NEWFILE", where "NEWFILE" doesn't exist, the 
resulting error message listed "newfile" in lowercase. Whenever both files 
existed, the resulting patch listed the names in the correct case. But I'll 
check this the next time I build a real diff.

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

Would you mind posting a brief summary of how the current Linux system 
works? I don't think anyone but you knows quite what it is :-) As I remember 
from when I discussed this with Marek way back when, it had options for 
either suspending the program when it was in the background, or going on 
running but switched so that it draws onto a memory bitmap surface, plus 
some way for the user to optionally take control of exactly when the switch 
takes place. Obviously not all of that will be possible on every OS, but if 
you can summarize exactly what currently happens in Linux, we can try to 
merge that with the Windows system to make a consistent higher level API. It 
will probably end up with wildly different features on each platform, but at 
least there can be some standard way for the user to check exactly how the 
current platform deals with this, and adjust their program accordingly.

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

At the moment we have a bunch of preprocessor defines for things like this. 
ALLEGRO_LOSE_BITMAPS is set if video memory is non-persistent. Crude, but it 
works.

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

I remember Tim Bird saying something about that. It would indeed be a 
problem: although we could just put the whole Linux Allegro under GPL, I'd 
hate to do that because it would seriously limit some of the possible uses 
for it.

You could try asking the SVGAlib maintainers (as long as you can track down 
the actual copyright holder, they are allowed to give explicit permission to 
reuse the code under some other license), or just rewrite it. There is no 
law against looking at GPL code in order to find out how to write a non-GPL 
alternative, as long as your replacement doesn't come out byte-for-byte 
identical to the original :-)


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