Re: wayland-protocols scope and governance

[Christopher James Halse Rogers]

On Wed, Nov 13, 2019 at 16:21, Jonas Ådahl  wrote:

On Tue, Nov 12, 2019 at 08:13:58PM +, Daniel Stone wrote:

 Hi,

 On Thu, 10 Oct 2019 at 16:12, Simon Ser > wrote:
 > This document governs the maintenance of wayland-protocols and 
serves to outline
 > the broader process for standardization of protocol extensions in 
the Wayland

 > ecosystem.

 OK, we're approaching the nine-month anniversary of this 
discussion. I

 think it would be good to merge it before it would've been born.

 We seem to have a unanimous set of agreed-upon initial members with
 defined points of contact (listed below). : EFL, Enlightenment, GTK,
 KWin, Mutter, Qt, Weston, wlroots (also as a proxy for the wider
 phosh/Sway/way-cooler/etc projects using wlroots).

 I think there's a good case to be made for adding Chromium/Exosphere
 to the list, since they are actively involved in protocol 
development

 and a few of their protocols have already found their way upstream.
 Other major users include GStreamer, Kodi, and VLC, but it doesn't
 seem like they participate too much in protocol development, and 
it's

 not clear to me whether or not they'd want to be involved. I don't
 have a strong opinion on whether or not they should be in the
 membership group. Similarly, you could add Firefox and perhaps even
 Mesa to that list; I remember others suggesting GLFW, SDL, maybe 
even

 imgui, mpv?



We at Mir would also be interested; developing and pushing extensions 
has not (yet) hit the top of our TODO list, but we have Thoughts, 
experience, and a place to implement them :).


This can be delayed until we actually have the cycles for serious 
review and proposal, though.


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag

[Scott Anderson]

On 14/11/19 3:08 am, Marius Vlad wrote:

Flag used to tell the compositor that it should avoid touching the
dmabuf buffer and forward it directly to the display controller.

Most likely this flag can be used together with the content-protection
protocol. It assures the client that the compositor will never handle
the buffer over to the GPU but instead it will forward it straight to
the display controller.

While content-protection protocol should be sufficient to restrict the
content on certain displays, on certain hardware platforms the GPU is
not a secure-path link in the secure-content-path chain, and as such,
this flag would be necessary to avoid passing the dmabuf buffer
over to the GPU altogether. GPUs reading the dmabuf residing in a
specially designed memory zone would be seen as an illegal memory access.

Other example include video players which might need this flag passed
down to avoid doing any composition, thus having an improvement of
bandwidth usage and performance. Set-up boxes with dedicated video
players could use this facility alongside the Pixman renderer, is
another potential example of why this flag would be useful.

Bumps zwp_linux_dmabuf_v1 and zwp_linux_buffer_params_v1 to version 4.

Signed-off-by: Marius Vlad 

---
This patch initially started as fork at
https://gitlab.freedesktop.org/marius.vlad0/wayland-protocols/merge_requests/3

This flag was used to be called 'no_gpu_import' but 'direct_display'
should better reflect its name and purpose.

Lastly, a WIP for the implementation of this flag for weston is at
https://gitlab.freedesktop.org/wayland/weston/merge_requests/298, which
should follow up closely.
---
  .../linux-dmabuf/linux-dmabuf-unstable-v1.xml | 15 ---
  1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml 
b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
index b43e81c..5b4b1e6 100644
--- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
+++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
@@ -2,7 +2,7 @@
  
  


-Copyright © 2014, 2015 Collabora, Ltd.
+Copyright © 2014, 2015, 2019 Collabora, Ltd.
  
  Permission is hereby granted, free of charge, to any person obtaining a

  copy of this software and associated documentation files (the "Software"),
@@ -24,7 +24,7 @@
  DEALINGS IN THE SOFTWARE.

  
-  

+  
  
Following the interfaces from:

https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
@@ -149,7 +149,7 @@
  

  
-  

+  
  
