We want compositors to be able to set the output
colorspace on DP and HDMI outputs, based on the
caps reported from the receiver via EDID.
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
We need the connector_state for colorspace and scaling information
and can get it from connector->state.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: Simon Ser
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc:
nction doc
Signed-off-by: Harry Wentland
Reviewed-by: Sebastian Wick
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: Simon Ser
Cc: Ville Syrjälä
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.o
that might create
more questions than answers
v5:
- Add note on YCC and RGB variants
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Reviewed-by: Harry Wentland
Reviewed-by: Sebastian Wick
Acked-by: Pekka Paalanen
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.c
Signed-off-by: Harry Wentland
Reviewed-by: Sebastian Wick
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: Simon Ser
Cc: Ville Syrjälä
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd
This allows us to use strongly typed arguments.
v2:
- Bring NO_DATA back
- Provide explicit enum values
v3:
- Drop unnecessary '&' from kerneldoc (emersion)
v4:
- Fix Normal Colorimetry comment
Signed-off-by: Harry Wentland
Reviewed-by: Simon Ser
Reviewed-by: Sebastian Wi
italy.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Jani Nikula
Cc: Michel Dänzer
Cc: Simon Ser
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Harry Wentland (10):
drm/connector: Convert DRM_MODE_COLORIMETRY to enum
dr
On 6/6/23 12:57, Melissa Wen wrote:
> On 06/06, Sebastian Wick wrote:
>> 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
ave missed something, please let me know if that's the
> case.
>
Looks like we're on the right track with this.
Patches 1-3, 15, 17, 24-31, 33-35 are
Reviewed-by: Harry Wentland
I left comments on a bunch of the other patches. Let's replace drm_
prefices with amdgpu_ or amdgpu
On 5/23/23 18:15, Melissa Wen wrote:
> From: Joshua Ashton
>
> Need to funnel the color caps through to these functions so it can check
> that the hardware is capable.
>
> Signed-off-by: Joshua Ashton
> Signed-off-by: Melissa Wen
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 35 +
On 5/23/23 18:15, Melissa Wen wrote:
> Wire up DC 3D LUT to DM CRTC color management (post-blending). On AMD
> display HW, we have to set a shaper LUT to delinearize or normalize the
> color space before applying a 3D LUT (since we have a reduced number of
> LUT entries). Therefore, we map DC sh
On 5/23/23 18:14, Melissa Wen wrote:
> From: Joshua Ashton
>
> Multiplier to 'gain' the plane. When PQ is decoded using the fixed func
> transfer function to the internal FP16 fb, 1.0 -> 80 nits (on AMD at
> least) When sRGB is decoded, 1.0 -> 1.0. Therefore, 1.0 multiplier = 80
> nits for SD
On 5/23/23 18:14, Melissa Wen wrote:
> Create and attach driver-private properties for plane color management.
> First add plane degamma LUT properties that means user-blob and its
> size. We will add more plane color properties in the next commits. In
> addition, we keep these driver-private pl
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
> and attach them according to HW capabilities defined by `struct
> dc_color_caps`. Add enumerated transfer function pro
From: Joshua Ashton
Replace the messy two if-else chains here that were
on the same value with a switch on the enum.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: Simon Ser
Cc: Melissa Wen
We want compositors to be able to set the output
colorspace on DP and HDMI outputs, based on the
caps reported from the receiver via EDID.
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
print
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: Simon Ser
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 57 +++
1
ult case to avoid warnings for unhandled
enum values
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: Simon Ser
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
.../gpu/drm/amd
nction doc
Signed-off-by: Harry 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: Simon Ser
Cc: Ville Syrjälä
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freed
We need to signal mode_changed to make sure we update the output
colorspace.
v2: No need to call drm_hdmi_avi_infoframe_colorimetry as DC does its
own infoframe packing.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc
indicate support for all colorspaces (Jani)
- Print drm_dbg_kms message when drivers pass 0
to signal that drivers should specify supported
colorspaecs explicity (Jani)
v3:
- Move changes to create a common colorspace_names array
to separate patch
Signed-off-by: Harry Wentland
Cc: Pekka
We need the connector_state for colorspace and scaling information
and can get it from connector->state.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: Simon Ser
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc:
From: Joshua Ashton
Given that we always pass dm_state into here now, this won't ever
trigger anymore.
This is needed for we will always fail mode validation with invalid
clocks or link bandwidth errors.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka Paalane
Signed-off-by: Harry 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: Simon Ser
Cc: Ville Syrjälä
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
v3: Fix kerneldocs (kernel test robot)
v4: Avoid returning NULL from drm_get_colorspace_name
Signed-off-by: Harry 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: Simon Ser
Cc: Ville Syrjälä
that might create
more questions than answers
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Reviewed-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Simon Ser
Cc: Ville Syrjälä
Cc: Melis
This allows us to use strongly typed arguments.
v2:
- Bring NO_DATA back
- Provide explicit enum values
v3:
- Drop unnecessary '&' from kerneldoc (emersion)
v4:
- Fix Normal Colorimetry comment
Signed-off-by: Harry Wentland
Reviewed-by: Simon Ser
Cc: Pekka Paalanen
Cc: Seba
ikula
Cc: Michel Dänzer
Cc: Simon Ser
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Harry Wentland (10):
drm/connector: Convert DRM_MODE_COLORIMETRY to enum
drm/connector: Pull out common create_colorspace_property code
drm/connector: Use co
On 5/24/23 04:24, Pekka Paalanen wrote:
> On Tue, 23 May 2023 21:14:50 -0100
> Melissa Wen wrote:
>
>> Hook up driver-specific atomic operations for managing AMD color
>> properties and create AMD driver-specific color management properties
>> and attach them according to HW capabilities defin
gh the cracks. Among them, there are
>>> unused variable and indentation issues. Also, we should consider all
>>> warnings to be compile errors, since the community will eventually end
>>> up complaining about them. So, enable -Werror, -Wunused and
>>> -Wmisleading-in
gt;>>>>>> On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
>>>>>>>> On Thu, 16 Mar 2023 12:47:51 +0200
>>>>>>>> Ville Syrjälä wrote:
>>>>>>>>
>>>>>>>>> On Thu, Mar 16, 202
On 3/8/23 04:24, Pekka Paalanen wrote:
> On Tue, 7 Mar 2023 10:10:59 -0500
> Harry Wentland wrote:
>
>> We want compositors to be able to set the output
>> colorspace on DP and HDMI outputs, based on the
>> caps reported from the receiver via EDID.
>>
>&g
On 3/8/23 04:09, Pekka Paalanen wrote:
> On Tue, 7 Mar 2023 10:10:53 -0500
> Harry Wentland wrote:
>
>> From: Joshua Ashton
>>
>> Userspace has no way of controlling or knowing the pixel encoding
>> currently, so there is no way for it to ever get the right
On 3/8/23 03:59, Pekka Paalanen wrote:
> On Tue, 7 Mar 2023 10:10:52 -0500
> Harry Wentland wrote:
>
>> From: Joshua Ashton
>>
>> To match the other enums, and add more information about these values.
>>
>> v2:
>> - Specify where an enum entry
ll that into there.
>
Ah, that's good. No problem then.
Harry
> On Tue, 9 May 2023 at 20:00, Harry Wentland wrote:
>>
>> On 5/9/23 12:54, Joshua Ashton wrote:
>>> We currently do not have a use for this as we settled on per-plane 3D
>>> LUT + Shaper, but we mi
issa Wen wrote:
>>
>> On 05/08, Harry Wentland wrote:
>>>
>>>
>>> On 4/23/23 10:10, Melissa Wen wrote:
>>>> From: Joshua Ashton
>>>>
>>>> Multiplier to 'gain' the plane. When PQ is decoded using the fixed func
&
On 5/9/23 12:52, Melissa Wen wrote:
> On 05/08, Harry Wentland wrote:
>>
>>
>> On 4/23/23 10:10, Melissa Wen wrote:
>>> Hi all,
>>>
>>> Joshua Ashton and I (with the great collaboration of Harry Wentland -
>>> thanks) have been wor
On 5/9/23 12:23, Melissa Wen wrote:
> On 05/08, Harry Wentland wrote:
>> On 4/23/23 10:10, Melissa Wen wrote:
>>> We are enabling a large set of color calibration features to enhance KMS
>>> color mgmt but these properties are specific of AMD display HW, and
>
r you?
Harry
> On Tue, 9 May 2023 at 16:26, Melissa Wen wrote:
>>
>> On 05/08, Harry Wentland wrote:
>>> On 4/23/23 10:10, Melissa Wen wrote:
>>>> We are enabling a large set of color calibration features to enhance KMS
>>>> color mgmt but these p
On 5/7/23 19:14, Dave Airlie wrote:
> On Sat, 6 May 2023 at 08:21, Sebastian Wick wrote:
>>
>> 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
On 4/23/23 10:10, Melissa Wen wrote:
> From: Joshua Ashton
>
> Multiplier to 'gain' the plane. When PQ is decoded using the fixed func
> transfer function to the internal FP16 fb, 1.0 -> 80 nits (on AMD at
> least) When sRGB is decoded, 1.0 -> 1.0. Therefore, 1.0 multiplier = 80
> nits for SD
On 4/23/23 10:10, Melissa Wen wrote:
> From amdgpu_dm_plane we can get it for both CRTC and plane color
> properties. We are adding new plane properties for AMD driver-private
> color mgmt.
>
> Signed-off-by: Melissa Wen
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 37 +
On 4/23/23 10:10, Melissa Wen wrote:
> From: Joshua Ashton
>
> Add predefined transfer function property to DRM CRTC gamma to convert
> to wire encoding with or without gamma LUT.
>
Are all these new CRTC properties used by gamescope? I would be reluctant
to merge them if they're currently n
On 4/23/23 10:10, Melissa Wen wrote:
> CRTC shaper LUT shapes the content after blending, i.e., de-linearizes
> or normalizes space before applying a 3D LUT color correction. In the
> next patch, we add CRTC 3D LUT property to DRM color management after
> this shaper LUT and before the current C
On 4/23/23 10:10, Melissa Wen wrote:
> Hi all,
>
> Joshua Ashton and I (with the great collaboration of Harry Wentland -
> thanks) have been working on KMS color pipeline enhancement for Steam
> Deck/SteamOS by exposing the large set of color caps available in AMD
> display
On 4/23/23 10:10, Melissa Wen wrote:
> We are enabling a large set of color calibration features to enhance KMS
> color mgmt but these properties are specific of AMD display HW, and
> cannot be provided by other vendors. Therefore, set a config option to
> enable AMD driver-private properties used
On 5/8/23 05:18, Daniel Vetter wrote:
> On Mon, 8 May 2023 at 10:58, Simon Ser wrote:
>>
>> On Friday, May 5th, 2023 at 21:53, Daniel Vetter wrote:
>>
>>> On Fri, May 05, 2023 at 04:06:26PM +, Simon Ser wrote:
On Friday, May 5th, 2023 at 17:28, Daniel Vetter wrote:
> Ok no c
On 5/5/23 09:35, Daniel Vetter wrote:
> On Fri, May 05, 2023 at 09:20:26AM -0400, Harry Wentland wrote:
>>
>>
>> On 5/5/23 06:16, Daniel Vetter wrote:
>>> On Fri, May 05, 2023 at 11:43:20AM +0300, Pekka Paalanen wrote:
>>>> On Thu, 4 May 2023
On 5/5/23 06:16, Daniel Vetter wrote:
> On Fri, May 05, 2023 at 11:43:20AM +0300, Pekka Paalanen wrote:
>> On Thu, 4 May 2023 17:25:57 -0400
>> Harry Wentland wrote:
>>
>>> We have steered away for a long time now from driver-specific KMS APIs
>>> for goo
order to move complex topics along.
[1] https://patchwork.freedesktop.org/series/116862/
Signed-off-by: Harry Wentland
Cc: Simon Ser
Cc: Joshua Ashton
Cc: Michel Dänzer
Cc: Sebastian Wick
Cc: Jonas Ådahl
Cc: Alex Goins
Cc: Pekka Paalanen
Cc: Melissa Wen
Cc: Aleix Pol
Cc: Xaver Hugl
Cc
On 5/4/23 11:22, 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 before it's blended with other planes. With this new uAPI we
aim to reduce the battery lif
On 4/11/23 20:09, Rodrigo Siqueira wrote:
> This commit adds missing luminance control registers to enable a more
> standard way (VESA) to deal with eDP luminance control.
>
> Cc: Anthony Koo
> Cc: Iswara Negulendran
> Cc: Felipe Clark
> Cc: Harry Wentland
> Signed-
On 3/22/23 12:05, Rodrigo Siqueira wrote:
> Cc: Anthony Koo
> Cc: Iswara Negulendran
> Cc: Felipe Clark
> Cc: Harry Wentland
> Signed-off-by: Rodrigo Siqueira
Reviewed-by: Harry Wentland
Harry
> ---
> include/drm/display/drm_dp.h | 2 ++
> 1 file changed, 2
On 3/10/23 12:51, Ville Syrjälä wrote:
> On Fri, Mar 10, 2023 at 07:48:04PM +0200, Ville Syrjälä wrote:
>> On Thu, Mar 09, 2023 at 04:30:27PM -0500, Hamza Mahfooz wrote:
>>> We should be checking if drm_dp_dpcd_read() returns the size that we are
>>> asking it to read instead of just checking if
gned-off-by: Hamza Mahfooz
I don't think we can ever hit a case where the return value is greater
than 0 but not equal to size as drm_dp_dpcd_access already checks for it.
Either way, the stricter check makes sense and is
Reviewed-by: Harry Wentland
Harry
> ---
> v2: drop the WARN_O
re/dc_stat.c:38: warning:
>>> Cannot understand
>>> *
>>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stat.c:76: warning:
>>> Cannot understand
>>> ***
This allows us to use strongly typed arguments.
v2:
- Bring NO_DATA back
- Provide explicit enum values
v4: Drop unnecessary '&' from kerneldoc (emersion)
Signed-off-by: Harry Wentland
Reviewed-by: Simon Ser
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
C
From: Joshua Ashton
Replace the messy two if-else chains here that were
on the same value with a switch on the enum.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-devel
In order to IGT test colorspace we'll want to print
the currently enabled colorspace on a stream. We add
a new debugfs to do so, using the same scheme as
current bpc reporting.
This might also come in handy when debugging display
issues.
Signed-off-by: Harry Wentland
Cc: Pekka Paalane
We use this by default but if userspace passes this explicitly
we should respect it.
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
From: Joshua Ashton
Userspace might not aware whether we're sending RGB or YCbCr
data to the display. If COLOR_SPACE_2020_RGB_FULLRANGE is
requested but the output encoding is YCbCr we should
send COLOR_SPACE_2020_YCBCR.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc:
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
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 43 ++-
1 file
We want compositors to be able to set the output
colorspace on DP and HDMI outputs, based on the
caps reported from the receiver via EDID.
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
We need the connector_state for colorspace and scaling information
and can get it from connector->state.
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.
We an use bitfields to track the support ones for HDMI
and DP. This allows us to print colorspaces in a consistent
manner without needing to know whether we're dealing with
DP or HDMI.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc
From: Joshua Ashton
Given that we always pass dm_state into here now, this won't ever
trigger anymore.
This is needed for we will always fail mode validation with invalid
clocks or link bandwidth errors.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka Paalane
Look at connector->colorimetry to determine output colorspace.
We don't want to impact current SDR behavior, so
DRM_MODE_COLORIMETRY_DEFAULT preserves current behavior.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
We need to signal mode_changed to make sure we update the output
colorspace.
v2: No need to call drm_hdmi_avi_infoframe_colorimetry as DC does its
own infoframe packing.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc
-by: Harry Wentland
Reviewed-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
include/drm/drm_connec
v3: Fix kerneldocs (kernel test robot)
Signed-off-by: Harry 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.freedesktop.org
Reviewed-By
indicate support for all colorspaces (Jani)
- Print drm_dbg_kms message when drivers pass 0
to signal that drivers should specify supported
colorspaecs explicity (Jani)
v3:
- Move changes to create a common colorspace_names array
to separate patch
Signed-off-by: Harry Wentland
Cc: Pekka
zer
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Harry Wentland (12):
drm/connector: Convert DRM_MODE_COLORIMETRY to enum
drm/connector: Pull out common create_colorspace_property code
drm/connector: Use common colorspace_names array
drm/connector: Print con
+ the colorspace.
Let's deprecate these values, and have one BT.2020 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-by: Harry Wen
Signed-off-by: Harry 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.freedesktop.org
Reviewed-By: Joshua Ashton
---
drivers/gpu/drm
This allows us to use strongly typed arguments.
v2:
- Bring NO_DATA back
- Provide explicit enum values
Signed-off-by: Harry Wentland
Reviewed-by: Simon Ser
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri
On 3/2/23 11:37, Harry Wentland wrote:
>
>
> On 3/1/23 15:21, Deepak R Varma wrote:
>> On Mon, Jan 23, 2023 at 12:23:19AM +0530, Deepak R Varma wrote:
>>> On Sun, Jan 15, 2023 at 12:52:10PM -0800, Joe Perches wrote:
>>>> On Sun, 2023-01-15 at 15:30 +0530
On 3/1/23 15:21, Deepak R Varma wrote:
> On Mon, Jan 23, 2023 at 12:23:19AM +0530, Deepak R Varma wrote:
>> On Sun, Jan 15, 2023 at 12:52:10PM -0800, Joe Perches wrote:
>>> On Sun, 2023-01-15 at 15:30 +0530, Deepak R Varma wrote:
The if / else block code has same effect irrespective of the
On 2/27/23 12:12, Jani Nikula wrote:
> On Mon, 27 Feb 2023, Harry Wentland wrote:
>> On 2/26/23 09:10, Yaroslav Bolyukin wrote:
>>> As per DisplayID v2.0 Errata E9 spec "DSC pass-through timing support"
>>> VESA vendor-specific data block may contain
On 2/26/23 09:10, Yaroslav Bolyukin wrote:
> VESA vendor header from DisplayID spec may contain fixed bit per pixel
> rate, it should be respected by drm driver
>
This will apply the fixed bpp for all modes. I don't think that's right.
It should apply only to VII timings.
Harry
> Signed-off-by:
On 2/26/23 09:10, Yaroslav Bolyukin wrote:
> As per DisplayID v2.0 Errata E9 spec "DSC pass-through timing support"
> VESA vendor-specific data block may contain target DSC bits per pixel
> fields
>
According to the errata this should only apply to VII timings. The way
it is currently implemen
On 2/8/23 03:56, Pekka Paalanen wrote:
> On Fri, 3 Feb 2023 02:07:43 +
> Joshua Ashton wrote:
>
>> To match the other enums, and add more information about these values.
>>
>> Signed-off-by: Joshua Ashton
>>
>> Cc: Pekka Paalanen
>> Cc: Sebastian Wick
>> Cc: vitaly.pros...@amd.com
>> C
ed-by: Harry Wentland
Harry
---
drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
On 2/15/23 06:46, Daniel Stone wrote:
> Hi,
>
> On Tue, 14 Feb 2023 at 16:57, Harry Wentland wrote:
>> On 2/14/23 10:49, Sebastian Wick wrote:
>> From what I've seen recently I am inclined to favor an incremental
>> approach more. The reason is that any API, o
On 2/15/23 04:40, Pekka Paalanen wrote:
> On Tue, 14 Feb 2023 15:04:52 -0500
> Harry Wentland wrote:
>
>> On 2/14/23 14:45, Sebastian Wick wrote:
>>> On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland
>>> wrote:
>>>>
>>>>
>>>&g
On 2/14/23 14:45, Sebastian Wick wrote:
On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland wrote:
On 2/14/23 10:49, Sebastian Wick wrote:
On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä
wrote:
On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
On 2/3/23 10:19, Ville Syrjälä
ly be consulted for simple
"cursor like" use cases.
v2: Try to add some docs
Cc: Simon Ser
Cc: Jonas Ådahl
Cc: Daniel Stone
Cc: Pekka Paalanen
Acked-by: Harry Wentland
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_mode_config.c | 7 +
drivers/gpu/drm/drm_pla
On 2/14/23 10:49, Sebastian Wick wrote:
> On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä
> wrote:
>>
>> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
>>>
>>>
>>> On 2/3/23 10:19, Ville Syrjälä wrote:
>>>> On Fr
On 2/10/23 04:28, Pekka Paalanen wrote:
> On Thu, 9 Feb 2023 13:27:02 -0100
> Melissa Wen wrote:
>
>> On 01/31, Pekka Paalanen wrote:
>>> On Mon, 9 Jan 2023 14:38:09 -0100
>>> Melissa Wen wrote:
>>>
On 01/09, Melissa Wen wrote:
> Hi,
>
> After collecting comments in diff
On 2/10/23 05:00, Deepak R Varma wrote:
> Remove duplicate or repeating expressions in the if condition
> evaluation. Issue identified using doubletest.cocci Coccinelle semantic
> patch.
>
> Signed-off-by: Deepak R Varma
Reviewed-by: Harry Wentland
Harry
> ---
> .../g
On 2/10/23 05:11, Deepak R Varma wrote:
> Remove duplicate or repeating expressions in the if condition
> evaluation. Issue identified using doubletest.cocci Coccinelle semantic
> patch.
>
> Signed-off-by: Deepak R Varma
Reviewed-by: Harry Wentland
Harry
> ---
> .../g
).
>
> Fixes: 589d2739332d ("drm/amd/display: Use crtc enable/disable_vblank hooks")
> Fixes: d2574c33bb71 ("drm/amd/display: In VRR mode, do DRM core vblank
> handling at end of vblank. (v2)")
> Signed-off-by: Hamza Mahfooz
Reviewed-by: Harry Wentland
Harry
&
thorough look at the details of this
implementation but like what it does, so this is
Acked-by: Harry Wentland
Harry
---
drivers/gpu/drm/drm_mode_config.c | 7 +++
drivers/gpu/drm/drm_plane.c | 33 +++
include/drm/drm_mode_config.h | 5 +
inc
:55PM +0200, Ville Syrjälä wrote:
>>>>> On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
>>>>>>
>>>>>>
>>>>>> On 2/3/23 11:00, Ville Syrjälä wrote:
>>>>>>> On Fri, Feb 03, 2023 at 10:24:52AM -0500,
On 2/3/23 14:34, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 09:25:38PM +0200, Ville Syrjälä wrote:
>> On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote:
>>> On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
>>>>
>>>>
On 2/3/23 14:25, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote:
>> On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
>>>
>>>
>>> On 2/3/23 11:00, Ville Syrjälä wrote:
>>>> On Fri, Feb 03
On 2/3/23 13:56, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
>>
>>
>> On 2/3/23 11:00, Ville Syrjälä wrote:
>>> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
>>>>
>>>>
>>&
On 2/3/23 11:00, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
>>
>>
>> On 2/3/23 10:19, Ville Syrjälä wrote:
>>> On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote:
>>>>
>>>>
>>&
On 2/3/23 10:19, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote:
>>
>>
>> On 2/3/23 07:59, Sebastian Wick wrote:
>>> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä
>>> wrote:
>>>>
>>>>
On 2/2/23 21:07, Joshua Ashton wrote:
> Userspace has no way of controlling or knowing the pixel encoding
> currently, so there is no way for it to ever get the right values here.
>
> When we do add pixel_encoding control from userspace,we can pick the
> right value for the colorimetry packet b
On 2/3/23 07:59, Sebastian Wick wrote:
> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä
> wrote:
>>
>> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote:
>>> Userspace has no way of controlling or knowing the pixel encoding
>>> currently, so there is no way for it to ever get the rig
301 - 400 of 1016 matches
Mail list logo
