[AD] 'teensy little change' to fbcon.c fixes allegro-4.0.3 to work on my stupid platform

["John Utz" <Johnut01@xxxxxxxxxx>]

Hi;

i am porting nintendo's aircraft cabin entertainment system over from
an STMicro STPC running win311 to a NatSemi('ne AMD) Geode running RHL
7.2-ish.

for various reasons, i concluded that framebuffer would be a better
choice than SVGAlib ( poking at the Geode's quasi-virtual VGA registers
seems to make the Geode very sullen and/or angry; it seems to respond
much better to the implicit courtesy involved in using /dev/fb0 ).

however, until this morning, i was unable to get an appropriate display
until i hacked the 'stride' assignment to use the fb fixedinfo
line_length instead of my_mode.xres_virtual:

roughly line 276 in src/linux/fbcon.c...

/* stride = my_mode.xres_virtual * BYTES_PER_PIXEL(color_depth); */

stride = fix_info.line_length * BYTES_PER_PIXEL(color_depth);

It works for me on my challenged platform, and i suspect that it might
be a generally applicable fix.

However, it begs the question of why it was coded that way in the first
place. 

Does it work properly as originally coded on somebody else's platform?
And, on said platform, is the line_length != xres_virtual?

If the original code *does* work properly for somebody else, i'd like
to hear about it, because it will probably give me a new understanding
about how framebuffer is supposed to work. 

My current understanding is that i am mmap'ing a linear area that
represents a linear area ( ala' progressive scan  DVD video) as opposed
to (for instance) a pair of 1/2 sized interlaced odd and even scanline
buffers (ala' oldskool NTSC or PAL video).

If it's a generally applicable fix, i'd love to see it added, if it's
not, i'd really love to hear about why it isnt.

tnx!

johnu