Dave Airlie <[email protected]> writes: >> >> We should already be hiding this from clients -- 24bpp front buffer >> exposes 32bpp images and shared memory pixmaps. Are you saying that >> in-server software rendering to 24bpp object is broken? > > Well clients doing things direct to the 24bpp window might have > issues?
I'm not sure how they'd be able to tell; all SHM pixmaps are 32bpp, along with images. > I can't tell for sure, its a background window under gnome-shell or nautilus, > ends up covering 3/4 of the screen instead of the whole screen in the > case I saw, > so maybe 24bpp putimage is busted, but who knows, I admit that I haven't tried this in years; however, someone has to do the 32bpp to 24bpp blt, and that's really all that could be broken in the PutImage case which you're already seeing. Can you check and see if the X server is advertising 32bpp? Maybe it's just the auto-select code in fb that's busted? > all I know is we have hacks > for qt in place that force it to use its native backend when it finds > a cirrus card, > and that clients seem to screw this up quite often. Right, we added the X server hacks to expose images as 32bpp precisely because almost every client screwed up 24bpp. -- [email protected]
pgpT0G048gpOY.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