This temporary object is a collection of dmabufs and other
parameters that together form a single logical buffer. The temporary
@@ -229,6 +229,7 @@



+  
  
  
  

@@ -254,6 +255,14 @@
  'bottom_first' is specified. It is undefined whether 'bottom_first'
  is ignored if 'interlaced' is not set.
  
+Flag 'direct_display' tells the compositor not to import it to the GPU

+in order to bypass it entirely, such that the buffer will be directly
+scanned-out by the display controller. If HW is not capable/or there
+aren't any available resources to directly scan-out the buffer, a
+placeholder should be installed in-place by the compositor. The
+compositor may perform checks on the dmabuf and refuse to create a
+wl_buffer if the dmabuf seems unusable for being used directly.
+
  This protocol does not convey any information about field rate,
  duration, or timing, other than the relative ordering between the
  two fields in one buffer. A compositor may have to estimate the


Has any thought been into how this would need to interact with 
dmabuf-hints[1]? Without that, it seems like it would be a total 
crapshoot for clients to try and use this flag, since they have no idea 
what formats+modifers the display controller supports, and instead only 
has the list that the GPU supports.
dmabuf-hints would also need to explicitly state that a tranche of 
formats+modifiers are supported for this flag.


I'm also worried about compositors that are capable of taking 
screenshots. This flag implies that it's "dangerous" to ever touch the 
buffer for any purpose. But then it sounds like you're encouraging video 
players to use this, which is only going to break basic functionality. I 
suspect than the only sensible thing for a screenshot-capable compositor 
to do is to simply reject all uses of this flag, making it useless 
outside of highly-integrated environments.


dmabuf-hints seems like a much better way to achieve the same effect of 
efficiency, instead of the client trying to dictate what the compositor 
should do. If this flag is added, I would want a stern warning to not 
carelessly use it unless the compositor literally can't access the 
buffer from the GPU.


Scott

[1]: https://patchwork.freedesktop.org/patch/263061/

Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag

[Drew DeVault]

Can you elaborate more on non-DRM use-cases? Most compositors are
already going to use direct scan-out as much as possible, and can make
reasonably well informed choices about when to do so. For example,
fullscreen surfaces will generally always be scanned out if possible.
More interesting approaches could include intelligently picking the most
frequently updated buffers to be placed on planes, or the most optimal
arrangement for a given combination of pixel formats.

In addition, the implication that the compositor shouldn't do things
like letting the user take screenshots when views like this are being
shown is a chilling effect on non-DRM use-cases, in which taking a
screenshot is a perfectly reasonable thing to do.

I don't really like the idea of DRM-enabling features being added to
linux-dmabuf with this level of justification for non-DRM use-cases.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wayland-protocols scope and governance

[Jonas Ådahl]

On Tue, Nov 12, 2019 at 08:13:58PM +, Daniel Stone wrote:
> Hi,
> 
> On Thu, 10 Oct 2019 at 16:12, Simon Ser  wrote:
> > This document governs the maintenance of wayland-protocols and serves to 
> > outline
> > the broader process for standardization of protocol extensions in the 
> > Wayland
> > ecosystem.
> 
> OK, we're approaching the nine-month anniversary of this discussion. I
> think it would be good to merge it before it would've been born.
> 
> We seem to have a unanimous set of agreed-upon initial members with
> defined points of contact (listed below). : EFL, Enlightenment, GTK,
> KWin, Mutter, Qt, Weston, wlroots (also as a proxy for the wider
> phosh/Sway/way-cooler/etc projects using wlroots).
> 
> I think there's a good case to be made for adding Chromium/Exosphere
> to the list, since they are actively involved in protocol development
> and a few of their protocols have already found their way upstream.
> Other major users include GStreamer, Kodi, and VLC, but it doesn't
> seem like they participate too much in protocol development, and it's
> not clear to me whether or not they'd want to be involved. I don't
> have a strong opinion on whether or not they should be in the
> membership group. Similarly, you could add Firefox and perhaps even
> Mesa to that list; I remember others suggesting GLFW, SDL, maybe even
> imgui, mpv?
> 
> I would suggest that we push the patch with the following initial
> member projects and their points of contact defined, and finally
> enable MRs:
>   * EFL/Enlightenment: Mike Blumenkrantz @zmike
>   * GTK/Mutter: Jonas Ådahl @jadahl

