> > @@ -416,6 +417,24 @@ int drm_mode_object_get_properties(struct
> > drm_mode_object *obj, bool atomic,
> > continue;
> > }
> >
> > + if (post_blend_color_pipeline && obj->type ==
> > DRM_MODE_OBJECT_CRTC) {
> > +
> We user space folks have been convinced at this point that the sRGB EOTF
> is actually gamma 2.2, and not the piece-wise function. Now, if the
> hardware is actually the piece-wise, then that's what should be exposed,
> but I'm a bit unsure if we should do that under the name sRGB EOTF.
Maybe sim
> Yes! I would prefer "SIZE" as I can see other color op types which use
> the "DATA" prop to require this as well.
+1, no need to make it specific to luts.
> It would become mutable only for hardware that supports switching the
> interpolation. It would remain immutable otherwise.
Please let's avoid making (more) properties *sometimes* immutable, it
just makes it easier to use KMS wrong, with no benefits to it.
If a compositor is written against a dri
> 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
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
> >>>
Am Do., 27. März 2025 um 00:58 Uhr schrieb Alex Hung :
>
> It is to be used to enable HDR by allowing userpace to create and pass
> 3D LUTs to kernel and hardware.
>
> new drm_colorop_type: DRM_COLOROP_3D_LUT.
>
> Signed-off-by: Alex Hung
> ---
> v8:
> - Fix typo in subject (Simon Ser)
> - Updat
> > The 3x4 CTM colorop is not yet explicit on whether it clamps its inputs
> > or outputs. Should all colorops be explicit about it?
> >
>
> Do we expect all HW/drivers to be able to support the same behavior?
> Is this critical to using the colorop?
It doesn't need to be the same on all hardware,
Am Di., 1. Apr. 2025 um 02:29 Uhr schrieb Alex Hung :
>
>
>
> On 3/31/25 12:53, Xaver Hugl wrote:
> >> Cursor plane has no color pipeline and thus it has no colorop either. It
> >> inherits color processing from its parent plane.
> >
> > Just to be
> Cursor plane has no color pipeline and thus it has no colorop either. It
> inherits color processing from its parent plane.
Just to be sure: That means amdgpu will reject atomic commits that try
to set a color pipeline on the primary plane while showing the cursor
plane on top of it? Just like w
Hi Harry,
I applied this patch and the two issues I mentioned before are gone.
I noticed a new problem though: Changes in the COLOR_PIPELINE value
aren't always applied immediately. For testing I played an HDR video
on an SDR screen with the work/zamundaaa/drm-colorop KWin branch, and
made it full
cription
>
> v2:
> - Rebased on drm-misc-next
> - Introduce a VKMS Kunit so we can test LUT functionality in vkms_composer
> - Incorporate feedback in color_pipeline.rst doc
> - Add support for sRGB inverse EOTF
> - Add 2nd enumerated TF colorop to VKMS
> - Fix LUTs and
I'm afraid that would not be very useful. It indeed depends on the refresh
rate, but also on how close to vblank the compositor does its commits / on
what the latency requirements for the currently shown content are.
When the compositor presents a fullscreen video with frames that are queued
up in
Am Fr., 27. Okt. 2023 um 12:01 Uhr schrieb Sebastian Wick <
sebastian.w...@redhat.com>:
> On Fri, Oct 27, 2023 at 10:59:25AM +0200, Michel Dänzer wrote:
> > On 10/26/23 21:25, Alex Goins wrote:
> > > On Thu, 26 Oct 2023, Sebastian Wick wrote:
> > >> On Thu, Oct 26, 2023 at 11:57:47AM +0300, Pekka
Hi,
Victoria wanted to take part in this meeting, but she's on vacation during
that week. Would you mind having the meeting the week afterwards instead?
Best regards,
Xaver
Am Do., 17. Aug. 2023 um 21:44 Uhr schrieb Simon Zeni :
> Hello there!
>
> Apologies again for the duplicated governance m
Hi everyone,
Monday 7th of August 2023, 11:00 CEST has been selected for next weeks
meeting.
Best regards,
Xaver
Am Do., 3. Aug. 2023 um 00:58 Uhr schrieb Xaver Hugl :
> This is a meeting annoucement.
>
> The Wayland Governance Meeting is semi-regular meeting to drive
> discussio
of August.
Notes of previous meetings can be found
here:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/wikis/meetings
In the interest of not having the meeting-link publically available,
please contact me under xaver.h...@kde.org if you wish to
participate.
Best regards,
Xaver Hugl
17 matches
Mail list logo
