Am Do., 15. Mai 2025 um 22:00 Uhr schrieb Leandro Ribeiro <leandro.ribe...@collabora.com>: > > > > On 5/15/25 15:39, Daniel Stone wrote: > > Hi, > > > > On Thu, 15 May 2025 at 19:02, Harry Wentland <harry.wentl...@amd.com> wrote: > >> On 2025-05-15 13:19, Daniel Stone wrote: > >>> Yeah, the Weston patches are marching on. We've still been doing a > >>> little bit of cleanup and prep work in the background to land them, > >>> but we also can't land them until the kernel lands. None of that work > >>> is material to the uAPI though: as said previously, the uAPI looks > >>> completely solid and it's something we can definitely beneficially use > >>> in Weston. (Even if we do need the obvious follow-ons for > >>> post-blending as well ...) > >> > >> We can't merge kernel uAPI without canonical userspace that uses it. > >> To move forward we'll need a userspace to at least publish a branch > >> that shows the use of this new uAPI. > >> > >> Do you have a public branch for the Weston work for this? > > > > Yeah, https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1702 > > has been around for a little while now. There are some driver bugs > > that Leandro commented on, but they don't seem material to the uAPI as > > such? > > Hello, > > Yes, there's nothing related to the API that is blocking us. It seemed > very flexible and easy to use. The bugs that I've spotted are probably > internal to AMD driver. > > I'd say that the Weston patches are converging nicely, we just need time > to get them fully reviewed. We had a few preparation MR's to land > before !1702, and now there's only one left (!1617).
I also updated the KWin MR (https://invent.kde.org/plasma/kwin/-/merge_requests/6600), it can now use all the available properties and I think it's ready. I found two issues with the kernel patches though: - while attempting to set COLOR_ENCODING and COLOR_RANGE results in the atomic commit being rejected, the existing values still get applied if you use YCbCr-type buffers. I would've expected the color pipeline to operate on the YUV values in that case - and leave conversion to RGB up to the compositor adding the relevant matrix to the pipeline - the interpolation mode drm properties for 1D and 3D LUTs are immutable, I think they shouldn't be - to make it less annoying if in the future we decide to add modes that userspace can set Other than that, I agree that it's ready to go. > Thanks, > Leandro > > > > Cheers, > > Daniel >
