On Thu, Mar 12, 2020 at 6:36 PM Jason Ekstrand <jason@xxxxxxxxxxxxxx> wrote: > From the perspective of a Wayland compositor (I used to play in this > space), they'd love to implement the new explicit sync extension but > can't. Sure, they could wire up the extension, but the moment they go > to flip a client buffer to the screen directly, they discover that KMS > doesn't support any explicit sync APIs. So, yes, they can technically > implement the extension assuming the EGL stack they're running on has > the sync_file extensions but any client buffers which come in using > the explicit sync Wayland extension have to be composited and can't be > scanned out directly. As a 3D driver developer, I absolutely don't > want compositors doing that because my users will complain about > performance issues due to the extra blit. <troll> Maybe this is something for the Marketing Department to solve? Sell the extra processing that can be done during such extra blit as a feature? As a former user of a wide-gamut monitor that has no sRGB mode, and a gamer, I would definitely accept the extra step (color conversion, not "just a blit"!) between the application and the actual output. In fact, I have set up compicc just for this purpose. Games with poisonous oversaturated colors (because none of the game authors care about wide-gamut monitors) are worse than the same games affected by the very small performance penalty due to the conversion. We just need a Marketing Person to come up with a huge list of other cases where such compositing step is required for correctness, and declare that direct scanout is something that makes no sense in the present day, except possibly on embedded devices. </troll> Of course the above trolling does not solve the problem related to inability to be sure about the correct API usage. -- Alexander E. Patrakov CV: http://pc.cd/PLz7 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
