Weston making system slow
I have Weston without notify enabled, with this Weston my UI application performance is fast. But I changed to Weston with notify, because I have to start as system service. I followed the procedure provided by you guys only. Now my UI application performance has reduced means application gets slow.responding very slow. Is Weston with notify lead to any performance degradation? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC wayland-protocols] Add secure output protocol
Hi Scott, As this was under discussion in last patchset, summarizing it here again: HDCP2.2 spec leaves the content-type classification to the content-provider (client). The same had been discussed earlier in #wayland, and the mailing list: https://lists.freedesktop.org/archives/wayland-devel/2018-June/038446.html https://lists.freedesktop.org/archives/wayland-devel/2018-June/038511.html The compositor in that case have to just pass on, the type of content to the kernel, which will take care of which protocol to use, based on content-type. Compositor, keeping track of the resolution and content-type is undesirable in my opinion. Regards, Ankit On 11/29/2018 9:36 AM, 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 (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
[PATCH wayland-protocols 3/3] linux-explicit-synchronization: Clarify implicit synchronization guarantees of release events
Clarify that after zwp_buffer_release_v1 events, otherwise unused buffers can be reused without any additional implicit synchronization. This is in contrast to wl_buffer.release, which doesn't guarantee that implicit synchronization is not required to safely use a buffer after the event is received. Signed-off-by: Alexandros Frantzis --- .../linux-explicit-synchronization-unstable-v1.xml | 10 ++ 1 file changed, 10 insertions(+) diff --git a/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml index 6d5783d..d0a8cf0 100644 --- a/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml +++ b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml @@ -226,6 +226,11 @@ signaled when all operations by the compositor on that buffer for that commit have finished. +Once the fence has signaled, and assuming the associated buffer is not +pending release from other wl_surface.commit requests, no additional +explicit or implicit synchronization is required to safely reuse or +destroy the buffer. + This event destroys the zwp_linux_buffer_release_v1 object. @@ -238,6 +243,11 @@ using it, or has a guarantee that all its operations on that buffer for that commit have finished. +Once this event is received, and assuming the associated buffer is not +pending release from other wl_surface.commit requests, no additional +explicit or implicit synchronization is required to safely reuse or +destroy the buffer. + This event destroys the zwp_linux_buffer_release_v1 object. -- 2.19.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-protocols 0/3] Updates to linux-explicit-synchronization
A series of assorted updates and clarifications for the linux-explicit-synchronization protocol. Alexandros Frantzis (3): linux-explicit-synchronization: Allow fences with opaque EGL buffers linux-explicit-synchronization: Warn about using the protocol while using graphics APIs linux-explicit-synchronization: Clarify implicit synchronization guarantees of release events ...x-explicit-synchronization-unstable-v1.xml | 29 --- 1 file changed, 25 insertions(+), 4 deletions(-) -- 2.19.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-protocols 2/3] linux-explicit-synchronization: Warn about using the protocol while using graphics APIs
Graphics APIs are expected to use this protocol under the hood, and since there can only be one user of explicit synchronization per surface, warn about using the protocol directly in such cases. Signed-off-by: Alexandros Frantzis --- .../linux-explicit-synchronization-unstable-v1.xml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml index 5809b42..6d5783d 100644 --- a/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml +++ b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml @@ -66,6 +66,12 @@ If the given wl_surface already has an explicit synchronization object associated, the synchronization_exists protocol error is raised. + +Graphics APIs, like EGL or Vulkan, that manage the buffer queue and +commits of a wl_surface themselves, are likely to be using this +extension internally. If a client is using such an API for a +wl_surface, it should not directly use this extension on that surface, +to avoid raising a synchronization_exists protocol error. https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-protocols 1/3] linux-explicit-synchronization: Allow fences with opaque EGL buffers
Add opaque EGL buffers to the supported buffer types for use with the explicit synchronization protocol. Opaque EGL buffers rely on the same EGL implementation in both the compositor and clients, which makes it straightforward to manage client expectations about fence support for such buffers. Also make it clearer that implementations are free to support other buffer types beyond the required ones. Signed-off-by: Alexandros Frantzis --- .../linux-explicit-synchronization-unstable-v1.xml | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml index db36284..5809b42 100644 --- a/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml +++ b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml @@ -26,7 +26,7 @@ DEALINGS IN THE SOFTWARE. - + This global is a factory interface, allowing clients to request explicit synchronization for buffers on a per-surface basis. @@ -76,7 +76,7 @@ - + This object implements per-surface explicit synchronization. @@ -101,8 +101,13 @@ Each surface can be associated with only one object of this interface at any time. - Explicit synchronization is guaranteed to be supported only for buffers - created with any version of the wp_linux_dmabuf buffer factory. + In version 1 of this interface, explicit synchronization is only + guaranteed to be supported for buffers created with any version of the + wp_linux_dmabuf buffer factory. Version 2 additionally guarantees + explicit synchronization support for opaque EGL buffers, which is a type + of platform specific buffers described in the EGL_WL_bind_wayland_display + extension. Compositors are free to support explicit synchronization for + additional buffer types. -- 2.19.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
