Thomas Zimmermann <tzimmermann@xxxxxxx> writes: > Hi Maxime > > Am 27.07.23 um 16:33 schrieb Maxime Ripard: >> 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. I agree with you Maxime and I believe Thomas also does, but the concensus when that topic was (heatedly) dicusssed was that drivers should not fake a pixel format. Even if is only about dropping the alpha channel, like in the patch that Jocelyn mentioned. > > Technically not, but it's still a difference. Even in such cases without > side effects, it was dismissed when discussed in the context of simpledrm. > Indeed. I remember that discussion. > The reasoning is that userspace should always be in control of the > format (sans that one exception). If userspace wants packed 24-bits it > can support RGB888 explicitly. For the color-format transformation, > it's better to do that in userspace with SSE-like instructions than in > the kernel. > > I wasn't super-happy with this, but I think it's a clear statement with > simple rules to follow. I'd prefer that over relaxed rules where each > driver does its own thing. > I wasn't super happy either, but if I remember correctly we were the only two that had this point of view and everyone else there thought that the drivers shouldn't expose a format that don't support (other than XR24) ?. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
