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