Re: [PATCH] unstable/drm-lease: DRM lease protocol support
On Fri Jun 28, 2019 at 10:37 AM Simon Ser wrote: > I'm now wondering if DRM leasing is that much different from xdg-shell > set_fullscreen requests. > > Is DRM leasing that much of a big deal regarding security? (Especially > if the compositor has a policy to lease only non-desktop outputs) > > One thing I'm concerned about is buffers read access. Someone posted a > Weston patch [1] to remove framebuffers when switching VTs, because the > new master could potentially read them. > > Would this type of thing be possible with DRM leases? Could a lessee > read buffers from the compositor's connectors? > > [1]: https://gitlab.freedesktop.org/wayland/weston/merge_requests/175 I tested this by acquiring a DRM lease and then attempting to mmap a framebuffer which was not included in the lease - EPERM. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2] 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 --- Makefile.am | 1 + unstable/drm-lease/README| 5 + unstable/drm-lease/drm-lease-unstable-v1.xml | 237 +++ 3 files changed, 243 insertions(+) create mode 100644 unstable/drm-lease/README create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml > I wonder if we should add the linux_ prefix here, just like > linux_dmabuf_unstable_v1. But maybe "drm" is enough (and maybe > linux_dmabuf_unstable_v1 should have been named drm_dmabuf_unstable_v1). I went -1 on this, because more operating systems than just Linux support DRM. Let's reconsider it if/when we promote linux_dmabuf from unstable to stable. > I think the protocol error enum is missing. Addressed in this version. > I'm not sure the client is in the best position to decide which > connectors to pick here. This patch adds an event advertising the EDID of the connector. Given that this is already tied to DRM, this seems like a reasonable addition. I think this should give clients everything they need to make an informed decision on which connectors to pick. > What would be other use-cases for DRM leases? I was thinking of adding DRM leasing support to wlroots, so you could run wlroots-based compositors through a DRM lease. Something would have to be done about input but it'd be a start. > There is a race with new connector objects. If the compositor sends a > new connector and the client destroys the manager at the same time, > the connector object is leaked. Addressed in this version by using a similar approach to the wlr-output-management protocol you mentioned. > > + > > + > > +Sent to indicate that the compositor will no longer honor requests > > for > > +DRM leases which include this connector. The client may still > > issue a > > +lease request including this connector, but the connector may not > > be > > +included in the issued lease. > > I wonder if the lease request should just fail if this happens. Added in this version. > For example, if I have two simultaneously connected VR headsets, each > running their own VR client, how would the two clients each lease only > the non-desktop connector corresponding to their headset? I imagine that the ideal case is that the VR clients would present their user with a list of available connectors (using the name or description events to provide names for them, or parsing the EDID and showing more detailed information), then letting the user sort it out. The worst case is that they issue conflicting requests, in which case the compositor will likely grant the first, withdraw offers for the leased connectors, and fail the second accordingly. Additional notes: Issuing a DRM lease with no objects, so that the user can scan the connectors and such, is not possible (EINVAL from the kernel). drmModeChangeLease didn't make the cut, but some code for it exists and I future-proofed this protocol in case it's added in the future. 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 +++
[PATCH wayland-protocols v2] xdg-output: deprecate the xdg_output.done event
This commit makes it so a wl_output.done event is guaranteed to be sent with a xdg_output.done event. This protocol change has been discussed in a recent xorg-devel discussions [1]. First let's recap why a change is needed: Xwayland listens to both wl_output and xdg_output changes. When an output's properties change, Xwayland expects to receive both a wl_output.done event and an xdg_output.done event. If that's not the case, Xwayland doesn't update its state (so old state is still exposed to X11 clients). Most of the time, both objects will be updated at the same time (e.g. the current mode is changed, so both wl_output.mode and xdg_output.logical_size are sent) so this won't be an issue. However in some situations only one of wl_output or xdg_output changes. For instance: - The mode is changed at the same time as the scale, resulting in the same logical_size. - The compositor doesn't expose the outputs' position via wl_output, so whenever the position changes only xdg_output is updated. Both KDE [2] and wlroots [3] have experienced this issue. For this reason, I'd like to update the xdg-output protocol to make it mandatory to always send a wl_output.done event after xdg_output changes. This effectively makes wl_output.done atomically apply all output state (including the state of add-on objects like xdg_output). This approach is pretty similar to wl_surface.commit: this request will atomically apply surface state including the state of e.g. the xdg_surface object tied to the wl_surface. To update the protocol to reflect this new requirement we can either: - **Bump xdg_output version**. The current protocol doesn't specify that wl_output.done must be sent, adding this new requirement would be a breaking change. We need to fix Xwayland for the current xdg_output version (maybe make it non-atomic for the current version, atomic for the new one?). Should we deprecate xdg_output.done in the new version? - **Don't bump xdg_output version**. This clarifies what is expected in practice by Xwayland, a major xdg_output consumer, and what is currently implemented by all compositors. There's one issue with the "don't bump" approach: indeed in practice compositors always send wl_output.done and xdg_output.done in pairs, however the ordering between those two events is not guaranteed. This means some compositors might send this sequence: wl_output.geometry(…) wl_output.done() xdg_output.logical_position(…) xdg_output.done() In this case the wl_output.done event fails to atomically apply the xdg_output state. For this reason, I think bumping the version is a better approach. This commit also deprecates xdg_output.done, which doesn't have any purpose anymore. [1]: https://lists.x.org/archives/xorg-devel/2019-April/058148.html [2]: https://phabricator.kde.org/D19253 [3]: https://github.com/swaywm/sway/issues/4064 Signed-off-by: Simon Ser Reviewed-by: Olivier Fourdan --- Changes from v1 to v2: state in xdg_output's description that wl_output.done is sent after properties have been sent (Jonas) unstable/xdg-output/xdg-output-unstable-v1.xml | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml b/unstable/xdg-output/xdg-output-unstable-v1.xml index ccbfe1c9a955..e3ed58766d17 100644 --- a/unstable/xdg-output/xdg-output-unstable-v1.xml +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml @@ -54,7 +54,7 @@ reset. - + A global factory interface for xdg_output objects. @@ -77,12 +77,17 @@ - + An xdg_output describes part of the compositor geometry. This typically corresponds to a monitor that displays part of the compositor space. + + After all xdg_output properties have been sent (when the object is + created and when properties are updated), a wl_output.done event is sent. + This allows changes to the output properties to be seen as atomic, even + if they happen via multiple events. @@ -157,6 +162,10 @@ This allows changes to the xdg_output properties to be seen as atomic, even if they happen via multiple events. + + For objects version 3 onwards, this event is deprecated. Compositors + are not required to send it anymore and must send wl_output.done + instead. -- 2.22.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: API feedback for an alternate libwayland implementation tailored for ffi bindings
On Mon, 01 Jul 2019 10:14:26 + "Victor Berger" wrote: > Hi everyone, > > A few weeks ago was discussed on IRC the idea or re-using my Rust > implementation of the Wayland protocol [1] to build an alternate > implementation of the libwayland C API. This is an idea I'm > interested in, and apparently at least a few other persons are > interested as well. > > However, if I'm going to re-implement a libwayland with a C API, I'd > be willing to adapt its API, to make it more friendly to FFI bindings > (after all Rust remains the main language in which I interact with > Wayland). Breaking backwards compatibility being naturally a > nonstarter, my idea is to rather create a library exposing both the > current C API and an alternate API, under a different namespace. > > This alternate API would be specifically targeted at languages > bindings, and not meant to be used directly by C applications. I have > made a draft of such an API for client-side, with detailed comments > about the guarantees it'd provide and how it should be used on this > gist: [2]. ... > My focus would then be to implement this new API using Rust, and then > add the necessary glue code to implement the current C API on top of > it, then exposing the whole thing as a drop-in alternative to > libwayland-client.so. I leave handling the server-side API for a > later time. > > I'd like to have your feedback on this tentative API before I try to > implement it, especially from other language bindings maintainers. I > may very well have missed some important question when designing it. > > [1]: https://github.com/Smithay/wayland-rs > [2]: https://gist.github.com/vberger/417729269d15cf11c8098aff683d5c56 Hi Victor, all I can personally say at this time is that the general idea sounds fine to me. I have no off-hand reason to NAK the idea of adding new APIs to libwayland to better suit more programming languages as long as everything that already exists keeps on working at least as well as it did. The current C implementation of libwayland is not going away. I imagine distributions will be choosing which implementation they ship, so it will be up to distributions to decide when the Rust implementation is good enough (features, quality, architecture and OS support) to take into use. As long as there is a maintained distribution using the C implementation, the C implementation will remain and be maintained. I wish you success in this effort. Thanks, pq pgpKM4ZTQvvr8.pgp Description: OpenPGP digital signature ___ 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
On Sat, Apr 27, 2019 at 07:44:39AM +, Simon Ser wrote: > This commit makes it so a wl_output.done event is guaranteed to be sent with a > xdg_output.done event. > > This protocol change has been discussed in a recent xorg-devel discussions > [1]. > > First let's recap why a change is needed: Xwayland listens to both wl_output > and > xdg_output changes. When an output's properties change, Xwayland expects to > receive both a wl_output.done event and an xdg_output.done event. If that's > not > the case, Xwayland doesn't update its state (so old state is still exposed to > X11 clients). > > Most of the time, both objects will be updated at the same time (e.g. the > current mode is changed, so both wl_output.mode and xdg_output.logical_size > are > sent) so this won't be an issue. However in some situations only one of > wl_output or xdg_output changes. For instance: > > - The mode is changed at the same time as the scale, resulting in the same > logical_size. > - The compositor doesn't expose the outputs' position via wl_output, so > whenever > the position changes only xdg_output is updated. > > Both KDE [2] and wlroots [3] have experienced this issue. > > For this reason, I'd like to update the xdg-output protocol to make it > mandatory > to always send a wl_output.done event after xdg_output changes. This > effectively > makes wl_output.done atomically apply all output state (including the state of > add-on objects like xdg_output). This approach is pretty similar to > wl_surface.commit: this request will atomically apply surface state including > the state of e.g. the xdg_surface object tied to the wl_surface. > > To update the protocol to reflect this new requirement we can either: > > - **Bump xdg_output version**. The current protocol doesn't specify that > wl_output.done must be sent, adding this new requirement would be a breaking > change. We need to fix Xwayland for the current xdg_output version (maybe > make > it non-atomic for the current version, atomic for the new one?). Should we > deprecate xdg_output.done in the new version? > - **Don't bump xdg_output version**. This clarifies what is expected in > practice > by Xwayland, a major xdg_output consumer, and what is currently implemented > by > all compositors. > > There's one issue with the "don't bump" approach: indeed in practice > compositors > always send wl_output.done and xdg_output.done in pairs, however the ordering > between those two events is not guaranteed. This means some compositors might > send this sequence: > > wl_output.geometry(…) > wl_output.done() > xdg_output.logical_position(…) > xdg_output.done() > > In this case the wl_output.done event fails to atomically apply the xdg_output > state. > > For this reason, I think bumping the version is a better approach. > > This commit also deprecates xdg_output.done, which doesn't have any purpose > anymore. Relying only on wl_output.done sounds good to me. Since the 'done' event here is eventally to go away, I think it'd be wise to state somewhere other than the 'done' documentation that the wl_output.done event is used to notify all changes have been communicated. Jonas (P.S. sorry for the ones in the To:/Cc: field for the multiple mails, for some reason mailman thinks I'm sending from my @redhat.com address, thus gets stuck on moderation. D.S.). > > [1]: https://lists.x.org/archives/xorg-devel/2019-April/058148.html > [2]: https://phabricator.kde.org/D19253 > [3]: https://github.com/swaywm/sway/issues/4064 > > Signed-off-by: Simon Ser > --- > unstable/xdg-output/xdg-output-unstable-v1.xml | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml > b/unstable/xdg-output/xdg-output-unstable-v1.xml > index ccbfe1c..01ac7a7 100644 > --- a/unstable/xdg-output/xdg-output-unstable-v1.xml > +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml > @@ -54,7 +54,7 @@ > reset. > > > - > + > >A global factory interface for xdg_output objects. > > @@ -77,7 +77,7 @@ > > > > - > + > >An xdg_output describes part of the compositor geometry. > > @@ -157,6 +157,10 @@ > > This allows changes to the xdg_output properties to be seen as > atomic, even if they happen via multiple events. > + > + For objects version 3 onwards, this event is deprecated. Compositors > + are not required to send it anymore and must send wl_output.done > + instead. > > > > -- > 2.21.0 > > > ___ > 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
