On Mon, 16 Jun 2025 11:30:23 +
"Borah, Chaitanya Kumar" wrote:
> > -Original Message-
> > From: Alex Hung
> > Sent: Wednesday, April 30, 2025 6:41 AM
> > To: dri-de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> > Cc: wayland-devel@lists.freedesktop.org; harry.wentl...@amd
On Wed, 4 Jun 2025 18:59:22 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Harry Wentland
> > Sent: Wednesday, June 4, 2025 1:57 AM
> > To: Pekka Paalanen ; Shankar, Uma
> >
> > Cc: Simon Ser ; Alex Hu
On Tue, 3 Jun 2025 08:30:23 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Pekka Paalanen
> > Sent: Friday, May 30, 2025 7:28 PM
> > To: Shankar, Uma
> > Cc: Simon Ser ; Harry Wentland
> > ; Alex Hung ; dri-
> > de...@
On Thu, 22 May 2025 11:33:00 +
"Shankar, Uma" wrote:
> One request though: Can we enhance the lut samples from existing 16bits to
> 32bits as lut precision is
> going to be more than 16 in certain hardware. While adding the new UAPI, lets
> extend this to 32 to make it future proof.
> Refer
On Thu, 22 May 2025 21:02:48 +
"Sloane, Brandon" wrote:
> > Could you explain more of your actual use cases? Maybe people would
> > have better ideas how to solve them.
>
> We are focused on cross domain and multi-level systems built using
> SELinux as a core part of their security archite
On Thu, 22 May 2025 09:54:50 -0400
Harry Wentland wrote:
> On 2025-05-22 09:49, Simon Ser wrote:
> > 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
On Wed, 21 May 2025 11:49:34 +0200
Jonas Ådahl wrote:
> On Wed, May 21, 2025 at 05:43:09AM -0400, Neal Gompa wrote:
> > On Tue, May 20, 2025 at 4:03 PM Simon Ser wrote:
> > >
> > > I would suggest to drop the alphas/betas from the release process, ie.
> > > go straight to RC1. The process woul
On Tue, 20 May 2025 19:11:06 +
"Sloane, Brandon" wrote:
> > -Original Message-
> > From: Pekka Paalanen
> > Sent: Tuesday, May 20, 2025 4:58 AM
> > To: Sloane, Brandon
> > Cc: wayland-devel@lists.freedesktop.org
> > Subject: Re: [RFC
On Wed, 21 May 2025 15:48:00 -0400
Harry Wentland wrote:
> On 2025-05-17 07:51, Xaver Hugl wrote:
> > 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
On Mon, 19 May 2025 15:48:04 +
"Sloane, Brandon" wrote:
> Hello,
>
> I've spent the past few months prototyping a security modules system
> for Wayland. Our specific motivation for this is to support SELinux
> integration to meet some rather unique security requirements.
> However, what we a
On Sun, 18 May 2025 17:10:36 + (UTC)
Pete wrote:
> Dear Wayland protocol developers, please improve Wayland's privacy
> and security model against recent screenshot and similar attacks.
Hi,
what attacks are you referring to?
> Use
> a screenshot and recording security model where applicati
On Tue, 13 May 2025 16:39:51 -0400
Harry Wentland wrote:
> On 2025-05-13 11:36, Melissa Wen wrote:
> > On 05/13, Pekka Paalanen wrote:
> >> On Mon, 12 May 2025 15:50:17 -0300
> >> Melissa Wen wrote:
> >>
> >>> On 04/29, Alex Hung wrote:
>
On Mon, 12 May 2025 15:50:17 -0300
Melissa Wen wrote:
> On 04/29, Alex Hung wrote:
> > Expose one 1D curve colorop with support for
> > DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
> > the sRGB transform when the colorop is not in bypass.
> >
> > With this change the following IGT te
On Tue, 15 Apr 2025 11:29:10 -0400
Harry Wentland wrote:
> On 2025-04-10 03:53, Pekka Paalanen wrote:
> > On Tue, 8 Apr 2025 13:30:46 -0400
> > Harry Wentland wrote:
> >
> >> On 2025-04-08 12:40, Daniel Stone wrote:
> >>> Hi there,
> >>&g
On Tue, 8 Apr 2025 13:30:46 -0400
Harry Wentland wrote:
> On 2025-04-08 12:40, Daniel Stone wrote:
> > Hi there,
> >
> > On Tue, 1 Apr 2025 at 20:53, Simon Ser wrote:
> >> On Tuesday, April 1st, 2025 at 17:14, Daniel Stone
> >> wrote:
...
> >>> 1. Is it guaranteed that, if any plane on
On Fri, 4 Apr 2025 22:14:10 +0300
Andrew Randrianasulu wrote:
> пт, 4 апр. 2025 г., 21:35 Andrea paz :
>
> > @Georgy
> > X11 supports CMS more or less well. Even I was able to profile the
> > monitor and install it with colord. It's not full support like Windows
> > or Apple has, but it's doable
On Mon, 7 Apr 2025 18:31:17 +0300
Andrew Randrianasulu wrote:
> пн, 7 апр. 2025 г., 17:18 Pekka Paalanen :
>
> > On Mon, 7 Apr 2025 14:44:25 +0300
> > Andrew Randrianasulu wrote:
> >
> > > пн, 7 апр. 2025 г., 14:19 Pekka Paalanen :
> > >
On Mon, 7 Apr 2025 14:44:25 +0300
Andrew Randrianasulu wrote:
> пн, 7 апр. 2025 г., 14:19 Pekka Paalanen :
>
> > On Fri, 4 Apr 2025 22:14:10 +0300
> > Andrew Randrianasulu wrote:
> >
> > > пт, 4 апр. 2025 г., 21:35 Andrea paz :
> > >
...
&g
On Wed, 5 Mar 2025 21:45:54 -0500
Bill Hayden wrote:
> I am porting a multi-threaded UI toolkit to Weston (layered on top of
> toytoolkit), and running into an issue. This UI toolkit expects to be able
> to draw from multiple threads, to be specific, from a different thread than
> the one that c
On Thu, 23 Jan 2025 15:16:29 -0500
Harry Wentland wrote:
> On 2025-01-17 04:06, Pekka Paalanen wrote:
> > On Thu, 16 Jan 2025 10:56:22 +0200
> > Pekka Paalanen wrote:
> >
> >> On Thu, 19 Dec 2024 21:33:37 -0700
> >> Alex Hung wrote:
> >>
&g
On Thu, 19 Dec 2024 21:33:49 -0700
Alex Hung wrote:
> From: Harry Wentland
>
> Add kernel doc for AMD color pipeline.
>
> Signed-off-by: Alex Hung
> Signed-off-by: Harry Wentland
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 122 +++---
> 1 file changed, 102 insertions
On Thu, 16 Jan 2025 10:56:22 +0200
Pekka Paalanen wrote:
> On Thu, 19 Dec 2024 21:33:37 -0700
> Alex Hung wrote:
>
> > From: Harry Wentland
> >
> > The BT.709 and BT.2020 OETFs are the same, the only difference
> > being that the BT.2020 variant is defined w
On Thu, 19 Dec 2024 21:33:35 -0700
Alex Hung wrote:
> From: Harry Wentland
>
> The PQ function defines a mapping of code values to nits (cd/m^2).
> The max code value maps to 10,000 nits.
>
> Windows DWM's canonical composition color space (CCCS) defaults
> to composing SDR contents to 80 nit
On Thu, 19 Dec 2024 21:33:37 -0700
Alex Hung wrote:
> From: Harry Wentland
>
> 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.
>
> Both are used as encoding functions for vid
On Fri, 14 Jun 2024 18:36:57 +
"Hoosier, Matt" wrote:
>
> Hmm. As I read through the history of the original support for
> writeback screenshots
> (https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/458)
> and get some initial results just trying to drive a steady stream of
> wri
On Wed, 12 Jun 2024 21:35:48 +
"Hoosier, Matt" wrote:
> > -Original Message-
> > From: Hoosier, Matt
> > Sent: Wednesday, June 12, 2024 8:37 AM
> > To: Pekka Paalanen
> > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad
> > ; wayland
On Mon, 10 Jun 2024 14:18:39 +
"Hoosier, Matt" wrote:
> Yes, the native Linux driver for the hardware still does end up being
> responsible for one or more planes.
>
> Other than trying to arrange the pieces so that there's some API that
> offers the client an option to guarantee that the so
On Fri, 7 Jun 2024 14:16:32 +
"Hoosier, Matt" wrote:
> > What do you mean you can capture all virtual machines with KMS
> > writeback?
> >
> > What's the architecture there? How do virtual machines access KMS
> > hardware? Why would Weston be able to capture their outputs at all?
>
> The wor
On Tue, 4 Jun 2024 20:33:48 +
"Hoosier, Matt" wrote:
> Tactical question: I somehow missed until this point that the remote
> and pipewire plugins will only run if the DRM backend is being used.
>
> But the DRM backend *really* doesn't want to start nowadays unless
> you're running on a syst
On Mon, 3 Jun 2024 17:57:18 +
"Hoosier, Matt" wrote:
> > What do you mean you can capture all virtual machines with KMS
> > writeback?
> >
> > What's the architecture there? How do virtual machines access KMS
> > hardware? Why would Weston be able to capture their outputs at all?
> >
>
> I
On Fri, 31 May 2024 13:26:12 +
"Hoosier, Matt" wrote:
>
> My goal is to implement this screen capture with a guarantee that the
> copy comes from a KMS writeback connector. I know this sounds like an
> odd thing to insist on. Let's say that in my industry, the system is
> rarely only running
On Thu, 30 May 2024 13:40:15 +
"Hoosier, Matt" wrote:
> Okay, interesting thoughts on all of that.
>
> I'm not sure how far I'm going to get toward a complete overhaul of
> the capture mechanism. Maybe it would be useful to know a couple
> things about the current one (weston_output_capture_
to help with this. This is more of a
wish than a requirement.
Thanks,
pq
>
> > -Original Message-
> > From: Pekka Paalanen
> > Sent: Wednesday, May 29, 2024 2:43 AM
> > To: Marius Vlad ; Hoosier, Matt
> >
> > Cc: wayland-devel@lists.freedeskto
On Tue, 28 May 2024 20:04:45 +0300
Marius Vlad wrote:
> On Tue, May 28, 2024 at 03:53:23PM +, Hoosier, Matt wrote:
> > Hi Marius,
> Hi,
> >
> > Okay, I guess that answers the bit about needing to screen-scrape to get
> > content into Pipewire now.
> >
> > But I'm still a little unclear a
On Wed, 8 May 2024 13:49:51 +0200
Philip Bizimis wrote:
> I am currently working on a small Wayland Snake game to
> learn about Wayland and game development. I am using SHM
> double buffers for rendering.
>
> My main game loop has two parts that run at different speeds so
> that I can have a con
On Mon, 29 Apr 2024 22:38:10 +0100
Bruce Steers wrote:
>
> I personally have written many applications with gambas.
>
> Some have no issue like my text editor for example, a standard looking
> editor with window and title bar.
>
> Although gambas provides a Settings.Write(window_name) /
> Sett
On Sat, 27 Apr 2024 08:28:00 +0100
Bruce Steers wrote:
> Hello
> I am a gambas basic developer and would like to report some wayland
> problems. (major issues) that we hear of on the gambas mailing list all the
> time.
>
> The attitude towards wayland with gambas coders at present is ,, ditch
>
GL-renderer framebuffer must be fully opaque.
These are indeed quite limiting, which why the work is on-going.
Thanks,
pq
>
> Thanks,
> Namit
>
> -Original Message-
> From: Pekka Paalanen
> Sent: Wednesday, April 10, 2024 3:57 PM
> To: Namit Solanki (QUIC)
On Mon, 8 Apr 2024 06:42:34 +
"Namit Solanki (QUIC)" wrote:
> Hi Weston team,
>
> We are working on Weston 10 version. We have a use case where we are
> playing a video using Gstreamer and on top of it we are running a
> Weston-simple-egl app.
>
> Status bar and the Weston-simple-egl layer
On Tue, 26 Mar 2024 11:42:48 -0400
Christopher Michael wrote:
> The 2024 X.Org Foundation membership renewal period has been extended
> one additional week and elections will start the following week on 01
> April 2024.
>
> Please note that only current members can vote in the upcoming electio
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: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
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 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: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: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: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 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: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
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
pgp3t8XTXtmZY.pgp
Description: OpenPGP digital signature
On Fri, 8 Mar 2024 14:50:30 +
Terry Barnaby wrote:
> On 05/03/2024 12:26, Pekka Paalanen wrote:
> > On Mon, 4 Mar 2024 17:59:25 +
> > Terry Barnaby wrote:
> >
...
> >> I would have thought it better/more useful to have a Wayland API call
> &
On Mon, 4 Mar 2024 17:59:25 +
Terry Barnaby wrote:
> On 04/03/2024 15:50, Pekka Paalanen wrote:
> > On Mon, 4 Mar 2024 14:51:52 +
> > Terry Barnaby wrote:
> >
> >> On 04/03/2024 14:14, Pekka Paalanen wrote:
> >>> On Mon, 4 Mar 2024
On Mon, 4 Mar 2024 14:51:52 +
Terry Barnaby wrote:
> On 04/03/2024 14:14, Pekka Paalanen wrote:
> > On Mon, 4 Mar 2024 13:24:56 +
> > Terry Barnaby wrote:
> >
> >> On 04/03/2024 09:41, Pekka Paalanen wrote:
> >>> On Mon, 4 Mar 2024
On Mon, 4 Mar 2024 13:24:56 +
Terry Barnaby wrote:
> On 04/03/2024 09:41, Pekka Paalanen wrote:
> > On Mon, 4 Mar 2024 08:12:10 +
> > Terry Barnaby wrote:
> >
> >> While I am trying to investigate my issue in the QtWayland arena via the
> >> Qt
On Mon, 4 Mar 2024 08:12:10 +
Terry Barnaby wrote:
> While I am trying to investigate my issue in the QtWayland arena via the
> Qt Jira Bug system, I thought I would try taking Qt out of the equation
> to simplify the application a bit more to try and gain some
> understanding of what is g
On Thu, 29 Feb 2024 16:32:26 -0500
jleivent wrote:
> On Tue, 27 Feb 2024 11:01:18 +0200
> Pekka Paalanen wrote:
>
>
> > > But suppose I'm writing a client that has the possibility of
> > > sending a rapid stream of msgs to the compositor that might be,
&g
On Wed, 28 Feb 2024 18:04:28 +
Terry Barnaby wrote:
> Hi Pekka,
>
> Some questions below:
>
> Thanks
>
> Terry
> On 26/02/2024 15:56, Pekka Paalanen wrote:
> > Ok. What Wayland API requests cause a surface to actually be mapped
> >> (Sorry don
On Mon, 26 Feb 2024 13:23:01 -0500
jleivent wrote:
> On Mon, 26 Feb 2024 15:12:23 +0200
> Pekka Paalanen wrote:
>
> ...
> > > What is the advantage to having the impacted clients grow their send
> > > buffers while waiting? They wait either way.
> >
On Mon, 26 Feb 2024 15:18:27 +
Terry Barnaby wrote:
> Hi Pekka,
>
> Thanks for the response. Notes below:
>
> Terry
>
> On 26/02/2024 13:28, Pekka Paalanen wrote:
> > On Sun, 25 Feb 2024 08:04:30 +
> > Terry Barnaby wrote:
> >
> >> Hi
On Sun, 25 Feb 2024 08:04:30 +
Terry Barnaby wrote:
> Hi,
>
> I have investigated a bit further. I have built my own Weston server to
> run under X11 on Fedora37 so I can add printf's and debug more easily
> than using a cross compiled iMX8mp target system etc. I added a new
> dsmc-shell
On Sat, 24 Feb 2024 15:35:27 -0500
jleivent wrote:
> On Fri, 23 Feb 2024 12:12:38 +0200
> Pekka Paalanen wrote:
>
>
> > I would think it to be quite difficult for a compositor to dedicate a
> > whole thread for each client.
>
> But that means it is possible t
hat if you need to
draw and you don't have a free pixel buffer, you allocate a new one.
It's up to the client to limit itself to a reasonable number of pixel
buffers per surface, and that number is not 2. It's probably 4 usually.
A reasonable number could be even more, depending.
Tha
On Wed, 21 Feb 2024 11:08:02 -0500
jleivent wrote:
> Not completely blocking makes sense for the compositor, but why not
> block the client?
Blocking in clients is indeed less of a problem, but:
- Clients do not usually have requests they *have to* send to the
compositor even if the composito
On Tue, 13 Feb 2024 10:16:36 +0200
Tomi Valkeinen wrote:
> When the driver sets up the zpos property it sets the default zpos value
> to the HW id of the plane. That is fine as such, but as on many DSS
> versions the driver arranges the DRM planes in a different order than
> the HW planes (to kee
On Thu, 21 Dec 2023 02:22:08 +
"Gramer, Markus" wrote:
> Hi there,
>
> Let me start with an apology posting this here on the development
> mailing list rather than somewhere more user related. Unfortunately,
> I couldn't find a forum/community for Weston/Wayland, so if there is
> a better pl
On Fri, 8 Dec 2023 10:10:28 -0500
jleivent wrote:
> On Fri, 8 Dec 2023 12:54:35 +0100
> Sebastian Wick wrote:
>
> > ...
> > I think a more useful thing to do would be to add this restriction (an
> > interface cannot have an event and a request with the same name) to
> > the documentation and to
On Wed, 8 Nov 2023 11:36:42 -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.
To be honest, this
On Wed, 8 Nov 2023 11:36:40 -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.
Would it not be better to mimic wh
On Wed, 8 Nov 2023 11:36:39 -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 u
On Wed, 8 Nov 2023 11:36:37 -0500
Harry Wentland wrote:
> This type is used to support a 3x4 matrix in colorops. A 3x4
> matrix uses the last column as a "bias" column. Some HW exposes
> support for 3x4. The calculation looks like:
>
> out matrixin
> |R| |0 1 2 3 | | R |
> |G| =
On Wed, 8 Nov 2023 11:36:36 -0500
Harry Wentland wrote:
> With the introduction of the pre-blending color pipeline we
> can no longer have color operations that don't have a clear
> position in the color pipeline. We deprecate all existing
> plane properties. For upstream drivers those are:
> -
On Wed, 8 Nov 2023 11:36:34 -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't
On Wed, 8 Nov 2023 11:36:32 -0500
Harry Wentland wrote:
> We're adding a new enum COLOR PIPELINE property. This
> property will have entries for each COLOR PIPELINE by
> referencing the DRM object ID of the first drm_colorop
> of the pipeline. 0 disables the entire COLOR PIPELINE.
I didn't find
On Wed, 8 Nov 2023 11:36:28 -0500
Harry Wentland wrote:
> Signed-off-by: Harry Wentland
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 18 ++
> drivers/gpu/drm/drm_colorop.c | 39 +++
> include/drm/drm_colorop.h | 20
> 3 files c
On Wed, 8 Nov 2023 11:36:25 -0500
Harry Wentland wrote:
> v3:
> - Describe DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE (Sebastian)
> - Ask for clear documentation of colorop behavior (Sebastian)
>
> v2:
> - Update colorop visualizations to match reality (Sebastian, Alex Hung)
> - Updated wording (Pe
On Wed, 8 Nov 2023 11:36:27 -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.
>
> v3:
> - Make TYPE a range property
> - Move enum drm_colorop_type to uapi header
> - Fix drm_get_c
On Wed, 8 Nov 2023 11:36:26 -0500
Harry Wentland wrote:
> This patches introduces a new drm_colorop mode object. This
> object represents color transformations and can be used to
> define color pipelines.
>
> We also introduce the drm_colorop_state here, as well as
> various helpers and state tr
On Wed, 8 Nov 2023 11:36:25 -0500
Harry Wentland wrote:
> v3:
> - Describe DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE (Sebastian)
> - Ask for clear documentation of colorop behavior (Sebastian)
>
> v2:
> - Update colorop visualizations to match reality (Sebastian, Alex Hung)
> - Updated wording (Pe
On Wed, 8 Nov 2023 11:36:23 -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
>
> v3:
> - Use include way of testing static functions (Arthur)
>
> Signed-off-by: Harry W
On Wed, 29 Nov 2023 10:10:05 +0100
Olivier Fourdan wrote:
> Hi all,
>
> In Fedora and Red Hat Enterprise Linux, we ship a small shell script called
> "xvfb-run" originating from Debian to launch an X11 client within Xvfb.
>
> With the future removal of Xorg and all related Xservers in RHEL [1],
On Tue, 21 Nov 2023 13:05:38 -0800
Robert Ayrapetyan wrote:
> Hi there, I'm having difficulty locating the specific location in the
> Wayland codebase where registry_bind function is called. I'm trying to
> comprehend why, for particular globals, there is no occurrence of a
> global->bind call.
On Tue, 7 Nov 2023 14:28:13 +
Joshua Ashton wrote:
> On 11/6/23 10:21, Pekka Paalanen wrote:
> > On Sat, 4 Nov 2023 13:11:02 +
> > Joshua Ashton wrote:
> >
> >> Hello,
> >
> > Hi Joshua,
> >
> > thanks for replying. The reason
On Mon, 13 Nov 2023 09:44:15 +
Simon Ser wrote:
> 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
On Fri, 10 Nov 2023 15:27:03 -0500
Harry Wentland wrote:
> On 2023-11-09 04:20, Pekka Paalanen wrote:
> > On Wed, 8 Nov 2023 11:27:35 -0500
> > Harry Wentland wrote:
> >
> >> On 2023-11-08 11:19, Pekka Paalanen wrote:
> >>> On Wed, 8 Nov 2023
On Mon, 13 Nov 2023 09:18:39 +
Simon Ser 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
> > > > > > > > > > > +effectively change only the FB_ID property
On Fri, 10 Nov 2023 11:27:14 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Pekka Paalanen
> > Sent: Thursday, November 9, 2023 5:26 PM
> > To: Shankar, Uma
> > Cc: Joshua Ashton ; Harry Wentland
> > ; dri-de...@lists.freede
On Thu, 9 Nov 2023 10:17:11 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Joshua Ashton
> > Sent: Wednesday, November 8, 2023 7:13 PM
> > To: Shankar, Uma ; Harry Wentland
> > ; dri-de...@lists.freedesktop.org
...
> > Subject: Re: [RFC PATCH v2 06/17] drm/doc/rfc: Descri
On Wed, 8 Nov 2023 11:27:35 -0500
Harry Wentland wrote:
> On 2023-11-08 11:19, Pekka Paalanen wrote:
> > On Wed, 8 Nov 2023 09:31:17 -0500
> > Harry Wentland wrote:
> >
> >> On 2023-11-08 06:40, Sebastian Wick wrote:
> >>> On Wed, Nov 8, 202
On Wed, 8 Nov 2023 09:31:17 -0500
Harry Wentland wrote:
> On 2023-11-08 06:40, Sebastian Wick wrote:
> > 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 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 Thu, 19 Oct 2023
On Mon, 6 Nov 2023 11:19:27 -0500
Harry Wentland wrote:
> On 2023-10-20 06:36, Pekka Paalanen wrote:
> > 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 Wentl
On Mon, 6 Nov 2023 11:24:50 -0500
Harry Wentland wrote:
> On 2023-10-20 06:17, Pekka Paalanen wrote:
> > 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
ries do you
associate with game content pixels?
How is the matrix dest_from_source in
https://github.com/ValveSoftware/gamescope/blob/master/src/color_helpers.cpp#L701
formed, what are its inputs?
This whole email started from you claiming to do saturation boosting,
while you are obviously
This is a continuation of
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14#note_2152254
because this is off-topic in that thread.
> No, we did widening. The Deck's internal display has a modest gamut
> that is < 71% sRGB.
If games do wide (well, full sRGB or wider) gam
On Wed, 1 Nov 2023 18:06:50 +0100
Carlos Garnacho wrote:
> Hi,
>
> On Thu, Oct 19, 2023 at 11:58 PM Carlos Garnacho wrote:
> >
> > Hi,
> >
> > I would like to propose a meeting about the color management protocol
> > [1] after next week (it's late to schedule for next, plus there's
> > people s
t; 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 Goins
> Cc: Joshua Ashton
> Cc: Michel Dänze
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, 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 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
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
1 - 100 of 2252 matches
Mail list logo
