Hi Thomas, On Wed, Jul 26, 2023 at 05:36:15PM +0200, Thomas Zimmermann wrote: > > I've already sent a patch to use internally 24bit colors, when userspace > > can use 32bit that would solve this issue as well. In the end, on the > > VGA link, 24 or 32 bit colors are the same. That would allow modern > > userspace to work on par with Xorg. So maybe we can reconsider it ? > > No way. We've had IRC flamewars over this topic already. People didn't get > work done that day; others ragequit-ed in frustration. Ask Javier, he'll > remember. :) > > The consent in DRM-land is: we're not going to mess with color formats > behind the back of userspace. The only exception is the emulation of > XRGB8888 iff the hardware does not support that. And only because it's the > fallback format that is universally supported. I'm aware that I might be reviving old heated debates here, but I'm not sure what is the problem here. I guess part of the problem is that due to the memcpy call, we would have it in software. But it's not clear to me how we're messing with color formats there: the memcpy would drop the alpha part that was doing to be dropped by the hardware anyway (and likely would have done so transparently if it wasn't for the memcpy). It doesn't affect the userspace at all, it doesn't change the way we interpret the format either, it just ignores a part of the format that is supposed to be ignored anyway. And doing so frees up a bunch of resources? So, AFAIU, it doesn't have any side effect except for the fact that it consumes less memory bandwidth and allows for more pixels to go through. That's not really "messing with the formats" in my book. Maxime
Attachment:
signature.asc
Description: PGP signature
