Re: X endianess problem

["Jochen Roth" <jochen@panix.com>]

> > Neither X nor fbi get the byte order right, though.
> 
> I think they just assume native byte order.

Yes -- Gerd Knorr set me straight on that one after I emailed him a
patch for fbi...

> > BTW, based on my debug output X never turns off the accelerator. Is
> > that OK?
> 
> fbdevHWMapMMIO() in 4.3.0 seems to disable it.

I will give that a try. I have not seen any negative side effects of
the accelerator being enabled, but it seems weird.

I also would have expected for the X server to just go and talk to
the fbdev kernel driver, instead of still mucking with the hardware
directly. At least the X server on exit at times seems to want to
reset my chip into 80x25 or 640x400 on occasion. Can't tell for sure,
my monitor does not digest the timing very well. I am fairly certain
that my driver does not do that, based on set_var() printks.

> > 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.
> 
> Well, there's no single byte swapping working for all cases, maybe you
> need to configure it by writing to some register(s)?

Yes. I found the 2 bits 36 hours ago. X looks much nicer with BE pixels.

Thanks for your suggestions.

Jochen



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5