2025 X.Org Foundation Election results
Hello all, The Board of Directors election concluded at 23:59 UTC on 14 May 2025. For this election, we had 77 members who could cast a vote. 72 did, so the turnout was 92.5%. This is the 3rd highest turnout in the last 10 elections, with only 2021 (93.8%) and 2016 (98.8%) being higher. It is also a 147% increase from last year's turnout (62.9%). Thank you to everyone who took the time to vote! In the election of the Directors to the Board of the X.Org Foundation, the results were that Lyude Paul, Andres Gomez, Arkadiusz Hiler and Harry Wentland were elected for two year terms. The old full board is: Erik Faye-Lund, Mark Filion, Neal Gompa, Arkadiusz Hiler, Christopher Michael, Lyude Paul, and Simon Ser. The new full board is: Erik Faye-Lund, Mark Filion, Andres Gomez, Neal Gompa, Arkadiusz Hiler, Lyude Paul, Simon Ser, and Harry Wentland. Mark Filion, on behalf of the X.Org elections committee
Re: [PATCH V9 00/43] Color Pipeline API w/ VKMS
Am Do., 15. Mai 2025 um 22:00 Uhr schrieb Leandro Ribeiro : > > > > On 5/15/25 15:39, Daniel Stone wrote: > > Hi, > > > > On Thu, 15 May 2025 at 19:02, Harry Wentland 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 >
Re: [PATCH V8 40/43] drm/colorop: Add 3D LUT support to color pipeline
On Saturday, May 17th, 2025 at 03:23, Xaver Hugl wrote: > Do we ever expect this to be something with multiple options that > userspace could select? I think it would be good to keep our options > open and make this property not immutable (properties that are > sometimes but not always immutable are more annoying to deal with in > userspace). We can always make the property mutable on drivers that support it in the future, much like the zpos property. I think we should keep it immutable for now.
Re: [PATCH V8 40/43] drm/colorop: Add 3D LUT support to color pipeline
> We can always make the property mutable on drivers that support it in > the future, much like the zpos property. I think we should keep it > immutable for now. Sure, but I don't see any reason for immutability with an enum property - it can just limit the possible values to what it supports, and that can be only one value. Either way, it's not a big issue.
