Personally I would say we could give it a go, but I don't believe that
this will significantly change how long some protocols take to get
merged. The group transaction is taking so long because the subsurface
sync and desync modes together with content update queues are hard to
get right and the
On Fri, Dec 8, 2023 at 12:44 AM jleivent wrote:
>
> On Thu, 7 Dec 2023 22:06:07 +
> David Edmundson wrote:
>
> > The generated C code be full of conflicts. The
> > MY_PROTOCOL_REQUESTEVENT_SINCE_VERSION define for a start.
> >
> > I think it might compile in C, but other generators exist
On Wed, Nov 8, 2023 at 11:16 AM Pekka Paalanen wrote:
>
> On Tue, 7 Nov 2023 11:58:26 -0500
> Harry Wentland wrote:
>
> > On 2023-11-07 04:55, Pekka Paalanen wrote:
> > > On Mon, 6 Nov 2023 11:19:27 -0500
> > > Harry Wentland wrote:
> > >
> > >> On 2023-10-20 06:36, Pekka Paalanen wrote:
> >
On Tue, Nov 07, 2023 at 11:52:11AM -0500, Harry Wentland wrote:
>
>
> On 2023-10-26 13:30, Sebastian Wick wrote:
> > On Thu, Oct 26, 2023 at 11:57:47AM +0300, Pekka Paalanen wrote:
> >> On Wed, 25 Oct 2023 15:16:08 -0500 (CDT)
> >> Alex Goins wrote:
> &g
On Fri, Oct 27, 2023 at 10:59:25AM +0200, Michel Dänzer wrote:
> On 10/26/23 21:25, Alex Goins wrote:
> > On Thu, 26 Oct 2023, Sebastian Wick wrote:
> >> On Thu, Oct 26, 2023 at 11:57:47AM +0300, Pekka Paalanen wrote:
> >>> On Wed, 25 Oct 2023 15:16:08 -0500
anen wrote:
> >
> > > On Fri, 20 Oct 2023 11:23:28 -0400
> > > Harry Wentland wrote:
> > >
> > > > On 2023-10-20 10:57, Pekka Paalanen wrote:
> > > > > On Fri, 20 Oct 2023 16:22:56 +0200
> > > > > Sebastian Wick wrote:
ility" section (Sebastian, Pekka)
>
> Signed-off-by: Harry Wentland
> Cc: Ville Syrjala
> Cc: Pekka Paalanen
> Cc: Simon Ser
> Cc: Harry Wentland
> Cc: Melissa Wen
> Cc: Jonas Ådahl
> Cc: Sebastian Wick
> Cc: Shashank Sharma
> Cc: Alexander Goins
:
> > + * No active pixel source.
> > + * Committing with a NONE pixel source will disable the plane.
> > + *
> > + * "FB":
> > + * Framebuffer source set by the "FB_ID" property.
> > + *
> > * Note that all the property extensions described here apply either to the
> > * plane or the CRTC (e.g. for the background color, which currently is not
> > * exposed and assumed to be black).
>
> This UAPI:
> Acked-by: Pekka Paalanen
Thanks Jessica, same for me
Acked-by: Sebastian Wick
>
>
> Thanks,
> pq
> Cc: Simon Ser
> > > Cc: Harry Wentland
> > > Cc: Melissa Wen
> > > Cc: Jonas Ådahl
> > > Cc: Sebastian Wick
> > > Cc: Shashank Sharma
> > > Cc: Alexander Goins
> > > Cc: Joshua Ashton
> > > Cc: Michel Dänzer
>
c: Simon Ser
> Cc: Harry Wentland
> Cc: Melissa Wen
> Cc: Jonas Ådahl
> Cc: Sebastian Wick
> Cc: Shashank Sharma
> Cc: Alexander Goins
> Cc: Joshua Ashton
> Cc: Michel Dänzer
> Cc: Aleix Pol
> Cc: Xaver Hugl
> Cc: Victoria Brekenfeld
> Cc: Daniel Vet
On Tue, Sep 05, 2023 at 02:33:04PM +0200, Sebastian Wick wrote:
> On Tue, Sep 05, 2023 at 02:33:26PM +0300, Pekka Paalanen wrote:
> > On Mon, 4 Sep 2023 14:29:56 +
> > "Shankar, Uma" wrote:
> >
> > > > -Original Message-
> > > >
On Tue, Sep 05, 2023 at 02:33:26PM +0300, Pekka Paalanen wrote:
> On Mon, 4 Sep 2023 14:29:56 +
> "Shankar, Uma" wrote:
>
> > > -Original Message-
> > > From: Sebastian Wick
> > > Sent: Thursday, August 31, 2023 2:46 AM
> >
ists.freedesktop.org
> > Cc: wayland-devel@lists.freedesktop.org; Ville Syrjala
> > ; Pekka Paalanen
> > ;
> > Simon Ser ; Melissa Wen ; Jonas Ådahl
> > ; Sebastian Wick ; Shashank
> > Sharma ; Alexander Goins ;
> > Naseer Ahmed ; Christopher Braga
> >
>
r information would have unecessary overhead that
> does not reflect the behavior of the solid fill feature. In addition,
> assigning the solid fill blob to FB_ID would require loosening some core
> drm_property checks that might cause unwanted side effects elsewhere.
The cover letter is
On Mon, Aug 28, 2023 at 05:05:08PM -0700, Jessica Zhang wrote:
> Document and add support for solid_fill property to drm_plane. In
> addition, add support for setting and getting the values for solid_fill.
>
> To enable solid fill planes, userspace must assign a property blob to
> the
On Tue, Aug 15, 2023 at 03:57:09PM -0300, André Almeida wrote:
> Given that prop changes may lead to modesetting, which would defeat the
> fast path of the async flip, refuse any atomic prop change for async
> flips in atomic API. The only exceptions are the framebuffer ID to flip
> to and the
On Mon, Aug 7, 2023 at 7:52 PM Jessica Zhang wrote:
>
>
>
> On 8/4/2023 6:15 AM, Sebastian Wick wrote:
> > On Fri, Jul 28, 2023 at 7:03 PM Jessica Zhang
> > wrote:
> >>
> >> Add support for pixel_source property to drm_plane and related
> >
On Fri, Aug 4, 2023 at 3:27 PM Dmitry Baryshkov
wrote:
>
> On Fri, 28 Jul 2023 at 20:03, Jessica Zhang wrote:
> >
> > Document and add support for solid_fill property to drm_plane. In
> > addition, add support for setting and getting the values for solid_fill.
> >
> > To enable solid fill
On Mon, Jul 31, 2023 at 6:01 AM Dmitry Baryshkov
wrote:
>
> On 28/07/2023 20:02, Jessica Zhang wrote:
> > Document and add support for solid_fill property to drm_plane. In
> > addition, add support for setting and getting the values for solid_fill.
> >
> > To enable solid fill planes, userspace
On Fri, Jul 28, 2023 at 7:03 PM Jessica Zhang wrote:
>
> Add support for pixel_source property to drm_plane and related
> documentation. In addition, force pixel_source to
> DRM_PLANE_PIXEL_SOURCE_FB in DRM_IOCTL_MODE_SETPLANE as to not break
> legacy userspace.
>
> This enum property will allow
On Sat, Jul 1, 2023 at 4:09 AM André Almeida wrote:
>
> From: Simon Ser
>
> If the driver supports it, allow user-space to supply the
> DRM_MODE_PAGE_FLIP_ASYNC flag to request an async page-flip.
> Set drm_crtc_state.async_flip accordingly.
>
> Document that drivers will reject atomic commits
On Fri, Jun 30, 2023 at 11:27 PM Jessica Zhang
wrote:
>
>
>
> On 6/30/2023 7:43 AM, Sebastian Wick wrote:
> > On Fri, Jun 30, 2023 at 2:26 AM Jessica Zhang
> > wrote:
> >>
> >> Add support for pixel_source property to drm_plane and related
> &
On Fri, Jun 30, 2023 at 2:26 AM Jessica Zhang wrote:
>
> Add support for pixel_source property to drm_plane and related
> documentation.
>
> This enum property will allow user to specify a pixel source for the
> plane. Possible pixel sources will be defined in the
> drm_plane_pixel_source enum.
>
On Fri, May 5, 2023 at 10:40 PM Dave Airlie wrote:
>
> On Fri, 5 May 2023 at 01:23, Simon Ser wrote:
> >
> > Hi all,
> >
> > The goal of this RFC is to expose a generic KMS uAPI to configure the color
> > pipeline before blending, ie. after a pixel is tapped from a plane's
> > framebuffer and
On Fri, May 5, 2023 at 5:28 PM Daniel Vetter wrote:
>
> On Thu, May 04, 2023 at 03:22:59PM +, Simon Ser wrote:
> > Hi all,
> >
> > The goal of this RFC is to expose a generic KMS uAPI to configure the color
> > pipeline before blending, ie. after a pixel is tapped from a plane's
> >
On Mon, Jan 23, 2023 at 11:43 PM Simon Ser wrote:
>
> On Monday, January 23rd, 2023 at 21:25, Sebastian Wick
> wrote:
>
> > Why is the TF defined for GL formats and both the primaries and TF for
> > Vulkan formats? The only exception here should be sRGB format
Why is the TF defined for GL formats and both the primaries and TF for
Vulkan formats? The only exception here should be sRGB formats. Where
did you get the information from?
On Mon, Jan 23, 2023 at 4:51 PM Laurent Pinchart
wrote:
>
> CC'ing the linux-media mailing list.
>
> On Mon, Jan 23, 2023
On Wed, Jan 4, 2023 at 2:10 AM Jessica Zhang wrote:
>
>
>
> On 12/22/2022 7:12 PM, Dmitry Baryshkov wrote:
> > On 23/12/2022 00:14, Jessica Zhang wrote:
> >> Initialize and use the color_fill properties for planes in DPU driver. In
> >> addition, relax framebuffer requirements within atomic
On Wed, Nov 16, 2022 at 1:34 PM Pekka Paalanen wrote:
>
> On Tue, 15 Nov 2022 00:11:56 +0100
> Sebastian Wick wrote:
>
> > There are still regular bug reports about monitors (sinks) and sources
> > disagreeing about the quantization range of the pixel data. In
> > p
>
> Regards
> Yussuf
>
> [1]
> https://patchwork.kernel.org/project/dri-devel/cover/20200413214024.46500-1-...@pp3345.net/
> [2] https://github.com/pp3345/linux/commits/rgb-quant-range-v2
>
> On 15.11.22 00:11, Sebastian Wick wrote:
> > There are still regular bug reports about
Hi Dave,
I noticed that I didn't get the Broadcast RGB property thanks to you
(more below)
On Tue, Nov 15, 2022 at 2:16 PM Dave Stevenson
wrote:
>
> Hi Sebastian
>
> Thanks for starting the conversation - it's stalled a number of times
> previously.
>
> On Mon, 14 Nov 202
There are still regular bug reports about monitors (sinks) and sources
disagreeing about the quantization range of the pixel data. In
particular sources sending full range data when the sink expects
limited range. From a user space perspective, this is all hidden in
the kernel. We send full range
On Tue, Nov 8, 2022 at 7:51 PM Simon Ser wrote:
>
> cc'ing Pekka and wayland-devel for userspace devs feedback on the new uAPI.
>
> On Saturday, October 29th, 2022 at 14:08, Dmitry Baryshkov
> wrote:
>
> > On 29/10/2022 01:59, Jessica Zhang wrote:
> > > Add support for COLOR_FILL and
On Fri, Sep 30, 2022 at 5:27 PM Pekka Paalanen wrote:
>
> On Fri, 30 Sep 2022 17:44:17 +0300
> Ville Syrjälä wrote:
>
> > On Fri, Sep 30, 2022 at 04:20:29PM +0200, Sebastian Wick wrote:
> > > On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen
> > > wrote:
>
On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen wrote:
>
> On Thu, 29 Sep 2022 20:06:50 +0200
> Sebastian Wick wrote:
>
> > If it is supposed to be a non-linear luminance curve, which one is it?
> > It would be much clearer if user space can control linear lumina
If it is supposed to be a non-linear luminance curve, which one is it?
It would be much clearer if user space can control linear luminance
and use whatever definition of perceived brightness it wants. The
obvious downside of it is that it requires bits to encode changes that
users can't perceive.
hidden vs.
> >exposed but really we just want to avoid deadlocks. As far as independent
> >studios care that model would do the job perfectly fine, not sure about the
> >big AAA studios but they can e-mail the Proton team if they run into any
> >trouble.
> >
>
On 2021-11-11 16:00, Neal Gompa wrote:
Hey all,
Is there a reason why the development of the surface-suspension
protocol[1] has completely stalled out? It's been in the 30 day
discussion period for a few months now and it's a pretty critical
protocol for games (it's the main blocker for SDL to
On 2020-06-24 13:14, Pekka Paalanen wrote:
On Wed, 24 Jun 2020 19:17:57 +1000
Brad Robinson wrote:
Hi All,
@Guillermo: yep, that's exactly the same problem I'm thinking about.
Hi,
I answered to Guillermo as well further down.
I had an idea that I'm wondering about the rendering
This protocol allows clients to attach a color space and rendering
intent to a wl_surface. It further allows the client to be informed
which color spaces a wl_surface was converted to on the last presented.
Signed-off-by: Sebastian Wick
---
Makefile.am | 1
-backend
Sebastian Wick (1):
unstable: add color management protocol
Makefile.am | 1 +
unstable/color-management/README | 4 +
.../color-management-unstable-v1.xml | 300 ++
3 files changed, 305 insertions(+)
create
On 2019-09-14 19:29, Erwin Burema wrote:
On Tue, 03 Sep 2019 00:15:56 +0200
Sebastian Wick wrote:
> On 2019-07-30 14:53, Drew DeVault wrote:
> > From: Marius Vlad
> >
> > DRM leasing is a feature which allows the DRM master to "lease" a
> > subset
&g
On 2019-07-30 14:53, Drew DeVault wrote:
From: Marius Vlad
DRM leasing is a feature which allows the DRM master to "lease" a
subset
of its DRM resources to another DRM master via drmModeCreateLease,
which
returns a file descriptor for the new DRM master. We use this protocol
to negotiate
On 2019-05-22 05:17, Erwin Burema wrote:
On Tue, 21 May 2019 at 21:07, Sebastian Wick
wrote:
On 2019-05-21 19:32, Erwin Burema wrote:
> Hi,
>
> This is the second version of my color manager calibration protocol,
> biggest change is that I now use a surface this surfa
On 2019-05-21 19:32, Erwin Burema wrote:
Hi,
This is the second version of my color manager calibration protocol,
biggest change is that I now use a surface this surface is set up in a
similar way to the touch screen calibration protocol. Another big
change is more (and hopefully better)
On April 17, 2019 12:38:15 PM GMT+02:00, Erwin Burema
wrote:
>On Wed, 17 Apr 2019 at 11:32, Pekka Paalanen
>wrote:
>>
>> On Tue, 16 Apr 2019 23:42:30 +0200
>> Erwin Burema wrote:
>>
>> > On Tue, 16 Apr 2019 at 17:03, Pekka Paalanen
>wrote:
>> > >
>> > > On Tue, 16 Apr 2019 13:33:02 +
>>
On April 17, 2019 12:38:15 PM GMT+02:00, Erwin Burema
wrote:
>On Wed, 17 Apr 2019 at 11:32, Pekka Paalanen
>wrote:
>>
>> On Tue, 16 Apr 2019 23:42:30 +0200
>> Erwin Burema wrote:
>>
>> > On Tue, 16 Apr 2019 at 17:03, Pekka Paalanen
>wrote:
>> > >
>> > > On Tue, 16 Apr 2019 13:33:02 +
>>
On 2019-04-16 12:45, Pekka Paalanen wrote:
On Sun, 14 Apr 2019 12:57:47 +0200
Erwin Burema wrote:
Without a way to calibrate/profile screens an color management
protocol looses a lot of its value. So to add this missing feature I
wrote the following protocol.
The idea is that the
On 2019-04-15 23:38, Erwin Burema wrote:
On Mon, 15 Apr 2019 at 20:30, Sebastian Wick
wrote:
On 2019-04-14 12:57, Erwin Burema wrote:
> Without a way to calibrate/profile screens an color management
> protocol looses a lot of its value. So to add this missing feature I
> wrote the
On 2019-04-15 21:01, Simon Ser wrote:
On Monday, April 15, 2019 9:30 PM, Sebastian Wick
wrote:
On 2019-04-14 12:57, Erwin Burema wrote:
> Without a way to calibrate/profile screens an color management
> protocol looses a lot of its value. So to add this missing feature I
> wrote the
On 2019-04-14 12:57, Erwin Burema wrote:
Without a way to calibrate/profile screens an color management
protocol looses a lot of its value. So to add this missing feature I
wrote the following protocol.
The idea is that the calibration/profiling SW only sets the RGB
triplet and then the
This protocol allows clients to attach a color space, rendering intent
and HDR information to surfaces and to query outputs about their color
spaces and HDR capabilities.
Signed-off-by: Sebastian Wick
---
Makefile.am | 1 +
unstable/color-management/README
surfaces
* clearify fd requirements (mmap-able 3-channel display ICC profile)
* removed well-known color spaces
* no more server created objects
Thanks for all the feedback so far and as always, more feedback is very welcome.
Sebastian Wick (1):
unstable: add color management protocol
Makefile.am
This protocol allows clients to attach a color space and rendering
intent to a wl_surface. It further allows the client to be informed
which color spaces a wl_surface was converted to on the last presented.
Signed-off-by: Sebastian Wick
---
Makefile.am | 1
hen blending? This hopefully
has a sinmple answer and there probably is some documention which
I just can't find.
There is some more open issues regarding HDR but I'll leave that to
Ankit.
Did I miss anything?
Sebastian Wick (1):
unstable: add color management protocol
Makefile.am
On 2019-03-04 14:45, Pekka Paalanen wrote:
Hi Sebastian and Graeme
On Mon, 04 Mar 2019 13:37:06 +0100
Sebastian Wick wrote:
On 2019-03-04 12:27, Pekka Paalanen wrote:
> On Mon, 4 Mar 2019 19:04:11 +1100
> Graeme Gill wrote:
>
>> Pekka Paalanen wrote:
>>
>> >
On 2019-03-04 12:27, Pekka Paalanen wrote:
On Mon, 4 Mar 2019 19:04:11 +1100
Graeme Gill wrote:
Pekka Paalanen wrote:
> My failing is that I haven't read about what ICC v4 definition actually
> describes, does it characterise content or a device, or is it more
> about defining a
://lists.freedesktop.org/archives/wayland-devel/2017-January/032770.html
[2]
https://gitlab.freedesktop.org/aknautiyal/weston/commit/9d08cc22d6ba2b0c48ac255abc86ba5e217a507c
Also, there are a few queries to understand the flow, please find
below inline:
On 2/14/2019 8:16 AM, Sebastian Wick wrote:
This protocol
On 2019-02-14 05:55, Sharma, Shashank via wayland-devel wrote:
Hello Sebastian,
My comments inline.
Regards
Shashank
-Original Message-
From: wayland-devel
[mailto:wayland-devel-boun...@lists.freedesktop.org] On
Behalf Of Sebastian Wick
Sent: Thursday, February 14, 2019 8:16 AM
Thanks. I don't really know about all the standards so I'll just trust
you on this.
On 2019-02-14 05:47, Chris Murphy wrote:
On Wed, Feb 13, 2019 at 7:55 PM Sebastian Wick
wrote:
+
I suggest ICC spec language. 'ICC-absolute colorimetric'
+
'media-relative colorimetric
-behaving client, the compositor can skip color
conversion entirely.
Feedback and comments appreciated. The protocol summary and description texts
could use more
work (help here would also be appreciated).
Sebastian Wick (1):
unstable: add color management protocol
Makefile.am
This protocol allows clients to attach a color space and rendering
intent to a wl_surface. It further allows the client to be informed
which color spaces a wl_surface was converted to on the last presented.
Signed-off-by: Sebastian Wick
---
Makefile.am | 1
Hey Jasper,
maybe I didn't understand what you're saying but why can't you use the
application authorization mechanism you're talking about in a WSM?
Wouldn't it make sense to make it independent of the compositor?
Am 2014-02-26 23:05, schrieb Jasper St. Pierre:
Hi Martin,
My experience
Am 2014-02-20 20:02, schrieb Martin Peres:
Le 20/02/2014 13:04, Pekka Paalanen a écrit :
snip
It can be done, but with a little more effort than implied here.
Binding to an interace means wl_registry.bind request, and failing
that
is always a fatal error, which terminates the client
Am 2014-01-08 13:02, schrieb Martin Peres:
On 07/01/2014 20:26, Jasper St. Pierre wrote:
Would it be ok for you if the compositor asked the user to agree
for the program to
do the operation? If so, we can guarantee that this is really the
user's intent and
allow the
Am 2014-01-07 15:07, schrieb Martin Peres:
Those are extremely rare cases. Users wanting to do that should agree
they give up
confidentiality and should thus be administrators in order to tell the
compositor that.
Why should those people have worse security then others only because
they want a
Am 2014-01-08 19:53, schrieb Martin Peres:
Le 08/01/2014 17:20, Sebastian Wick a écrit :
Am 2014-01-07 15:07, schrieb Martin Peres:
Those are extremely rare cases. Users wanting to do that should agree
they give up
confidentiality and should thus be administrators in order to tell
Am 2014-01-06 16:05, schrieb Martin Peres:
As I said before, I think trusting applications is taking the problem
the wrong way.
What we want is that a screenshot can only happen when the *user* wants
it.
This is why I think it is the desktop shell's job to launch the
screenshot app when
Am 2014-01-06 19:33, schrieb Martin Peres:
Le 06/01/2014 19:10, Sebastian Wick a écrit :
Am 2014-01-06 16:05, schrieb Martin Peres:
As I said before, I think trusting applications is taking the problem
the wrong way.
What we want is that a screenshot can only happen when the *user*
wants
Am 2014-01-02 23:01, schrieb Maarten Baert:
On 31/12/13 05:02, Sebastian Wick wrote:
I haven't looked at your code yet, but I suspect this detection
mechanism would be seriously flawed, because it doesn't consider the
environment of the application (chroot, LD_PRELOAD, LD_LIBRARY_PATH,
the Qt
I'm currently working on a system which allows specific clients to use
restricted interfaces [1]. This is needed for applications like
screenhooters,
desktop recorders outside of the compositor, accessibility tools and
others.
The current implementation consists of a protocol which can be
Am 2013-12-16 00:52, schrieb Timothée Ravier:
polkit could also be used for the whole process of deciding whether a
screenshot action is allowed or not:
* The compositor would first request authorization for the screenshot
action to polkit;
* polkit would check if the action is legitimate using
Am 2013-12-13 16:12, schrieb Martin Peres:
What prevents other applications from modifying this setting to true
if they want to
spy on applications?
Nothing. But then again if you can write to the ini file you can make
the compositor load any code with the shell setting.
I don't even think my
Am 2013-12-10 00:20, schrieb Bryce W. Harrington:
On Wed, Dec 04, 2013 at 05:38:23PM +0100, Sebastian Wick wrote:
This patch adds a screenshooter section with the restrict-access
setting which is on by default and is the current behavior of weston.
When turning it off, all clients can use
This patch adds a screenshooter section with the restrict-access
setting which is on by default and is the current behavior of weston.
When turning it off, all clients can use the screenshooter protocol.
This makes screen capturing for clients easier because they don't
have to be started by
This patch allows wayland clients to use protocols which give away information
about other clients without being started by the compositor. The reason to
denie access on those protocols is to make sure no information about the
clients is leaked to other clients (=security). I think that we
76 matches
Mail list logo
