Adam Jackson <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
