It seems that cfbfillrect and cfbcopyarea were written in a big-endian
machine (if I'm not mistaken, by Geert on m68k?) as unaligned access in
little endian produces this bug.

 

That patch set fixes my problems with vesafb. For the tested subset of 
possible
font dimensions and rotation values everything seems to be ok now. But maybe
someone with a  big-endian machine should also verify the code.

Isn´t it amazing that code as old as this still contains undetected bugs?

Is there anything like a framebuffer test suite that could be used for a 
quick verification
of especially the seldom used features?

btw: my favourite text editor sedt fails if the number of lines exceeds 
an internal
limit hit by rotation == 1 or 3 and small fonts, but it complains that 
it cannot read
its perfectly readable initialization file in that case ...  I wonder if 
there are more
applications like that.

cu,
 Knut



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click