Re: libweston as a DRM lease lessee

[Scott Anderson]

On 1/02/21 10:19 pm, Damian Hobson-Garcia wrote:

Hi all,

I am working on adding DRM lease support to a libweston based compositor.
The compositor will be a client (lessee) that will display output to a 
DRM lease that
is created by another (lessor) process, so this is kind of the opposite 
direction to the DRM lease patches

that were submitted a while back [1].

The motivation is to be able to run multiple instances of weston w/ DRM 
backend, where each instance
has direct access to a subset of the DRM connectors.  Each instance 
could, for example, run in a separate container,

with minimal host interaction.

In this configuration the DRM lease would be received from a UNIX domain 
socket connection to the lessor,
so would not discoverable via udev, in the same way that DRM device 
nodes normally are.


I think that I would need to make changes to the compositor-drm, but if 
possible,
I'd like to make those changes generic enough to be useful upstream as 
well, so I was hoping to get some feedback before possibly heading down 
a wrong path.


 From what I can tell, I need to:

1. Get the DRM lease file descriptor, given an identifier (In my DRM 
lease case this is a name that maps to a socket path)
2. Get a udev_device struct for the device corresponding to the above fd 
(via the major:minor numbers)


I think that #1 can be implemented in either via the launcher API (a new 
launcher type?) or by adding an option for
the compositor to provide the fd, but #2 seems like it should be in 
compositor-drm, right?


Are there other use cases that would benefit from extending the launcher 
/ compostior APIs in this way?
or the udev device handle creation? Are there any plans/interest for 
running the DRM backend from inside

a container?

Thank you,
Damian

[1] 
https://lists.freedesktop.org/archives/wayland-devel/2018-February/037162.html 


This doesn't answer any of your questions about Weston specifically, but 
an alternative approach would be to add drm-lease support to logind. It 
already has its own concept of groups of devices (seats), so it would 
also solve any issues regarding who gets what input devices, and the 
solution wouldn't be specific to weston. Any logind-capable display 
server (i.e. all of them, including Xorg) would be able to use this, 
without requiring any modification.


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

Re: Best practices for client side buffer management

[Scott Anderson]

On 19/06/20 3:24 pm, Brad Robinson wrote:

Hi All,

I'm fairly new to Wayland and Linux GUI programming in general, but 
doing some experiments to figure out how to integrate it into my custom 
UI toolkit library and have a couple of questions about client side 
buffer management.


Firstly, this is how I'm allocating the backing memory for client side 
buffer pools.  This is C# p-invoking to libc, and basically it's using 
mkstemp() to get a temp file, ftruncate() to set its length, mmap() to 
map it and then unlink() once mapped so temp files aren't left behind.  
Any issues with this approach?


             // Get temp file
             var sb = new 
StringBuilder(System.IO.Path.Join(System.IO.Path.GetTempPath(), 
"mmXX"));

             int fd = mkstemp(sb);
             ftruncate(fd, (ulong)capacity);

             // Map it
             var addr = mmap(IntPtr.Zero, (ulong)capacity, Prot.Read | 
Prot.Write, Map.Shared, fd, 0);


             // Unlink it (so temp files not left behind)
             unlink(sb.ToString());


An alternative implementation would be to use memfd_create, but that is 
Linux-specific. Otherwise what you have there looks correct to me.


Secondly I'm wondering about practical strategies for managing client 
side buffers.  The toolkit in question basically needs arbitrarily sized 
buffers to render whatever size the window happens to be.  Seems like to 
use a buffer pool for this would require some sort of heap manager to 
manage what's in each pool.  I'm wondering if there's any 
recommendations or best practices for how to deal with this.  eg: create 
one big pool and explicitly manage what's in there as a heap, use lots 
of little pools with one buffer in each, a combination of both, 
something else?


It would be possible to deal use heaps, but in practice most clients 
will just use a dedicated shared memory object (wl_shm_pool) for each 
buffer, which works perfectly fine. Shared memory clients usually only 
need 2 buffers, but it's a good idea to write your program in a way so 
that it can use up to 4, allocating the extra as needed, and freeing 
them when you're done.


Finally, the toolkit already maintains an off-screen buffer with the 
window's current contents rendered into it.  I'll probably replace that 
with a Wayland buffer, but wondering about partial updates.  eg: if the 
client only needs to redraw a part of the window what's the correct 
process to update just that part with Wayland.  Can I just update the 
existing buffer and prompt Wayland to just redraw that part?


There are requests in the protocol specifically for telling the 
compositor about partial updates, which are wl_surface.damage and 
wl_surface.damage_buffer. Using wl_surface.damage_buffer is generally a 
better idea.


Here is a blog post that goes over some more general details: 
https://emersion.fr/blog/2019/intro-to-damage-tracking/
It's slightly more slanted to talking about the compositor side of 
things, but I still think could be helpful.


Scott


Any advice appreciated...

Brad


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

Re: Best practices for saving and restoring window layout

[Scott Anderson]

On 5/06/20 10:09 pm, Pekka Paalanen wrote:

On Fri, 5 Jun 2020 02:06:00 +1000
Brad Robinson  wrote:


Hi All,

First post here...

I'm looking into porting an existing UI library to Gtk+ and I'm struggling
to solve a couple of problems related to window positioning when using
Wayland as the backend.

I've read through the posts on this list's archive about window positioning
and it's clear that a global coordinate system isn't something that Wayland
supports - fair enough and I understand the reasons why.

However, I'm wondering what the recommendations are for applications with
complicated user-controllable layouts that need to be persisted not only
across application runs, but also between documents and across application
modes.

For example:

* my application is a music app where the user might have many plugin
windows carefully positioned across multiple monitors.
* each document file has a different set of plugins loaded and those plugin
windows need to be restored to their previous location.
* the app can be in "Live" mode or "Edit" mode and switching between modes
saves and restores the plugin window locations for each mode.

How should such an app be handled under Wayland?

Note: the app doesn't need to be able to explicitly position windows. It
just needs a way to capture and restore a window's position.  An opaque
string or data structure that the app can save and use to later reposition
a window back to that same place would be perfect.  It would need to be
client persistable though - eg: giving a window an id that the window
manager can use to store previous geometry probably wouldn't suffice.


Hi,

I believe the above is the consensus: ask the server to give you a
token that records the current state, including position, of the
window. You store the token, or any number of tokens. When you want to
recall old state, you pass the token back to the compositor.

The problem is that I don't remember seeing an extension spec for this.
It has been talked about, sure, but at least wayland-protocols does not
seem to have anything for it.


Thanks,
pq



A protocol was that was proposed relatively recently.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18


I'm about to refactor a big part of the code that handles this and now is
the time I can make conceptual changes that could better cater for Wayland
as a back end. I've seen comments in the archive about how a global
coordinate system isn't necessary and that issues related to a lack of one
can be better solved by other means but I'm not sure what those other means
are and I'm struggling to see a way forward with this.

Any thoughts, suggestions, recommendations greatly appreciated.

Brad



___
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: Protocol backwards compatibility requirements?

[Scott Anderson]

On 21/04/20 12:57 pm, Christopher James Halse Rogers wrote:

On Mon, Apr 20, 2020 at 15:05, Pekka Paalanen  wrote:

On Thu, 16 Apr 2020 17:47:56 +1000
Christopher James Halse Rogers  wrote:


 On Wed, Apr 15, 2020 at 14:27, Simon Ser  wrote:
 > Hi,
 >
 > On Monday, April 13, 2020 1:59 AM, Peter Hutterer
 >  wrote:
 >>  Hi all,
 >>
 >>  This is request for comments on the exact requirements for protocol
 >>  backwards compatibility for clients binding to new versions of an
 >> interface.
 >>  Reason for this are the high-resolution wheel scrolling patches:
 >> https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72
 >>
 >>  Specifically, the question is: do we **change** protocol 
elements or
 >>  behaviour as the interface versions increase? A few random 
examples:

 >
 > What we can't do is:
 >
 > - Change existing messages' signature
 > - Completely remove a message


