Re: X endianess problem

I just finished reading through the radeonfb/endianness thread. I am
working on an old IBM PReP thin client with an S3 Trio64V2/DX.

I started out with 2.4.19 from kernel.org and added startup code and
some patches for prep_pci.c etc. I am testing this under XFree86
4.1.0.1 with the fbdev module, current stable ppc off of debian.org.

I got the 16bit console stuff working by byte-swapping the packed
rgb words in the _setcolreg handler. Same code basically as in the
clgenfb.c, for instance.

Neither X nor fbi get the byte order right, though. I tried both the
0, 5, 10 and the 8, -3, 2 offsets for 5:5:5, and the equialents for
5:6:5 as well. (I understand the -3 conceptually, but I need to look
at the source for the library fbi uses.)

BTW, here is what happens after startx (xinit):
...
s3triofb_op_set_var con=6 1024x768-1024x768-16bpp mode=22271 56 8\
 41 0 176 8 -- act=2
fb_mmap() enter
fb_mmap() success
s3triofb_op_set_var con=6 1024x768-1024x768-16bpp mode=15385 160\
 24 29 3 136 6 AT act=0
...

The 22271 ps mode must get set by XFree, or it is the default for a
new VT. Then comes the mmap, followed by the proper mode switch -- this
order is not really safe, I would think.

BTW, based on my debug output X never turns off the accelerator. Is
that OK?

The hardware documentation for my chip says that there is supposed to
be an endian-swapped mapping for the frame buffer, essentially the
second 32MB of the 64MB total bar0. As far as I can tell this second
mapping does not byte-swap the video buffer.

Any suggestions on how best to proceed are greatly appreciated.

Jochen



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.