Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user
Hi Pekka, Thank you for your comments! On Wed, Oct 16, 2019 at 11:31 AM Pekka Paalanen wrote: > On Wed, 16 Oct 2019 10:54:08 +0200 > Olivier Fourdan wrote: > > > Hey Carlos, > > > > On Wed, Oct 16, 2019 at 10:43 AM Carlos Garnacho > wrote: > > > > > > This protocol takes over 3 different, but interrelated aspects of > > > DE/client interaction: > > > - Startup notification: presenting feedback about applications > > > being launched, either through the compositor or another client > > > - Focus stealing prevention: letting the compositor figure out > > > whether immediately switching focus to a surface makes sense. > > > - Window raising/activation: allowing existing clients to request > > > focus in a controlled manner. > > > > > > Signed-off-by: Carlos Garnacho > > Hi Carlos, > > this seems well written and a good idea to me. More comments inline. > > > > --- > > > Makefile.am | 1 + > > > unstable/presentation/README | 5 + > > > .../presentation/presentation-unstable-v1.xml | 175 ++ > > > 3 files changed, 181 insertions(+) > > > create mode 100644 unstable/presentation/README > > > create mode 100644 unstable/presentation/presentation-unstable-v1.xml > > > > > > diff --git a/Makefile.am b/Makefile.am > > > index d2c89a8..bd0e52d 100644 > > > --- a/Makefile.am > > > +++ b/Makefile.am > > > @@ -24,6 +24,7 @@ unstable_protocols = > \ > > > unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > > > > unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml > \ > > > unstable/primary-selection/primary-selection-unstable-v1.xml > \ > > > + unstable/presentation/presentation-unstable-v1.xml > \ > > > $(NULL) > > > > > > stable_protocols = > \ > > > diff --git a/unstable/presentation/README > b/unstable/presentation/README > > > new file mode 100644 > > > index 000..5a77e97 > > > --- /dev/null > > > +++ b/unstable/presentation/README > > > @@ -0,0 +1,5 @@ > > > +Presentation protocol > > > + > > > +Maintainers: > > > +Carlos Garnacho > > > + > > > diff --git a/unstable/presentation/presentation-unstable-v1.xml > b/unstable/presentation/presentation-unstable-v1.xml > > > new file mode 100644 > > > index 000..84bf961 > > > --- /dev/null > > > +++ b/unstable/presentation/presentation-unstable-v1.xml > > > @@ -0,0 +1,175 @@ > > > + > > > + > > > + > > > +Copyright 2018-2019 © Red Hat, Inc. > > > + > > > +Permission is hereby granted, free of charge, to any person > > > +obtaining a copy of this software and associated documentation > files > > > +(the "Software"), to deal in the Software without restriction, > > > +including without limitation the rights to use, copy, modify, > merge, > > > +publish, distribute, sublicense, and/or sell copies of the > Software, > > > +and to permit persons to whom the Software is furnished to do so, > > > +subject to the following conditions: > > > + > > > +The above copyright notice and this permission notice (including > the > > > +next paragraph) shall be included in all copies or substantial > > > +portions of the Software. > > > + > > > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > > > +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > > > +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > > > +NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT > HOLDERS > > > +BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN > > > +ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN > > > +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE > > > +SOFTWARE. > > > + > > > + > > > + > > > +This description provides a high-level overview of the interplay > between > > > +the interfaces defined this protocol. For details, see the > protocol > > > +specification. > > This is the protocol specification, the whole file. > Uh, got that bit of the wording from zwp_tablet, removed locally :). > > > > + > > > +The finality of the protocol is defining a compositor context for > > > +surfaces requesting to be presented. Presentation requests are > usually > > > +initiated by an existing surface, and acknowledged by a surface > being > > > +mapped. By having both ends talk with the compositor through this > protocol, > > > +the compositor has the information to implement different > commonplace > > > +policies: > > > + > > > +- Startup notification: The compositor may track wp_presenter > interfaces > > > + being created from the launcher side, and replied upon on the > launchee > > > + side. Compositors may also perform the application launcher role > > > + themselves. > > Ok, I see that. > > > > + > > > +- Focus stealing prevention: The
Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user
Hi Dorota! On Wed, Oct 16, 2019 at 11:16 AM Dorota Czaplejewicz < dorota.czaplejew...@puri.sm> wrote: > On Wed, 16 Oct 2019 10:43:00 +0200 > Carlos Garnacho wrote: > > > This protocol takes over 3 different, but interrelated aspects of > > DE/client interaction: > > - Startup notification: presenting feedback about applications > > being launched, either through the compositor or another client > > - Focus stealing prevention: letting the compositor figure out > > whether immediately switching focus to a surface makes sense. > > - Window raising/activation: allowing existing clients to request > > focus in a controlled manner. > > > > Signed-off-by: Carlos Garnacho > > --- > > Makefile.am | 1 + > > unstable/presentation/README | 5 + > > .../presentation/presentation-unstable-v1.xml | 175 ++ > > 3 files changed, 181 insertions(+) > > create mode 100644 unstable/presentation/README > > create mode 100644 unstable/presentation/presentation-unstable-v1.xml > > > > diff --git a/Makefile.am b/Makefile.am > > index d2c89a8..bd0e52d 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -24,6 +24,7 @@ unstable_protocols = > \ > > unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > > > unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml > \ > > unstable/primary-selection/primary-selection-unstable-v1.xml > \ > > + unstable/presentation/presentation-unstable-v1.xml > \ > > $(NULL) > > > > stable_protocols = > \ > > diff --git a/unstable/presentation/README b/unstable/presentation/README > > new file mode 100644 > > index 000..5a77e97 > > --- /dev/null > > +++ b/unstable/presentation/README > > @@ -0,0 +1,5 @@ > > +Presentation protocol > > + > > +Maintainers: > > +Carlos Garnacho > > + > > diff --git a/unstable/presentation/presentation-unstable-v1.xml > b/unstable/presentation/presentation-unstable-v1.xml > > new file mode 100644 > > index 000..84bf961 > > --- /dev/null > > +++ b/unstable/presentation/presentation-unstable-v1.xml > > @@ -0,0 +1,175 @@ > > + > > + > > + > > +Copyright 2018-2019 © Red Hat, Inc. > > + > > +Permission is hereby granted, free of charge, to any person > > +obtaining a copy of this software and associated documentation files > > +(the "Software"), to deal in the Software without restriction, > > +including without limitation the rights to use, copy, modify, merge, > > +publish, distribute, sublicense, and/or sell copies of the Software, > > +and to permit persons to whom the Software is furnished to do so, > > +subject to the following conditions: > > + > > +The above copyright notice and this permission notice (including the > > +next paragraph) shall be included in all copies or substantial > > +portions of the Software. > > + > > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > > +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > > +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > > +NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS > > +BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN > > +ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN > > +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE > > +SOFTWARE. > > + > > + > > + > > +This description provides a high-level overview of the interplay > between > > +the interfaces defined this protocol. For details, see the protocol > > +specification. > > + > > +The finality of the protocol is defining a compositor context for > > +surfaces requesting to be presented. Presentation requests are > usually > > +initiated by an existing surface, and acknowledged by a surface > being > > +mapped. By having both ends talk with the compositor through this > protocol, > > +the compositor has the information to implement different > commonplace > > +policies: > > Why does a presentation request have to come from a surface? I would > expect that, similarly to creating a surface, presenting it would not > require anything but a client (and maybe even no specific client) at least > in the case of startup notification. > Wrt the startup notification aspect of this protocol, the reasoning was that the spawning of UI-less processes (wayland clients or not) is rarely worth UI feedback. I think my reasoning makes sense, but perhaps there's some usecase I missed? However, the other aspects (activation, focus stealing prevention) do require a surface, so if the consensus is that we shouldn't do that for startup notification, should probably be split somehow. > > > + > > +- Startup notification: The compositor may track wp_presenter > interfaces > > + being created from the launcher side, and replied upon on
Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user
Hey :), On Wed, Oct 16, 2019 at 10:54 AM Olivier Fourdan wrote: > The name itself, “presentation” might be confusing considering we > already have a “presentation-time” protocol. > Right... I'm open to naming suggestions. Struggled a bit there, other single word that I could come up with are "activation" or "launch", "presentation" sounded more neutral though. Cheers, Carlos ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v7] unstable/drm-lease: DRM lease protocol support
On Thu Oct 17, 2019 at 6:08 PM Simon Ser wrote: > Should we keep the connector event, now that we have an unprivileged > DRM FD? > > Alternatives include: > > - Let the client use the FD to get what it needs (EDID/a configured > output/something else). Isn't this: > - Keep an event to advertise lease-able connector IDs What it's still there for? I'm not sure I understand, otherwise how is the client supposed to know which DRM resources it can request a lease for? How does it encode those intentions into a lease request? afaict the connector is still necessary. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v7] unstable/drm-lease: DRM lease protocol support
Should we keep the connector event, now that we have an unprivileged DRM FD? Alternatives include: - Let the client use the FD to get what it needs (EDID/a configured output/something else). - Keep an event to advertise lease-able connector IDs ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v7] unstable/drm-lease: DRM lease protocol support
From: Marius Vlad DRM leasing is a feature which allows the DRM master to "lease" a subset of its DRM resources to another DRM master via drmModeCreateLease, which returns a file descriptor for the new DRM master. We use this protocol to negotiate the terms of the lease and transfer this file descriptor to clients. In less DRM-specific terms: this protocol allows Wayland compositors to give over their GPU resources (like displays) to a Wayland client to exclusively control. The primary use-case for this is Virtual Reality headsets, which via the non-desktop DRM property are generally not used as desktop displays by Wayland compositors, and for latency reasons (among others) are most useful to games et al if they have direct control over the DRM resources associated with it. Basically, these are peripherals which are of no use to the compositor and may be of use to a client, but since they are tied up in DRM we need to use DRM leasing to get them into client's hands. Signed-off-by: Marius Vlad Signed-off-by: Drew DeVault --- v7's main change is that, upon binding to the drm_lease_manager, the server now sends along a non-master DRM fd for the client to use to enumerate resources. For this reason, the EDID event has been removed from the connector interface, under the assumption that clients who want to examine the EDID will line the connnector ID up with the appropriate resources from DRM. Updated patches are available for: wlroots: https://github.com/swaywm/wlroots/pull/1730 sway: https://github.com/swaywm/sway/pull/4289 kmscube: https://git.sr.ht/~sircmpwn/kmscube Xwayland: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/248 Additionally, the Vulkan extension has been polished up: https://github.com/KhronosGroup/Vulkan-Docs/pull/1001 A new implementation for Mesa's Vulkan WSI implementation will be available soon, as well as an implementation of the Wayland extension for Monado. Makefile.am | 1 + unstable/drm-lease/README| 5 + unstable/drm-lease/drm-lease-unstable-v1.xml | 246 +++ 3 files changed, 252 insertions(+) create mode 100644 unstable/drm-lease/README create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 345ae6a..d9fff89 100644 --- a/Makefile.am +++ b/Makefile.am @@ -4,6 +4,7 @@ unstable_protocols = \ unstable/pointer-gestures/pointer-gestures-unstable-v1.xml \ unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml \ unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml \ + unstable/drm-lease/drm-lease-unstable-v1.xml \ unstable/text-input/text-input-unstable-v1.xml \ unstable/text-input/text-input-unstable-v3.xml \ unstable/input-method/input-method-unstable-v1.xml \ diff --git a/unstable/drm-lease/README b/unstable/drm-lease/README new file mode 100644 index 000..16f8551 --- /dev/null +++ b/unstable/drm-lease/README @@ -0,0 +1,5 @@ +Linux DRM lease + +Maintainers: +Drew DeVault +Marius Vlad diff --git a/unstable/drm-lease/drm-lease-unstable-v1.xml b/unstable/drm-lease/drm-lease-unstable-v1.xml new file mode 100644 index 000..5fbc0e3 --- /dev/null +++ b/unstable/drm-lease/drm-lease-unstable-v1.xml @@ -0,0 +1,246 @@ + + + +Copyright © 2018 NXP +Copyright © 2019 Status Research Development GmbH. + +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 is used by Wayland compositors which act as Direct + Renderering Manager (DRM) masters to lease DRM resources to Wayland + clients. Once leased, the compositor will not use the leased resources +
Adding additional package for new waltham backend build environment
Hi, We are trying to create merge request for new weston backend Which uses waltham IPC library to connect to remote and transmit client buffer using gstreamer framework. What waltham-backend can do? - Per surface sharing to remote side - Input handling for the shared surface We pushed our changes here https://gitlab.freedesktop.org/VKadasani/weston/commits/waltham-transmitter-backend The auto triggered build job failed because it is not able to find the waltham library in the build environment used by gitlab. waltham IPC library https://github.com/waltham/waltham How do we add this in build environment to make the build job succeed? Best regards, Kenji Hosokawa Advanced Driver Information Technology Corp. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: XDC allocator workshop and Wayland dmabuf hints
On Thu, 17 Oct 2019 12:09:44 +0300 Pekka Paalanen said: > On Mon, 14 Oct 2019 06:02:59 -0700 > James Jones wrote: > > > On 10/13/19 2:05 PM, Scott Anderson wrote: > > > (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. > > Hi Scott and James, > > thanks for the write-up, it all sounds good to me FWI'mW. > > > > -As you note, this limits things to formats/layouts that can be > > composited (basically, things that can be textures). "Things that can > > be textures" is a superset of "Things that can be scanned out" for these > > purposes on our HW, so that's fine for NVIDIA. Does that hold up > > elsewhere? A secondary motivation for me was that the compositor could > > transition back to compositing from overlay compositing without > > requiring a blit or a new frame from the client in cases where that > > didn't hold up, but I don't know if that's interesting or not. > > It is interesting. > > The compositor transitioning back from overlay to compositing without > requiring a new frame from the client is a minimum requirement under > normal circumstances in Wayland architecture. If a compositor cannot do > that because of a buffer format, how could a conversion blit be > possible either? > > In Wayland architecture, having the compositor (display server) wait > for any client before it is able to update the screen is unacceptable > because it has a high risk of disturbing visual glitches. Or it has the result of a single non-responsive client holding the compositor hostage, unable to update the screen until that client responds. This also would be unacceptable. This requires there be a hardware accelerated conversion "blitter" somewhere that is able to convert between such displayable and non displayable formats, and/or that all such formats be clearly specified and documented and such conversions need to be done on the CPU as a fallback. Unless of course we're dealing with the kinds of content that are "secure" or "encrypted" etc. with some kind of DRM (digital rights management) scheme in place where the whole point is to have that buffer only ever displayable as a hardware plane. In these cases The compositor can replace such buffers with a picture of a horse to indicate that that buffer is not intended to be visible when it has to fall back to a composited path, but it needs to know that this is intended vs. a bug. > OTOH, I have heard of special use cases, where all buffers should > always go on overlays and falling back to composition would be > considered a bug. For such cases, there are some ideas towards that at > https://gitlab.freedesktop.org/wayland/weston/issues/244 . > > > Thanks, > pq -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: XDC allocator workshop and Wayland dmabuf hints
On Mon, 14 Oct 2019 06:02:59 -0700 James Jones wrote: > On 10/13/19 2:05 PM, Scott Anderson wrote: > > (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. Hi Scott and James, thanks for the write-up, it all sounds good to me FWI'mW. > -As you note, this limits things to formats/layouts that can be > composited (basically, things that can be textures). "Things that can > be textures" is a superset of "Things that can be scanned out" for these > purposes on our HW, so that's fine for NVIDIA. Does that hold up > elsewhere? A secondary motivation for me was that the compositor could > transition back to compositing from overlay compositing without > requiring a blit or a new frame from the client in cases where that > didn't hold up, but I don't know if that's interesting or not. It is interesting. The compositor transitioning back from overlay to compositing without requiring a new frame from the client is a minimum requirement under normal circumstances in Wayland architecture. If a compositor cannot do that because of a buffer format, how could a conversion blit be possible either? In Wayland architecture, having the compositor (display server) wait for any client before it is able to update the screen is unacceptable because it has a high risk of disturbing visual glitches. OTOH, I have heard of special use cases, where all buffers should always go on overlays and falling back to composition would be considered a bug. For such cases, there are some ideas towards that at https://gitlab.freedesktop.org/wayland/weston/issues/244 . Thanks, pq pgpj9Y2q2mukb.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