Indeed.



 It should be relatively easy to modify wayland-scanner to support both
 of these things, *if* we decide that it's a reasonable thing to do.
 (You'd do something like add support for  and the like)


How would that work, given the version is negotiated at runtime?

The message signature structs are now ABI as well, and we have no room
for alternate signatures, do we?


Sure we do. Internally we can just give them different names, with 
different contents, and switch based on the version requested at runtime.


 From the client API side it's more difficult (at least for requests), 
because we can't remove any symbols - we *can* make it a client error 
with a good error message, though.


On the events side it's easier, as we can add a wl_foo_listener_v5 
struct and wl_foo_add_listener_v5.


This does add a new sharp edge to the raw wl_proxy_* interface, but 
client code isn't expected to be using that and this doesn't seem 
particularly hard for language bindings to adapt to.


There is more than just libwayland and wayland-scanner for C that needs 
to be taken into consideration here. Adding any of these kinds of 
changes requires that _everybody_ updates to handle this, including 
things like the Rust Wayland binding/reimplementation and Qt's own 
Wayland scanner.


I really don't think it's worth the effort.

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

Re: linux-dmabuf and eglBindWaylandDisplayWl

[Scott Anderson]

On 10/04/20 10:34 am, Matt Hoosier wrote:
On Thu, Apr 9, 2020 at 2:51 PM Simon Ser > wrote:


On Thursday, April 9, 2020 9:41 PM, Matt Hoosier
mailto:matt.hoos...@gmail.com>> wrote:

 > If I remember correctly, I've read various messages on the list
here saying that eventually it would be preferred for EGL
implementations would just use linux-dmabuf as their buffer factory.
That would mean that EGL backends would now also want to register a
zwp_linux_dmabuf_v1 global.

Mesa already binds to zwp_linux_dmabuf_v1 and uses it if possible.

 > I'm wondering how the logistics on that would work. Normally, you
can't register two globals having the same name in the compositor.
Does this lead to a conflict between the EGL implementation's
ability to enumerate a linux-dmabuf API for its own use, and the
linux-dmabuf API that the overall compositor might offer?

Just to be clear: we're talking about the client side right?

It's fine to bind twice to the same global. This creates two
independent objects.


No, I mean from the standpoint of a compositor implementer.

-Matt


Mesa does not implement zwp_linux_dmabuf_v1 on the compositor side. It's 
the compositor's job to do that, and they can use EGL or Vulkan 
extensions [1] to import them for rendering with, or otherwise use them 
with anything capable of consuming dmabufs.


eglBindWaylandDisplayWL still only handles wl_drm.

- Scott

[1]:
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VK_EXT_external_memory_dma_buf
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Chrome Remote Desktop and Wayland

[Scott Anderson]

On 8/04/20 4:04 pm, Erik Jensen wrote:

Hello,

I'm currently looking into how best to continue supporting Linux for
Chrome Remote Desktop given the current direction of development for
graphical sessions on Linux, and would like some community feedback as
to the best path forward.

Chrome Remote Desktop currently works on Linux by spinning up its own
Xvfb server and running a graphical session in that. However, as more
and more parts of the stack assume that a user will have at most one
graphical session, this is leading to more breakage more often. E.g.,
several distros have switched DBUS to using a single session bus per
user, which only supports one graphical session, and recent versions
of GDM will fail to log a user in locally at all if a Chrome Remote
Desktop session is running due to
https://gitlab.gnome.org/GNOME/gdm/-/issues/580. Given that Chrome
Remote Desktop starts at boot, the latter means that even just setting
it up and rebooting is enough to break local logins for the user,
which is obviously less than ideal.


This point about Gnome breaking multiple sessions has been a pain point 
for us (sway/wlroots), and why we typically push back against D-Bus 
solutions to Wayland problems, at least on the session bus. Wayland 
itself works perfectly fine with multiple sessions, and is something we 
want to preserve.


It may be possible to create individual session buses for each login 
session, but I don't know how this works in practice and I don't think 
anybody currently does it.



We have the following constraints for our use case:
  * Chrome Remote Desktop must be usable after boot without the user
needing to log in locally, first.
  * It must be possible to "curtain" the session, meaning that, when a
user is connected, their session is not displayed on the local
monitor. (Imagine a user working from home and connecting to their
workstation in a shared office space.)
  * When the user disconnects, the session must be locked in some
manner so a person at the local machine can't take over the session
without authentication.
  * It's okay to require X11 today, but there should be a reasonable
path forward as more distributions switch to Wayland.
  * It would be nice, though not required, if the user could access the
same session remotely as they see locally. (Though, as noted above,
having two separate sessions seems to be explicitly not supported by
many new developments, so this may be effectively required.)
  * It would be nice, though not required, if the session could be
resized to fit the client display when the user is connected remotely.
  * It would be nice, though not required, if apps in the session could
have access to graphics acceleration when accessed remotely.

Possible idea brainstorming:
I'm hoping for feedback for the feasibility of these, given I don't
have a lot of experience with Wayland or the modern graphical session
architecture. All of these have gaps which make them likely not usable
*right now*, so the question is probably which approach would be the
most likely to be accepted by the relevant projects, and potentially
which would be the quickest to design and get working.

There's likely other possibilities that I haven't thought of.

~Use a nesting compositor~
This involves having an outer compositor that we control that renders
to the local screen when used locally, and handles curtaining,
offscreen rendering, video capture, and input injection when used
remotely. It would run X11 sessions via a fullscreen XWayland in
rooted (not rootless) mode, and a Wayland session in nested mode.

This would need some integration with the display manager so that
logging in locally would bring the session to the local display and
disconnect the remote connection. Similarly, connecting remotely would
need to return to the login screen and switch to off screen rendering.
I don't know enough to know whether this is feasible, or whether the
necessary GPU resource sharing is currently possible.

Additionally, nesting Wayland sessions requires support from
sub-compositor for nesting, which appears not to be ubiquitous, and
generally requires a special command-line flag. This means support for
Wayland sessions would have to be special cased if supported at all.
That said, sticking to nested X11 sessions only would probably be
tenable for now, assuming there is a future path forward for nested
Wayland sessions in the future, and assuming the technical details of
interacting with the local login manager could be figured out.

~Integrate with a system compositor~
I've seen some discussion of having a system compositor that runs from
the boot splash to shutdown, and manages the display of each session
(and even the console). This seems like an ideal place to install
hooks that a tool such as Chrome Remote Desktop or an RDP server could
use to provide remote access to the machine, including curtaining.
This has the potential for a very integrated experience like RDP
sessions on Windows.

T

Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1

[Scott Anderson]

On 4/02/20 10:16 pm, Pekka Paalanen wrote:

On Mon, 3 Feb 2020 23:26:55 -0600
Jason Ekstrand  wrote:


Sorry to drag up ancient threads, but what's the status of this?  I see
rumors that it's in Weston.  Is it stable?  Is it implemented anywhere
else?  It'd be great, for the sake of Vulkan, if we could get this stable
and everywhere.

--Jason

On Mon, Dec 17, 2018 at 11:25 AM Tomek Bury  wrote:


Thanks! That looks better than my patch.

On Mon, 17 Dec 2018 at 15:37, Alexandros Frantzis <
alexandros.frant...@collabora.com> wrote:



[1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/32


Hi,

the above MR is merged, the code is in Weston and is supposed to work.
I have a vague recollection that the implementation might not be
"totally optimal" in all cases, meaning that it may choose to deliver
`immediate_release` rather than `fenced_release` even if the latter was
theoretically possible.

I don't know about other compositors, we don't have the extension
information site up yet.

The protocol itself is in unstable:
https://gitlab.freedesktop.org/wayland/wayland-protocols/tree/master/unstable/linux-explicit-synchronization

This does not mean that we can break it at will. The committed protocol
is stable in the sense that we cannot break it anymoe, but unstable in
the sense that zwp_linux_explicit_synchronization_v1 is not the final
name.

IOW, it is safe to look for Wayland extension
zwp_linux_explicit_synchronization_v1 and use it. If we need changes
that cannot be made backward-compatible, a new extension with name
zwp_linux_explicit_synchronization_v2 will be created. Once we are sure
we do not need backward-incompatible changes anymore, the extension
will be renamed to wp_linux_explicit_synchronization which will be the
final change that all servers and clients should very much implement.

Both compositors and clients are encouraged to implement all major
versions of the extension if possible for maximum compatibility.

TL;DR:

If you find a Wayland compositor advertising
zwp_linux_explicit_synchronization_v1 via wl_registry, feel free to use
it and expect it to not break from under you.


Thanks,
pq


Just as a follow up, I plan to add support in wlroots. I want to go with 
a much more elaborate implementation than Weston's one, which changes 
some of our fundamental assumptions about surface state, and requires a 
lot of changes, which is why it has been slow to get implemented.


I have a description about it here [1] that other compositors might be 
interested in.


Scott

[1]: https://github.com/swaywm/wlroots/issues/894#issuecomment-465096345
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wl_surface/wl_subsurface composition

[Scott Anderson]

On 11/12/19 8:46 pm, Martin Stransky wrote:

Hi guys,

while solving a Firefox Wayland bug [1] I wonder if there's any 
composition between a surface and a subsurface on compositor side 
(namely mutter) when the subsurface area is subset of the surface and 
the surface is set as opaque.


Both surface and subsurface are using ARGB pixel format.

Thanks,
Martin

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1591489#c9


The two surfaces should be blended together correctly, regardless if 
either of them have any opaque regions. They're no different to regular 
surfaces in this regard.


However, if you mark a region as opaque, it really needs to be opaque in 
the buffer, i.e. alpha is 1.0 or the format doesn't have any alpha. It's 
not something to say "please don't alpha blend this region" to the 
compositor.


The opaque region is mainly just an optimization for the compositor, so 
it knows it won't need to draw surfaces behind yours.


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

Re: libwayland surface coordinate question

[Scott Anderson]

On 22/11/19 2:40 pm, Ken C wrote:

I am just starting out with libweston and have a beginner question
regarding surface/view coordinates. I am looking to implement
something along the lines of issue #277 on gitlab[1], "New shell
plugin for single-app usecases". I have swapped out
weston-desktop-shell with a toy client just to get grounded, and am
using the X11 and RDP backends for testing. I can see where the
initial client position gets set up in
weston_view_set_initial_position() in shell.c. However I am finding
that even if weston_view_set_position() is called with {0,0}, the
resulting window on output is offset by ~32ish pixels. I've also
started from westiny[2], which is about as simple as it gets, but find
the same mysterious (to me) offset. I can set the initial position to
a negative x,y value in weston_view_set_initial_position(), forcing
the window into the corner. Maximizing the toy client interestingly
enough fills the screen (a single head).

I've looked high and low for where that ~32 pixel offset comes from,
but have not had luck. While I look some more maybe someone has a
quick pointer. If I can set a breakpoint I'm sure it will become
obvious.

[1] https://gitlab.freedesktop.org/wayland/weston/issues/277
[2] https://gitlab.freedesktop.org/daniels/westiny/blob/master/westiny.c


Hi,

It may be because of the client's "window geometry"[1]. There may be 
some drop shadows or otherwise transparent border around the client's 
contents, and the window geometry will tell you which part of the 
surface you should consider to be the client's contents.


If you'll excuse the terrible ASCII drawing:

(0,0)
+---+ <--- Surface
| (32,32)   |
|  +-+<--- Geometry
|  | |# |
|  | |# |
|  | |# |
|  +-+# |
|   |
+---+

When a client is maximized or fullscreened, they're asked to not draw 
these kinds of things, and should fill the entire surface with their 
window's contents.


weston_desktop_surface_get_geometry is the function you call to get this 
information.


Scott


[1]: 
https://gitlab.freedesktop.org/wayland/wayland-protocols/blob/master/stable/xdg-shell/xdg-shell.xml#L445-476


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

Re: Do I need wl_frame_callback at all?

[Scott Anderson]

On 21/11/19 12:15 am, Martin Stransky wrote:

On 11/20/19 12:12 PM, Scott Anderson wrote:

On 21/11/19 12:03 am, Martin Stransky wrote:

Hi guys,

what happens and is it a correct behavior when application does not 
use wl_frame_callback at all and just do the drawing 
(wl_surface_commit) whatever it has a data do draw?


I know it may be sub-optimal to draw more frequently but I'd need to 
cache the visual data elsewhere otherwise so it easier for me to just 
put it at compositor instead to store it offscreen and then copy it 
to wl_buffer when wl_frame_callback comes.


Thanks,
ma.


Hi

It's perfectly legal in the protocol to commit whenever you want to. 
The frame event is just a suggestion. Nothing is stopping anyone from 
rendering and committing at 1000 frames per second, other than people 
asking you to stop being so wasteful.


Wayland uses the "mailbox" model (this is Vulkan terminology), so the 
compositor will just use whatever the current commit is at the time it 
does its composition.


So do you mean in this scenario:

-- composition
 commit A
 commit B
 commit C
-- composition

only 'commit C' is painted and A/B are lost?

Martin


Any changes to the surface state are kept, but yes, the buffers you 
attached in commit A or B will never be shown.


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

Re: Do I need wl_frame_callback at all?

[Scott Anderson]

On 21/11/19 12:03 am, Martin Stransky wrote:

Hi guys,

what happens and is it a correct behavior when application does not use 
wl_frame_callback at all and just do the drawing (wl_surface_commit) 
whatever it has a data do draw?


I know it may be sub-optimal to draw more frequently but I'd need to 
cache the visual data elsewhere otherwise so it easier for me to just 
put it at compositor instead to store it offscreen and then copy it to 
wl_buffer when wl_frame_callback comes.


Thanks,
ma.


Hi

It's perfectly legal in the protocol to commit whenever you want to. The 
frame event is just a suggestion. Nothing is stopping anyone from 
rendering and committing at 1000 frames per second, other than people 
asking you to stop being so wasteful.


Wayland uses the "mailbox" model (this is Vulkan terminology), so the 
compositor will just use whatever the current commit is at the time it 
does its composition.


Scott
___
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 15/11/19 4:04 am, Drew DeVault wrote:

On Fri Nov 15, 2019 at 12:39 AM, Scott Anderson wrote:

A hint is merely a hint. The compositor can abide or not by that.
This flag will explicitly close the client connection if the buffer
can't be scanned out when this flag is passed.


This flag doesn't sound like a hint to me, but a hard requirement. From
the discussion I saw on the MR [1], if we don't abide, we risk being killed.


I agree: that's not a hint, it's a demand.

I think that there would be value in being able to suggest that a
particluar buffer be scanned out for performance reasons. But, as a
suggestion, and not a demand, and definitely not for secrecy reasons.
wlroots-based compositors would reserve the right to read your buffers
whenever we want. If I want to read your buffer for a frame to take a
screenshot, it's not going to be the end of the world for performance
and I don't want to end up segfaulting because of it.

>

But without the excuse for performance, that also raises another issue
for me about content-protection living in a "wp" protocol. The
governance thing hasn't officially been applied yet, and I wouldn't even
be the official spokesperson for wlroots, but I would personally NACK
that. Content-protection is a niche use case not generally useful to
Wayland implementations. I think a "ext" "wl_buffer factory for
protected dmabufs" would be a better place for this. It means you could
advertise a correct list of formats+modifiers too.


As an official spokesperson for wlroots:

If this protocol change were for the purpose of _suggesting_ scan-out,
I'd be on board with it. But this is not that - if it were, we would
dispense with any ideas around enforcing it with memory protections.
Then we could get an improvement for performance without a regression
for usability.

Rather, this just seems to be a DRM-enabling change, and the official
policy of wlroots will always be to NACK those for the wp and xdg
namespaces.


I don't think a hint for "please scan me out" has any value. A Wayland 
compositor that is capable of scanning out will try to scan out 
everybody as often as they can anyway, making the hint meaningless. A 
Wayland compositor that is not capable of scanning out is also going to 
ignore the hint, also making it meaningless.


The only situation I could possibly think of where this could make a 
difference is if you have two surfaces, and the compositor's policy 
would normally be to scan out the focused surface, but chooses to scan 
out e.g. a video player surface with this flag instead. That only works 
if the video player is not occluded.


But that's also cheapened by the fact that this flag sounds like "free 
performance", and everybody would just set it.

___
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]

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.


Well I'm not aware of that hint extension, but I think this wasn't taken
into consideration because it isn't the same thing. There's no assurance
from the compositor that the buffer will not read/be imported by the
GPU.
Yeah, dmabuf-hints wouldn't replace this flag, but does interact with 
it. It's supposed to give the client the best possible chance of being 
able to be scanned out if it's possible, and is dynamic with how the 
surface is currently being used. I consider it a much better way to deal 
with any of the performance-related aspects of this, but doesn't say 
anything about the content-protection cases.


Regarding formats+modifiers, the set of them that is valid is 
potentially very different from the ones advertised by wp_linux_dmabuf.
The client has no reliable way to know what they are. dmabuf-hints does 
give a good idea of what the direct-scanout formats are, but doesn't 
really fit the content-protection case _that_ well.



A hint is merely a hint. The compositor can abide or not by that.
This flag will explicitly close the client connection if the buffer
can't be scanned out when this flag is passed.


This flag doesn't sound like a hint to me, but a hard requirement. From 
the discussion I saw on the MR [1], if we don't abide, we risk being killed.



Regarding the screenshot bit not sure what is the concern here. Are you
afraid you won't able to take screenshots? The placeholder graphics is
in place only if view to which the buffer is attached can no longer be
assigned to a HW plane. >
It would be nice to know what basic functionality will this break, as I
not aware of any.


Yes, the functionality is the ability to take correct screenshots.

We can't take a screenshot of a plane, so we're forced to compose. But 
this flag basically forces us to never compose, at risk of being killed. 
This is intended in the content-protection case, but not for anything else.


When an application think it's being clever by using this flag (and they 
have no reason to NOT set it; it sounds like free performance), it 
breaks basic screenshots for us, and users are going to be annoyed by 
placeholders for random surfaces.


