[PATCH] modesetting: 24bpp are too confusing, shadow our way out.

Keith Packard keithp at keithp.com
Tue Jan 28 21:28:26 PST 2014

Dave Airlie <airlied at gmail.com> 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.

keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140128/3bbd7d9b/attachment.pgp>

More information about the xorg-devel mailing list