I'd like to add Carlos Garnacho @garnacho here as well as an additional
point of contact.


Jonas

>   * KWin: Roman Gilg @romangg
>   * Qt: Johan Helsing @johanhelsing
>   * Weston: Daniel Stone @daniels, Pekka Paalanen @pq
>   * wlroots (& its users): Drew DeVault @ddevault, Simon Ser @emersion
> 
> If we find interest from other projects, we can use their membership
> applications as a first test of our governance procedures.
> 
> Cheers,
> Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] unstable/linux-dmabuf: Add 'direct_display' flag

[Marius Vlad]

Flag used to tell the compositor that it should avoid touching the
dmabuf buffer and forward it directly to the display controller.

Most likely this flag can be used together with the content-protection
protocol. It assures the client that the compositor will never handle
the buffer over to the GPU but instead it will forward it straight to
the display controller.

While content-protection protocol should be sufficient to restrict the
content on certain displays, on certain hardware platforms the GPU is
not a secure-path link in the secure-content-path chain, and as such,
this flag would be necessary to avoid passing the dmabuf buffer
over to the GPU altogether. GPUs reading the dmabuf residing in a
specially designed memory zone would be seen as an illegal memory access.

Other example include video players which might need this flag passed
down to avoid doing any composition, thus having an improvement of
bandwidth usage and performance. Set-up boxes with dedicated video
players could use this facility alongside the Pixman renderer, is
another potential example of why this flag would be useful.

Bumps zwp_linux_dmabuf_v1 and zwp_linux_buffer_params_v1 to version 4.

Signed-off-by: Marius Vlad 

---
This patch initially started as fork at
https://gitlab.freedesktop.org/marius.vlad0/wayland-protocols/merge_requests/3

This flag was used to be called 'no_gpu_import' but 'direct_display'
should better reflect its name and purpose.

Lastly, a WIP for the implementation of this flag for weston is at
https://gitlab.freedesktop.org/wayland/weston/merge_requests/298, which
should follow up closely.
---
 .../linux-dmabuf/linux-dmabuf-unstable-v1.xml | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml 
b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
index b43e81c..5b4b1e6 100644
--- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
+++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
@@ -2,7 +2,7 @@
 
 
   
-Copyright © 2014, 2015 Collabora, Ltd.
+Copyright © 2014, 2015, 2019 Collabora, Ltd.
 
 Permission is hereby granted, free of charge, to any person obtaining a
 copy of this software and associated documentation files (the "Software"),
@@ -24,7 +24,7 @@
 DEALINGS IN THE SOFTWARE.
   
 
-  
+  
 
   Following the interfaces from:
   
https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
@@ -149,7 +149,7 @@
 
   
 
-  
+  
 
   This temporary object is a collection of dmabufs and other
   parameters that together form a single logical buffer. The temporary
@@ -229,6 +229,7 @@
   
   
   
+  
 
 
 
@@ -254,6 +255,14 @@
 'bottom_first' is specified. It is undefined whether 'bottom_first'
 is ignored if 'interlaced' is not set.
 
+Flag 'direct_display' tells the compositor not to import it to the GPU
+in order to bypass it entirely, such that the buffer will be directly
+scanned-out by the display controller. If HW is not capable/or there
+aren't any available resources to directly scan-out the buffer, a
+placeholder should be installed in-place by the compositor. The
+compositor may perform checks on the dmabuf and refuse to create a
+wl_buffer if the dmabuf seems unusable for being used directly.
+
 This protocol does not convey any information about field rate,
 duration, or timing, other than the relative ordering between the
 two fields in one buffer. A compositor may have to estimate the
-- 
2.24.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Getting a compositor display name?

[Jonas Ådahl]

