[PATCH xserver 0/5] Remove (most) 24bpp support

[Adam Jackson]

On Wed, 2016-12-07 at 14:18 -0800, Keith Packard wrote:

> I think the only question is about staging the change; do we fix DIX
> or hw/xfree86 to transparently handle this before we remove the
> rendering support?

I guess it depends what you mean by "transparently handle".

There's kind of two things being conflated in the first patch, pixmap
bpp and framebuffer bpp, but there's not much point in treating them
separately. The intent is that if you asked for 24/24 it would just be
silently ignored and you'd get 24/32 instead.

Upon a second reading, it has bugs. It will silently accept -pixmap32
on the command line, but no longer accept -pixmap24 (and thus fails to
start if you say that), even though Option "Pixmap" in xorg.conf is
silently ignored. Also you can still say -fbbpp 24, which _does_ get
parsed, but would then fail to start because that's no longer legal.
I'll respin the series, there's some other junk in 4/5 that shouldn't
be there, and the 32->24 code from modesetting should be in dix.

Assuming those bugs are gone, the only configurations that would break
are the two drivers mentioned in the commit message, and any manual
configuration that had set 24bpp in order to fit in available VRAM. The
first two we can easily fix in code, the second is a little rougher.
Personally, given how antique 24bpp-supporting hardware is at this
point, I'm okay with just a release note saying that some
configurations might break.

A more ambitious approach might be to move shadow fb setup into xfree86
from the drivers and have it automatically set up 32->24 if the driver
needs it. But how is the server to know that will work? r128 for
example has exa code for 24bpp (!), so if that initializes _and_ we add
the shadow setup we'd have two paths competing for the framebuffer.

- ajax