Re: [PATCH v6] unstable/drm-lease: DRM lease protocol support
On 2019-07-30 14:53, Drew DeVault wrote: From: Marius Vlad DRM leasing is a feature which allows the DRM master to "lease" a subset of its DRM resources to another DRM master via drmModeCreateLease, which returns a file descriptor for the new DRM master. We use this protocol to negotiate 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. Talking about use-cases, I'm evaluating leasing for display calibration and profiling which requires leasing outputs which are are part of the desktop and also requires user interaction (keyboard, mice). Are there any ideas on how something like that would work? I think it would be great if it worked similar to fullscreen surfaces but input handling depends on having a surface but leasing an output is independent. Signed-off-by: Marius Vlad Signed-off-by: Drew DeVault --- When implementing this for Xwayland, we realized that we would really like to be able to obtain a lease with zero connectors. The kernel does not support this today, but adding support shouldn't be especially difficult. v6 changes the protocol accordingly to allow for leases with zero connectors, though on today's kernels this will fail vaugely with the finished event. 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..083d004 --- /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 + until the lease is
Re: [PATCH v6] unstable/drm-lease: DRM lease protocol support
On Tue, 30 Jul 2019 08:53:31 -0400 Drew DeVault wrote: > From: Marius Vlad > > DRM leasing is a feature which allows the DRM master to "lease" a subset > of its DRM resources to another DRM master via drmModeCreateLease, which > returns a file descriptor for the new DRM master. We use this protocol > to negotiate 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 Hi Drew, I seem to recall that you didn't want to add multi-DRM-device support here just yet and go first with just one implied DRM device. That is ok, but would be nice to have a TODO note somewhere near the top in the XML file saying that this will be re-designed to support multiple DRM devices at some point. > --- > When implementing this for Xwayland, we realized that we would really > like to be able to obtain a lease with zero connectors. The kernel does > not support this today, but adding support shouldn't be especially > difficult. v6 changes the protocol accordingly to allow for leases with > zero connectors, though on today's kernels this will fail vaugely with > the finished event. Can you point to the discussion or elaborate here on when a zero connector lease would be useful? I checked the Xwayland discussion and didn't see it there. I remember some old talk about giving out a no-resources lease first for discovering DRM resources to lease, but that didn't work because non-leased resources would not be visible either. > > 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..083d004 > --- /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
Re: One question on wayland desing on buffer
On Mon, 02 Sep 2019 08:40:41 +0800 "HalleyZhao" said: > Hi experts: wayland designs a light-weight server, usually client manages > buffer by themselves. It gives client more flexibility, migration > rendering/composition between different server, subsurface to keep layout > while keeping view hiarchy. however, there is something not convenient for > wayland server. take android surfaceflinger as counterpart, surfaceflinger > manages the buffer/layer of surface, then any client (owns the BufferQueue > client proxy) can update the surface directly. that is, mediaserver in > android can enqueueBuffer to update the surface directly. in wayland world, a > mediaserver has to pass the buffer (handle) to app/UI process, then the > surface is updated in app process. Is my above understanding correct? Correct. Clients are totally isolated from each other. Client A (media server) can't modify resources or even know client B (video player) exists VIA the compositor. This is both for security and simplicity. This makes Wayland compositors/servers nice and simple. They only deal with the client that owns those surfaces/buffers and can assume that client presents precisely what it wants to have presented. It's a "client problem" to deal with a media server if there is such a thing, take buffers from that media server and then pass them on to the compositor. This makes things like synchronisation much easier as "the client does it" and can either just draw media buffers using opengl or whatever mechanisms itself into a single buffer of it's own, or split them out into subsurfaces and ensure those subsurfaces and other rendered content are syncrhonized correctly. -- - 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
