Hello, > > I had a look at x.org's sunffb and all they did is to rewrite > > ffb_accel.c to use XAA and add a hardware-accelerated alpha-blending > > function ( plus accompanying changes in ffb_driver.c to load > > relevant modules and a few more or less trivial ones in other files > > ). Now I have something that works, is fast but for some strange > > reason all text drawn via XRender has red and blue components > > swapped. Only text, images are fine. Playing with anti-aliasing > > parameters seems to change this too, after disabling subpixel > > hinting newly started apps get it right, until next start of the > > Xserver... It worked fine with the old code and affects both KDE and > > GTK apps. The other changes are only reformatting source and > > renaming of some macros ( XF86* -> XORG* and such ). > > Any ideas? > > Looks almost like an un- or misinitialized variable somewhere, > > defaults to ARGB, gets overwritten when someone changes > > anti-aliasing parameters and nobody noticed since ARGB is almost > > always right. > > Looks like an endian bug to me
I've found the bug. In fbpict.c / fbComposite() calls fbCompositeSolidMask_nx8x8888() when rendering text. This takes a drawable to provide the font colour as source, one with the background color as destination and the font as alpha mask. The problem is that gtk and KDE call this with an RGB picture as source even when rendering directly to the screen which is BGR. fbCompositeSolidMask*() doesn't convert the source color to the destination picture's format - apparently it assumes RGB - which is why text is drawn in the wrong color. Programs that render always in the display's native format, like apparently WindowMaker, didn't have the problem in the first place. have fun Michael
pgp1QrYCLg58Z.pgp
Description: PGP signature
pgplytfgHOonf.pgp
Description: PGP signature