For wlroots, which is never going to support content-protection, maybe 
we'd just completely ignore the issue, but the most sensible 
implementation to me would be to just completely disallow this flag.


This flag should be completely re-contextualized about being 
content-protection only, or otherwise buffers we literally cannot access 
from the GPU. There should be no implications about performance, and it 
should be clear that 99.9% of clients don't want to use it.


But without the excuse for performance, that also raises another issue 
for me about content-protection living in a "wp" protocol. The 
governance thing hasn't officially been applied yet, and I wouldn't even 
be the official spokesperson for wlroots, but I would personally NACK 
that. Content-protection is a niche use case not generally useful to 
Wayland implementations. I think a "ext" "wl_buffer factory for 
protected dmabufs" would be a better place for this. It means you could 
advertise a correct list of formats+modifiers too.


Scott

[1]: 
https://gitlab.freedesktop.org/marius.vlad0/wayland-protocols/merge_requests/3#note_291389

___
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: wl_subsurace position - double buffered state?

[Scott Anderson]

On 30/10/19 10:41 am, Martin Stransky wrote:

Hi Guys,

while solving a FF bug [1] I'm unable to figure out why a subsurface has 
wrong offset. There's the related part of wayland-debug log:


[1622539.791]  -> wl_compositor@53.create_surface(new id wl_surface@61)

[1622539.821]  -> wl_subcompositor@57.get_subsurface(new id 
wl_subsurface@62, wl_surface@61, wl_surface@42)


gdk_window_get_position 26 23

[1622539.857]  -> wl_subsurface@62.set_position(26, 23)

[1622539.868]  -> wl_subsurface@62.set_desync()

[1622539.874]  -> wl_compositor@53.create_region(new id wl_region@63)

[1622539.882]  -> wl_surface@61.set_input_region(wl_region@63)

[1622539.889]  -> wl_region@63.destroy()

[1622539.904]  -> wl_surface@61.set_buffer_scale(2)

[1622539.912]  -> wl_surface@61.commit()


but I still see the sub surface on old initial position (0,0). It's 
moved to correct position imediately when I try to resize the window. 
(full log is attached).


Sometimes it happens that the surface is on correct position right after 
start - but I don't see any difference in the log.


It's on Fedora 30 / mutter-3.32.2-4.fc30.x86_64.

Any idea what can be wrong?

Thanks,
Martin

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1592350


Hi Martin.

The wl_subsurface position is actually a property of the parent surface, 
and will be applied on wl_surface.commit for the parent. It's that way 
so you can set the position of several subsurfaces and have them all be 
applied atomically.


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

XDC allocator workshop and Wayland dmabuf hints

[Scott Anderson]

(Sorry to CCs for spam, I made an error in my first posting)

Hi,

There were certainly some interesting changes discussed at the allocator
workshop during XDC this year, and I'd like to just summarise my
thoughts on it and make sure everybody is on the same page.

For those who don't know who I am or my stake in this, I'm the
maintainer of the DRM and graphics code for the wlroots Wayland
compositor library. I'm ascent12 on Github and Freenode.


My understanding of the issue Nvidia was trying to solve was the
in-place transition between different format modifiers. E.g. if a client
is to be scanned out, the buffer would need to be transitioned to a
non-compressed format that the display controller can work with, but if
the client is to be composited, a compressed format would be used,
saving on memory bandwidth. Hardware may have more efficient ways to
transition between different formats, so it would be good if we can use
these and not rely on having to perform a blit if we don't need to. The
problem is more general than this, but that was just the example given.

The original solution proposed in James' talk was to add functions to
EGL/OpenGL/Vulkan and have the display server perform transitions where
required.

Discussions during the workshop at the start tended to having libliftoff
handle all of this, but would require libliftoff to have its own
rendering context, which I think is bloating the purpose of the library.
Also discussed was to have libliftoff ask the compositor to perform the
transition if it thinks it was possible.


Another suggestion I made was to make use of Simon's dmabuf hints patch
to the wp_linux_dmabuf protocol [1] and leave it up to the client's GPU
driver to handle any transitions. This wasn't adequately represented in
the lightning talk summarising the workshop, so I'll go over it here
now, making sure everyone understands what it is and why I think it is
the way we should go forward.

Right now, a Wayland compositor will advertise all of the
format+modifier pairs that it supports, but currently does not provide
any context for clients as to which one they should actually choose.
It's basically up to chance if a client is able to be scanned out and is
likely to lead to several suboptimal situations.

The dmabuf hints patch adds a way to suggest a better format to use,
based on the current context. This is dynamic, and can be sent multiple
times over the lifetime of a surface. The patch also adds a way for the
compositor to tell the client which GPU its using, which is useful for
clients to know in multi GPU situations.

