ted over to
> atomic (like i915).
>
> Reported-by: Pekka Paalanen
> Cc: Pekka Paalanen
> Cc: stable at vger.kernel.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_plane_helper.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drive
On Thu, 16 Jun 2016 10:40:51 -0400
Rob Clark wrote:
> So, if we wanted to extend this to support the fourcc-modifiers that
> we have on the kernel side for compressed/tiled/etc formats, what
> would be the right approach?
>
> A new version of the existing extension or a new
> EGL_EXT_image_dma_b
On Fri, 17 Jun 2016 08:26:04 -0400
Rob Clark wrote:
> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen
> wrote:
> > On Thu, 16 Jun 2016 10:40:51 -0400
> > Rob Clark wrote:
> >
> >> So, if we wanted to extend this to support the fourcc-modifiers that
&g
On Fri, 17 Jun 2016 11:44:34 -0400
Rob Clark wrote:
> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen
> wrote:
> > On Fri, 17 Jun 2016 08:26:04 -0400
> > Rob Clark wrote:
> >
> >> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen
> >> wrote:
On Fri, 17 Jun 2016 11:44:34 -0400
Rob Clark wrote:
> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen
> wrote:
> > On Fri, 17 Jun 2016 08:26:04 -0400
> > Rob Clark wrote:
> >
> >> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen
> >> wrote:
On Mon, 20 Jun 2016 09:45:26 -0400
Rob Clark wrote:
> On Mon, Jun 20, 2016 at 8:37 AM, Pekka Paalanen
> wrote:
> > On Fri, 17 Jun 2016 11:44:34 -0400
> > Rob Clark wrote:
> >
> >> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen
> >> wrote:
On Thu, 06 Nov 2014 16:08:56 +0900
Michel Dänzer wrote:
> On 06.11.2014 03:06, Frederic Plourde wrote:
> > Many features, like animations, hardly depend on page flip timestamps
> > to work properly, but some DRM drivers do not correctly support page flip
> > timestamps (or not at all) and in tha
On Fri, 07 Nov 2014 07:04:16 +0100
Mario Kleiner wrote:
> On 06/11/14 17:42, Pekka Paalanen wrote:
> > On Thu, 06 Nov 2014 16:08:56 +0900
> > Michel Dänzer wrote:
> >
> >> On 06.11.2014 03:06, Frederic Plourde wrote:
> >>> Many features, like animati
On Fri, 21 Aug 2015 13:54:49 +0900
Hyungwon Hwang wrote:
> Hi Emil,
>
> On Thu, 20 Aug 2015 17:17:27 +0100
> Emil Velikov wrote:
>
> > Hi Hyungwon,
> >
> > On 19 August 2015 at 01:58, Hyungwon Hwang
> > wrote:
> > > This patch seprates the code, which sorts proprty sets and
> > > eliminates
On Fri, 21 Aug 2015 15:06:58 +0900
Hyungwon Hwang wrote:
> Hi Emil,
>
> On Thu, 20 Aug 2015 17:23:09 +0100
> Emil Velikov wrote:
>
> > On 19 August 2015 at 01:58, Hyungwon Hwang
> > wrote:
> > > This patch makes 'struct _drmModeAtomicReqItem' and 'struct
> > > _drmModeAtomicReq' visible from
On Fri, 21 Aug 2015 16:18:59 +0900
Hyungwon Hwang wrote:
> Hi Pekka,
>
> On Fri, 21 Aug 2015 09:42:26 +0300
> Pekka Paalanen wrote:
>
> > On Fri, 21 Aug 2015 13:54:49 +0900
> > Hyungwon Hwang wrote:
> >
> > > Hi Emil,
> > >
> > >
Hi,
I have a somewhat of my own view on what would be involved with VRR,
and I'd like to hear what you think of it. Comments inline.
On Tue, 25 Sep 2018 09:51:37 -0400
"Kazlauskas, Nicholas" wrote:
> On 09/24/2018 04:26 PM, Ville Syrjälä wrote:
> > On Mon, Sep 24, 2018 at 03:06:02PM -0400, Kaz
On Fri, 5 Oct 2018 12:21:20 -0400
"Kazlauskas, Nicholas" wrote:
> On 10/05/2018 04:10 AM, Pekka Paalanen wrote:
> > Hi,
> >
> > I have a somewhat of my own view on what would be involved with VRR,
> > and I'd like to hear what you think of it. Comments
On Wed, 10 Oct 2018 09:35:50 -0400
"Kazlauskas, Nicholas" wrote:
> The patches I've put out target this use case mostly because of the
> benefit for a relatively simple interface. VRR can and has been used in
> more ways that this, however.
>
> An example usecase that differs from this would a
On Fri, 12 Oct 2018 07:35:57 +
"Koenig, Christian" wrote:
> Am 12.10.2018 um 09:23 schrieb Pekka Paalanen:
> > On Wed, 10 Oct 2018 09:35:50 -0400
> > "Kazlauskas, Nicholas" wrote:
> >
> >> The patches I've put out target this use c
On Fri, 12 Oct 2018 08:58:23 -0400
"Kazlauskas, Nicholas" wrote:
> On 10/12/2018 07:20 AM, Koenig, Christian wrote:
> > Am 12.10.2018 um 11:21 schrieb Pekka Paalanen:
> >> On Fri, 12 Oct 2018 07:35:57 +
> >> "Koenig, Christian" wrote:
&g
On Mon, 15 Oct 2018 12:02:14 -0400
"Kazlauskas, Nicholas" wrote:
> On 10/15/2018 09:57 AM, Pekka Paalanen wrote:
> > On Fri, 12 Oct 2018 08:58:23 -0400
> > "Kazlauskas, Nicholas" wrote:
> >
> >> On 10/12/2018 07:20 AM, Koenig, Christian w
On Thu, 11 Oct 2018 12:39:41 -0400
Nicholas Kazlauskas wrote:
> These include the drm_connector 'vrr_capable' and the drm_crtc
> 'vrr_enabled' properties.
>
> Signed-off-by: Nicholas Kazlauskas
> ---
> Documentation/gpu/drm-kms.rst | 7 +++
> drivers/gpu/drm/drm_connector.c | 22 +++
On Mon, 15 Oct 2018 12:06:52 +0200
Michel Dänzer wrote:
> On 2018-10-15 11:47 a.m., Christian König wrote:
> > Am 15.10.2018 um 11:40 schrieb Michel Dänzer:
> >> On 2018-10-13 7:38 p.m., Christian König wrote:
> >>> Am 12.10.2018 um 18:44 schrieb Nicholas Kazlauskas:
> This patch intro
On Fri, 26 Oct 2018 17:34:15 +
"Kazlauskas, Nicholas" wrote:
> On 10/26/18 10:53 AM, Ville Syrjälä wrote:
> > On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote:
> >> On 10/26/18 7:37 AM, Pekka Paalanen wrote:
> >>> Hi,
>
On Wed, 31 Oct 2018 17:54:34 +
"Kazlauskas, Nicholas" wrote:
> On 10/31/18 12:20 PM, Michel Dänzer wrote:
> > On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote:
> >> On 10/31/18 10:12 AM, Michel Dänzer wrote:
> >>> On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote:
> On 10/30/1
On Wed, 21 Mar 2018 12:08:25 +0200
Peter Ujfalusi wrote:
> Hi,
>
> Changes since v1:
> - rebased it on drm-next
> - Dropped the devm_kzalloc conversion patch
>
> Changes since RFC:
> - Comments from Laurent have been addressed:
> - Get alias ID once and store it for later use in sorting
> - C
gt; >> 'vrr_enabled' properties.
> >>
> >> Signed-off-by: Nicholas Kazlauskas
> >> Cc: Harry Wentland
> >> Cc: Manasi Navare
> >> Cc: Pekka Paalanen
> >> Cc: Ville Syrjälä
> >> Cc: Michel Dänzer
> >> ---
On Thu, 6 Sep 2018 21:36:51 +
Deepak Singh Rawat wrote:
> >
> > - Why no input validation on the damage clips against the framebuffer
> > size? Ime not validating just leads to funny driver bugs down the road,
> > so what's the use-case you have in mind here?
>
> My motivation behind
On Sat, 23 Jun 2018 12:13:53 -0500
Jason Ekstrand wrote:
> I haven't thought through this comment all that hard but would it make
> sense to have three timestamps, CPU, GPU, CPU so that you have error bars
> on the GPU timestamp? At the very least, two timestamps would be better
> than one so
On Tue, 10 Jul 2018 11:02:23 -0700
"Keith Packard" wrote:
> Pekka Paalanen writes:
>
> > On Sat, 23 Jun 2018 12:13:53 -0500
> > Jason Ekstrand wrote:
> >
> >> I haven't thought through this comment all that hard but would it make
> >&
per huge thanks! Looks pretty much like kmscube is what
> > I've been looking for :)
> >
> > Thanks again!
> >
> >
> > On Mon, Dec 9, 2013 at 2:46 PM, Pekka Paalanen
> > wrote:
> >
> >> On Mon, 9 Dec 2013 14:15:16 +0300
> >> Artsiom Anikeyenk
+ * Extra care should be taken when doing software conversion with
> + * DRM_CAP_DUMB_PREFER_SHADOW, there are more detailed explanations here:
> + * https://lore.kernel.org/dri-devel/20230818162415.2185f8e3@eldfell/
> */
Acked-by: Pekka Paalanen
Thanks,
pq
pgpvAcp793rZI.pgp
Description: OpenPGP digital signature
On Fri, 25 Aug 2023 13:29:44 -0100
Melissa Wen wrote:
> On 08/22, Pekka Paalanen wrote:
> > On Thu, 10 Aug 2023 15:02:59 -0100
> > Melissa Wen wrote:
> >
> > > The next patch adds pre-blending degamma to AMD color mgmt pipeline, but
> > > pre-blending
On Fri, 25 Aug 2023 13:37:08 -0100
Melissa Wen wrote:
> On 08/22, Pekka Paalanen wrote:
> > On Thu, 10 Aug 2023 15:03:11 -0100
> > Melissa Wen wrote:
> >
> > > dc->caps.color.mpc.gamut_remap says there is a post-blending color block
> > > for gamut
?
Does anyone know of any doc about that?
If drivers do not agree on the behaviour of a KMS property, then that
property is useless for generic userspace.
Thanks,
pq
> On Tuesday, 22 August 2023, Pekka Paalanen
> wrote:
> > On Thu, 10 Aug 2023 15:02:59 -0100
> > Meliss
roperty 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,
pq
pgpB1mG5llUZQ.pgp
Description: OpenPGP digital signature
On Mon, 28 Aug 2023 17:05:08 -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" plan
gt; BIT(DRM_PLANE_PIXEL_SOURCE_SOLID_FILL);
> int i;
>
> /* FB is supported by default */
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index a38e18bfb43e..49995c4be2ab 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
On Mon, 28 Aug 2023 17:05:11 -0700
Jessica Zhang wrote:
> Add solid_fill property data to the atomic plane state dump.
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/drm_atomic.c | 4
> drivers/gpu/drm/drm_plane.c | 8
> include/drm/drm_plane.h | 3 +++
> 3 files
On Mon, 28 Aug 2023 17:05:13 -0700
Jessica Zhang wrote:
> Loosen the requirements for atomic and legacy commit so that, in cases
> where pixel_source != FB, the commit can still go through.
>
> This includes adding framebuffer NULL checks in other areas to account for
> FB being NULL when non-FB
On Mon, 28 Aug 2023 12:56:04 -0100
Melissa Wen wrote:
> On 08/28, Pekka Paalanen wrote:
> > On Mon, 28 Aug 2023 09:45:44 +0100
> > Joshua Ashton wrote:
> >
> > > Degamma has always been on the plane on AMD. CRTC DEGAMMA_LUT has actually
> > > just be
On Wed, 30 Aug 2023 08:59:36 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Harry Wentland
> > Sent: Wednesday, August 30, 2023 1:10 AM
> > To: Shankar, Uma ; intel-...@lists.freedesktop.org;
> > dri-
> > de...@lists.freedesktop.org
> > Cc: Borah, Chaitanya Kumar ; wayland
On Tue, 29 Aug 2023 21:33:51 +0530
Uma Shankar wrote:
> From: Chaitanya Kumar Borah
>
> Each Color Hardware block will be represented uniquely
> in the color pipeline. Define the structure to represent
> the same.
>
> These color operations will form the building blocks of
> a color pipeline w
On Mon, 4 Sep 2023 13:44:49 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: dri-devel On Behalf Of Pekka
> > Paalanen
> > Sent: Wednesday, August 30, 2023 5:59 PM
> > To: Shankar, Uma
> > Cc: intel-...@lists.freedeskt
On Mon, 4 Sep 2023 14:10:05 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: dri-devel On Behalf Of Pekka
> > Paalanen
> > Sent: Wednesday, August 30, 2023 6:30 PM
> > To: Shankar, Uma
> > Cc: intel-...@lists.freedeskt
i-devel@lists.freedesktop.org; wayland-
> > de...@lists.freedesktop.org; Ville Syrjala ;
> > Pekka
> > Paalanen ; Simon Ser ;
> > Melissa Wen ; Jonas Ådahl ; Shashank
> > Sharma ; Alexander Goins ;
> > Naseer Ahmed ; Christopher Braga
> >
> > Subject: Re
On Wed, 6 Sep 2023 16:15:10 -0400
Harry Wentland wrote:
> On 2023-08-25 10:18, Melissa Wen wrote:
> > On 08/22, Pekka Paalanen wrote:
> >> On Thu, 10 Aug 2023 15:02:47 -0100
> >> Melissa Wen wrote:
> >>
> >>> Instead of relying o
On Wed, 6 Sep 2023 15:30:04 -0400
Harry Wentland wrote:
> On 2023-08-10 12:02, Melissa Wen wrote:
> > Add 3D LUT property for plane gamma correction using a 3D lookup table.
> > Since a 3D LUT has a limited number of entries in each dimension we want
> > to use them in an optimal fashion. This me
On Thu, 7 Sep 2023 10:10:50 -0400
Harry Wentland wrote:
> On 2023-09-07 03:49, Pekka Paalanen wrote:
> > On Wed, 6 Sep 2023 16:15:10 -0400
> > Harry Wentland wrote:
> >
> >> On 2023-08-25 10:18, Melissa Wen wrote:
> >>> On 08/22, Pekka Paalanen w
On Thu, 7 Sep 2023 12:31:47 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Pekka Paalanen
> > Sent: Tuesday, September 5, 2023 5:03 PM
> > To: Shankar, Uma
> > Cc: intel-...@lists.freedesktop.org; Borah, Chaitanya Kumar
> &
On Fri, 8 Sep 2023 11:21:51 +0200
Thomas Zimmermann wrote:
> Hi
>
> Am 25.08.23 um 16:04 schrieb Jocelyn Falempe:
> [...]
> > + *
> > + * But there are two exceptions only for dumb buffers:
> > + * * To support XRGB if it's not supported by the hardware.
>
>
> > + * * Any dri
On Fri, 8 Sep 2023 15:56:51 +0200
Thomas Zimmermann wrote:
> Hi
>
> Am 08.09.23 um 13:16 schrieb Pekka Paalanen:
> > On Fri, 8 Sep 2023 11:21:51 +0200
> > Thomas Zimmermann wrote:
> >
> >> Hi
> >>
> >> Am 25.08.23 um 16:04 schrieb Joc
On Fri, 8 Sep 2023 17:10:46 +0200
Thomas Zimmermann wrote:
> Hi
>
> Am 08.09.23 um 16:41 schrieb Pekka Paalanen:
> > On Fri, 8 Sep 2023 15:56:51 +0200
> > Thomas Zimmermann wrote:
> >
> >> Hi
> >>
> >> Am 08.09.23 um 13:16 schrieb Pek
On Fri, 8 Sep 2023 11:02:26 -0400
Harry Wentland wrote:
> 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: Alexan
gt;
> > On Fri, Sep 08, 2023 at 11:02:26AM -0400, Harry Wentland wrote:
> >> Signed-off-by: Harry Wentland
> >> Cc: Ville Syrjala
> >> Cc: Pekka Paalanen
> >> Cc: Simon Ser
> >> Cc: Harry Wentland
> >> Cc: Melissa Wen
> >> Cc
On Mon, 4 Mar 2024 18:45:08 +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
> control over the output format to figure out which variants can be used
> for a given KMS commit.
riants:
> - *
> - * Since userspace is not aware of the encoding on the wire
> - * (RGB or YCbCr), drivers are free to pick the appropriate
> - * variant, regardless of what userspace selects. E.g., if
> - * BT2020_RGB is selected by userspace a driver will pick
> - * BT2020_
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 wrote:
> >
> > > The initial idea of the Colorspace prop was that this maps 1:1 t
On Wed, 6 Mar 2024 18:29:53 +0100
Louis Chauvet wrote:
> [...]
>
> > > > > > > +++ b/drivers/gpu/drm/vkms/vkms_formats.c
> > > > > > > @@ -9,6 +9,17 @@
> > > > > > >
> > > > > > > #include "vkms_formats.h"
> > > > > > >
> > > > > > > +/**
> > > > > > > + * packed_pixels_offset() - Get the o
On Thu, 7 Mar 2024 14:02:33 +0530
Nemesa Garg wrote:
> This allows the user to set the intensity
> so as to get the sharpness effect.
>
> It is useful in scenario when the output is blurry
> and user want to sharpen the pixels.
>
> Signed-off-by: Nemesa Garg
> ---
> drivers/gpu/drm/drm_atomi
pretty much a de-facto standard now and we can provide helpers for it.
> >
> > Let's plumb it into the newly created HDMI connector.
> >
> > Reviewed-by: Dave Stevenson
> > Acked-by: Pekka Paalanen
> > Reviewed-by: Sebastian Wick
> > Sig
On Mon, 26 Feb 2024 16:10:17 -0500
Harry Wentland wrote:
> A value of 0x8000 and higher should round up, and
> below should round down. VKMS Kunit tests for lerp_u16
> showed that this is not the case. Fix it.
>
> 1 << (DRM_FIXED_POINT_HALF - 1) =
> 1 << 15 = 0x8000
>
> This is not 0.5, but
On Mon, 26 Feb 2024 16:10:20 -0500
Harry Wentland wrote:
> Debugging LUT math is much easier when we can unit test
> it. Add kunit functionality to VKMS and add tests for
> - get_lut_index
> - lerp_u16
>
> v4:
> - Test the critical points of the lerp function (Pekka)
>
> v3:
> - Use include
type.
> + However, try to not define colorops for "use cases", especially if
> + they require you to combine multiple hardware blocks.
> +
> +- Design new colorops as prescriptive, not descriptive; by the
> + mathematical formula, not by the assumed input and output.
> +
> +A defined colorop type must be deterministic. The exact behavior of the
> +colorop must be documented entirely, whether via a mathematical formula
> +or some other description. Its operation can depend only on its
> +properties and input and nothing else, allowed error tolerance
> +notwithstanding.
> +
> +
> +Driver Forward/Backward Compatibility
> +=
> +
> +As this is uAPI drivers can't regress color pipelines that have been
> +introduced for a given HW generation. New HW generations are free to
> +abandon color pipelines advertised for previous generations.
> +Nevertheless, it can be beneficial to carry support for existing color
> +pipelines forward as those will likely already have support in DRM
> +clients.
> +
> +Introducing new colorops to a pipeline is fine, as long as they can be
> +bypassed or are purely informational. DRM clients implementing support
> +for the pipeline can always skip unknown properties as long as they can
> +be confident that doing so will not cause unexpected results.
> +
> +If a new colorop doesn't fall into one of the above categories
> +(bypassable or informational) the modified pipeline would be unusable
> +for user space. In this case a new pipeline should be defined.
> +
> +
> +References
> +==
> +
> +1.
> https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze_hD5nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1QWn488=@emersion.fr/
> \ No newline at end of file
All in all, I think this is good enough to have my
Acked-by: Pekka Paalanen
in spite of the comments I had. They are just fine tuning.
Thanks,
pq
pgpqA8Xx126xx.pgp
Description: OpenPGP digital signature
What about SDR vs. HDR imagery?
Thanks,
pq
> > -Original Message-
> > From: dri-devel On Behalf Of Simon
> > Ser
> > Sent: Monday, March 4, 2024 7:46 PM
> > To: Garg, Nemesa
> > Cc: Pekka Paalanen ; intel-
> > g...@lists.freedesktop.org; dri-d
On Mon, 26 Feb 2024 16:10:24 -0500
Harry Wentland wrote:
> Add a read-only TYPE property. The TYPE specifies the colorop
> type, such as enumerated curve, 1D LUT, CTM, 3D LUT, PWL LUT,
> etc.
>
> v4:
> - Use enum property for TYPE (Pekka)
>
> v3:
> - Make TYPE a range property
> - Move enum
On Mon, 26 Feb 2024 16:10:31 -0500
Harry Wentland wrote:
> This patch introduces a VKMS color pipeline that includes two
> drm_colorops for named transfer functions. For now the only ones
> supported are sRGB EOTF, sRGB Inverse EOTF, and a Linear TF.
> We will expand this in the future but I don'
On Mon, 26 Feb 2024 16:10:36 -0500
Harry Wentland wrote:
> Certain operations require us to preserve values below 0.0 and
> above 1.0 (0x0 and 0x respectively in 16 bpc unorm). One
> such operation is a BT709 encoding operation followed by its
> decoding operation, or the reverse.
>
> We'll
On Tue, 12 Mar 2024 15:15:13 +
Simon Ser wrote:
> 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 nev
On Tue, 12 Mar 2024 16:26:00 +0200
Pekka Paalanen wrote:
> On Tue, 12 Mar 2024 08:30:34 +
> "Garg, Nemesa" wrote:
>
> > This KMS property is not implementing any formula
>
> Sure it is. Maybe Intel just does not want to tell what the algorithm
&g
On Mon, 11 Mar 2024 17:06:34 +0100
Sebastian Wick wrote:
> 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:
.pekka.paala...@collabora.com/
> > >>
> > > Hi Arthur,
> > >
> > > thanks for addressing this issue.
> > >
> > > Please, add a fix tag to the commit that you are fixing, so we can
> > > easily backport. Might be this commit:
> > > htt
On Mon, 26 Feb 2024 16:10:37 -0500
Harry Wentland wrote:
> We add two 3x4 matrices into the VKMS color pipeline. The reason
> we're adding matrices is so that we can test that application
> of a matrix and its inverse yields an output equal to the input
> image.
You will test also cases where th
On Mon, 26 Feb 2024 16:10:38 -0500
Harry Wentland wrote:
> While working on the CTM implementation of VKMS I had to ascertain
> myself of a few assumptions. One of those is whether drm_fixed.h
> treats its numbers using signed-magnitude or twos-complement. It is
> twos-complement.
>
> In order t
On Mon, 26 Feb 2024 16:10:39 -0500
Harry Wentland wrote:
> A whole slew of tests for CTM handling that greatly helped in
> debugging the CTM code. The extent of tests might seem a bit
> silly but they're fast and might someday help save someone
> else's day when debugging this.
>
> v4:
> - Comm
On Wed, 13 Mar 2024 15:45:47 +0100
Xaver Hugl wrote:
> Hi all,
>
> This was already discussed on IRC, but I think this should be on the
> mailing list as well and get some more official conclusion that's
> written down somewhere.
>
> Recently I've experienced a GPU reset, which the system succe
On Wed, 13 Mar 2024 18:44:55 +0100
Louis Chauvet wrote:
> Few no-op changes to remove double spaces and fix wrong alignments.
>
> Signed-off-by: Louis Chauvet
Reviewed-by: Pekka Paalanen
Thanks,
pq
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 10 +-
> dr
On Wed, 13 Mar 2024 18:44:56 +0100
Louis Chauvet wrote:
> From: Arthur Grillo
>
> Remove intermidiary variables and access the variables directly from
> drm_frame. These changes should be noop.
>
> Signed-off-by: Arthur Grillo
> Signed-off-by: Louis Chauvet
> ---
callbacks, it should never append.
s/append/happen/
Reviewed-by: Pekka Paalanen
Thanks,
pq
>
> Document for those typedefs.
>
> Signed-off-by: Louis Chauvet
> ---
> drivers/gpu/drm/vkms/vkms_drv.h | 23 ++-
> drivers/gpu/drm/vkms/vkms_formats.c | 124
> +++
&format);
> - return (pixel_read_t)NULL;
> + return &black_to_argb_u16;
Hi Louis,
I'm perhaps a bit paranoid in these things, but I'd make this not
black. Maybe something more "screaming" like magenta. There is a slight
chance that
On Wed, 13 Mar 2024 18:45:00 +0100
Louis Chauvet wrote:
> As the pixel_read and pixel_write function should never modify the input
> buffer, mark those pointers const.
>
> Signed-off-by: Louis Chauvet
Reviewed-by: Pekka Paalanen
Thanks,
pq
> ---
> drivers/gpu/d
On Wed, 13 Mar 2024 18:45:01 +0100
Louis Chauvet wrote:
> Introduce the usage of block_h/block_w to compute the offset and the
> pointer of a pixel. The previous implementation was specialized for
> planes with block_h == block_w == 1. To avoid confusion and allow easier
> implementation of tiled
On Wed, 13 Mar 2024 18:45:02 +0100
Louis Chauvet wrote:
> The pre_mul_alpha_blend is dedicated to blending, so to avoid mixing
> different concepts (coordinate calculation and color management), extract
> the x_limit and x_dst computation outside of this helper.
> It also increases the maintainab
On Wed, 13 Mar 2024 18:45:03 +0100
Louis Chauvet wrote:
> The pixel_read_direction enum is useful to describe the reading direction
> in a plane. It avoids using the rotation property of DRM, which not
> practical to know the direction of reading.
> This patch also introduce two helpers, one to c
On Mon, 25 Mar 2024 11:15:13 -0300
Maíra Canal wrote:
> On 3/13/24 14:45, Louis Chauvet wrote:
> > Re-introduce a line-by-line composition algorithm for each pixel format.
> > This allows more performance by not requiring an indirection per pixel
> > read. This patch is focused on readability of
* @format: DRM_FORMAT_* value for which to obtain a conversion function
> (see [drm_fourcc.h])
> */
> -pixel_read_t get_pixel_read_function(u32 format)
> +pixel_read_line_t get_pixel_read_line_function(u32 format)
> {
> switch (format) {
> case DRM_FORMAT_ARGB:
> - return &ARGB_to_argb_u16;
> + return &ARGB_read_line;
> case DRM_FORMAT_XRGB:
> - return &XRGB_to_argb_u16;
> + return &XRGB_read_line;
> case DRM_FORMAT_ARGB16161616:
> - return &ARGB16161616_to_argb_u16;
> + return &ARGB16161616_read_line;
> case DRM_FORMAT_XRGB16161616:
> - return &XRGB16161616_to_argb_u16;
> + return &XRGB16161616_read_line;
> case DRM_FORMAT_RGB565:
> - return &RGB565_to_argb_u16;
> + return &RGB565_read_line;
> default:
> /*
>* This is a bug in vkms_plane_atomic_check. All the supported
> diff --git a/drivers/gpu/drm/vkms/vkms_formats.h
> b/drivers/gpu/drm/vkms/vkms_formats.h
> index 3ecea4563254..8d2bef95ff79 100644
> --- a/drivers/gpu/drm/vkms/vkms_formats.h
> +++ b/drivers/gpu/drm/vkms/vkms_formats.h
> @@ -5,7 +5,7 @@
>
> #include "vkms_drv.h"
>
> -pixel_read_t get_pixel_read_function(u32 format);
> +pixel_read_line_t get_pixel_read_line_function(u32 format);
>
> pixel_write_t get_pixel_write_function(u32 format);
>
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index 10e9b23dab28..8875bed76410 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -112,7 +112,6 @@ static void vkms_plane_atomic_update(struct drm_plane
> *plane,
> frame_info = vkms_plane_state->frame_info;
> memcpy(&frame_info->src, &new_state->src, sizeof(struct drm_rect));
> memcpy(&frame_info->dst, &new_state->dst, sizeof(struct drm_rect));
> - memcpy(&frame_info->rotated, &new_state->dst, sizeof(struct drm_rect));
> frame_info->fb = fb;
> memcpy(&frame_info->map, &shadow_plane_state->data,
> sizeof(frame_info->map));
> drm_framebuffer_get(frame_info->fb);
> @@ -122,10 +121,8 @@ static void vkms_plane_atomic_update(struct drm_plane
> *plane,
>
> DRM_MODE_REFLECT_X |
>
> DRM_MODE_REFLECT_Y);
>
> - drm_rect_rotate(&frame_info->rotated,
> drm_rect_width(&frame_info->rotated),
> - drm_rect_height(&frame_info->rotated),
> frame_info->rotation);
>
> - vkms_plane_state->pixel_read = get_pixel_read_function(fmt);
> + vkms_plane_state->pixel_read_line = get_pixel_read_line_function(fmt);
> }
>
> static int vkms_plane_atomic_check(struct drm_plane *plane,
>
This is looking good enough that I can give an
Acked-by: Pekka Paalanen
Thanks,
pq
pgprCr6kRnsWN.pgp
Description: OpenPGP digital signature
k at some old threads
> > (that I was a part of, and barely remembered :-}
> >
> > At least Sean Paul, Lyude, Simon Ser, Pekka Paalanen
> > have expressed a desire for a "flight-recorder"
> > it'd be hard to say now that 2-3 such buffers would always be
On Tue, 10 Oct 2023 15:13:46 -0100
Melissa Wen wrote:
> O 09/08, Harry Wentland wrote:
> > Signed-off-by: Harry Wentland
> > Cc: Ville Syrjala
> > Cc: Pekka Paalanen
> > Cc: Simon Ser
> > Cc: Harry Wentland
> > Cc: Melissa Wen
> > Cc: Jonas Åd
tter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Rob Clark
> Cc: Simon Ser
> Cc: Manasi Navare
> Cc: Ville Syrjälä
> Cc: Abhinav Kumar
> Cc: Dmitry Baryshkov
&
On Wed, 11 Oct 2023 11:42:24 +0200
Daniel Vetter wrote:
> On Wed, Oct 11, 2023 at 11:48:16AM +0300, Pekka Paalanen wrote:
> > On Tue, 10 Oct 2023 10:06:02 -0600
> > jim.cro...@gmail.com wrote:
> >
> > > since I name-dropped you all,
> >
> > Hi
On Thu, 12 Oct 2023 11:53:52 +0200
Daniel Vetter wrote:
> On Thu, Oct 12, 2023 at 11:55:48AM +0300, Pekka Paalanen wrote:
> > On Wed, 11 Oct 2023 11:42:24 +0200
> > Daniel Vetter wrote:
> >
> > > On Wed, Oct 11, 2023 at 11:48:16AM +0300, Pekka Paalanen wrote:
On Mon, 16 Oct 2023 12:52:32 +0200
André Almeida wrote:
> Hi Michel,
>
> On 8/17/23 12:37, Michel Dänzer wrote:
> > On 8/15/23 20:57, André Almeida wrote:
> >> From: Pekka Paalanen
> >>
> >> Specify how the atomic state is maintained between usersp
On Mon, 16 Oct 2023 15:42:16 +0200
André Almeida wrote:
> Hi Pekka,
>
> On 10/16/23 14:18, Pekka Paalanen wrote:
> > On Mon, 16 Oct 2023 12:52:32 +0200
> > André Almeida wrote:
> >
> >> Hi Michel,
> >>
> >> On 8/17/23 12:37, Michel Dänze
On Thu, 19 Oct 2023 10:56:29 -0400
Harry Wentland wrote:
> On 2023-09-13 07:29, Pekka Paalanen wrote:
> > On Fri, 8 Sep 2023 11:02:26 -0400
> > Harry Wentland wrote:
> >
> >> Signed-off-by: Harry Wentland
...
>
On Thu, 19 Oct 2023 10:56:40 -0400
Harry Wentland wrote:
> On 2023-10-10 12:13, Melissa Wen wrote:
> > O 09/08, Harry Wentland wrote:
> >> Signed-off-by: Harry Wentland
...
> > Also, with this new plane API in place, I understand that we will
> > already need think on how to deal with the mi
On Fri, 20 Oct 2023 16:22:56 +0200
Sebastian Wick wrote:
> Thanks for continuing to work on this!
>
> On Thu, Oct 19, 2023 at 05:21:22PM -0400, Harry Wentland wrote:
> > v2:
> > - Update colorop visualizations to match reality (Sebastian, Alex Hung)
> > - Updated wording (Pekka)
> > - Change
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:
> >
> >> Thanks for continuing to work on this!
> >>
> >> On Thu, Oct 19
ion is generic enough to not special case for any
> specific hypervisor and should apply equally to all.
>
> Signed-off-by: Zack Rusin
Hi,
the below doc text:
Acked-by: Pekka Paalanen
Thanks,
pq
> ---
> Documentation/gpu/drm-kms.rst | 6
&
across reboots, but since a KMS object
> ID is baked in there that's not the case. So PATH shouldn't be
> used as-is in config files and such.
>
> Signed-off-by: Simon Ser
> Cc: Pekka Paalanen
> Cc: Dmitry Baryshkov
> Cc: Daniel Vetter
> ---
> drive
On Tue, 24 Oct 2023 16:03:27 +0300
Ville Syrjälä wrote:
> On Tue, Oct 24, 2023 at 09:03:22AM +, Simon Ser wrote:
> > On Tuesday, October 24th, 2023 at 09:36, Pekka Paalanen
> > wrote:
> >
> > > Are DP MST port numbers guaranteed to be tied to the physica
On Wed, 25 Oct 2023 15:16:08 -0500 (CDT)
Alex Goins wrote:
> Thank you Harry and all other contributors for your work on this. Responses
> inline -
>
> On Mon, 23 Oct 2023, Pekka Paalanen wrote:
>
> > On Fri, 20 Oct 2023 11:23:28 -0400
> > Harry Wentland wrote:
&g
On Fri, 27 Oct 2023 12:01:32 +0200
Sebastian Wick wrote:
> 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:47
On Wed, 20 Sep 2023 16:35:18 +0200
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.
>
> Both d
On Wed, 20 Sep 2023 16:35:20 +0200
Maxime Ripard wrote:
> We'll add automatic selection of the output BPC in a following patch,
> but let's add it to the HDMI connector state already.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/drm_atomic.c | 4 +++-
> drivers/gpu/dr
801 - 900 of 1083 matches
Mail list logo
