[AD] Frame buffers and appended datafiles

["Grzegorz Adam Hankiewicz" <gah@xxxxxxxxxx>]

> What framebuffer driver are you using?

Matrox framebuffer for Millenium G200 8mb

> I can only use the vesafb device on my machine, which doesn't
> support changing resolution except at boot time, so I've been
> unable to test the mode setting code at all. It's good to hear that
> it does at least mostly work :-) 

Yes, I have now tried with the vesa one and I correctly got 
informed about not being able to switch resolutions.

> Could you add some printouts in vesafb.c, to find out exactly what
> it does return from that ioctl, and whether it thinks it has set an
> ok mode, or has actually failed but then somehow left the hardware
> in a strange state? 

Yep, now I have found other interesting things too.

The bit I was saying about Allegro setting strange video modes 
(usually blank, but sometimes with garbage on the screen) seems 
to be a problem of GFX_SAFE. It tries to use the standard VGA(?) 
When I am using a VESA framebuffer, this works, and it switches 
to 320x200, later again to the resolution I was.

However, when using the matrox fb, the mode 320x200 is set, but 
I just get the demo animation running wrapped around the screen, 
and in some sort of "interlaced mode" :-) Looks like matroxfb 
monopolizes everything related to video hardware, and it messes 
standard VGA too, so I can hardly display anything correctly at 
normal VGA resolutions (mode-x too).

And that's the funny thing. Printfing some values, I have 
discovered that I always "get" the desired resolution. It's the card 
which is unable to view it properly. Attached goes debug.txt. The 
tests where performed first with a fb resolution of 1024x768 (I 
mean, the one I use on the command line) and later at 640x480.

All reports indicate that the resolutions where set correctly. 
However, with the last 4 tests, I could only "see" properly 
640x480, because that was the mode I was in before running the 
demo. Having set 1024x768 at the command line, allowed me in the 
four first tests to see all of the resolutions, but with some 
peculiarities.

In fact, except 1024x768 which was viewed correctly, the others 
had problems with screen borders, or the screen being stretched 
bigger or smaller.

I guess it has to do with the fb not setting correctly the pixel clocks 
of the card when changing resolutions, because for example, 
800x600 was viewed streched down in the y-axis, plus the 
screen periodically flickered. 640x480 was streched even more, 
but the screen didn't flicker. 1280x1024 was too big to fit on the 
screen, and using the monitor switches didn't help -> the beams of 
the monitor were trying to draw outside of the screen (???)

Or maybe the matrox fb is still too alpha or something like that and 
doesn't know how to change card frequencies? At least fbset 
works correctly for me. Maybe if we had the source to that 
program we could figure out if there are any fields on the fb 
structure which have to be filled too...

Now, other things I have noticed:

The NumLock and CapsLock leds keep lit on after an Allegro has 
exited (even if I don't use them), and there's no way to turn them 
off, unless I reboot.

Where can I get makeinfo? I thought it would be included with the 
gcc or fileutils packages, but allegro's makefile tells me otherwise.

When I am switching consoles, the Fx keys seem to get stuck in 
the keyboard buffer (maybe with Ctrl too?), and when i return, if 
the program is using the gui routines, enter doesn't work, and 
when I click a button, that Fx key get's promptly reported. I checked 
this with Multitet, which uses Fx keys to print help, lower sound, 
etc.

Compiling fbcon.c reported: implicit declaration of function memset.

Exedat works under linux. However:

If you run strip on the exe, the attached datafile goes away.
You can't run upx on the a linux exe with datafile, but you _can_ 
use it on allegro exes which don't have attached datafiles. I will 
report this to the authors of UPX too.

I got to compile the linux version of Multitet without any warning!! :-)
And it runs very well, except for that console switching keyboard 
jamming I said before. BTW, exgui suffers from the same problem.

Grzegorz Adam Hankiewicz - gradha@xxxxxxxxxx
Gogosoftware - http://welcome.to/gogosoftware/

With the framebuffer set to 1024x768

Calling fb_init with w:1024 h:768 v_w:0 v_h:8 depth:36
Setting the mode succeded with try 0:
xres: 1024 yres: 768 xres_virtual: 1024 yres_virtual: 8188
xoffset: 0 yoffset: 0, bpp: 8 grayscale: 0

Calling fb_init with w:800 h:600 v_w:0 v_h:8 depth:36
Setting the mode succeded with try 0:
xres: 800 yres: 600 xres_virtual: 832 yres_virtual: 10077
xoffset: 0 yoffset: 0, bpp: 8 grayscale: 0

Calling fb_init with w:640 h:480 v_w:0 v_h:8 depth:36
Setting the mode succeded with try 0:
xres: 640 yres: 480 xres_virtual: 640 yres_virtual: 13100
xoffset: 0 yoffset: 0, bpp: 8 grayscale: 0

Calling fb_init with w:1280 h:1024 v_w:0 v_h:8 depth:36
Setting the mode succeded with try 0:
xres: 1280 yres: 1024 xres_virtual: 1280 yres_virtual: 6550
xoffset: 0 yoffset: 0, bpp: 8 grayscale: 0

Now the same with 640x480

Calling fb_init with w:640 h:480 v_w:0 v_h:8 depth:36
Setting the mode succeded with try 0:
xres: 640 yres: 480 xres_virtual: 640 yres_virtual: 13100
xoffset: 0 yoffset: 32, bpp: 8 grayscale: 0

Calling fb_init with w:1024 h:768 v_w:0 v_h:8 depth:36
Setting the mode succeded with try 0:
xres: 1024 yres: 768 xres_virtual: 1024 yres_virtual: 8188
xoffset: 0 yoffset: 32, bpp: 8 grayscale: 0

Calling fb_init with w:800 h:600 v_w:0 v_h:8 depth:36
Setting the mode succeded with try 0:
xres: 800 yres: 600 xres_virtual: 832 yres_virtual: 10077
xoffset: 0 yoffset: 0, bpp: 8 grayscale: 0

Calling fb_init with w:1280 h:1024 v_w:0 v_h:8 depth:36
Setting the mode succeded with try 0:
xres: 1280 yres: 1024 xres_virtual: 1280 yres_virtual: 6550
xoffset: 0 yoffset: 0, bpp: 8 grayscale: 0