These hints are in various "tranches", which are just groups of
format+modifier pairs of the same preference. The tranches are ordered
from most optimal to least optimal. The most optimal tranche would imply
direct scanout, while a less optimal tranche would imply compositing,
but is not actually defined like that in the protocol.

If a client becomes fullscreen, we would send the format+modifier pairs
for the primary plane as the most optimal tranche. If a client is
eligible to be scanned out on an overlay plane, we would send the
format+modifier pairs for that plane. If a client is partially occluded
or otherwise not possible to be scanned out, we'd just have the normal
format+modifier pairs that we can use as a texture. Note that the
compositor won't send format+modifier pairs which we cannot texture
from, even if the plane advertises it's supported. We always need to be
able to fall back to compositing.


The hard part of figuring out which clients are "eligible" for being
scanned out on an overlay plane could be handled by libliftoff (or
something similar) and given back to the compositor to forward to
clients. For libliftoff to make a properly informed decision, I think
the atomic KMS API needs to be changed. We can only TEST_ONLY for valid
buffers, testing the immediate configuration, but doesn't allow us to
test for a configuration we WANT to go to. We need some sort of fake
framebuffer not backed by any real memory, but will allow us to
TEST_ONLY it. Without this, we may tell the client format+modifier pairs
that we think will work for scanout, but don't due to whatever hardware
limitations or transient issues like memory bandwidth, and we could
actually make things worse by having the client transition formats.

As an aside, I would really like these fake framebuffers for my
modesetting set up to be a lot cleaner too.

I'm sure this has been discussed before, and I'm not really sure what
the implications are from a driver perspective. I'd have to leave it up
to people more familiar with KMS and driver internals to comment on
this. Even if the solution isn't 100%, something that works most of
time would be hugely helpful (especially with RGB formats). Perhaps this
is not possible, and would need to live inside of driver-specific code
inside of libraries like libliftoff, but it would be nice not to come to
that. It seems useful enough for a generic KMS

Re: where is weston-content-protection-client-protocol.h?

[Scott Anderson]

On 1/10/19 3:35 pm, Barry Song wrote:

Hi Ankit and all,
clients/content_protection.c includes
weston-content-protection-client-protocol.h, and i found commit
8b40def845c1b965c2888b1f036ef1f19d76 added
weston_content_protection_protocol_c and
weston_content_protection_client_protocol_h

diff --git a/clients/meson.build b/clients/meson.build
index 3d36efe4..ff6246db 100644
--- a/clients/meson.build
+++ b/clients/meson.build
@@ -229,6 +229,14 @@ demo_clients = [
 'dep_objs': dep_vertex_clipping
 },
 { 'basename': 'confine' },
