On Tuesday, June 17th, 2025 at 06:27, Alex Hung wrote:
> - 1D LUT is no longer immutable (Xaver Hugl)
I think we should keep it immutable for now, and we can make it mutable
in the future when we want to extend the uAPI to make it switchable by
user-space.
On Tuesday, June 17th, 2025 at 06:26, Alex Hung wrote:
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 651bdf48b766..21bd96f437e0 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -872,6 +872,16 @@ struct drm_color_lut {
> _
history since RC3 below.
Simon Ser (1):
build: bump version to 1.24.0
git tag: 1.24.0
https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.24.0/downloads/wayland-1.24.0.tar.xz
SHA256: 82892487a01ad67b334eca83b54317a7c86a03a89cfadacfef5211f11a5d0536
wayland-1.24.0.tar.xz
SHA512
This is the RC3 release for Wayland 1.24.
Full commit history below.
Demi Marie Obenour (1):
connection: Do not busy-loop if a message exceeds the buffer size
Simon Ser (1):
build: bump version to 1.23.93
git tag: 1.23.93
https://gitlab.freedesktop.org/wayland/wayland/-/releases
dicts themselves
tests: Add support for specifying runtime dependencies
tests: Depend on exec-fd-leak-checker
egl: Make `wayland-egl symbols check` depend on `wayland_egl`
Simon Ser (1):
build: bump version to 1.23.92
Tobias Stoeckmann (5):
cursor: Fix undefined
Hi all!
Today I've migrated the wayland-devel mailing list over to Mailman 3.
Up until now we were still using Mailman 2, but it's not supported
anymore (depends on Python 2) and has some annoying limitations (for
instance, archives are split per month).
Subscriptions and archives have been migra
documentation
shm: Remove refcount check which cannot be triggered
shm: Add wl_shm_buffer ref and unref functions
shm: Generate an error when shm access failed even without a resource
Simon Ser (11):
build: re-open main branch for regular development
scanner: extract
Thanks for the feedback! It seems like everybody is on board for
skipping alphas/betas, so let's try that. We can always go back to the
old process later if we realize it was valuable.
Simon
On Thursday, May 22nd, 2025 at 15:28, Harry Wentland
wrote:
> > > What we should
> > > do is reject YCbCr-type buffers with the color pipeline until we
> > > implement support for COLOR_ENCODING and COLOR_RANGE as a new
> > > CSC colorop.
> >
> > Rejecting is fine, but is implementing COLOR_ENC
On Wednesday, May 21st, 2025 at 21:18, Harry Wentland
wrote:
> On 2025-05-20 16:13, Harry Wentland wrote:
>
> > On 2025-05-19 19:43, Simon Ser wrote:
> >
> > > On Sunday, May 18th, 2025 at 00:32, Xaver Hugl xaver.h...@gmail.com wrote:
> > >
> > >
On Wednesday, May 21st, 2025 at 11:43, Neal Gompa wrote:
> Funnily enough, I think wlroots should probably have them since
> wlroots releases are so highly disruptive for basically every
> consumer...
wlroots has them since the last release.
> That said, going straight to RCs for libwayland its
Hi all,
With years passing by, development in the main Wayland repository has
slowed down quite a bit, activity has moved over to wayland-protocols
and compositors. However, cutting a new Wayland release is still a
heavyweight process: it takes at least one and a half months with at
least 3 pre-re
On Sunday, May 18th, 2025 at 00:32, Xaver Hugl wrote:
> > 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
> pr
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
On Thursday, May 15th, 2025 at 16:11, Harry Wentland
wrote:
> > Have there been updates from user-space implementations?
>
> I know Leandro has been working on Weston to make use of
> this and last year Xaver had a prototype in kwin.
Cool!
> Ideally we'd have gamescope adopt it and switch off
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
I've reviewed all of the core DRM patches :)
Have there been updates from user-space implementations?
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
On Tuesday, April 15th, 2025 at 13:12, Borah, Chaitanya Kumar
wrote:
> On 4/8/2025 10:10 PM, Daniel Stone wrote:
>
> > As it stands, I've gone through the implementation pretty thoroughly,
> > as well as our use of it in Weston. I'm happy with how it looks for
> > pre-blend, and I'm even happie
On Tuesday, April 15th, 2025 at 17:05, Harry Wentland
wrote:
> > > > We want to have just one change in the way we expose the hardware
> > > > capabilities else all looks good in general.
> > >
> > > I would really recommend leaving this as a follow-up extension. It's a
> > > complicated
> > >
On Tuesday, April 15th, 2025 at 08:09, Shankar, Uma
wrote:
> We want to have just one change in the way we expose the hardware
> capabilities else
> all looks good in general.
I would really recommend leaving this as a follow-up extension. It's a
complicated addition that requires more discuss
On Tuesday, April 8th, 2025 at 18:40, Daniel Stone wrote:
> > > 5. For a given colorop property, is it an invariant that the colorop
> > > will only appear in one color pipeline at a time? (I believe so, but
> > > this probably needs documenting and/or igt.)
> >
> > I don't really understand why
On Tuesday, April 1st, 2025 at 04:42, Alex Hung wrote:
> On 3/29/25 09:48, Simon Ser wrote:
>
> > I would prefer these functions to be introduced together with the
> > patches adding functions to create objects and adding the new fields.
> > That way it's easier to
On Tuesday, April 1st, 2025 at 02:10, Alex Hung wrote:
> On 3/29/25 09:26, Simon Ser wrote:
>
> > I would also highlight that we need to seamlessly switch between HW
> > fixed-function blocks and shaders/CPU with no visible difference. Depending
> > on
> > the co
Thanks a lot for these docs, very well written. I especially like the
"Driver Implementer's Guide" section.
A few minor comments below, regardless:
Reviewed-by: Simon Ser
> +What problem are we solving?
> +
> +
> +We would like to supp
Reviewed-by: Simon Ser
On Tuesday, April 1st, 2025 at 17:14, Daniel Stone wrote:
>
>
> Hi Alex,
>
> On Wed, 26 Mar 2025 at 23:50, Alex Hung alex.h...@amd.com wrote:
>
> > +static int drm_colorop_init(struct drm_device *dev, struct drm_colorop
> > *colorop,
> > + struct drm_plane *plane, enum drm_colorop_type
Thanks a lot for sending the updated series, Alex! I've looked at all
of the core DRM patches and they all look pretty close to being R-b'ed.
I don't think I'd have time to look at vkms or amdgpu patches. Let me
know if I missed anything!
Simon
I would prefer these functions to be introduced together with the
patches adding functions to create objects and adding the new fields.
That way it's easier to check the symmetry and at no point in the
series there are memory leaks.
Additionally, I would avoid using the name "cleanup", which seems
I'm personally not a fan of such boolean function arguments, especially
when caller and callee are far apart. From the caller side, the meaning
of the boolean argument is not immediately clear.
I would prefer a "flags" argument, which can take a e.g.
DRM_COLOROP_FLAG_ALLOW_BYPASS value.
But I'm n
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
um, but
(1) who knows what/how distros might end up cherry-picking (2) future
patches might take inspiration from this one.
With that fixed:
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Two nits below, regardless:
Reviewed-by: Simon Ser
> + } else if (property == plane->color_pipeline_property) {
> + /* find DRM colorop object */
> + struct drm_colorop *colorop = NULL;
> +
> + colorop = drm_colorop_find(d
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
On Tuesday, February 25th, 2025 at 15:43, Harry Wentland
wrote:
> > > We need to be a bit careful when merging patches from the same series
> > > via multiple trees. Maybe we'll merge the colorop stuff via the amd
> > > tree? I don't remember the rules around trees, and I don't know if it
> > >
On Tuesday, February 25th, 2025 at 10:37, Louis Chauvet
wrote:
> Can I extract this patch from the series and apply it on drm-misc-next?
That sounds completely fine by me, and TBH it sounds like it could even
be drm-misc-fixes material?
We need to be a bit careful when merging patches from the
On Friday, February 21st, 2025 at 19:41, Harry Wentland
wrote:
> > Other people have argued that strings make it easier for user-space to
> > start using a new KMS property without deploying new kernel uAPI headers.
>
> I don't understand this argument. You would either need to define the
> str
On Friday, February 21st, 2025 at 17:18, Harry Wentland
wrote:
> I did a brief survey of other enum properties and noticed
> that this isn't well documented for others, such as the Content
> Protection connector property, or the COLOR_RANGE and COLOR_ENCODING
> plane properties.
Isn't the Conte
On Monday, February 10th, 2025 at 23:03, Harry Wentland
wrote:
> > > + * DOC: overview
> > > + *
> > > + * A colorop represents a single color operation. Colorops are chained
> > > + * via the NEXT property and make up color pipelines. Color pipelines
> > > + * are advertised and selected via th
On Thursday, January 23rd, 2025 at 21:06, Harry Wentland
wrote:
> On 2025-01-15 03:00, Simon Ser wrote:
>
> > Is this 125 magic number something we can expect other hardware to
> > implement as well?
>
> It's based on MS's CCCS interpretation of 80 nits as 1.
On Wednesday, January 22nd, 2025 at 22:05, Harry Wentland
wrote:
> On 2025-01-15 02:56, Simon Ser wrote:
>
> > Is this "ignore" something we could do at the core DRM level, instead
> > of doing it in all drivers? e.g. by silently ignoring user-space requests
>
On Wednesday, January 22nd, 2025 at 20:48, Harry Wentland
wrote:
> On 2025-01-13 13:23, Simon Ser wrote:
>
> > > v4:
> > > - Don't block setting of COLOR_RANGE and COLOR_ENCODING
> > > when client cap is set
> >
> > Can you remind me why the
Some minor comments below, apart from that looks good!
Typo in the commit title: s/supports/support/
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 5ef87cb5b242..316c643e0dea 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -913
Reviewed-by: Simon Ser
On Friday, January 17th, 2025 at 00:33, Alex Hung wrote:
> On 1/15/25 01:14, Simon Ser wrote:
> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> >> b/drivers/gpu/drm/drm_atomic_uapi.c
> >> index a3e1fcad47ad..4744c12e429d 100644
> >> --- a/drivers/gpu/d
Reviewed-by: Simon Ser
> + prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "SIZE",
Ah, I forgot something: I think this needs to be DRM_MODE_PROP_ATOMIC?
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index a3e1fcad47ad..4744c12e429d 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -701,6 +701,9 @@ static int drm_atomic_color_set_data_property(struct
> drm_col
> The BT.709 and BT.2020 OETFs are the same, the only difference
> being that the BT.2020 variant is defined with more precision
> for 10 and 12-bit per color encodings.
Just to make sure, the spec defines this precision, correct? It's
not an AMD-specific thing?
> Both are used as encoding functi
Is this 125 magic number something we can expect other hardware to
implement as well?
Could AMD use the HDR multiplier or another block to behave as if
the multiplier didn't exist?
Note, I am no HDR expert. Maybe others have a better idea whether this
makes sense or not.
Is this "ignore" something we could do at the core DRM level, instead
of doing it in all drivers? e.g. by silently ignoring user-space requests
to set the property?
It sounds like this codepath still resets the colorspace to sRGB, which
is later overwritten by colorops pulled in the atomic state a
Reviewed-by: Simon Ser
> v4:
> - Don't block setting of COLOR_RANGE and COLOR_ENCODING
>when client cap is set
Can you remind me why these should not be blocked?
We should also add doc comments in the color_range and color_encoding fields,
to document that drivers should ignore these fields when the cap is set.
Two nits below, regardless:
Reviewed-by: Simon Ser
> +static int drm_colorop_create_data_prop(struct drm_device *dev, struct
> drm_colorop *colorop)
> +{
> + struct drm_property *prop;
> +
> + /* data */
> + prop = drm_property_create(dev,
> +int
> +drm_atomic_add_affected_colorops(struct drm_atomic_state *state,
> + struct drm_plane *plane)
> +{
> + struct drm_colorop *colorop;
> + struct drm_colorop_state *colorop_state;
> +
> + WARN_ON(!drm_atomic_get_new_plane_state(state, plane));
> +
> +
> +static void drm_atomic_colorop_print_state(struct drm_printer *p,
> + const struct drm_colorop_state *state)
> +{
> + struct drm_colorop *colorop = state->colorop;
> +
> + drm_printf(p, "colorop[%u]:\n", colorop->base.id);
> + drm_printf(p, "\ttype=%s\n", drm_get_colorop_
> +void drm_colorop_set_next_property(struct drm_colorop *colorop, struct
> drm_colorop *next)
> +{
> + if (!colorop->next_property)
> + return;
Why is this early return necessary? Shouldn't this field be always
populated?
Even if that's not the case, I don't think silently ignor
Reviewed-by: Simon Ser
This patch should probably come after all patches introducing the
properties referenced in the docs, e.g. NEXT and COLOR_PIPELINE.
Probably after "[13/45] drm/colorop: Introduce
DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE"?
> +/**
> + * DOC: overview
> + *
> + * A colorop represents a single color operati
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
On Friday, December 20th, 2024 at 10:46, Campbell Barton
wrote:
> > Instead, we've standardized a protocol to set semantic cursor shapes:
> > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/staging/cursor-shape?ref_type=heads
> >
> > Does that help?
>
> It's not a solution
Hi!
This has been discussed before, with an XCursor configuration protocol
proposal:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/21
However that approach turned out to be quite complex, and a bit
backwards (back-and-forth and duplicated work in compositors and client
On Thursday, October 3rd, 2024 at 22:01, Harry Wentland
wrote:
> From: Alex Hung
>
> It is to be used to enable HDR by allowing userpace to create and pass
> 3D LUTs to kernel and hardware.
>
> 1. new drm_colorop_type: DRM_COLOROP_3D_LUT.
> 2. 3D LUT modes define hardware capabilities to user
On Sunday, October 13th, 2024 at 17:19, Simon Ser wrote:
> Would be nice to have user-space uAPI docs for the colorop properties.
> Just like we have for other KMS object types:
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties
Ah, I suppose s
Would be nice to have user-space uAPI docs for the colorop properties.
Just like we have for other KMS object types:
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties
Internal kernel docs aren't great for user-space developers, because
user-space developers have n
I think this can be folded into "drm/colorop: Add atomic state print for
drm_colorop".
Shouldn't this patch come before the others, otherwise we're exposing
unconditionally color OP uAPI to user-space in-between the first patch
and this one?
Usually we try to not have a broken kernel in intermediate commits. It's
important for bisecting.
This is a bugfix release for Wayland 1.23.
Joaquim Monteiro (1):
meson: Fix use of install_data() without specifying install_dir
Kirill Primak (1):
Put WL_DEPRECATED in front of the function declarations
Sebastian Wick (1):
client: Handle proxies with no queue
Simon Ser (4
dd support for the HDMI Audio Data Block
cta: HDMI Audio: Add a failure when NonMixed is supported without MS
build: build edid-decode as subproject
Simon Ser (22):
build: bump version to 0.2.0-dev
build: fix invalid library version
readme: add IRC channel
test/data
On Friday, May 31st, 2024 at 16:45, Simon Ser wrote:
> > See:
> > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124
> >
> > > My goal is to implement this screen capture with a guarantee that the
> > > copy comes from a KMS wri
On Friday, May 31st, 2024 at 16:39, Andri Yngvason wrote:
> Hi Matt,
>
> fös., 31. maí 2024 kl. 13:26 skrifaði Hoosier, Matt matt.hoos...@garmin.com:
>
> > Hi,
> >
> > Yeah. I agree that although I can prototype something quick and dirty here
> > as a change to weston_output_capture_v1, it's
On Friday, May 31st, 2024 at 15:26, Hoosier, Matt
wrote:
> Drew or Simon, does either of
> https://github.com/swaywm/wlroots/blob/master/protocol/wlr-screencopy-unstable-v1.xml
> or
> https://github.com/swaywm/wlroots/blob/master/protocol/wlr-export-dmabuf-unstable-v1.xml
> strike you as a g
_user_data() and wl_client_set_user_data() to more easily attach
custom data to a client
- OpenBSD support
- A wl_shm.release request for proper cleanup of this global
Commit history since RC1 below.
Hugo Osvaldo Barrera (1):
protocol: clarify divergence in compositor behaviour
Si
Simon Ser (2):
server: document wl_display_add_socket_fd() ownership
build: bump to version 1.22.93 for the RC1 release
Vlad Zahorodnii (1):
server: Clarify fd ownership in wl_client_create()
git tag: 1.22.93
https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.22.93
This is the beta release for Wayland 1.23.
Full commit history below.
Julian Orth (1):
protocol: explicitly describe wl_keyboard state
Simon Ser (1):
build: bump to version 1.22.92 for the beta release
git tag: 1.22.92
https://gitlab.freedesktop.org/wayland/wayland/-/releases
c: Improve wording for packed IDs
Peter Hutterer (1):
Add a triage-policies file for bugbot
Sebastian Wick (3):
protocol: specify the exact form of premultiplication
server: add wl_client_get_user_data/wl_client_set_user_data
protocol: define content updates and their interna
Hi all,
Here is the release schedule for Wayland 1.23.0:
- Alpha: April 25th (in 2 weeks)
- Beta: May 9th
- RC1: May 23rd
- First potential final release: May 30th
Package maintainers are encouraged to pick up the pre-releases to make
sure packaging can be tested (and fixed) before the stable re
On Tuesday, March 12th, 2024 at 16:02, Pekka Paalanen
wrote:
> This list here is the list of all values the enum could take, right?
> Should it not be just the one value it's going to have? It'll never
> change, and it can never be changed.
Listing all possible values is how other properties be
I personally find the current code more readable.
On Wednesday, December 27th, 2023 at 19:09, jleivent
wrote:
> Is it legal for a protocol message to contain an array arg where the
> contents of the array are Wayland object ids? I don't see any instance
> of this in any current protocol descriptions I have.
Technically nothing prevents this, b
For wlroots-based compositors this is passed down via XCURSOR_THEME and
XCURSOR_SIZE just like on X11 although env vars aren't a good fit for
configuration.
There was an earlier xcursor-configuration protocol with per-seat live
XCursor config which ended up being abandoned. I wouldn't recommend th
On Monday, December 4th, 2023 at 18:51, Abhinav Kumar
wrote:
> > Where are the IGT and userspace for this uAPI addition?
>
> Yes, we made IGT changes to test and validate this. We will post them on
> the IGT dev list shortly and CC you.
>
> We do not have a compositor change yet for this as we
On Saturday, December 2nd, 2023 at 22:41, Dmitry Baryshkov
wrote:
> On Fri, 27 Oct 2023 15:32:50 -0700, Jessica Zhang wrote:
>
> > Some drivers support hardware that have optimizations for solid fill
> > planes. This series aims to expose these capabilities to userspace as
> > some compositors
On Wednesday, November 29th, 2023 at 10:35, Olivier Fourdan
wrote:
> > I'd prefer this to be kept in your personal namespace: I'd prefer not to
> > make
> > this an official Wayland project.
>
> Well, that was quick! :)
>
> If I may, would it be possible to elaborate on the rationale behind y
On Wednesday, November 29th, 2023 at 10:10, Olivier Fourdan
wrote:
> So my question is, if there is any interest for such a project [4], should
> this be moved to the wayland namespace in gitlab (we could even change the
> name of the project), should that be added to the existing "wayland-utili
On Monday, November 13th, 2023 at 11:15, Pekka Paalanen
wrote:
>
>
> On Mon, 13 Nov 2023 09:44:15 +0000
> Simon Ser cont...@emersion.fr wrote:
>
> > On Monday, November 13th, 2023 at 10:38, Pekka Paalanen ppaala...@gmail.com
> > wrote:
> >
> &g
On Monday, November 13th, 2023 at 10:41, Michel Dänzer
wrote:
> On 11/13/23 10:18, Simon Ser wrote:
>
> > On Monday, October 23rd, 2023 at 10:25, Simon Ser cont...@emersion.fr wrote:
> >
> > > > > > > > > > > > +An atomic commit with the
On Monday, November 13th, 2023 at 10:38, Pekka Paalanen
wrote:
> On Mon, 13 Nov 2023 09:18:39 +
> Simon Ser cont...@emersion.fr wrote:
>
> > On Monday, October 23rd, 2023 at 10:25, Simon Ser cont...@emersion.fr wrote:
> >
> > > > > > >
On Monday, October 23rd, 2023 at 10:25, Simon Ser wrote:
> > > > > > > > > > +An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is
> > > > > > > > > > allowed to
> > > > > > > > > > +effective
re?
With that fixed:
Reviewed-by: Simon Ser
Have you seen the comment on top?
* Atomic drivers should never call this function directly, the core will read
* out property values through the various ->atomic_get_property callbacks.
It seems like atomic drivers shouldn't call drm_object_property_get_value()
at all?
1 - 100 of 567 matches
Mail list logo
