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
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) /
>
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
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
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
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 never
> &g
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
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
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,
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:
> -
pecially 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 cal
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
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't r
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
raw 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.
Thanks,
pq
> On Thu, 22 Feb 2024
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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:
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
ware/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 doing saturation reduction in total. Turns out
the saturation boosting (yes, you do that) is not the whole color
t
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)
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
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änzer
> Cc
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
> ---
> drivers/gpu/drm/drm_
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
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 Thu, 19 Oct 2023 23:58:18 +0200
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 still likely at XDC). After talking with GIMP maintainers, I
> think this topic
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
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 Wed, 18 Oct 2023 09:18:45 +0200
Emmanuel Gil Peyrot wrote:
> Hi,
>
> On Wed, Oct 18, 2023 at 12:00:45AM +, Joe M wrote:
> > In a GLES app wired up to Weston/Wayland using EGL, we're calling
> > `eglSwapBuffers` in a render loop that takes about 12-13ms to draw
> > our content, based on
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 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 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 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 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
; (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 enough,
> > esp as theres a p
On Wed, 4 Oct 2023 11:09:42 -0400
jleivent wrote:
> On Wed, 4 Oct 2023 11:26:02 +0300
> Pekka Paalanen wrote:
>
> > ...
> > For the forked clients, there is stop_display()/display_resume().
> > Maybe that helps?
>
> Maybe if I understand their usage cor
On Tue, 3 Oct 2023 14:46:14 -0400
jleivent wrote:
> I am trying to write some tests that provoke errors in libwayland, but
> it doesn't seem to me like the existing test suite provides a mechanism
> to create specific event orderings that are allowed but not guaranteed
> by the asynchrony of the
On Tue, 26 Sep 2023 10:56:03 -0400
jleivent wrote:
> On Tue, 26 Sep 2023 11:53:07 +0300
> Pekka Paalanen wrote:
>
> > On Mon, 25 Sep 2023 12:05:30 -0400
> > jleivent wrote:
> >
> > > How do I get CI/CD capability turned on? I tried building the unit
On Mon, 25 Sep 2023 17:10:30 +0100
John Cox wrote:
> Hi
>
> Assuming I have a separate poll/read_events/dispatch_queue thread to my
> main thread. If I go wl_display_sync/wl_callback_add_listener on the
> main thread is there a race condition between those two calls where the
> other thread can
On Sat, 23 Sep 2023 09:49:20 -0400
jleivent wrote:
> On Sat, 23 Sep 2023 09:40:20 -0400
> jleivent wrote:
>
> > Could I have CI/CD privileges for
> > https://gitlab.freedesktop.org/jonleivent/wayland-idfix
> >
> > Thanks
> > Jon
>
> Also:
> With respect to the caching scheme described in
On Mon, 25 Sep 2023 12:05:30 -0400
jleivent wrote:
> How do I get CI/CD capability turned on? I tried building the unit
> tests locally, but get errors that suggest those tests need to be run
> in CI. Issue 540 says I need to apply for the guest role - how do I do
> that?
I don't recall
On Fri, 22 Sep 2023 15:47:13 +0100
John Cox wrote:
> Hi
>
> >On 9/14/23 14:24, John Cox wrote:
> >
> >> Hi
> >>
> >> A, hopefully, simple question - should I expect a wl_buffer::release
> >> event from the buffer previously committed to a surface after I've
> >> attached (and invalidated &
On Tue, 19 Sep 2023 10:02:55 -0400
jleivent wrote:
> On Tue, 19 Sep 2023 16:26:37 +0300
> Pekka Paalanen wrote:
>
> > ...
> > > But aren't those fast frame updates done through shared fds? Hence
> > > not part of the wire protocol, and would not be impact
On Mon, 18 Sep 2023 11:31:18 -0400
jleivent wrote:
> On Mon, 18 Sep 2023 14:06:51 +0300
> Pekka Paalanen wrote:
>
> > On Sat, 16 Sep 2023 12:18:35 -0400
> > jleivent wrote:
> >
> > > The easiest fix I can think of is to go full-on half duplex.
>
On Sat, 16 Sep 2023 12:18:35 -0400
jleivent wrote:
> The easiest fix I can think of is to go full-on half duplex. Meaning
> that each side doesn't send a single message until it has fully
> processed all messages sent to it in the order they arrive (thankfully,
> sockets preserve message order,
On Fri, 15 Sep 2023 14:12:25 +0100
John Cox wrote:
> Hi
>
> >On Thu, 14 Sep 2023 12:24:42 +0100
> >John Cox wrote:
> >
> >> Hi
> >>
> >> A, hopefully, simple question - should I expect a wl_buffer::release
> >> event from the buffer previously committed to a surface after I've
> >> attached
On Thu, 14 Sep 2023 12:24:42 +0100
John Cox wrote:
> Hi
>
> A, hopefully, simple question - should I expect a wl_buffer::release
> event from the buffer previously committed to a surface after I've
> attached (and invalidated & committed) a NULL buffer to the surface? it
> doesn't seem to
On Thu, 14 Sep 2023 15:10:48 -0400
jleivent wrote:
> On Thu, 14 Sep 2023 16:32:06 +0300
> Pekka Paalanen wrote:
>
> >
> > As an aside, we collect unfixable issues under
> > https://gitlab.freedesktop.org/wayland/wayland/-/issues/?label_name%5B%5D=Protoco
On Wed, 13 Sep 2023 20:16:09 -0400
jleivent wrote:
> Forgive the long post. Tl;dr: what are the rules of object ID lifetime
> and reuse in the Wayland protocol?
Hi,
congratulations, I think you may have found everything that is not
quite right in the fundamental Wayland protocol design. :-)
> > 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: Jon
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
On Mon, 11 Sep 2023 12:53:15 +0100
John Cox wrote:
> Hi
> I am clearly deeply confused by event queues and proxies - I have this
> snippet of code (from some VLC work I'm doing):
>
> sys->eventq = wl_display_create_queue(video_display(sys));
> if (sys->eventq == NULL) {
> msg_Err(vd,
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
> &
i-de...@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 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.freede
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.freede
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
1 - 100 of 5779 matches
Mail list logo