+   {
+   'basename': 'content_protection',
+   'add_sources': [
+   weston_content_protection_client_protocol_h,
+   weston_content_protection_protocol_c,
+   ]
+   },
+
 { 'basename': 'dnd' },
 {
 'basename': 'editor',

But anyway, where is the weston-content-protection-client-protocol.h?
I can't find it in weston:
weston$ find ./ -name "weston-content-protection-client-protocol.h"

And i failed to find it in google.

Thanks
Barry


Hi Barry,

With all Wayland extension protocols (and even the core protocol 
itself), they are all defined in an .xml file, and then the 
wayland-scanner tool generates the .c and .h code for it. So if you want 
to look at the header file directly, it'll be inside of your build 
directory (e.g. 
build/protocols/weston-content-protection-client-protocol.h).


If you want to use this in your own projects, you should use 
wayland-scanner yourself rather than copying the .c and .h files.


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

Re: universal planes in drm backend

[Scott Anderson]

On 17/09/19 7:38 pm, zou lan wrote:

Hi Daniel & all

I find the function drm_output_prepare_overlay_view() only use the plane 
type of WDRM_PLANE_TYPE_OVERLAY. it could be a waste for some planes of 
type WDRM_PLANE_TYPE_PRIMARY if the universal planes is enable.


For example, the kernel define 6 crtcs, and each crtc will have one 
primary type plane, but not all of the crtcs are used by weston_output. 
Some crtcs may never used, if we reserve  all the primary type planes as 
scanout plane, that could waste some of them.


Could the open source drm backend modify the logic of judge the overlay 
plane? let the primary plane equal to overlay plane or judge in 
drm_output_prepare_overlay_view(), if the plane is not used by outputs, 
it could be used by overlay?


Thank you!

Best regards
Nancy

Hi,

As far as I'm aware, the kernel never advertises more than one primary 
plane per CRTC and they're never possible to be used with multiple 
CRTCs: 
https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#plane-abstraction


>All drivers should provide one primary plane per CRTC to avoid 
surprising userspace too much


Perhaps that restriction is not as strict as I interpret it to be, but 
I'm not aware of anything which does not have a one-to-one relationship 
between primary planes and CRTCs.


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

Re: bo flags isn't passed through wayland-drm protocl, how weston respect these flags?

[Scott Anderson]

On 6/08/19 1:03 pm, HalleyZhao wrote:


Hi experts:
when we create buffer object at wayland client side, there are some 
usage flags, for example gbm_bo_flags.
but when we pass these buffer fd to weston through wayland-drm protocl, 
these flags are ignored.

then, how weston respect these flags when using the buffer object?
thanks.


     
     
       
       
       
       
       
       
       
       
       
       
       
     




Hi,

I think GPU drivers have their own driver-specific ways to get extra 
metadata associated with the buffer. So if you're simply passing a 
buffer allocated from the same driver, things should "just work". But 
it's not as easy when you're mixing GPUs/drivers.


Somewhat recently, 'modifiers' which describe extra information about a 
buffer were introduced to remove some of this driver-specific magic [1]. 
Although, not every driver supports modifiers yet.


Also, by the sounds of it, you're using the wl_drm interface directly. 
This isn't really a good idea, and it was supposed to be a private 
implementation detail of Mesa, and doesn't support modifiers. 
wp_linux_dmabuf [2] is the modern and more properly standardized way to

create a wl_buffer from a dmabuf.

Scott


[1] https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#format-modifiers
[2] 
https://gitlab.freedesktop.org/wayland/wayland-protocols/blob/master/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml

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

Re: dmabuf modifiers for HW overlays

[Scott Anderson]

On 2/08/19 10:19 pm, Martin Stransky wrote:

On 8/2/19 12:04 PM, Martin Stransky wrote:

Also I wonder if it's feasible to use any modifiers as I need
plain/linear buffer to draw into by skia. I suspect when I create the
buffer with modifiers and then I map it to CPU memory for SW drawing,
intermediate buffer is created and then the pixels are de-composed back
to GPU memory.


No, I don't believe there is any kind of intermediate buffer behind the
scenes in GBM or dmabuf ioctls/mmap. OpenGL drivers may use
intermediate buffers. Some EGLImage operations are allowed to create
more buffers behind the scenes but I think implementations try to avoid
it. Copies are bad for performance, and implicit copies are unexpected
performance bottle-necks. So yes, I believe you very much need to
ensure the buffer gets allocated as linear from the start.

Some hardware may have hardware tiling units, that may be able to
represent a linear CPU view into a tiled buffer, but I know very little
of that. I think they might need driver-specific ioctls to use or
something, and are a scarce resource.


The HW overlays is another use-case I'm working on. I want to draw 2D 
data to dmabuf buffer by CPU and send it directly to GPU to render from 
(bind as wl_buffer and attach it to wl_subsurface). I guess it also 
depends on compositor how to handles that and how does that handle 
mutter?. Does mutter such dmabuf buffer pass directly to GPU?

>
Also is it feasible to use *any* modifiers here and which flags should I 
pass to gbm_bo_create()? I want to use plain DRM_FORMAT_ARGB for the 
dmabuf buffer as it's easy to draw into but I wonder if that buffer can 
be used by GPU directly for compositing and how effective is tha >

Thanks,
ma
As the client, you don't need to try do the compositor's/driver's job 
for it. If you want CPU accessable buffers, just use wl_shm. Trying to 
push CPU data into a dmabuf directly can potentially hurt more than it 
helps. You should benchmark if that actually leads to increased 
performance, especially across different hardware/drivers.


Regarding overlays, a pending change to wp_linux_dmabuf [1] would give 
the client more information about how to allocate its GPU buffers so 
that's it's more likely to work with hardware overlays or be more 
efficient in general, but it's a complicated thing to get correct, and 
it'll never be perfect.


I'm also puzzled as to why you would need to use GBM directly. Some 
clients have a justified use for it, but most don't, and is mainly 
useful for display servers instead. Are the EGL/OpenGL APIs not sufficient?


Scott

[1]: 
https://lists.freedesktop.org/archives/wayland-devel/2018-November/039660.html

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

Re: how to implement animation in wayland since window move request is not supported?

[Scott Anderson]

On 6/05/19 1:37 pm, Barry Song wrote:

sorry for the ascii text picture can't show well in gmail. the
animation is pretty much like
  drop-down terminal - Yakuake
https://kde.org/applications/system/yakuake/

when you push a key, the Yakuake will move out from the top.


Barry Song <21cn...@gmail.com> 于2019年5月6日周一 下午1:31写道：


Hi Simon,

Simon Ser  于2019年5月6日周一 上午9:54写道：


Hi,

On Monday, May 6, 2019 12:17 AM, Barry Song <21cn...@gmail.com> wrote:

Hi,
It seems wayland doesn't support the move() and setGeometry() from
clients. No any message is sent from Qt to weston for qWidget.move()
or qDialog.move(). So weston has no any idea that clients are
requesting to move a window.
Under this condition, how could people implement animation of a window?

Right now, a software uses a timer to move window, in the callback of
the timer, the window is moved a little and the timer is fired again.
So the window can move and move, which is generating an animation.
This works well in non-wayland platforms. But the move() codes seems
to have no any impact under wayland.

So do we have some alternative way to implement the animation of a window?


This has been intentionally left out.

Could you explain exactly what is your use-case? What kind of
application are you working on, what does this dialog contain, what you
want to do?


click a button, a window will move out from the top to its position.

click a button, a window will move out from the right to its position.

the windows are not shown on screen directly, it is moving out.



Thanks,

--
Simon Ser
https://emersion.fr


-barry


Hi,

This is the kind of feature that would be implemented in the compositor, 
not in the client. As Simon already mentioned, normal clients have know 
knowledge or control of where they are placed.


However, there is an extension protocol called wlr-layer-shell which 
allows clients to anchor itself to the side of the screen (among other 
things) which would work for something like Yakuake, but that is not 
implemented in all compositors.


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

Re: xwayland display variable

[Scott Anderson]

On 1/05/19 11:30 pm, Damian Ivanov wrote:

Hello,

Is it somewhere documented how Xwayland applications are choosing
which compositor to display on? e.g 2 compostiors (1 nested or on
another VT)
wayland-0 and wayland-1
export WAYLAND_DISPLAY=wayland-1
GDK_BACKEND=x11 gedit //starts on wayland-0

If it's not documented how to do it?
Thank you in advance!

Damian


Hi,

X programs running through Xwayland connect to it with the exact same 
mechanism they use for connecting to a normal X server, which usually 
means looking at the DISPLAY environment variable.


Each Wayland compositor would start and manage their own separate 
Xwayland server, and would take their own DISPLAY values (e.g. 
DISPLAY=:0, DISPLAY=:1).


In the case of the WAYLAND_DISPLAY=wayland-1 compositor's X server takes 
DISPLAY=:1, you'd run that command like:


  GDK_BACKEND=x11 DISPLAY=:1 gedit

So setting WAYLAND_DISPLAY isn't technically needed, but it's still a 
good idea to set it too, because it can have an effect on other 
processes which your command can start.


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

Re: [PATCH wayland-protocols] xdg-output: deprecate the xdg_output.done event

[Scott Anderson]

This commit makes it so a wl_output.done event is guaranteed to be sent with a
xdg_output.done event.


Humm, I am not sure I like changing xdg-output to rely on another protocol
event, it's looks like a weird mixup to me...


As noted below, this is idiomatic in the Wayland protocol. The
wl_surface.commit request applies xdg_surface's state.


Just to expand on this with my two-cents, many of the Wayland protocol 
objects are conceptually extensions of other protocol objects. 
xdg_surface extends wl_surface, xdg_toplevel extends xdg_surface, and if 
we want to go cross-extension-protocol, xdg_toplevel_decoration extends 
xdg_toplevel.


While this is 4 protocol objects, we're conceptually just dealing with a 
single surface's state. The protocol objects are simply adding new 
interfaces to that surface and are meaningless on their own. We want to 
keep that surface's state consistent, so they need to share the same 
synchronisation to ensure atomicity, which includes wl_output.commit and 
xdg_surface.configure.


So there is certainly precedence for relying on the events and requests 
of other protocols.


Now applying that to xdg_output, it's simply adding interfaces to an 
wl_output object, and isn't meaningful on its own. It only makes sense 
to synchronise it properly with wl_output.


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

Re: wayland-protocols scope and governance

[Scott Anderson]

Do we want anything formal regarding the removal of protocols?

The one comes to mind currently is xdg-shell-unstable-v5, which most (if 
not all?) compositors have dropped support for.


If something previously widespread falls out of usage and compositors 
remove their implementations, is there grounds for removing it from the 
registry? Should there be different treatment for protocols that are 
marked stable or unstable?


I don't think people would strongly object to xdg-shell-unstable-v5 
being removed, but hypothetically, if something like wl_shell was an 
extension, should it be removed? It has been completely supplanted by 
xdg-shell, and we don't want to encourage clients to use it.
wl_shell is core, so it wouldn't actually get removed, but the idea is 
if a similar situation happens again between extension protocols.


I suppose the real question is whether the registry is an up-to-date and 
relevant list of extensions that clients should realistically use or 
simply a list extensions that only gets added to over time.


Perhaps the solution is to keep the extensions but to just formally mark 
them as obsolescent and specify what they should be doing instead. It 
would be nice to not keep several versions of old unstable protocols, 
though.


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

Re: Sharing a single wl_display (client) by multiple toolkits

[Scott Anderson]

On 22/03/19 8:37 am, Jaroslaw Kubik wrote:

Hi,

Does wayland-client support sharing a single connection object between
unrelated pieces of code? Such feature could be useful for integrating
multiple toolkits (ie. showing GTK widget in a Qt application). I am trying
to get something similar (but less spectacular) done at the moment, and
I am facing the following issue: When two unrelated pieces of code
(ie. GTK and Qt) use the same wl_display and both create a proxy to a
global object (ie. wl_output), then from the server perspective both these
proxies are indistinguishable. When sending events like wl_surface.enter,
the server has to pick a single wl_resource as an argument. That  wl_resource
is bound to a specific wl_output proxy on the client side. If the server
chooses wrong, then the window created and managed by Qt will receive
wl_surface.enter event with wl_output proxy instance that belongs to GTK.
It will attempt to access it's user-data and crash because it's not the data
it is expecting.

In the above scenario the server has no way of knowing which of the proxies
are expected as parameters in any given case. And the client has no way of
"discovering" equivalent proxies in case it would like to straighten it out.
This leads me to believe that the design of the wayland protocol makes it
impossible to share a connection object between unrelated code and that
use-case is simply not supported.

Is that correct? Are there any plans to address this?

Best Regards,
Jaroslaw Kubik


Hi,

Wayland can handle this perfectly fine. Separate sections of code can 
create their own wl_registries and bind their own wl_globals 
independently of each other, including using different versions of each 
global. The only requirement is that they use the same wl_display 
object, otherwise they will actually be two separate clients to the 
compositor.


For example, the EGL and Vulkan Wayland platform is implemented this 
way, where you give it a reference to your wl_display and wl_surface, 
and it handles setting up and committing the buffer separately from 
anything else.


If some global is bound multiple times, you will receive an event on 
each of them and there won't be any mix up regarding user-data, so you 
don't need to worry about whether the right global gets used.


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

Re: [PATCH wayland v2] contributing: use Gitlab merge request workflow

[Scott Anderson]

are not tracked in the Wayland Patchwork.
-
-The following applies only to Wayland.
-
-If a patch is not found in Patchwork, there is a high possibility for it to be
-forgotten. Patches attached to bug reports or not arriving to the mailing list
-because of e.g. subscription issues will not be in Patchwork because Patchwork
-only collects patches sent to the list.
-
-When you send a revised version of a patch, it would be very nice to mark your
-old patch as superseded (or rejected, if that is applicable). You can change
-the status of your own patches by registering to Patchwork - ownership is
-identified by email address you use to register. Updating your patch status
-appropriately will help maintainer work.
-
-The following patch states are found in Patchwork:
-
-- **New**:
-Patches under discussion or not yet processed.
-
-- **Under review**:
-Mostly unused state.
-
-- **Accepted**:
-The patch is merged in the master branch upstream, as is or slightly
-modified.
-
-- **Rejected**:
-The idea or approach is rejected and cannot be fixed by revising
-the patch.
-
-- **RFC**:
-Request for comments, not meant to be merged as is.
-
-- **Not applicable**:
-The email was not actually a patch, or the patch is not for Wayland.
-Libinput patches are usually automatically ignored by Wayland
-Patchwork, but if they get through, they will be marked as Not
-applicable.
-
-- **Changes requested**:
-Reviewers determined that changes to the patch are needed. The
-submitter is expected to send a revised version. (You should
-not wait for your patch to be set to this state before revising,
-though.)
-
-- **Awaiting upstream**:
-Mostly unused as the patch is waiting for upstream actions but
-is not shown in the default list, which means it is easy to
-overlook.
-
-- **Superseded**:
-A revised version of the patch has been submitted.
-
-- **Deferred**:
-Used mostly during freeze periods before releases, to temporarily
-hide patches that cannot be merged during a freeze.
-
-Note, that in the default listing, only patches in *New* or *Under review* are
-shown.
-
-There is also a command line interface to Patchwork called `pwclient`, see
-http://patchwork.freedesktop.org/project/wayland/
-for links where to get it and the sample `.pwclientrc` for Wayland.
+Once submitted to GitLab, your patches will be reviewed by the Wayland
+development team on GitLab. Review may be entirely positive and result in your
+code landing instantly, in which case, great! You're done. However, we may ask
+you to make some revisions: fixing some bugs we've noticed, working to a
+slightly different design, or adding documentation and tests.
+
+If you do get asked to revise the patches, please bear in mind the notes above.
+You should use `git rebase -i` to make revisions, so that your patches follow
+the clear linear split documented above. Following that split makes it easier
+for reviewers to understand your work, and to verify that the code you're
+submitting is correct.
+
+A common request is to split single large patch into multiple patches. This can
+happen, for example, if when adding a new feature you notice a bug elsewhere
+which you need to fix to progress. Separating these changes into separate
+commits will allow us to verify and land the bugfix quickly, pushing part of
+your work for the good of everyone, whilst revision and discussion continues on
+the larger feature part. It also allows us to direct you towards reviewers who
+best understand the different areas you are working on.
+
+When you have made any requested changes, please rebase the commits, verify
+that they still individually look good, then force-push your new branch to
+GitLab. This will update the merge request and notify everyone subscribed to
+your merge request, so they can review it again.
+
+There are also
+[many GitLab CLI clients](https://about.gitlab.com/applications/#cli-clients),
+if you prefer to avoid the web interface. It may be difficult to follow review
+comments without using the web interface though, so we do recommend using this
+to go through the review process, even if you use other clients to track the
+list of available patches.
  
  
  Coding style




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

Re: Wayland / Weston Multi Display Client-Side Functionality

[Scott Anderson]

On 25/02/19 8:21 pm, AMAR SEN wrote:

Hi,

1. Is there any client side functionality to handle multiple displays? 
It can be seen as like a particular client has some options that can 
direct the server to show frames on either of the displays or both 
(multiple displays) of them at the same time. If it has such 
functionality, can somebody point me to an example implementation of 
such client?


A normal Wayland client has no control regarding how it is placed by the 
compositor, which is an intentional design decision.
The most control I can think of (which may fit your use case), is that a 
client can ask to be placed fullscreen on a particular output using the 
fullscreen-shell protocol


2. As I have read at multiple places that weston supports multi-display 
for drm based devices, is it also possible for fbdev backend, or it has 
some functionality constraint that do not let that to work on fbdev?


I _think_ the fbdev backend does support multiple outputs. I've never 
actually used the fbdev backend before, but the code implies that it 
does. Either way, I would strongly recommend that you use the DRM 
backend instead.


3. I am actually using weston-3.0.0 version for my project, does it have 
multi-display support for any backend? If yes, can someone please help 
me find  the commit to the wayland weston project which brought in the 
multi-display support?


Just to be absolutely sure, are you just referring to having multiple 
computer monitors ("heads") connected? I believe weston has always had 
support for that.
Later versions of weston are capable of cloning a monitor's contents 
efficiently across multiple monitors, which may potentially be useful 
for you.



Thanks,
Amar Sen


If you require more complex control of how Weston does window 
management, writing a Weston plugin would be the way to do that, as 
opposed to a client trying to take control (which it can't).


Scott

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

Re: Question about linux-explicit-synchronization

[Scott Anderson]

On 18/02/19 11:02 pm, Daniel Stone wrote:

Hi Scott,

On Mon, 18 Feb 2019 at 03:27, Scott Anderson
 wrote:

In the Weston implementation, it's simply a case of the compositor
getting the fence from the client, using eglWaitSyncKHR (or equivilent)
on it, and passing back a release fence from OUT_FENCE_FD.


Yep, that's pretty much the MVP ...


However, is the protocol intended to allow a compositor which takes a
more active role in monitoring the fences? For example, a compositor
could check the state of the fence at drawing time and decide to use the
client's previous buffer if the fence hasn't been signalled.

Is it worth a compositor being implemented like this? As far as I
understand, doing this would stop any particuarly slow clients from
stalling the compositor's drawing too much and possibly missing vblank.
But I'm not an expert on fences or how eglWaitSyncKHR affects anything
at a driver level.


No, you're totally right. The intention is that compositors should be
able to use this to schedule composition. It's still helpful without
doing that - you get more information for tracing - but in an ideal
world, compositors would be able to delay presentation if it would
endanger full frame rate.

Doing this gets _really_ tricky as you start considering things like
synchronised subsurfaces (which always seems to be the case), since
you have to make sure you're not presenting incoherent results. But
for unrelated surfaces, you can definitely delay presentation.


Ok, cool. That actually answers a follow-up question I would've had. 
I've been looking at implementing this in wlroots, and subsurfaces 
certainly were a point I was wondering about.


The case in particular would be:
- Parent surface is "ready" (signaled fence or no fence)
- Subsurface is synchronized and fence is not signaled

The intuitive thing would be to delay the parent's content from being 
updated until the subsurface is ready, but the protocol itself is a bit 
underspecified when it comes to this.



FWIW, eglWaitSyncKHR just ensures that the GPU waits for completion of
the sync object before executing any of the commands you give it
subsequently: it's a guaranteed stall. For making that decision on the
compositor side, you just want to be using the dma-fence FD. You can
add dma-fence FDs to a poll loop, where they become 'readable' when
the fence has been signalled.

Cheers,
Daniel


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

Question about linux-explicit-synchronization

[Scott Anderson]

Hi,

I have a question about the usage of 
zwp_linux_explicit_synchronization_unstable_v1.


In the Weston implementation, it's simply a case of the compositor 
getting the fence from the client, using eglWaitSyncKHR (or equivilent) 
on it, and passing back a release fence from OUT_FENCE_FD.


However, is the protocol intended to allow a compositor which takes a 
more active role in monitoring the fences? For example, a compositor 
could check the state of the fence at drawing time and decide to use the 
client's previous buffer if the fence hasn't been signalled.


Is it worth a compositor being implemented like this? As far as I 
understand, doing this would stop any particuarly slow clients from 
stalling the compositor's drawing too much and possibly missing vblank. 
But I'm not an expert on fences or how eglWaitSyncKHR affects anything 
at a driver level.


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

Re: [PATCH RFC wayland-protocols v3 1/2] Add secure output protocol

[Scott Anderson]

On 2/02/19 1:16 am, Pekka Paalanen wrote:

On Mon,  3 Dec 2018 19:14:50 +1300
scott.ander...@collabora.com wrote:


From: Scott Anderson 

This protocol allows a client to ask the compositor to only allow it to
be displayed on a "secure" output.

This is based on a chromium protocol of the same name [1].

This protocol is mostly useful for closed systems, where the client can
trust the compositor, such as set-top boxes. This is not a way to
implement any kind of Digital Rights Management on desktops. The
protocol deliberately doesn't define what a "secure output" is, and the
compositor would be free to lie to the client anyway.

The protocol has been designed to be extendable with other protocols to
implement more specific types of security that a client may care about,
e.g. HDCP. This extensibility is based on the concept of a "role" that a
wl_surface has.

Signed-off-by: Scott Anderson 


Hi Scott,

the commit message is very much to the point. I like how it underlines
"closed systems" and "not rights management".

My comments below are necessarily colored by the discussions I had with
Ankit and Ramalingam quite a while ago.



[1] 
https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/secure-output/secure-output-unstable-v1.xml
---
  Makefile.am   |   1 +
  unstable/secure-output/README |   4 +
  .../secure-output-unstable-v1.xml | 189 ++
  3 files changed, 194 insertions(+)
  create mode 100644 unstable/secure-output/README
  create mode 100644 unstable/secure-output/secure-output-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 345ae6a..4d94747 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -23,6 +23,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/secure-output/secure-output-unstable-v1.xml\
$(NULL)
  
  stable_protocols =\

diff --git a/unstable/secure-output/README b/unstable/secure-output/README
new file mode 100644
index 000..3251af9
--- /dev/null
+++ b/unstable/secure-output/README
@@ -0,0 +1,4 @@
+Secure output protocol
+
+Maintainers:
+David Reveman 


Would Reveman really be the only maintainer? I don't recall seeing any
email from him on this mailing list for a long time. Would he respond
to any questions and change suggestions that might arise?



That's a good point. I just copied this from the chromium protocol which 
I originally based this on, and didn't really put much thought into 
updating it.



diff --git a/unstable/secure-output/secure-output-unstable-v1.xml 
b/unstable/secure-output/secure-output-unstable-v1.xml
new file mode 100644
index 000..867a03c
--- /dev/null
+++ b/unstable/secure-output/secure-output-unstable-v1.xml
@@ -0,0 +1,189 @@
+
+
+
+  
+Copyright 2016 The Chromium Authors.
+Copyright 2018 Collabora, Ltd.
+
+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 protocol specifies a set of interfaces used to prevent surface
+contents from appearing in screenshots or from being visible on non-secure
+outputs.
+
+In order to prevent surface contents from appearing in screenshots or from
+being visible on non-secure outputs, a client must first bind the global
+interface "wp_secure_output" which, if a compositor supports secure output,
+is exposed by the registry. Using the bound global object, the client uses
+the "get_security" request to instantiate an interface extension for a
+w

[PATCH wayland] protocol: Add new wl_shm formats

[scott . anderson]

From: Scott Anderson 

This adds several new wl_shm formats to match the newly added DRM fourcc
ones.

Signed-off-by: Scott Anderson 
---
 protocol/wayland.xml | 16 
 1 file changed, 16 insertions(+)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index ea04623..592a53e 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -298,6 +298,12 @@
   
   
   
+  
+  
+  
+  
+  
+  
   
   
   
@@ -339,10 +345,20 @@
   
   
   
+  
+  
+  
+  
+  
+  
+  
+  
   
   
   
   
+  
+  
   
   
   
-- 
2.20.1

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

[RFC v3 wayland-protocols] inputfd - direct input access protocol

[Scott Anderson]

Hi,

I thought I would try to push this [1] protocol along, as it's what 
would be needed for wayland client gamepad input. There is still no 
client-side "libgamepadinput", so clients are on their own when it comes 
to handling these devices.


Here is a basic proof-of-concept implementation for weston:
https://gitlab.freedesktop.org/ascent/weston/tree/inputfd

It's a little rough around the edges, and a more complete implementation 
would add some configurability. It just gives every device to whichever 
client has the keyboard focus.


There is a very basic test client which just reports which devices it 
receives, but doesn't currently do anything else with them.


The only oddity I noticed was there is a 'serial' argument to 
zwp_inputfd_device_evdev_v1.focus_in which has no description and 
doesn't seem to serve any purpose. A follow up version of this protocol 
should remove that.


Scott

[1] 
https://lists.freedesktop.org/archives/wayland-devel/2017-August/034828.html

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

[PATCH RFC wayland-protocols v3 1/2] Add secure output protocol

[scott . anderson]

From: Scott Anderson 

This protocol allows a client to ask the compositor to only allow it to
be displayed on a "secure" output.

This is based on a chromium protocol of the same name [1].

This protocol is mostly useful for closed systems, where the client can
trust the compositor, such as set-top boxes. This is not a way to
implement any kind of Digital Rights Management on desktops. The
protocol deliberately doesn't define what a "secure output" is, and the
compositor would be free to lie to the client anyway.

The protocol has been designed to be extendable with other protocols to
implement more specific types of security that a client may care about,
e.g. HDCP. This extensibility is based on the concept of a "role" that a
wl_surface has.

Signed-off-by: Scott Anderson 

[1] 
https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/secure-output/secure-output-unstable-v1.xml
---
 Makefile.am   |   1 +
 unstable/secure-output/README |   4 +
 .../secure-output-unstable-v1.xml | 189 ++
 3 files changed, 194 insertions(+)
 create mode 100644 unstable/secure-output/README
 create mode 100644 unstable/secure-output/secure-output-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 345ae6a..4d94747 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -23,6 +23,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/secure-output/secure-output-unstable-v1.xml\
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/secure-output/README b/unstable/secure-output/README
new file mode 100644
index 000..3251af9
--- /dev/null
+++ b/unstable/secure-output/README
@@ -0,0 +1,4 @@
+Secure output protocol
+
+Maintainers:
+David Reveman 
diff --git a/unstable/secure-output/secure-output-unstable-v1.xml 
b/unstable/secure-output/secure-output-unstable-v1.xml
new file mode 100644
index 000..867a03c
--- /dev/null
+++ b/unstable/secure-output/secure-output-unstable-v1.xml
@@ -0,0 +1,189 @@
+
+
+
+  
+Copyright 2016 The Chromium Authors.
+Copyright 2018 Collabora, Ltd.
+
+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 protocol specifies a set of interfaces used to prevent surface
+contents from appearing in screenshots or from being visible on non-secure
+outputs.
+
+In order to prevent surface contents from appearing in screenshots or from
+being visible on non-secure outputs, a client must first bind the global
+interface "wp_secure_output" which, if a compositor supports secure output,
+is exposed by the registry. Using the bound global object, the client uses
+the "get_security" request to instantiate an interface extension for a
+wl_surface object. This extended interface will then allow surfaces
+to be marked as only visible on secure outputs.
+
+Warning! The protocol described in this file is experimental and backward
+incompatible changes may be made. Backward compatible changes may be added
+together with the corresponding interface version bump. Backward
+incompatible changes are done by bumping the version number in the protocol
+and interface names and resetting the interface version. Once the protocol
+is to be declared stable, the 'z' prefix and the version number in the
+protocol and interface names are removed and the interface version number 
is
+reset.
+  
+
+  
+ 

[no subject]

[scott . anderson]

Hi,

I've come to realise that it's become a bit of a fool's errand to try
and put all of the information related to content security into a single
protocol and have the interface be general yet sane, so I've instead
redesigned this to be general core which can be extended by other protocols.

This takes heavy inspiration from wl_surface "roles" and copies a lot of
the language of that. So each security interface will now have an
"implementation" which currently could be HDCP, the "I don't care" one,
or whatever one that someone decides to extend this with in the future.

The HDCP protocol is basically copied from [1], but I don't really know
a lot of the details of HDCP and it would currently rely on kernel
interfaces not upstream. This protocol is only really here to show what
it could look like.

I also have a basic proof-of-concept implementation of the first
protocol here [2].

Scott

[1] 
https://gitlab.freedesktop.org/wayland/weston/blob/5700409c4da6512cfdc6ffc0e644853273b455f3/protocol/content-protection.xml
[2] https://gitlab.freedesktop.org/ascent/weston/tree/secure-output

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

[PATCH RFC wayland-protocols v3 2/2] Add HDCP security protocol

[scott . anderson]

From: Scott Anderson 

This is an extension to the secure output protocol for clients that
specifically want to control properties related to HDCP.

Signed-off-by: Scott Anderson 
---
 .../secure-output-hdcp-unstable-v1.xml| 120 ++
 1 file changed, 120 insertions(+)
 create mode 100644 unstable/secure-output/secure-output-hdcp-unstable-v1.xml

diff --git a/unstable/secure-output/secure-output-hdcp-unstable-v1.xml 
b/unstable/secure-output/secure-output-hdcp-unstable-v1.xml
new file mode 100644
index 000..ad62ca1
--- /dev/null
+++ b/unstable/secure-output/secure-output-hdcp-unstable-v1.xml
@@ -0,0 +1,120 @@
+
+
+
+  
+Copyright 2018 Collabora, Ltd.
+Copyright 2018 Intel Corporation
+
+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 protocol specifies an implementation for a wp_security object,
+providing content protection via the High-bandwith Digital Content
+Protection protocol.
+
+Warning! The protocol described in this file is experimental and backward
+incompatible changes may be made. Backward compatible changes may be added
+together with the corresponding interface version bump. Backward
+incompatible changes are done by bumping the version number in the protocol
+and interface names and resetting the interface version. Once the protocol
+is to be declared stable, the 'z' prefix and the version number in the
+protocol and interface names are removed and the interface version number 
is
+reset.
+  
+
+  
+
+  The global interface exposing secure output capabilities is used
+  to instantiate an interface extension for a wl_surface object.
+  This extended interface will then allow surfaces to be marked as
+  as only visible on secure outputs.
+
+
+
+  
+Informs the server that the client will not be using this
+protocol object anymore. This does not affect any other objects,
+security objects included.
+  
+
+
+
+  
+
+
+
+  
+Creates an object representing HDCP protection for a surface's
+contents.
+
+This will set the implementation of the security object and fail if
+the security object already has an implementation.
+
+The wp_hdcp_security object must be destroyed before the wp_security
+object that is is associated with.
+  
+  
+  
+
+  
+
+  
+
+  A protocol object representing an HDCP wp_security implementation.
+  It provides a set of functionality related to protecting content
+  with HDCP.
+
+  If the wl_surface associated with this object is destroyed, the HDCP
+  security object becomes inert.
+
+
+
+  
+  
+
+
+
+  
+Destroy the zwp_hdcp_security_v1 object.
+An wp_security must only be destroyed after its implementation is
+destroyed.
+  
+
+
+
+  
+Sets the HDCP content type for this security object. See the HDCP
+specification for the meaning of content types.
+
+The initial content type value is Type-0.
+
+The content type state is double-buffered and will be applied
+on the next wl_surface.commit.
+  
+  
+
+  
+
+
-- 
2.19.2

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

[PATCH RFC wayland-protocols] Add secure output protocol

[scott . anderson]

From: Scott Anderson 

This protocol allows a client to ask the compositor to only allow it to
be displayed on a "secure" output (e.g. HDCP).

This is based on a chromium protocol of the same name [1].

This protocol is mostly useful for closed systems, where the client can
trust the compositor, such as set-top boxes. This is not a way to
implement any kind of Digital Rights Management on desktops. The
protocol deliberately doesn't define what a "secure output" is, and the
compositor would be free to lie to the client anyway.

Signed-off-by: Scott Anderson 

[1] 
https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/secure-output/secure-output-unstable-v1.xml
---

There is a proof-of-concept implementation of this protocol for weston
here: https://gitlab.freedesktop.org/ascent/weston/tree/secure-output

Changes since v1:
 - Fix formatting
 - Add 'secure_resolution' event

As Simon brought up, this may not be the type of patch that is
necessarily wanted upstream, and it's completely understandable if it's
not. There are probably multiple parties that are interested in such a
thing, but I suppose the answer depends on what wayland-protocols is
designed to accommodate.

I'm just proposing the 'secure_resolution' event, because I believe it
can allow for the client to adjust to changing security conditions
without being tied to any specific underlying technology (e.g. HDCP).
It's still largely up to compositor policy how this could be used, but
we'll have to see if this can meet everybody's requirements.

 Makefile.am   |   1 +
 unstable/secure-output/README |   4 +
 .../secure-output-unstable-v1.xml | 144 ++
 3 files changed, 149 insertions(+)
 create mode 100644 unstable/secure-output/README
 create mode 100644 unstable/secure-output/secure-output-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 345ae6a..4d94747 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -23,6 +23,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/secure-output/secure-output-unstable-v1.xml\
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/secure-output/README b/unstable/secure-output/README
new file mode 100644
index 000..3251af9
--- /dev/null
+++ b/unstable/secure-output/README
@@ -0,0 +1,4 @@
+Secure output protocol
+
+Maintainers:
+David Reveman 
diff --git a/unstable/secure-output/secure-output-unstable-v1.xml 
b/unstable/secure-output/secure-output-unstable-v1.xml
new file mode 100644
index 000..51b2c13
--- /dev/null
+++ b/unstable/secure-output/secure-output-unstable-v1.xml
@@ -0,0 +1,144 @@
+
+
+
+  
+Copyright 2016 The Chromium Authors.
+Copyright 2018 Collabora, Ltd.
+
+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 protocol specifies a set of interfaces used to prevent surface
+contents from appearing in screenshots or from being visible on non-secure
+outputs.
+
+In order to prevent surface contents from appearing in screenshots or from
+being visible on non-secure outputs, a client must first bind the global
+interface "wp_secure_output" which, if a compositor supports secure output,
+is exposed by the registry. Using the bound global object, the client uses
+the "get_security" request to instantiate an interface extension for a
+wl_surface object. This extended i

Re: [PATCH RFC wayland-protocols] Add secure output protocol

[Scott Anderson]

Hi,

As far as I understand, the different types and versions of protection a 
client would want is based on the resolution of the content, rather than 
anything about what the content actually is. Is there any particular 
reason a client would care if their content is being used on a higher 
HDCP version than is necessary? e.g. would a client with 720p content 
care about using HDCP 2.2?


If that's the case, I think it would make sense for the compositor to 
always try to negotitate the strongest level of protection that it can 
(or a lower level if set by some policy), and report to the client the 
largest resolution that it can support securely. With that, the client 
can then make the decision about what content it can provide.



  



  


This would remove a lot of the back-and-forth between the client and the 
compositor, where the client says what content it has, and the 
compositor saying if it can securely display it.


This event could also be re-emitted when the protection status changes. 
There could also be the special case of 0x0, where the compositor failed 
to negotiate any secure connection, and no resolution is secure.


A compositor may also choose to emit this signal based on what output 
the client is set to display on, but that would probably be left up to 
the compositor policy. It's possible that wl_output could be integrated 
into this somehow, but I haven't thought too much about how yet.


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

[PATCH RFC wayland-protocols] Add secure output protocol

[scott . anderson]

From: Scott Anderson 

This protocol allows a client to ask the compositor to only allow it to
be displayed on a "secure" output (e.g. HDCP).

This is based on a chromium protocol of the same name [1].

This protocol is mostly useful for closed systems, where the client can
trust the compositor, such as set-top boxes. This is not a way to
implement any kind of Digital Rights Management on desktops. The
protocol deliberately doesn't define what a "secure output" is, and the
compositor would be free to lie to the client anyway.

Signed-off-by: Scott Anderson 

[1] 
https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/secure-output/secure-output-unstable-v1.xml
---

Intel has proposed a similar protocol as a Weston merge request [2].
I believe these two protocols should be compared and merged to try and
come up with a general solution that everybody is happy with.

While this protocol is currently intended for using HDCP, I don't
believe it should be tied to HDCP in any way. If any other similar
technology is developed, it would be nice to not need to define a new
protocol or modify this one.

I don't think it's necessary for the client to know what type of
protection the compositor is providingi or if the protection status of
an output changes. It's up to the compositor to choose and negotiate
what kind of protection is required, and all the client needs to do is
trust that the compositor is putting their content on a secure output.
Clients should have no control or knowledge of how/where they're
presented.

The protocol also should be per wl_surface, instead of any type of
global client state. A client can have multiple surfaces, and they could
need to be treated differently. For example, one surface may be the
protected content which uses this interface, and the other may be a
dialog box which could be placed anywhere.

[2] 
https://gitlab.freedesktop.org/wayland/weston/blob/bb546cbbaaf6257ce018e7392747cc0fbdc1639f/protocol/content-protection.xml

 Makefile.am   |   1 +
 unstable/secure-output/README |   4 +
 .../secure-output-unstable-v1.xml | 119 ++
 3 files changed, 124 insertions(+)
 create mode 100644 unstable/secure-output/README
 create mode 100644 unstable/secure-output/secure-output-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 345ae6a..4d94747 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -23,6 +23,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/secure-output/secure-output-unstable-v1.xml\
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/secure-output/README b/unstable/secure-output/README
new file mode 100644
index 000..3251af9
--- /dev/null
+++ b/unstable/secure-output/README
@@ -0,0 +1,4 @@
+Secure output protocol
+
+Maintainers:
+David Reveman 
diff --git a/unstable/secure-output/secure-output-unstable-v1.xml 
b/unstable/secure-output/secure-output-unstable-v1.xml
new file mode 100644
index 000..63a2cdf
--- /dev/null
+++ b/unstable/secure-output/secure-output-unstable-v1.xml
@@ -0,0 +1,119 @@
+
+
+
+  
+Copyright 2016 The Chromium Authors.
+Copyright 2018 Collabora, Ltd.
+
+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 protocol specifies a set of interfaces used to prevent surface
+contents from appearing in screenshots or from being visible on non-secure
+outputs.
+
+In order to prevent surfac

Re: [PATCH wayland-protocols v3] Add alpha-compositing protocol

[Scott Anderson]

On 16/11/18 6:05 am, Derek Foreman wrote:

This looks nice to me, and I have need of something like this.

A couple of comments below.

On 11/14/18 7:00 PM, Scott Anderson wrote:

This protocol specifies a set of interfaces used to control the alpha
compositing and blending of surface contents, based on the Chromium
Wayland protocol of the same name [1].

Signed-off-by: Scott Anderson 

[1] 
https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
---

Changes in v3:
   - Rename "blending" event to "blending_equation"
   - Add enum specifier to "blending_equation" event and "set_blending"
 request.
   - Fix typos

Changes in v2:
   - Add additional "fromsource" blending equation used by [3]
   - Allow the server to advertise which blending equations it supports
   - Added a protocol error for using an unsupported equation
   - Added a protocol error for using an invalid alpha value
   - Added clarification about wl_surface.set_opaque_region
   - Added clarification about per-pixel alpha values

  Makefile.am   |   1 +
  unstable/alpha-compositing/README |   5 +
  .../alpha-compositing-unstable-v1.xml | 175 ++
  3 files changed, 181 insertions(+)
  create mode 100644 unstable/alpha-compositing/README
  create mode 100644 
unstable/alpha-compositing/alpha-compositing-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 6394e26..ac6c9f8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -21,6 +21,7 @@ unstable_protocols =  
\
unstable/xdg-output/xdg-output-unstable-v1.xml  
\
unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
+   unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
\
$(NULL)
  
  stable_protocols =\

diff --git a/unstable/alpha-compositing/README 
b/unstable/alpha-compositing/README
new file mode 100644
index 000..5826967
--- /dev/null
+++ b/unstable/alpha-compositing/README
@@ -0,0 +1,5 @@
+Alpha compositing protocol
+
+Maintainers:
+David Reveman 
+Alexandros Frantzis 
diff --git a/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml 
b/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
new file mode 100644
index 000..d3c41d5
--- /dev/null
+++ b/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
@@ -0,0 +1,175 @@
+
+
+
+  
+Copyright 2016  The Chromium Authors.
+Copyright 2017-2018 Collabora Ltd
+Copyright 2018  NXP
+
+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 protocol specifies a set of interfaces used to control the alpha
+compositing and blending of surface contents.
+
+Warning! The protocol described in this file is experimental and backward
+incompatible changes may be made. Backward compatible changes may be added
+together with the corresponding interface version bump. Backward
+incompatible changes are done by bumping the version number in the protocol
+and interface names and resetting the interface version. Once the protocol
+is to be declared stable, the 'z' prefix and the version number in the
+protocol and interface names are removed and the interface version number 
is
+reset.
+  
+
+  
+
+  The global interface exposing compositing and blending capabilities is
+  used to instantiate an interface extension for a wl_surface object.
+  This extended interface will then allow the client to specify the
+  blending equation and alpha value used for compositing the wl_surface.
+
+
+
+  
+
+
+
+  
+   

[PATCH wayland-protocols v3] Add alpha-compositing protocol

[Scott Anderson]

This protocol specifies a set of interfaces used to control the alpha
compositing and blending of surface contents, based on the Chromium
Wayland protocol of the same name [1].

Signed-off-by: Scott Anderson 

[1] 
https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
---

Changes in v3:
  - Rename "blending" event to "blending_equation"
  - Add enum specifier to "blending_equation" event and "set_blending"
request.
  - Fix typos

Changes in v2:
  - Add additional "fromsource" blending equation used by [3]
  - Allow the server to advertise which blending equations it supports
  - Added a protocol error for using an unsupported equation
  - Added a protocol error for using an invalid alpha value
  - Added clarification about wl_surface.set_opaque_region
  - Added clarification about per-pixel alpha values

 Makefile.am   |   1 +
 unstable/alpha-compositing/README |   5 +
 .../alpha-compositing-unstable-v1.xml | 175 ++
 3 files changed, 181 insertions(+)
 create mode 100644 unstable/alpha-compositing/README
 create mode 100644 unstable/alpha-compositing/alpha-compositing-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 6394e26..ac6c9f8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -21,6 +21,7 @@ unstable_protocols =  
\
unstable/xdg-output/xdg-output-unstable-v1.xml  
\
unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
+   unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
\
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/alpha-compositing/README 
b/unstable/alpha-compositing/README
new file mode 100644
index 000..5826967
--- /dev/null
+++ b/unstable/alpha-compositing/README
@@ -0,0 +1,5 @@
+Alpha compositing protocol
+
+Maintainers:
+David Reveman 
+Alexandros Frantzis 
diff --git a/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml 
b/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
new file mode 100644
index 000..d3c41d5
--- /dev/null
+++ b/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
@@ -0,0 +1,175 @@
+
+
+
+  
+Copyright 2016  The Chromium Authors.
+Copyright 2017-2018 Collabora Ltd
+Copyright 2018  NXP
+
+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 protocol specifies a set of interfaces used to control the alpha
+compositing and blending of surface contents.
+
+Warning! The protocol described in this file is experimental and backward
+incompatible changes may be made. Backward compatible changes may be added
+together with the corresponding interface version bump. Backward
+incompatible changes are done by bumping the version number in the protocol
+and interface names and resetting the interface version. Once the protocol
+is to be declared stable, the 'z' prefix and the version number in the
+protocol and interface names are removed and the interface version number 
is
+reset.
+  
+
+  
+
+  The global interface exposing compositing and blending capabilities is
+  used to instantiate an interface extension for a wl_surface object.
+  This extended interface will then allow the client to specify the
+  blending equation and alpha value used for compositing the wl_surface.
+
+
+
+  
+
+
+
+  
+Informs the server that the client will not be using this
+protocol object anymore. This does not affect any other objects,
+

[PATCH wayland-protocols v2] Add alpha-compositing protocol

[Scott Anderson]

This protocol specifies a set of interfaces used to control the alpha
compositing and blending of surface contents.

It's based on the Chromium Wayland protocol of the same name ([1]) and
an old proposal of this protocol ([2]).

Differences from v1 proposal:
- Add additional "fromsource" blending equation used by [3]
- Allow the server to advertise which blending equations it supports
- Added a protocol errors for using an unsupported equation
- Added a protocol error for using an invalid alpha value
- Added clarification about wl_surface.set_opaque_region
- Added clarification about per-pixel alpha values

A proof-of-concept implementation for Weston can be found at:
https://gitlab.freedesktop.org/ascent/weston/tree/alpha-compositing-v1

[1] 
https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
[2] https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
[3] 
https://lists.freedesktop.org/archives/wayland-devel/2018-September/039437.html
---
 Makefile.am   |   1 +
 unstable/alpha-compositing/README |   5 +
 .../alpha-compositing-unstable-v1.xml | 172 ++
 3 files changed, 178 insertions(+)
 create mode 100644 unstable/alpha-compositing/README
 create mode 100644 unstable/alpha-compositing/alpha-compositing-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 6394e26..ac6c9f8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -21,6 +21,7 @@ unstable_protocols =  
\
unstable/xdg-output/xdg-output-unstable-v1.xml  
\
unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
+   unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
\
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/alpha-compositing/README 
b/unstable/alpha-compositing/README
new file mode 100644
index 000..5826967
--- /dev/null
+++ b/unstable/alpha-compositing/README
@@ -0,0 +1,5 @@
+Alpha compositing protocol
+
+Maintainers:
+David Reveman 
+Alexandros Frantzis 
diff --git a/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml 
b/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
new file mode 100644
index 000..aae1d6e
--- /dev/null
+++ b/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
@@ -0,0 +1,172 @@
+
+
+
+  
+Copyright 2016  The Chromium Authors.
+Copyright 2017-2018 Collabora Ltd
+Copyright 2018  NXP
+
+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 protocol specifies a set of interfaces used to control the alpha
+compositing and blending of surface contents.
+
+Warning! The protocol described in this file is experimental and backward
+incompatible changes may be made. Backward compatible changes may be added
+together with the corresponding interface version bump. Backward
+incompatible changes are done by bumping the version number in the protocol
+and interface names and resetting the interface version. Once the protocol
+is to be declared stable, the 'z' prefix and the version number in the
+protocol and interface names are removed and the interface version number 
is
+reset.
+  
+
+  
+
+  The global interface exposing compositing and blending capabilities is
+  used to instantiate an interface extension for a wl_surface object.
+  This extended interface will then allow the client to specify the
+  blending equation and alpha value used for compositing the wl_surface.
+
+
+
+  
+
+
+
+  
+Informs the server that the client will not be using this
+