On Wed, Nov 13, 2019 at 11:00:05AM +, Simon Ser wrote:
> On Wednesday, November 13, 2019 11:11 AM, Pekka Paalanen 
>  wrote:
> 
> > However, my fear with adding such information is that then clients
> > might start adding conditional code paths based on the Wayland
> > compositor name or version, which is an incorrect approach. Client
> > behaviour that depends on the particular compositor must be keyed by
> > the available global Wayland interfaces and their versions, not by the
> > compositor identity.
> >
> > OTOH, Wayland is a few years old by now and developers should have
> > learnt better, so maybe that fear is no longer relevant.
> 
> I share this fear as well. IMHO `ps` is good enough. You could
> also use something like `lsof /dev/dri/card0` to get the DRM
> master.

There is also $XDG_CURRENT_DESKTOP specified in the
desktop-entry-spec[0].


Jonas

[0] 
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s06.html

> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Getting a compositor display name?

[Simon Ser]

On Wednesday, November 13, 2019 12:25 AM, Drew DeVault  wrote:

> I don't know of a way to do this today, but I think it would make for a
> reasonable addition to wl_display.

Additions cannot be made to wl_display, because it's not versioned.
Only globals retrieved through wl_registry.bind and their children are
versioned.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Getting a compositor display name?

[Simon Ser]

On Wednesday, November 13, 2019 11:11 AM, Pekka Paalanen  
wrote:

> However, my fear with adding such information is that then clients
> might start adding conditional code paths based on the Wayland
> compositor name or version, which is an incorrect approach. Client
> behaviour that depends on the particular compositor must be keyed by
> the available global Wayland interfaces and their versions, not by the
> compositor identity.
>
> OTOH, Wayland is a few years old by now and developers should have
> learnt better, so maybe that fear is no longer relevant.

I share this fear as well. IMHO `ps` is good enough. You could
also use something like `lsof /dev/dri/card0` to get the DRM
master.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Getting a compositor display name?

[Pekka Paalanen]

On Tue, 12 Nov 2019 12:59:40 -0700
"Ronan Pigott"  wrote:

> Hello,
> 
> So EWMH has this thing "_NET_SUPPORTING_WM_CHECK":
> 
> https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317670464
> 
> where the WM maintains a special window with some atoms for
> introspecting the running wm, including a suitable display name in
> _NET_WM_NAME, like "i3".
> 
> I'm wondering if there is anything similar in wayland for compositors to
> export a suitable display name such as "sway" or "myfirstcompositor"?
> 
> I thought that maybe there'd be a such a request in wl_compositor, but
> it doesn't appear so. Am I looking in the right place?
> 
> I think it could be useful for system-info type applications, but I
> don't know of any that support a more sophisticated method of getting a
> compositors display name than grepping ps.

Hi,

such thing has not been added, basically because no-one has provided a
convincing use case for it. System-info might be a convincing use case.

However, my fear with adding such information is that then clients
might start adding conditional code paths based on the Wayland
compositor name or version, which is an incorrect approach. Client
behaviour that depends on the particular compositor must be keyed by
the available global Wayland interfaces and their versions, not by the
compositor identity.

OTOH, Wayland is a few years old by now and developers should have
learnt better, so maybe that fear is no longer relevant.


Thanks,
pq


pgp1ahufsL8PH.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user

[Guido Günther]

