(Sorry for re-sending; used a web mail client which send html)
On Mon, Sep 15, 2025, at 2:31 PM, Daniel Stone wrote:
> Hi Nícolas,
>
> On Wed, 3 Sept 2025 at 19:43, Nícolas F. R. A. Prado
> wrote:
> > On Tue, 2025-08-26 at 13:25 +0100, Daniel Stone wrote:
> > Based on this discussion, this is my
On Mon, Sep 15, 2025, at 2:31 PM, Daniel Stone wrote:
> Hi Nícolas,
>
> On Wed, 3 Sept 2025 at 19:43, Nícolas F. R. A. Prado
> wrote:
> > On Tue, 2025-08-26 at 13:25 +0100, Daniel Stone wrote:
> > Based on this discussion, this is my understanding for the changes
> > desired on the series and t
On Wed Aug 27, 2025 at 1:08 PM CEST, Sebastian Wick wrote:
> On Wed Aug 27, 2025 at 12:39 PM CEST, Daniel Stone wrote:
>> Hey,
>>
>> On Wed, 27 Aug 2025 at 10:41, Maxime Ripard wrote:
>>> On Wed, Aug 27, 2025 at 12:26:56AM +0800, Shengyu Qu wrote:
>>> >
On Fri Aug 22, 2025 at 8:36 PM CEST, Nícolas F. R. A. Prado wrote:
> Introduce support for a post-blend color pipeline API analogous to the
> pre-blend color pipeline API. While the pre-blend color pipeline was
> configured through a COLOR_PIPELINE property attached to a drm_plane,
> the post-blend
On Wed Aug 27, 2025 at 12:39 PM CEST, Daniel Stone wrote:
> Hey,
>
> On Wed, 27 Aug 2025 at 10:41, Maxime Ripard wrote:
>> On Wed, Aug 27, 2025 at 12:26:56AM +0800, Shengyu Qu wrote:
>> > 1.Can you send patch with only i915/amdgpu first? It's a long-needed
>> > feature
>> > to deal with some moni
With the small improvements, the core drm parts are
Reviewed-by: Sebastian Wick
On Fri Aug 15, 2025 at 5:49 AM CEST, Alex Hung wrote:
> This is an RFC set for a color pipeline API, along with implementations
> in VKMS and amdgpu. It is tested with a set of IGT tests that can be
> fo
On Wed Aug 20, 2025 at 8:16 PM CEST, Alex Hung wrote:
>
>
> On 8/19/25 09:31, Sebastian Wick wrote:
>>> +/**
>>> + * drm_plane_colorop_curve_1d_lut_init - Initialize a DRM_COLOROP_1D_LUT
>>> + *
>>> + * @dev: DRM device
>>> + * @colorop: Th
On Fri Aug 15, 2025 at 5:50 AM CEST, Alex Hung wrote:
> We've previously introduced DRM_COLOROP_1D_CURVE for
> pre-defined 1D curves. But we also have HW that supports
> custom curves and userspace needs the ability to pass
> custom curves, aka LUTs.
>
> This patch introduces a new colorop type, ca
On Fri Aug 15, 2025 at 5:49 AM CEST, Alex Hung wrote:
> From: Harry Wentland
>
> We want to be able to bypass each colorop at all times.
> Introduce a new BYPASS boolean property for this.
>
> Reviewed-by: Simon Ser
> Reviewed-by: Louis Chauvet
> Signed-off-by: Alex Hung
> Signed-off-by: Harry
On Fri Aug 15, 2025 at 5:49 AM CEST, Alex Hung wrote:
> From: Harry Wentland
>
> Add a new drm_colorop with DRM_COLOROP_1D_CURVE with two subtypes:
> DRM_COLOROP_1D_CURVE_SRGB_EOTF and DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF.
>
> Reviewed-by: Simon Ser
> Reviewed-by: Louis Chauvet
> Signed-off-by: Ha
From: Sebastian Wick
This reverts commit 63d0b87213a0ba241b3fcfba3fe7b0aed0cd1cc5.
The panel_power_savings sysfs entry can be used to change the displayed
colorimetry which breaks color managed setups.
The "do not break userspace" rule which was violated here is enough
reason to r
From: Sebastian Wick
This reverts commit 76cb763e6ea62e838ccc8f7a1ea4246d690fccc9.
Reverting the panel_power_savings sysfs. See next commit.
Signed-off-by: Sebastian Wick
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++
1 file changed, 4 insertions(+), 25 deletions
On Fri, Aug 2, 2024 at 4:37 PM Harry Wentland wrote:
>
> On 2024-08-02 09:28, Sebastian Wick wrote:
> > I'm very unhappy about how this has played out.
> >
> > We have a new sysfs property that controls a feature of the display
> > path that has been set to a
I'm very unhappy about how this has played out.
We have a new sysfs property that controls a feature of the display
path that has been set to a default(!) which changes the color
behavior! This broke color management for everyone who is on a device
which supports this feature.
What should have be
rt
* Make it clear that drivers can choose between RGB and YCbCr on their
own
Signed-off-by: Sebastian Wick
Reviewed-by: Pekka Paalanen
---
drivers/gpu/drm/drm_connector.c | 79 +
include/drm/drm_connector.h | 8
2 files changed, 61 insertions(+), 26
When extending support for a driver-specific KMS property to additional
drivers, we should apply all the requirements for new properties and
make sure the semantics are the same and documented.
v2: devs of the driver which introduced property shall help and ack
Signed-off-by: Sebastian Wick
On Thu, Mar 07, 2024 at 10:29:22AM +0200, Pekka Paalanen wrote:
> On Wed, 6 Mar 2024 17:42:09 +0100
> Sebastian Wick wrote:
>
> > On Wed, Mar 06, 2024 at 10:27:21AM +0200, Pekka Paalanen wrote:
> > > On Tue, 5 Mar 2024 14:51:49 +0100
> > > Sebastian Wick wr
When extending support for a driver-specific KMS property to additional
drivers, we should apply all the requirements for new properties and
make sure the semantics are the same and documented.
v2: devs of the driver which introduced property shall help and ack
Signed-off-by: Sebastian Wick
On Wed, Mar 06, 2024 at 03:14:15PM +0100, Maxime Ripard wrote:
> Hi,
>
> On Thu, Feb 29, 2024 at 09:28:31PM +0100, Sebastian Wick wrote:
> > When extending support for a driver-specific KMS property to additional
> > drivers, we should apply all the requirements for new pr
On Wed, Mar 06, 2024 at 10:27:21AM +0200, Pekka Paalanen wrote:
> On Tue, 5 Mar 2024 14:51:49 +0100
> Sebastian Wick wrote:
>
> > The initial idea of the Colorspace prop was that this maps 1:1 to
> > InfoFrames/SDP but KMS does not give user space enough information nor
rt
* Make it clear that drivers can choose between RGB and YCbCr on their
own
Signed-off-by: Sebastian Wick
---
drivers/gpu/drm/drm_connector.c | 79 +
include/drm/drm_connector.h | 8
2 files changed, 61 insertions(+), 26 deletions(-)
diff --git a/d
usable from user space and consistent with other
KMS properties for those variants is left as an exercise for whoever
wants to use them.
Signed-off-by: Sebastian Wick
---
drivers/gpu/drm/drm_connector.c | 67 -
include/drm/drm_connector.h | 8
2 files changed
On Fri, Mar 01, 2024 at 01:12:02PM +0100, Maxime Ripard wrote:
> On Fri, Mar 01, 2024 at 12:29:41PM +0100, Sebastian Wick wrote:
> > On Fri, Mar 01, 2024 at 11:30:56AM +0100, Maxime Ripard wrote:
> > > On Thu, Feb 29, 2024 at 08:47:26PM +0100, Sebastian Wick wrote:
> > &
On Fri, Mar 01, 2024 at 11:30:56AM +0100, Maxime Ripard wrote:
> On Thu, Feb 29, 2024 at 08:47:26PM +0100, Sebastian Wick wrote:
> > > @@ -1708,6 +1731,39 @@
> > > EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property);
> > > /**
> >
On Fri, Mar 01, 2024 at 09:29:17AM +0100, Hans Verkuil wrote:
> On 29/02/2024 20:47, Sebastian Wick wrote:
> > On Thu, Feb 22, 2024 at 07:14:07PM +0100, Maxime Ripard wrote:
> >> The i915 driver has a property to force the RGB range of an HDMI output.
> >> The vc4 drive
Hey all,
I was trying to document the Colorspace property variants with what the
sink expects, what kind of data the CRTC should be configured to
produce, and what drivers must guarantee. I tried to stick to CTA-861-I
for this exercise and after more than an hour to get the "Default"
variant right
When extending support for a driver-specific KMS property to additional
drivers, we should apply all the requirements for new properties and
make sure the semantics are the same and documented.
Signed-off-by: Sebastian Wick
---
Documentation/gpu/drm-kms.rst | 5 +
1 file changed, 5
NULL;
> +
> + return broadcast_rgb_names[broadcast_rgb].name;
> +}
> +EXPORT_SYMBOL(drm_hdmi_connector_get_broadcast_rgb_name);
> +
> static const char * const output_format_str[] = {
> [HDMI_COLORSPACE_RGB] = "RGB",
> [HD
On Wed, Feb 28, 2024 at 08:42:41PM -0300, Arthur Grillo wrote:
>
>
> On 15/01/24 12:06, Sebastian Wick wrote:
> > On Wed, Jan 10, 2024 at 02:44:00PM -0300, Arthur Grillo wrote:
> >> This patchset aims to add support for additional buffer YUV formats.
> >> More
he list is "in order of preference"
> Add a a link to the mutter MR
>
> Cc: Simon Ser
> Cc: Jonas Ådahl
> Cc: Daniel Stone
> Cc: Sameer Lattannavar
> Cc: Sebastian Wick
> Acked-by: Harry Wentland
> Acked-by: Pekka Paalanen
> Signed-of
On Thu, Feb 22, 2024 at 02:58:45PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 22, 2024 at 11:54:04AM +0100, Maxime Ripard wrote:
> > On Mon, Feb 19, 2024 at 03:01:44PM +0100, Sebastian Wick wrote:
> > > On Thu, Feb 15, 2024 at 12:00:01PM +0100, Maxime Ripard wrote:
> > >
On Thu, Feb 15, 2024 at 12:00:01PM +0100, Maxime Ripard wrote:
> On Mon, Feb 12, 2024 at 06:06:18PM +0100, Sebastian Wick wrote:
> > On Mon, Feb 12, 2024 at 05:53:48PM +0100, Maxime Ripard wrote:
> > > On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote:
> > >
On Tue, Feb 13, 2024 at 11:26:44AM +0200, Ville Syrjälä wrote:
> On Mon, Feb 12, 2024 at 05:50:36PM +0100, Sebastian Wick wrote:
> > On Mon, Feb 12, 2024 at 11:10:15AM +0200, Pekka Paalanen wrote:
> > > On Fri, 9 Feb 2024 17:53:07 +0100
> > > Xaver Hugl wrote:
> >
On Tue, Feb 13, 2024 at 12:18:16PM +0530, Uma Shankar wrote:
> Add capability property which a colorop can expose it's
> hardware's abilities. It's a blob property that can be
> filled with respective data structures depending on the
> colorop. The user space is expected to read this property
> and
On Tue, Feb 13, 2024 at 12:18:15PM +0530, Uma Shankar wrote:
> This defines a new structure to define color lut ranges,
> along with related macro definitions and enums. This will help
> describe segmented lut ranges/PWL LUTs in the hardware.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Chaita
On Mon, Feb 12, 2024 at 05:53:48PM +0100, Maxime Ripard wrote:
> On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote:
> > On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote:
> > > On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote:
> > >
On Mon, Feb 12, 2024 at 11:10:15AM +0200, Pekka Paalanen wrote:
> On Fri, 9 Feb 2024 17:53:07 +0100
> Xaver Hugl wrote:
>
> > Signed-off-by: Xaver Hugl
> > ---
> > drivers/gpu/drm/drm_connector.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_connec
the property.
> + *
> * Basically the expectation from userspace is:
> * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
> *colorspace
> --
> 2.43.0
>
Thank you!
Reviewed-by: Sebastian Wick
gt; On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard wrote:
> > > > > Hi,
> > > > >
> > > > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian Wick wrote:
> > > > > > > > /**
> > > > > > > > *
On Fri, Feb 02, 2024 at 04:49:04PM +0100, Maxime Ripard wrote:
> Hi Sebastian,
>
> On Mon, Jan 15, 2024 at 03:33:08PM +0100, Sebastian Wick wrote:
> > > /**
> > > * DOC: HDMI connector properties
> > > *
> > > + * Broadcast RGB
> > >
On Wed, Jan 17, 2024 at 12:58:15PM +, Andri Yngvason wrote:
> mið., 17. jan. 2024 kl. 09:21 skrifaði Pekka Paalanen :
> >
> > On Tue, 16 Jan 2024 14:11:43 +
> > Andri Yngvason wrote:
> >
> > > þri., 16. jan. 2024 kl. 13:29 skrifaði Sebastian Wick
&g
On Mon, Jan 15, 2024 at 04:25:41PM +0100, Maxime Ripard wrote:
> On Mon, Jan 15, 2024 at 03:33:08PM +0100, Sebastian Wick wrote:
> > On Thu, Dec 07, 2023 at 04:49:31PM +0100, Maxime Ripard wrote:
> > > The i915 driver has a property to force the RGB range of an HDMI output.
&g
On Tue, Jan 16, 2024 at 01:13:13PM +, Andri Yngvason wrote:
> Hi Sebastian,
>
> þri., 16. jan. 2024 kl. 11:42 skrifaði Sebastian Wick
> :
> >
> > On Mon, Jan 15, 2024 at 04:05:52PM +, Andri Yngvason wrote:
> > > From: Werner Sembach
> > >
> &g
On Mon, Jan 15, 2024 at 04:05:52PM +, Andri Yngvason wrote:
> From: Werner Sembach
>
> Add a new general drm property "force color format" which can be used
> by userspace to tell the graphics driver which color format to use.
I don't like the "force" in the name. This just selects the color
On Wed, Jan 10, 2024 at 02:44:00PM -0300, Arthur Grillo wrote:
> This patchset aims to add support for additional buffer YUV formats.
> More specifically, it adds support to:
>
> Semi-planar formats:
>
> - NV12
> - NV16
> - NV24
> - NV21
> - NV61
> - NV42
>
> Planar formats:
>
> - YUV440
> - YU
On Thu, Jan 11, 2024 at 05:17:46PM +, Andri Yngvason wrote:
> mið., 10. jan. 2024 kl. 13:26 skrifaði Daniel Stone :
> > >
> > > This thing here works entirely differently, and I think we need somewhat
> > > new semantics for this:
> > >
> > > - I agree it should be read-only for userspace, so i
On Mon, Jan 15, 2024 at 03:33:08PM +0100, Sebastian Wick wrote:
> On Thu, Dec 07, 2023 at 04:49:31PM +0100, Maxime Ripard wrote:
> > The i915 driver has a property to force the RGB range of an HDMI output.
> > The vc4 driver then implemented the same property with the same
> >
On Thu, Dec 07, 2023 at 04:49:31PM +0100, Maxime Ripard wrote:
> The i915 driver has a property to force the RGB range of an HDMI output.
> The vc4 driver then implemented the same property with the same
> semantics. KWin has support for it, and a PR for mutter is also there to
> support it.
>
> B
On Thu, Nov 09, 2023 at 06:38:20PM +, Dave Stevenson wrote:
> Hi Simon
>
> On Thu, 9 Nov 2023 at 17:46, Simon Ser wrote:
> >
> > On Thursday, November 9th, 2023 at 16:42, Dave Stevenson
> > wrote:
> >
> > > > > - What would be a good name for the heap? "vc4" is maybe a bit naive
> > > > >
On Wed, Nov 8, 2023 at 11:16 AM Pekka Paalanen wrote:
>
> On Tue, 7 Nov 2023 11:58:26 -0500
> Harry Wentland wrote:
>
> > On 2023-11-07 04:55, Pekka Paalanen wrote:
> > > On Mon, 6 Nov 2023 11:19:27 -0500
> > > Harry Wentland wrote:
> > >
> > >> On 2023-10-20 06:36, Pekka Paalanen wrote:
> > >>>
On Tue, Nov 07, 2023 at 11:52:11AM -0500, Harry Wentland wrote:
>
>
> On 2023-10-26 13:30, Sebastian Wick wrote:
> > On Thu, Oct 26, 2023 at 11:57:47AM +0300, Pekka Paalanen wrote:
> >> On Wed, 25 Oct 2023 15:16:08 -0500 (CDT)
> >> Alex Goins wrote:
> &g
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 Paalanen wrote:
> >>> On Wed, 25 Oct 2023 15:16:08 -0500
anen wrote:
> >
> > > On Fri, 20 Oct 2023 11:23:28 -0400
> > > Harry Wentland wrote:
> > >
> > > > On 2023-10-20 10:57, Pekka Paalanen wrote:
> > > > > On Fri, 20 Oct 2023 16:22:56 +0200
> > > > > Sebastian Wick wrote:
Honestly, the less time people spend on this property the better. Lift
the Intel one into core and be done with it. We'll hopefully be able
to remove it in the not-to-distant future with the new color pipeline
API and adding a new property which only sets the connector metadata
instead of influenci
patibility" section (Sebastian, Pekka)
>
> Signed-off-by: Harry Wentland
> Cc: Ville Syrjala
> Cc: Pekka Paalanen
> Cc: Simon Ser
> Cc: Harry Wentland
> Cc: Melissa Wen
> Cc: Jonas Ådahl
> Cc: Sebastian Wick
> Cc: Shashank Sharma
> Cc: Alexander
:
> > + * No active pixel source.
> > + * Committing with a NONE pixel source will disable the plane.
> > + *
> > + * "FB":
> > + * Framebuffer source set by the "FB_ID" property.
> > + *
> > * Note that all the property extensions described here apply either to the
> > * plane or the CRTC (e.g. for the background color, which currently is not
> > * exposed and assumed to be black).
>
> This UAPI:
> Acked-by: Pekka Paalanen
Thanks Jessica, same for me
Acked-by: Sebastian Wick
>
>
> Thanks,
> pq
> Cc: Simon Ser
> > > Cc: Harry Wentland
> > > Cc: Melissa Wen
> > > Cc: Jonas Ådahl
> > > Cc: Sebastian Wick
> > > Cc: Shashank Sharma
> > > Cc: Alexander Goins
> > > Cc: Joshua Ashton
> > > Cc: Michel Dänzer
>
On Thu, Oct 05, 2023 at 04:14:55PM -0100, Melissa Wen wrote:
> Hello,
>
> Just another iteration for AMD driver-specific color properties.
> Basically, addressing comments from the previous version.
>
> Recap: this series extends the current KMS color management API with AMD
> driver-specific pro
On Thu, Oct 05, 2023 at 04:15:04PM -0100, Melissa Wen wrote:
> Add 3D LUT property for plane color transformations using a 3D lookup
> table. 3D LUT allows for highly accurate and complex color
> transformations and is suitable to adjust the balance between color
> channels. It's also more complex
gt; Cc: Simon Ser
> Cc: Harry Wentland
> Cc: Melissa Wen
> Cc: Jonas Ådahl
> Cc: Sebastian Wick
> Cc: Shashank Sharma
> Cc: Alexander Goins
> Cc: Joshua Ashton
> Cc: Michel Dänzer
> Cc: Aleix Pol
> Cc: Xaver Hugl
> Cc: Victoria Brekenfeld
> Cc: Danie
On Tue, Sep 05, 2023 at 02:33:04PM +0200, Sebastian Wick wrote:
> On Tue, Sep 05, 2023 at 02:33:26PM +0300, Pekka Paalanen wrote:
> > On Mon, 4 Sep 2023 14:29:56 +
> > "Shankar, Uma" wrote:
> >
> > > > -Original Message-
> > > >
On Tue, Sep 05, 2023 at 02:33:26PM +0300, Pekka Paalanen wrote:
> On Mon, 4 Sep 2023 14:29:56 +
> "Shankar, Uma" wrote:
>
> > > -Original Message-
> > > From: Sebastian Wick
> > > Sent: Thursday, August 31, 2023 2:46 AM
> >
.@lists.freedesktop.org
> > Cc: wayland-de...@lists.freedesktop.org; Ville Syrjala
> > ; Pekka Paalanen
> > ;
> > Simon Ser ; Melissa Wen ; Jonas Ådahl
> > ; Sebastian Wick ; Shashank
> > Sharma ; Alexander Goins ;
> > Naseer Ahmed ; Christopher Braga
> >
>
color information would have unecessary overhead that
> does not reflect the behavior of the solid fill feature. In addition,
> assigning the solid fill blob to FB_ID would require loosening some core
> drm_property checks that might cause unwanted side effects elsewhere.
The cover lette
On Mon, Aug 28, 2023 at 05:05:08PM -0700, Jessica Zhang wrote:
> Document and add support for solid_fill property to drm_plane. In
> addition, add support for setting and getting the values for solid_fill.
>
> To enable solid fill planes, userspace must assign a property blob to
> the "solid_fill"
EVICE_LOST`` for submissions.
> +This error code means, among other things, that a device reset has happened
> and
> +it needs to recreate the contexts to keep going.
> +
> +Reporting causes of resets
> +--
> +
> +Apart from propagating the
On Tue, Aug 15, 2023 at 03:57:09PM -0300, André Almeida wrote:
> Given that prop changes may lead to modesetting, which would defeat the
> fast path of the async flip, refuse any atomic prop change for async
> flips in atomic API. The only exceptions are the framebuffer ID to flip
> to and the mode
On Fri, Aug 4, 2023 at 3:03 PM Daniel Vetter wrote:
>
> On Tue, Jun 27, 2023 at 10:23:23AM -0300, André Almeida wrote:
> > Create a section that specifies how to deal with DRM device resets for
> > kernel and userspace drivers.
> >
> > Acked-by: Pekka Paalanen
> > Signed-off-by: André Almeida
>
On Mon, Aug 7, 2023 at 7:52 PM Jessica Zhang wrote:
>
>
>
> On 8/4/2023 6:15 AM, Sebastian Wick wrote:
> > On Fri, Jul 28, 2023 at 7:03 PM Jessica Zhang
> > wrote:
> >>
> >> Add support for pixel_source property to drm_plane and related
> >>
On Fri, Aug 4, 2023 at 3:27 PM Dmitry Baryshkov
wrote:
>
> On Fri, 28 Jul 2023 at 20:03, Jessica Zhang wrote:
> >
> > Document and add support for solid_fill property to drm_plane. In
> > addition, add support for setting and getting the values for solid_fill.
> >
> > To enable solid fill planes,
On Mon, Jul 31, 2023 at 6:01 AM Dmitry Baryshkov
wrote:
>
> On 28/07/2023 20:02, Jessica Zhang wrote:
> > Document and add support for solid_fill property to drm_plane. In
> > addition, add support for setting and getting the values for solid_fill.
> >
> > To enable solid fill planes, userspace mu
On Fri, Jul 28, 2023 at 7:03 PM Jessica Zhang wrote:
>
> Add support for pixel_source property to drm_plane and related
> documentation. In addition, force pixel_source to
> DRM_PLANE_PIXEL_SOURCE_FB in DRM_IOCTL_MODE_SETPLANE as to not break
> legacy userspace.
>
> This enum property will allow u
On Sun, Jul 30, 2023 at 12:51 AM Maíra Canal wrote:
>
> After we flush the workqueue at the commit tale, we need to make sure
> that no work is queued until we destroy the state. Currently, new work
> can be queued in the workqueue, even after the commit tale, as the
> vblank thread is still runni
For what it's worth this series is
Reviewed-by: Sebastian Wick
On Thu, Aug 3, 2023 at 5:49 PM Daniel Stone wrote:
>
> Hi all,
> This is v2 to the linked patch series; thanks to everyone for reviewing
> the initial version. I've moved this out of a pure DRM scope
On Sat, Jul 1, 2023 at 4:09 AM André Almeida wrote:
>
> From: Simon Ser
>
> If the driver supports it, allow user-space to supply the
> DRM_MODE_PAGE_FLIP_ASYNC flag to request an async page-flip.
> Set drm_crtc_state.async_flip accordingly.
>
> Document that drivers will reject atomic commits if
On Fri, Jun 30, 2023 at 11:27 PM Jessica Zhang
wrote:
>
>
>
> On 6/30/2023 7:43 AM, Sebastian Wick wrote:
> > On Fri, Jun 30, 2023 at 2:26 AM Jessica Zhang
> > wrote:
> >>
> >> Add support for pixel_source property to drm_plane and related
> >&g
On Fri, Jun 30, 2023 at 4:59 PM Alex Deucher wrote:
>
> On Fri, Jun 30, 2023 at 10:49 AM Sebastian Wick
> wrote:
> >
> > On Tue, Jun 27, 2023 at 3:23 PM André Almeida
> > wrote:
> > >
> > > Create a section that specifies how to deal with DRM
On Tue, Jun 27, 2023 at 3:23 PM André Almeida wrote:
>
> Create a section that specifies how to deal with DRM device resets for
> kernel and userspace drivers.
>
> Acked-by: Pekka Paalanen
> Signed-off-by: André Almeida
> ---
>
> v4:
> https://lore.kernel.org/lkml/20230626183347.55118-1-andreal
On Fri, Jun 30, 2023 at 2:26 AM Jessica Zhang wrote:
>
> Add support for pixel_source property to drm_plane and related
> documentation.
>
> This enum property will allow user to specify a pixel source for the
> plane. Possible pixel sources will be defined in the
> drm_plane_pixel_source enum.
>
On Fri, May 26, 2023 at 6:21 PM Aravind Iddamsetty
wrote:
>
> Our hardware supports RAS(Reliability, Availability, Serviceability) by
> exposing a set of error counters which can be used by observability
> tools to take corrective actions or repairs. Traditionally there were
> being exposed via PM
On Tue, Jun 6, 2023 at 6:19 PM Joshua Ashton wrote:
>
>
>
> On 6/1/23 20:17, Harry Wentland wrote:
> >
> >
> > On 5/23/23 18:14, Melissa Wen wrote:
> >> Hook up driver-specific atomic operations for managing AMD color
> >> properties and create AMD driver-specific color management properties
> >>
With the documentation about RGB and YCC variants added the drm core patches are
Reviewed-by: Sebastian Wick
On Fri, May 26, 2023 at 6:24 PM Sebastian Wick
wrote:
>
> On Fri, May 26, 2023 at 3:16 PM Pekka Paalanen wrote:
> >
> > On Thu, 25 May 2023 15:17:56 -0400
> &g
On Fri, May 26, 2023 at 6:37 PM Simon Ser wrote:
>
> On Friday, May 26th, 2023 at 18:27, Sebastian Wick
> wrote:
>
> > > + * @DRM_MODE_COLORIMETRY_DEFAULT:
> > > + * Driver specific behavior.
> > > + * @DRM_MODE_COLORIMETRY_NO_DATA:
> > > + * Dri
o support with e.g. the appropriate YCC
transform when necessary, independent of the sink support.
> Signed-off-by: Harry Wentland
> Cc: Pekka Paalanen
> Cc: Sebastian Wick
> Cc: vitaly.pros...@amd.com
> Cc: Joshua Ashton
> Cc: Simon Ser
> Cc: Ville Syrjälä
> Cc: Melissa Wen
CYCC is "constant luminance"
> - correct type for BT.601
>
> v4:
> - drop DP/HDMI clarifications that might create
> more questions than answers
>
> Signed-off-by: Joshua Ashton
> Signed-off-by: Harry Wentland
> Reviewed-by: Harry Wentland
>
> Cc: Pekka
On Fri, May 26, 2023 at 3:16 PM Pekka Paalanen wrote:
>
> On Thu, 25 May 2023 15:17:56 -0400
> Harry Wentland wrote:
>
> > This patchset is based on Joshua's previous patchset [1], as well
> > as my previous patchset [2].
> >
> > It is
> > - enabling support for the colorspace property in amdgpu,
On Fri, May 5, 2023 at 10:40 PM Dave Airlie wrote:
>
> On Fri, 5 May 2023 at 01:23, Simon Ser wrote:
> >
> > Hi all,
> >
> > The goal of this RFC is to expose a generic KMS uAPI to configure the color
> > pipeline before blending, ie. after a pixel is tapped from a plane's
> > framebuffer and bef
On Fri, May 5, 2023 at 5:28 PM Daniel Vetter wrote:
>
> On Thu, May 04, 2023 at 03:22:59PM +, Simon Ser wrote:
> > Hi all,
> >
> > The goal of this RFC is to expose a generic KMS uAPI to configure the color
> > pipeline before blending, ie. after a pixel is tapped from a plane's
> > framebuffe
e the colorspace property
> directly to the infoframe and reduce the options to sRGB, BT709,
> BT601, and BT2020 (and possibly opRGB).
>
> v2:
> - Tested with DP and HDMI analyzers
> - Confirmed driver will fallback to lower bpc when needed
> - Dropped hunk to set HDMI AVI infof
On Fri, Mar 17, 2023 at 7:38 PM Ville Syrjälä
wrote:
>
> On Fri, Mar 17, 2023 at 06:40:53PM +0100, Sebastian Wick wrote:
> > On Fri, Mar 17, 2023 at 5:34 PM Ville Syrjälä
> > wrote:
> > >
> > > On Fri, Mar 17, 2023 at 05:37:51PM +0200, Pekka Paalanen wrote:
; > > > On Fri, 17 Mar 2023 14:50:40 +0200
> > > > Ville Syrjälä wrote:
> > > >
> > > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:
> > > > > > On Fri, 17 Mar 2023 01:01:38 +0200
> > > >
On Thu, Mar 16, 2023 at 11:59 PM Rob Clark wrote:
>
> On Thu, Mar 16, 2023 at 3:22 PM Sebastian Wick
> wrote:
> >
> > On Thu, Mar 16, 2023 at 5:29 PM Rob Clark wrote:
> > >
> > > On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl wrote:
> > > >
&g
On Thu, Mar 16, 2023 at 5:29 PM Rob Clark wrote:
>
> On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl wrote:
> >
> > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote:
> > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl wrote:
> > > >
> > > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark
; > > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > > Ville Syrjälä wrote:
> > > >
> > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
> > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland
> > > >
sed by the driver.
Not great at all. Something to remember for the new property.
> Signed-off-by: Harry Wentland
> Cc: Pekka Paalanen
> Cc: Sebastian Wick
> Cc: vitaly.pros...@amd.com
> Cc: Joshua Ashton
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-...@lists.freede
On Thu, Mar 9, 2023 at 11:03 AM Pekka Paalanen wrote:
>
> On Thu, 9 Mar 2023 01:56:11 +0100
> Sebastian Wick wrote:
>
> > On Wed, Mar 8, 2023 at 9:59 AM Pekka Paalanen wrote:
> > >
> > > On Tue, 7 Mar 2023 10:10:52 -0500
> > > Harry Wentl
ndy when debugging display
> issues.
>
> Signed-off-by: Harry Wentland
> Cc: Pekka Paalanen
> Cc: Sebastian Wick
> Cc: vitaly.pros...@amd.com
> Cc: Joshua Ashton
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Reviewed-By: Joshua Ashton
d
> Cc: Pekka Paalanen
> Cc: Sebastian Wick
> Cc: vitaly.pros...@amd.com
> Cc: Joshua Ashton
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Reviewed-By: Joshua Ashton
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 38 +++--
arry Wentland
> Cc: Pekka Paalanen
> Cc: Sebastian Wick
> Cc: vitaly.pros...@amd.com
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Cc: Joshua Ashton
> Cc: Jani Nikula
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-...@lists.freedeskt
20 colorspace entry
> > that userspace can use.
> >
> > v2:
> > - leave CYCC alone for now; it serves a purpose
> > - leave BT2020_RGB the new default BT2020
> >
> > Signed-off-by: Joshua Ashton
> > Signed-off-by: Harry Wentland
> > Reviewed
1 - 100 of 141 matches
Mail list logo
