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

[Keith Packard]

Adam Jackson <ajax at redhat.com> writes:

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

Well, in a perfect world, you'd be able to plug in a card and get a
24bpp frame buffer and have the server expose that using shadow as
32bpp. As a simple fallback, could we force configurations asking for
24bpp back to 16bpp? At least the server would start?

> 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.

At a minimum, forcing those to 16bpp would at least keep the screen lit
up.

> 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.

I thought there were a pile of 24bpp chips in recent server boxes?

> 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?

Yeah, drivers would have to opt-in.

> 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.

Drivers which don't tell us they're happy to have shadow provided would
get smashed back to 16bpp?

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20161208/3d22a20d/attachment.sig>