Javier Martinez Canillas <javierm@xxxxxxxxxx> writes: > Thomas Zimmermann <tzimmermann@xxxxxxx> writes: > [...] >> 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) ?. > I think that this unwritten rule must be documented somewhere so that we could know what the rule really is instead of people making assumptions. Because my understanding from the discussion was that user-space has no way to know if a format is "native" or "fake" and it shouldn't pay for the performance penalty of doing these format conversions in the drivers. But the irony here is that enforcing such a rule in this particular case would prevent to have a performance gain. So it seems to me as if it's the opposite to what such a rule wanted to achieve. My proposal is to write a doc patch explicitly stating that drivers must only expose a "virtual" XRGB8888 format for compatibility and that it is allowed to drop the alpha channel in the driver if that would improve the performance for a particular device (e.g: slow DMA as is the case here). That way, the spirit of the rule would be to make the driver/device as performant as possible. What do you think ? Does this make sense to you ? -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
