#51 problem with 4.2.2 using linux fbcon 8bpp

[ccrodie]

After compiling allegro-4.2.2 on Slackware 11 (gcc 3.4.6) and running example programs using fbcon, I found that programs exalpha, exblend, etc. that used 16bpp color depth or better worked fine, while programs like exhello that use 8bpp depth did not display anything on the screen.

I traced the problem to a little bug in allegro/src/linux/fbcon.c in the function fb_set_palette(). The device independent colormap
structure in linux/fb.h uses arrays of unsigned shorts for holding the color values. The docs say the color values have big endian byte order for truecolor modes. But it seems they have little endian order for 8bpp modes. Here's what fixed my problem (with no apparent ill effect on other modes):

if 1

/* in color map, big endian byte order
 * holds only for true color modes --
 * for 8bpp, using palette, we need the
 * rgb color values in low bytes
 */

for (i=0; i < (int)cmap.len; i++) {
r[i] = p[from+i].r << 2;
g[i] = p[from+i].g << 2;
b[i] = p[from+i].b << 2;
}

else

/* the original 4.2.2 code */

for (i=0; i < (int)cmap.len; i++) {
r[i] = (p[from+i].r << 10);
g[i] = (p[from+i].g << 10);
b[i] = (p[from+i].b << 10);
}

endif

I hope this is helpful. I appreciate very much this great library, and I am glad to have an opportunity to contribute just a small thing.

Regards,
Chris Rodie
Mirador Software, Inc.
Atlanta, GA

[Milan Mimica]

Logged In: YES
user_id=1171214
Originator: NO

It doesn't fix it for me :-/ With FB kernel driver are you using?

I'm using vesafb which AFAIR doesn't allow for changing color depth... I should reboot to switch to 8-bpp mode to test it I guess.

[Milan Mimica]

Logged In: YES
user_id=1171214
Originator: NO

OK, retried with vesafb in 8-bpp color depth and exhello works fine regardless to your patch. I do find it strange.

[ccrodie]

Logged In: YES
user_id=1455580
Originator: YES

I tested using i810 and i830 fb, kernel version 2.6.21.5. Maybe the behaviour I saw was peculiar to these drivers. If so, and if things work as is for other drivers, maybe the best solution is to put the values in both high and low-order bytes. I will test again with vesafb.