Hi Carlos,
On Fri, Oct 18, 2019 at 01:08:36AM +0200, Carlos Garnacho wrote:
> Hi Pekka,
> 
> Thank you for your comments!
> 
> On Wed, Oct 16, 2019 at 11:31 AM Pekka Paalanen  wrote:
> 
> > On Wed, 16 Oct 2019 10:54:08 +0200
> > Olivier Fourdan  wrote:
> >
> > > Hey Carlos,
> > >
> > > On Wed, Oct 16, 2019 at 10:43 AM Carlos Garnacho 
> > wrote:
> > > >
> > > > This protocol takes over 3 different, but interrelated aspects of
> > > > DE/client interaction:
> > > > - Startup notification: presenting feedback about applications
> > > >   being launched, either through the compositor or another client
> > > > - Focus stealing prevention: letting the compositor figure out
> > > >   whether immediately switching focus to a surface makes sense.
> > > > - Window raising/activation: allowing existing clients to request
> > > >   focus in a controlled manner.
> > > >
> > > > Signed-off-by: Carlos Garnacho 
> >
> > Hi Carlos,
> >
> > this seems well written and a good idea to me. More comments inline.
> >
> > > > ---
> > > >  Makefile.am   |   1 +
> > > >  unstable/presentation/README  |   5 +
> > > >  .../presentation/presentation-unstable-v1.xml | 175 ++
> > > >  3 files changed, 181 insertions(+)
> > > >  create mode 100644 unstable/presentation/README
> > > >  create mode 100644 unstable/presentation/presentation-unstable-v1.xml
> > > >
> > > > diff --git a/Makefile.am b/Makefile.am
> > > > index d2c89a8..bd0e52d 100644
> > > > --- a/Makefile.am
> > > > +++ b/Makefile.am
> > > > @@ -24,6 +24,7 @@ unstable_protocols =
> >   \
> > > > unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
> > > >
> >  
> > unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
> > \
> > > > unstable/primary-selection/primary-selection-unstable-v1.xml
> >   \
> > > > +   unstable/presentation/presentation-unstable-v1.xml
> >   \
> > > > $(NULL)
> > > >
> > > >  stable_protocols =
> >  \
> > > > diff --git a/unstable/presentation/README
> > b/unstable/presentation/README
> > > > new file mode 100644
> > > > index 000..5a77e97
> > > > --- /dev/null
> > > > +++ b/unstable/presentation/README
> > > > @@ -0,0 +1,5 @@
> > > > +Presentation protocol
> > > > +
> > > > +Maintainers:
> > > > +Carlos Garnacho 
> > > > +
> > > > diff --git a/unstable/presentation/presentation-unstable-v1.xml
> > b/unstable/presentation/presentation-unstable-v1.xml
> > > > new file mode 100644
> > > > index 000..84bf961
> > > > --- /dev/null
> > > > +++ b/unstable/presentation/presentation-unstable-v1.xml
> > > > @@ -0,0 +1,175 @@
> > > > +
> > > > +
> > > > +  
> > > > +Copyright 2018-2019 © Red Hat, Inc.
> > > > +
> > > > +Permission is hereby granted, free of charge, to any person
> > > > +obtaining a copy of this software and associated documentation
> > files
> > > > +(the "Software"), to deal in the Software without restriction,
> > > > +including without limitation the rights to use, copy, modify,
> > merge,
> > > > +publish, distribute, sublicense, and/or sell copies of the
> > Software,
> > > > +and to permit persons to whom the Software is furnished to do so,
> > > > +subject to the following conditions:
> > > > +
> > > > +The above copyright notice and this permission notice (including
> > the
> > > > +next paragraph) shall be included in all copies or substantial
> > > > +portions of the Software.
> > > > +
> > > > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > > > +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > > > +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > > > +NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > HOLDERS
> > > > +BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> > > > +ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> > > > +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> > > > +SOFTWARE.
> > > > +  
> > > > +
> > > > +  
> > > > +This description provides a high-level overview of the interplay
> > between
> > > > +the interfaces defined this protocol. For details, see the
> > protocol
> > > > +specification.
> >
> > This is the protocol specification, the whole file.
> >
> 
> Uh, got that bit of the wording from zwp_tablet, removed locally :).
> 
> 
> >
> > > > +
> > > > +The finality of the protocol is defining a compositor context for
> > > > +surfaces requesting to be presented. Presentation requests are
> > usually
> > > > +initiated by an existing surface, and acknowledged by a surface
> > being
> > > > +mapped. By having both ends talk with the compositor through this
> > protocol,
> > > > +the compositor has the information to implement different
> > commonplace
> > > > +policies:
> > > > +
> > > > +-