Re: How to release the weston_buffer after weston_view is destroyed.
Hi Pekka,
Thanks for your reply. Yes, preferably if I can hide the map and unmap from
client, in this case I cannot because it is part of a desktop shell. After
I unmap it and remap the view next time, it is not expected the shell to
continue from last draw. I would want the shell be drawing total different
things instead. If I simply remap, I shall see the last frame that did get
drawed.
It can be seen as a problem in the application, designing smarter clients
which is aware of such details, by not sending the last frame for example,
but I found an easier solution by unmap the view in the `frame_signal`. It
worked quite well.
Regards,
Sichem
Le ven. 3 août 2018 07 h 49, Pekka Paalanen a écrit :
> > On Sat, Jul 28, 2018 at 8:15 PM, Sichem Zhou
> wrote:
> >
> > > Dear Weston devs:
> > >
> > > Sorry for the bothering in when weston-5.0 is approaching, but I am
> stuck
> > > in the project for three days I need some one's help very much.
> > >
> > > I have a widget implementation of shell widgets that destroys the
> > > weston_view
> > > when pressed Esc. The widget is implemented in wayland EGL. Here is the
> > > view_destroy code.
> > >
> > > void
> > > twshell_close_ui_surface(struct weston_surface *wd_surface)
> > > {
> > > struct weston_view *view, *next;
> > > wd_surface->committed = NULL;
> > > wd_surface->committed_private = NULL;
> > > wl_list_for_each_safe(view, next, _surface->views,
> > > surface_link) {
> > > weston_view_destroy(view);
> > > }
> > > }
> > >
> > > The weston_view is destroyed but the the buffer in the last commit was
> not
> > > released and the done event was not sent to the widget. When I
> triggered
> > > the event to show widget again, the client was stuck in EGLSwapbuffer.
> I
> > > found out about this by using WAYLAND_DEBUG env variable, I hope to the
> > > way to release the buffer after umapping the weston view. Thanks very
> much.
>
> Hi,
>
> destroying or unmapping a weston_view is not meant to release the
> wl_surface's buffer. If the compositor spontaneously chooses to hide a
> surface, it may also spontaneously choose to show it again. To show a
> surface, it must have content, so if the renderer needs the buffer
> around, hiding cannot release the buffer.
>
> Views are Weston internal objects, clients are completely unaware of
> them. However, clients are aware of the mappedness of a wl_surface
> (weston_surface). Clients issue protocol requests and assume a specific
> sequence will map the surface. A compositor must keep up that
> appearance, even if it was a lie internally. That is, if a compositor
> spontaneously unmaps the view, it will not make the surface unmapped.
> This is also why we have 'bool is_mapped' in both weston_surface and
> weston_view. The client still thinks the surface is mapped, so it will
> not even expect the buffer to be released.
>
> The only client-visible effect of unmapping all views is that the frame
> callbacks will pause. This does not mean that the surface is unmapped,
> it is just temporarily not visible. Frame callbacks are used to
> throttle clients so that they don't draw frames that will not be shown.
>
> If you don't forcefully release the buffer, re-creating the view should
> let your app continue as usual while Weston is showing the last frame
> it got.
>
> It is also intentional that frame callback 'done' events are only ever
> triggered from repaint. Repaint makes the frame visible. As long as the
> frame is not processed yet, 'done' should not be sent.
>
> 'done' means that it is a good time for a continuously animating client
> to start drawing the next frame. It is an advisory throttling
> mechanism, and if your client really knows better, it can choose to
> draw new frames regardless.
>
> When you use EGL in a client, is it important to never let
> eglSwapBuffers() block for you. You need to track frame callbacks
> manually or set eglSwapInterval to zero, preferably both, so your
> application code does not get blocked by EGL API that was designed for
> applications far less smart than yours.
>
>
> On Sun, 29 Jul 2018 20:49:24 -0400
> Sichem Zhou wrote:
>
> > I actually found the reason, in the function `weston_output_repaint`, the
> > frame_callbacks
> > only send the done events for surface which has view on the compositor's
> > view_list,
> > but this poses a dilemma, since I cannot either destroy or unmap the view
> > before the
> > output repainted.
>
> I don't see a problem on the compositor side. You can unmap or destroy
> the view, and the frame callbacks will stall until you re-map the view
> again. The last buffer will not get released while unmapped, because
> the compositor needs it on re-map. The pending frame callbacks will
> resume once the view is re-mapped.
>
> It sounds like your problem is in the app: do not let eglSwapBuffers()
> block on a frame callback. Create a frame callback just before you call
> eglSwapBuffers(), and do not
Re: [v2, weston] gl-renderer.c: Use gr->egl_config to create pbuffer surface
Hi Adam, On Fri, 3 Aug 2018 at 19:05, Adam Jackson wrote: > On Thu, 2018-08-02 at 17:21 -0700, Madhurkiran Harikrishnan wrote: > > The original implementation always chose first egl config for pbuffer > > surface type, however the returned configs are implementation specific > > and egl config may not always match between ctx and surface. Hence, > > use gr->egl_config which already has the matching config but ensure that > > windows and pbuffer bit are set for the surface type. > > Does this make pbuffer surface support mandatory? (Or, is it mandatory > already.) If so it might make more sense to just do: It's only mandatory if configless_context is not supported. The patch we need to see from this is: if configless_context is not supported, select EGL_WINDOW_BIT | EGL_PBUFFER_BIT for gr->egl_config. Without selecting configs twice, or querying the configs later. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [v2, weston] gl-renderer.c: Use gr->egl_config to create pbuffer surface
On Thu, 2018-08-02 at 17:21 -0700, Madhurkiran Harikrishnan wrote:
> The original implementation always chose first egl config for pbuffer
> surface type, however the returned configs are implementation specific
> and egl config may not always match between ctx and surface. Hence,
> use gr->egl_config which already has the matching config but ensure that
> windows and pbuffer bit are set for the surface type.
Does this make pbuffer surface support mandatory? (Or, is it mandatory
already.) If so it might make more sense to just do:
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index 2c50d2da..97a8ef6a 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -3263,7 +3263,7 @@ gl_renderer_setup_egl_extensions(struct weston_compositor
*ec)
}
static const EGLint gl_renderer_opaque_attribs[] = {
- EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
+ EGL_SURFACE_TYPE, EGL_WINDOW_BIT | EGL_PBUFFER_BIT,
EGL_RED_SIZE, 1,
EGL_GREEN_SIZE, 1,
EGL_BLUE_SIZE, 1,
@@ -3273,7 +3273,7 @@ static const EGLint gl_renderer_opaque_attribs[] = {
};
static const EGLint gl_renderer_alpha_attribs[] = {
- EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
+ EGL_SURFACE_TYPE, EGL_WINDOW_BIT | EGL_PBUFFER_BIT,
EGL_RED_SIZE, 1,
EGL_GREEN_SIZE, 1,
EGL_BLUE_SIZE, 1,
As that way you'll always pick an EGLConfig with pbuffer support.
- ajax
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v6 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol
On August 3, 2018 6:12 PM, Dorota Czaplejewicz wrote: > Provides the ability to emulate keyboards by applications. Complementary to > input-method protocol. > > The interface is a mirror copy of wl_keyboard, with removed serials, and > added seat binding. > --- > Hello, > > this is the change I wanted to send previously (sorry). > > Regards, > Dorota Czaplejewicz Thanks for this update! Reviewed-by: Simon Ser > Makefile.am| 1 + > unstable/virtual-keyboard/README | 2 + > .../virtual-keyboard-unstable-v1.xml | 114 > + > 3 files changed, 117 insertions(+) > create mode 100644 unstable/virtual-keyboard/README > create mode 100644 unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 6394e26..d67aa1b 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -20,6 +20,7 @@ unstable_protocols = > \ > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > \ > unstable/xdg-output/xdg-output-unstable-v1.xml > \ > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > + unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml \ > unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > $(NULL) > > diff --git a/unstable/virtual-keyboard/README > b/unstable/virtual-keyboard/README > new file mode 100644 > index 000..a2c646d > --- /dev/null > +++ b/unstable/virtual-keyboard/README > @@ -0,0 +1,2 @@ > +Virtual keyboard protocol > + > diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > new file mode 100644 > index 000..9eae804 > --- /dev/null > +++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > @@ -0,0 +1,114 @@ > + > + > + > +Copyright © 2008-2011 Kristian Høgsberg > +Copyright © 2010-2013 Intel Corporation > +Copyright © 2012-2013 Collabora, Ltd. > +Copyright © 2018 Purism SPC > + > +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. > + > + > + > + > + The virtual keyboard provides an application with requests which > emulate > + the behaviour of a physical keyboard. > + > + This interface can be used by clients on its own to provide raw input > + events, or it can accompany the input method protocol. > + > + > + > + > +Provide a file descriptor to the compositor which can be > memory-mapped > +to provide a keyboard mapping description. > + > + +summary="keymap format"/> > + > + > + > + > + > + > + > + > + > + > +A key was pressed or released. > + > +The time argument is a timestamp with millisecond granularity, with > an > +undefined base. All requests regarding a single object must share the > +same clock. > + > +Keymap must be set before issuing this request. > + > + +summary="timestamp with millisecond granularity"/> > + > + +summary="physical state of the key"/> > + > + > + > + > +Notifies the compositor that the modifier and/or group state has > +changed, and it should update state. > + > +Keymap must be set before issuing this request. > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + A virtual keyboard manager allows an application to provide keyboard > + input events as if they came from a physical keyboard. > + > + If the compositor enables a keyboard to perform arbitrary actions, it > + should prevent untrusted
[PATCH v6 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol
Provides the ability to emulate keyboards by applications. Complementary to input-method protocol. The interface is a mirror copy of wl_keyboard, with removed serials, and added seat binding. --- Hello, this is the change I wanted to send previously (sorry). Regards, Dorota Czaplejewicz Makefile.am| 1 + unstable/virtual-keyboard/README | 2 + .../virtual-keyboard-unstable-v1.xml | 114 + 3 files changed, 117 insertions(+) create mode 100644 unstable/virtual-keyboard/README create mode 100644 unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 6394e26..d67aa1b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -20,6 +20,7 @@ unstable_protocols = \ unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ + unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml \ unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ $(NULL) diff --git a/unstable/virtual-keyboard/README b/unstable/virtual-keyboard/README new file mode 100644 index 000..a2c646d --- /dev/null +++ b/unstable/virtual-keyboard/README @@ -0,0 +1,2 @@ +Virtual keyboard protocol + diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml new file mode 100644 index 000..9eae804 --- /dev/null +++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml @@ -0,0 +1,114 @@ + + + +Copyright © 2008-2011 Kristian Høgsberg +Copyright © 2010-2013 Intel Corporation +Copyright © 2012-2013 Collabora, Ltd. +Copyright © 2018 Purism SPC + +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. + + + + + The virtual keyboard provides an application with requests which emulate + the behaviour of a physical keyboard. + + This interface can be used by clients on its own to provide raw input + events, or it can accompany the input method protocol. + + + + +Provide a file descriptor to the compositor which can be memory-mapped +to provide a keyboard mapping description. + + + + + + + + + + + + +A key was pressed or released. + +The time argument is a timestamp with millisecond granularity, with an +undefined base. All requests regarding a single object must share the +same clock. + +Keymap must be set before issuing this request. + + + + + + + + +Notifies the compositor that the modifier and/or group state has +changed, and it should update state. + +Keymap must be set before issuing this request. + + + + + + + + + + + + + + + A virtual keyboard manager allows an application to provide keyboard + input events as if they came from a physical keyboard. + + If the compositor enables a keyboard to perform arbitrary actions, it + should prevent untrusted clients from using this interface. + + + + +Creates a new virtual keyboard associated to a seat. + + + + + + + +Destroys the virtual keyboard manager. + +Existing zwp_virtual_keyboard_v1 objects remain valid. + + + + -- 2.14.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v5 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol
Provides the ability to emulate keyboards by applications. Complementary to input-method protocol. The interface is a mirror copy of wl_keyboard, with removed serials, and added seat binding. --- Hello again, I'm sending this patch to bring virtual-keyboard back in line with the v3 of the patch. This version doesn't contain any functional changes, but it's better formatted, and properties are referenced in a more idiomatic way. Having only minimal fixes compared to v3 (which is now also part of sway [0]), v5 looks pretty complete to me. Regards, Dorota Czaplejewicz [0] https://github.com/swaywm/sway/pull/2376 Makefile.am| 1 + unstable/virtual-keyboard/README | 2 + .../virtual-keyboard-unstable-v1.xml | 154 + 3 files changed, 157 insertions(+) create mode 100644 unstable/virtual-keyboard/README create mode 100644 unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 6394e26..d67aa1b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -20,6 +20,7 @@ unstable_protocols = \ unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ + unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml \ unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ $(NULL) diff --git a/unstable/virtual-keyboard/README b/unstable/virtual-keyboard/README new file mode 100644 index 000..a2c646d --- /dev/null +++ b/unstable/virtual-keyboard/README @@ -0,0 +1,2 @@ +Virtual keyboard protocol + diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml new file mode 100644 index 000..173f3bc --- /dev/null +++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml @@ -0,0 +1,154 @@ + + + +Copyright © 2008-2011 Kristian Høgsberg +Copyright © 2010-2013 Intel Corporation +Copyright © 2012-2013 Collabora, Ltd. +Copyright © 2018 Purism SPC + +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. + + + + + The virtual keyboard provides an application with requests which emulate + the behaviour of a physical keyboard. + + This interface can be used by clients on its own to provide raw input + events, or it can accompany the input method protocol. + + + + +Provide a file descriptor to the compositor which can be memory-mapped +to provide a keyboard mapping description. + + + + + + + + + + + + +A key was pressed or released. +The time argument is a timestamp with millisecond granularity, with an +undefined base. All requests regarding a single object must share the +same clock. + +Keymap must be set before issuing this request. + + + + + + + + +Notifies the compositor that the modifier and/or group state has +changed, and it should update state. + +Keymap must be set before issuing this request. + + + + + + + + + + + + + + + A virtual keyboard manager allows an application to provide keyboard + input events as if they came from a physical keyboard. + + If the compositor enables a keyboard to perform arbitrary actions, it + should prevent untrusted clients from using this interface. + + + + +Asks to create a new virtual keyboard associated to a seat. + +If the client is found unauthorized to create a virtual keyboard, then +
Re: [PATCH weston v5 03/14] libweston: add weston_debug API and implementation
On Fri, 20 Jul 2018 20:03:24 +0100
Daniel Stone wrote:
> From: Pekka Paalanen
>
> weston_debug is both a libweston API for relaying debugging messages,
> and the compositor-debug wayland protocol implementation for accessing those
> debug messages from a Wayland client.
>
> weston_debug_compositor_{create,destroy}() are private API, hence not
> exported.
>
> Signed-off-by: Pekka Paalanen
>
> append the debug scope name along with the timestamp in
> weston_debug_scope_timestamp API
>
> Signed-off-by: Maniraj Devadoss
> Reviewed-by: Pekka Paalanen
>
> Add explicit advertisement of debug scope names.
>
> Signed-off-by: Daniel Stone
> ---
> Makefile.am | 2 +
> libweston/compositor.c | 6 +
> libweston/compositor.h | 9 +
> libweston/weston-debug.c | 723 +++
> libweston/weston-debug.h | 107 ++
> 5 files changed, 847 insertions(+)
> create mode 100644 libweston/weston-debug.c
> create mode 100644 libweston/weston-debug.h
>
...
> diff --git a/libweston/weston-debug.c b/libweston/weston-debug.c
> new file mode 100644
> index 0..039247f14
> --- /dev/null
> +++ b/libweston/weston-debug.c
> @@ -0,0 +1,723 @@
> +/*
> + * Copyright © 2017 Pekka Paalanen
> + *
> + * 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.
> + */
> +
> +#include "config.h"
> +
> +#include "weston-debug.h"
> +#include "helpers.h"
> +#include "compositor.h"
> +
> +#include "weston-debug-server-protocol.h"
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/** Main weston-debug context
> + *
> + * One per weston_compositor.
> + *
> + * \internal
> + */
> +struct weston_debug_compositor {
> + struct weston_compositor *compositor;
> + struct wl_listener compositor_destroy_listener;
> + struct wl_global *global;
> + struct wl_list scope_list; /**< weston_debug_scope::compositor_link */
> +
> + struct weston_debug_scope *list;
Hi Daniel,
'list' member is now unused, replaced by the explicit advertisement
events.
> +};
> +
> +/** weston-debug message scope
> + *
> + * This is used for scoping debugging messages. Clients can subscribe to
> + * only the scopes they are interested in. A scope is identified by its name
> + * (also referred to as debug stream name).
> + */
> +struct weston_debug_scope {
> + char *name;
> + char *desc;
'desc' is never used anymore. This was meant to give the human looking
at the list of debug scopes a description of what they are, but looks
like the protocol does not carry it.
Do we not need it?
> + weston_debug_scope_cb begin_cb;
> + void *user_data;
> + struct wl_list stream_list; /**< weston_debug_stream::scope_link */
> + struct wl_list compositor_link;
> +};
> +
> +/** A debug stream created by a client
> + *
> + * A client provides a file descriptor for the server to write debug
> + * messages into. A weston_debug_stream is associated to one
> + * weston_debug_scope via the scope name, and the scope provides the
> messages.
> + * There can be several streams for the same scope, all streams getting the
> + * same messages.
> + */
> +struct weston_debug_stream {
> + int fd; /**< client provided fd */
> + struct wl_resource *resource; /**< weston_debug_stream_v1 object */
> + struct wl_list scope_link;
> +};
...
> +static void
> +bind_weston_debug(struct wl_client *client,
> +void *data, uint32_t version, uint32_t id)
> +{
> + struct weston_debug_compositor *wdc = data;
> + struct weston_debug_scope *scope;
> + struct wl_resource *resource;
> +
> + resource = wl_resource_create(client,
> + _debug_v1_interface,
> + version, id);
> + if (!resource) {
> + wl_client_post_no_memory(client);
> +
Re: connection: Detect overflows in length field.
On Thu, Aug 2, 2018 at 8:37 PM Michal Srb wrote:
>
> The length field can be any uint32 value. Two kinds of overflows may
> happen on 32 bit systems:
>
> 1) If the value is in range [UINT32_MAX-3, UINT32_MAX], the DIV_ROUNDUP
> will turn it into 0. Then `next` equals `p` and so the big `length` is not
> detected. But the wl_array will contain the original big value. Probably
> leading to crashes it is used later.
>
> 2) The pointer may overflow if the `length` is sufficiently big. In that
> case `next` will point to some memory before the beginning of the buffer
> and the the check `next > end` is not triggered. Using `next` later can
> crash.
>
> Signed-off-by: Michal Srb
> ---
>
> Note that the problem happens only on 32bit systems.
>
> src/connection.c| 19 +--
> tests/connection-test.c | 46 ++
> 2 files changed, 63 insertions(+), 2 deletions(-)
>
> diff --git a/src/connection.c b/src/connection.c
> index 294c521..b48f3a4 100644
> --- a/src/connection.c
> +++ b/src/connection.c
> @@ -46,6 +46,21 @@
>
> #define DIV_ROUNDUP(n, a) ( ((n) + ((a) - 1)) / (a) )
>
> +inline uint32_t *
> +ptr_add_saturating(uint32_t *p, uint32_t length) {
> + // Make sure that rounding length up will not overflow.
> + if (length > UINT32_MAX - sizeof(uint32_t))
> + return (uint32_t*) INTPTR_MAX;
> +
> + length = DIV_ROUNDUP(length, sizeof(uint32_t));
> +
> + // Make sure that adding length to p will not overflow.
> + if (length * sizeof(uint32_t) > UINTPTR_MAX - (uintptr_t) p)
> + return (uint32_t*) INTPTR_MAX;
> +
> + return p + length;
> +}
This patch probably fixes the problem in practice, but AFAICS the
patched version still, in theory, contains undefined behavior. The C99
standard says: "If both the pointer operand and the result point to
elements of the same array object, or one past the last element of the
array object, the evaluation shall not produce an overflow; otherwise,
the behavior is undefined."
Can you please change the patch so that it compares lengths instead of
comparing potentially out-of-bounds pointers, thereby avoiding
undefined behavior?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Why do I require a `wl_event_loop_add_idle` in creating a fork-exec wayland client
Hi Markus,
I am using the same parameters for socketpair. Here is my actual code:
static int
exec_wayland_client(const char *path, int fd)
{
if (seteuid(getuid()) == -1) {
return -1;
}
//unblock all the signals
sigset_t allsignals;
sigfillset();
sigprocmask(SIG_UNBLOCK, , NULL);
char sn[10];
int clientid = dup(fd);
snprintf(sn, sizeof(sn), "%d", clientid);
setenv("WAYLAND_SOCKET", sn, 1);
if (execlp(path, path, NULL) == -1) {
weston_log("failed to execute the client %s\n", path);
close(clientid);
return -1;
}
return 0;
}
struct wl_client *
tw_launch_client(struct weston_compositor *ec, const char *path)
{
int sv[2];
pid_t pid;
struct wl_client *client;
if (os_socketpair_cloexec(AF_UNIX, SOCK_STREAM, 0, sv)) {
weston_log("taiwins_client launch: "
"failed to create the socket for client `%s`\n",
path);
return NULL;
}
pid = fork();
if (pid == -1) {
close(sv[0]);
close(sv[1]);
weston_log("taiwins_client launch: "
"failed to create the process, `%s`\n",
path);
return NULL;
}
if (pid == 0) {
//you should close the server end
close(sv[0]);
//find a way to exec the child with sv[0];
//okay, this is basically setting the environment variables
exec_wayland_client(path, sv[1]);
//replace this
exit(-1);
}
//for parents, we don't need socket[1]
close(sv[1]);
//wayland client launch setup: by leveraging the UNIX
//socketpair functions. when the socket pair is created. The
client = wl_client_create(ec->wl_display, sv[0]);
if (!client) {
//this can't be happening, but housework need to be done
close(sv[0]);
weston_log("taiwins_client launch: "
"failed to create wl_client for %s", path);
return NULL;
}
//now we some probably need to add signal on the server side
return client;
}
The actual reason which causes the hang up in the process I haven't figured
out. But I guess it may be related the who is polling first, client or
server.
Regards,
Sichem
On Thu, Aug 2, 2018 at 11:46 PM, Markus Ongyerth wrote:
> On 2018/7月/11 09:42, Sichem Zhou wrote:
> > Hi All,
> >
> > I have a question related to the wl_client creation in the compositor. I
> > followed these step like weston did:
> >
> > 1. create socketpair.
> > 2. fork a process and close `socket[0]` in child, close `socket[1]` in in
> > parent process.
> > 3. set the `WAYLAND_SOCKET` to `socket[1]`.
> > 4. exec the program.
>
> You seem to be missing a few steps here. They probably exist in your code,
> but
> it suggests to me that you might cause this somewhere else.
> I have code [1] that doesn't rely on any idle dispatching and worked fine
> so
> far.
>
> This includes a single step in the compositor:
> 3. Set up client with wl_display_create_client
>
>
> Just lookking at my code, I see and remember that I'm using AF_UNIX and
> SOCK_STREAM arguments for the socketpair, which ones do you pass to yours?
>
>
> [1] https://github.com/waymonad/waymonad/blob/master/src/
> Waymonad/Actions/Spawn.hs#L181
>
> ongy
>
> >
> > I found out if I do this directly both compositor and client will stuck
> in
> > the eventloop. It seems the compositor is stuck in the
> > `wl_display_flush_clients` and client is stuck in
> `wl_event_queue_dispatch`
> > and internally stuck in the epoll. So I think both compositor and client
> > were waiting each other for some update.
> >
> > Then I found out that I need to pack the code in a
> > `wl_event_loop_idle_func_t` and add it to the event_loop. But I am
> couldn't
> > figure out why did the compositor stuck in the first place and why did
> the
> > wl_event_loop_add_idle helped.
> >
> > Thanks very much.
> > SZ
>
> > ___
> > 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: How to release the weston_buffer after weston_view is destroyed.
> On Sat, Jul 28, 2018 at 8:15 PM, Sichem Zhou wrote:
>
> > Dear Weston devs:
> >
> > Sorry for the bothering in when weston-5.0 is approaching, but I am stuck
> > in the project for three days I need some one's help very much.
> >
> > I have a widget implementation of shell widgets that destroys the
> > weston_view
> > when pressed Esc. The widget is implemented in wayland EGL. Here is the
> > view_destroy code.
> >
> > void
> > twshell_close_ui_surface(struct weston_surface *wd_surface)
> > {
> > struct weston_view *view, *next;
> > wd_surface->committed = NULL;
> > wd_surface->committed_private = NULL;
> > wl_list_for_each_safe(view, next, _surface->views,
> > surface_link) {
> > weston_view_destroy(view);
> > }
> > }
> >
> > The weston_view is destroyed but the the buffer in the last commit was not
> > released and the done event was not sent to the widget. When I triggered
> > the event to show widget again, the client was stuck in EGLSwapbuffer. I
> > found out about this by using WAYLAND_DEBUG env variable, I hope to the
> > way to release the buffer after umapping the weston view. Thanks very much.
Hi,
destroying or unmapping a weston_view is not meant to release the
wl_surface's buffer. If the compositor spontaneously chooses to hide a
surface, it may also spontaneously choose to show it again. To show a
surface, it must have content, so if the renderer needs the buffer
around, hiding cannot release the buffer.
Views are Weston internal objects, clients are completely unaware of
them. However, clients are aware of the mappedness of a wl_surface
(weston_surface). Clients issue protocol requests and assume a specific
sequence will map the surface. A compositor must keep up that
appearance, even if it was a lie internally. That is, if a compositor
spontaneously unmaps the view, it will not make the surface unmapped.
This is also why we have 'bool is_mapped' in both weston_surface and
weston_view. The client still thinks the surface is mapped, so it will
not even expect the buffer to be released.
The only client-visible effect of unmapping all views is that the frame
callbacks will pause. This does not mean that the surface is unmapped,
it is just temporarily not visible. Frame callbacks are used to
throttle clients so that they don't draw frames that will not be shown.
If you don't forcefully release the buffer, re-creating the view should
let your app continue as usual while Weston is showing the last frame
it got.
It is also intentional that frame callback 'done' events are only ever
triggered from repaint. Repaint makes the frame visible. As long as the
frame is not processed yet, 'done' should not be sent.
'done' means that it is a good time for a continuously animating client
to start drawing the next frame. It is an advisory throttling
mechanism, and if your client really knows better, it can choose to
draw new frames regardless.
When you use EGL in a client, is it important to never let
eglSwapBuffers() block for you. You need to track frame callbacks
manually or set eglSwapInterval to zero, preferably both, so your
application code does not get blocked by EGL API that was designed for
applications far less smart than yours.
On Sun, 29 Jul 2018 20:49:24 -0400
Sichem Zhou wrote:
> I actually found the reason, in the function `weston_output_repaint`, the
> frame_callbacks
> only send the done events for surface which has view on the compositor's
> view_list,
> but this poses a dilemma, since I cannot either destroy or unmap the view
> before the
> output repainted.
I don't see a problem on the compositor side. You can unmap or destroy
the view, and the frame callbacks will stall until you re-map the view
again. The last buffer will not get released while unmapped, because
the compositor needs it on re-map. The pending frame callbacks will
resume once the view is re-mapped.
It sounds like your problem is in the app: do not let eglSwapBuffers()
block on a frame callback. Create a frame callback just before you call
eglSwapBuffers(), and do not call eglSwapBuffers() again until that
frame callback has signalled. That way eglSwapBuffers should never
block indefinitely. Additionally you can set eglSwapInterval to zero in
case there are situations where you really need to eglSwapBuffers()
before the frame callback has signalled.
Thanks,
pq
pgpANAKmE6Zvn.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libxkbcommon 0.8.1
libxkbcommon 0.8.1 == - Fix various problems found in the meson build (see commit messages for more details): - Fix compilation on Darwin. - Fix compilation of the x11 tests and demos when XCB is installed in a non-standard location. - Fix xkbcommon-x11.pc missing the Requires specification. - Fix various problems found with fuzzing and Coverity (see commit messages for more details): - Fix stack overflow in the XKB text format parser when evaluating boolean negation. - Fix NULL-dereferences in the XKB text format parser when some unsupported tokens appear (the tokens are still parsed for backward compatibility). - Fix NULL-dereference in the XKB text format parser when parsing an xkb_geometry section. - Fix an infinite loop in the Compose text format parser on some inputs. - Fix an invalid free() when using multiple keysyms. - Replace the Unicode characters for the leftanglebracket and rightanglebracket keysyms from the deprecated LEFT/RIGHT-POINTING ANGLE BRACKET to MATHEMATICAL LEFT/RIGHT ANGLE BRACKET. - Reject out-of-range Unicode codepoints in xkb_keysym_to_utf8 and xkb_keysym_to_utf32. Tarball: git tag: xkbcommon-0.8.1 https://xkbcommon.org/download/libxkbcommon-0.8.1.tar.xz MD5:890da32b01f7cd48414e6428b6f44e64 libxkbcommon-0.8.1.tar.xz SHA1: 0c38d160120e79e6d0d49e1c83b73bcbd6b02335 libxkbcommon-0.8.1.tar.xz SHA256: 8d1df6bdf216950da611e66cff1af576710aad79772de3be6e131019f761f897 libxkbcommon-0.8.1.tar.xz Ran ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/4] doc: Use GitLab MRs for patches, not the list
On Sat, 14 Jul 2018 14:09:07 +0100 Daniel Stone wrote: > Though Wayland and the protocols still use mail-based patch review, > Weston can now move to GitLab MRs with review through that system. > > Add some documentation on how to submit patches through GitLab, > specifically targeted at people who may be familiar with GitLab review, > but not familiar with our rebasing microcommit workflow. > > Signed-off-by: Daniel Stone > --- > CONTRIBUTING.md | 140 > 1 file changed, 70 insertions(+), 70 deletions(-) Hi Daniel, I'm happy to move to MR-based work flow immediately. > > diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md > index 91b3fffe9..33b78510e 100644 > --- a/CONTRIBUTING.md > +++ b/CONTRIBUTING.md > @@ -4,8 +4,45 @@ Contributing to Weston > Sending patches > --- > > -Patches should be sent to **wayland-devel@lists.freedesktop.org**, using > -`git send-email`. See [git documentation] for help. > +Patches should be sent via > +[GitLab merge > requests](https://docs.gitlab.com/ce/gitlab-basics/add-merge-request.html). > +Weston is > +[hosted on freedesktop.org's > GitLab](https://gitlab.freedesktop.org/wayland/weston/): > +in order to submit code, you should create an account on this GitLab > instance, > +fork the core Weston repository, push your changes to a branch in your new > +repository, and then submit these patches for review through a merge request. > + > +Weston formerly accepted patches via `git-send-email`, sent to > +**wayland-devel@lists.freedesktop.org**; these were > +[tracked using > Patchwork](https://patchwork.freedesktop.org/projects/wayland/). > +Some old patches continue to be sent this way, and we may accept small new > +patches sent to the list, but please send all new patches through GitLab > merge > +requests. > + > +Formatting and separating commits > +- > + > +Unlike many projects using GitHub and GitLab, Weston has a > +[linear history](http://www.bitsnbites.eu/a-tidy-linear-git-history/). This From the above link, I found this: http://www.bitsnbites.eu/git-history-work-log-vs-recipe/ which explain the below in more words. Maybe include this link as well? Linear history doesn't exactly imply "recipe" history, we want both. I only came to think of the differences after reading both of the above links. > +means that every commit should be small, digestible, stand-alone, and > +functional. Rather than a chronological commit history like this: > + > +doc: final docs for view transforms > +fix tests when disabled, redo broken doc formatting > +better transformed-view iteration (thanks Hannah!) > +try to catch more cases in tests > +tests: add new spline test > +fix compilation on splines > +doc: notes on reticulating splines > +compositor: add spline reticulation for view transforms > + > +we aim to have a clean history which only reflects the final state, broken up > +into functional groupings: > + > +compositor: add spline reticulation for view transforms > +compositor: new iterator for view transforms > +tests: add view-transform correctness tests > +doc: fix Doxygen formatting for view transforms > > The first line of a commit message should contain a prefix indicating > what part is affected by the patch followed by one sentence that > @@ -54,74 +91,37 @@ deserve, and the patches may cause redundant review > effort. > Tracking patches and following up > - > > -[Wayland Patchwork](http://patchwork.freedesktop.org/project/wayland/list/) > is > -used for tracking patches to Wayland and Weston. Xwayland patches are tracked > -with the [Xorg project](https://patchwork.freedesktop.org/project/Xorg/list/) > -instead. Libinput patches, even though they use the same mailing list as > -Wayland, are not tracked in the Wayland Patchwork. > - > -The following applies only to Wayland and Weston. We need a wayland patch to remove notes about Weston like the above. ... > -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/Weston. > +Once submitted to GitLab, your patches will be reviewed by the Weston > +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
Re: [PATCH weston 3/4] README: Move to Markdown, rewrite introduction
On Sat, 14 Jul 2018 14:09:06 +0100 Daniel Stone wrote: > Move the README file to Markdown, and update it to attempt to explain > the current status and use of Weston. > > The first sections are user-facing, so they can quickly understand what > Weston is, what it does, what it doesn't do, and how to go about using > it. The following sections on libweston and for distribution packagers > are left intact, but should probably be moved to separate documents. > > Signed-off-by: Daniel Stone > --- > README => README.md| 108 ++--- > doc/wayland-screenshot.jpg | Bin 0 -> 143832 bytes > 2 files changed, 78 insertions(+), 30 deletions(-) > rename README => README.md (69%) > create mode 100644 doc/wayland-screenshot.jpg > > diff --git a/README b/README.md > similarity index 69% > rename from README > rename to README.md > index a0a078c46..404859548 100644 > --- a/README > +++ b/README.md > @@ -1,33 +1,81 @@ > - Weston > - == > - > -Weston is the reference implementation of a Wayland compositor, and a > -useful compositor in its own right. Weston has various backends that > -lets it run on Linux kernel modesetting and evdev input as well as > -under X11. Weston ships with a few example clients, from simple > -clients that demonstrate certain aspects of the protocol to more > -complete clients and a simplistic toolkit. There is also a quite > -capable terminal emulator (weston-terminal) and an toy/example desktop > -shell. Finally, weston also provides integration with the Xorg server > -and can pull X clients into the Wayland desktop and act as an X window > -manager. > - > -Refer to https://wayland.freedesktop.org/building.html for building > -weston and its dependencies. > - > -The test suite can be invoked via `make check`; see > -https://wayland.freedesktop.org/testing.html for additional details. > - > -Developer documentation can be built via `make doc`. Output will be in > -the build root under > - > -docs/developer/html/index.html > -docs/tools/html/index.html > - > - > - > - Libweston > - = > +Weston > +== > + > + I don't think you need to spell out the whole URL, a local path should suffice according to the gitlab markdown manual:  Btw. the file you add in this patch is called wayland-screenshot.jpg instead. > + > +Weston is the reference implementation of a Wayland compositor, as well as a > +useful environment in and of itself. > + > +Out of the box, Weston provides a partly-featured desktop, or a full-featured Can we call it full-featured even there? More like "a basic environment". Or "simple"? "Lean"? > +environment for non-desktop uses such as automotive, embedded, in-flight, > +industrial, kiosks, set-top boxes and TVs. It also provides a library > allowing > +other projects to build their own full-featured environments on top of > Weston's > +core and provide their own full-featured environments. A bit of repetition of "full-featured environments". > + > +The core focus of Weston is correctness and reliability. Weston aims to be > lean > +and fast, but more importantly, to be predictable. Whilst Weston does have > known > +bugs and shortcomings, we avoid unknown or variable behaviour as much as > +possible. The core compositor's performance should always be predictable and > +measurable. Could you explain what you mean by predictable and measurable for me? I can't think of tangible examples of what would or would not be like that. Not necessarily to add to the README but as background information. > + > +A small suite of example or demo clients are also provided: though they can > be > +useful in themselves, their main purpose is to be an example or test case for > +others building compositors or clients. > + > +If you are after a more mainline desktop experience, the > +[GNOME](https://www.gnome.org) and [KDE](https://www.kde.org) projects > provide > +full-featured desktop environments built on the Wayland protocol. Many other > +projects also exist providing Wayland clients and desktop environments: you > are > +not limited to just what you can find in Weston. > + > +Reporting issues and contributing > += > + > +Weston's development is > +[hosted on freedesktop.org > GitLab](https://gitlab.freedesktop.org/wayland/weston/). > +Please also see [the contributing document](CONTRIBUTING.md), which details > how > +to make code or non-technical contributions to Weston. > + > +Building Weston > +=== > + > +Weston is built using autotools, with `autogen.sh` and `make`. It often > depends > +on the current release versions of > +[Wayland](https://gitlab.freedesktop.org/wayland/wayland) and >
Re: Weston default pixel format
Hi Daniel, El 03/08/18 a las 10:41, Daniel Stone escribió: Hi Santiago, On Fri, 3 Aug 2018 at 09:28, Santiago Otero wrote: El 03/08/18 a las 09:35, Pekka Paalanen escribió: No, you cannot use another KMS application at the same time as Weston is active. The kernel DRM core will forbid access (denies DRM Master status) if there is already something using KMS, so at any time you can only run either Weston or some other DRM KMS app. The fact that you think it is possible suggests that you are using a deliberately broken downstream kernel. A normal upstream kernel would deny this. I think there's no need to get DRM Master if you only want to use another different plane for drawing (/dev/dri/controlD64). I've got it working this way. Control nodes have been removed from upstream kernels a couple of years ago: https://cgit.freedesktop.org/drm/drm-tip/commit/?id=8a357d10043c75e980e7fcdb60d2b913491564af From the commit message, it sounds like your downstream kernel tree has some changes to allow control nodes to be used in this way, since they did not work out of the box. It will also not work with modern atomic drivers anymore. Yes, you're right. I didn't know it. I'm using NXP kernel for iMX8M (based on version 4.9.88) and it has DRM control nodes back. My recommendation instead is to rearchitect your software stack so that Weston will be the only KMS app in the system, and video players push their content via Wayland through Weston, using e.g. the Wayland dmabuf extension and Weston's support for overlays (and underlays, if someone implements them). I've tried to make it work with Wayland dmabuf with little success. The performance was bad, there was tearing and it didn't work for HDR video due to some KMS/DRM properties that I need to set. Using patched Weston and my player with KMS, now it's working right. We've had good success with this in the past: the performance has been completely fine, and tearing is just a result of missing synchronisation, which at a guess could be improper handling of buffer release events. GStreamer's waylandsink is a good example of how to correctly use the interface if that helps. I've already did some tests with Gstreamer's waylandsink and there was some tearing in the video. I need to try again. One problem that I saw was that with Gstreamer's waylandsink there was some overload due to a lot of calls to drmModeAddFB2 from Weston. I though that drmModeAddFB2 was only needed first time when you register the buffer. Doing a strace to Weston process I see a lot of these calls during Gstreamer playing video with waylandsink: ioctl(16, DRM_IOCTL_PRIME_FD_TO_HANDLE, 0xee93e910) = 0 ioctl(16, DRM_IOCTL_MODE_ADDFB2, 0xee93e828) = 0 ioctl(16, DRM_IOCTL_GEM_CLOSE, 0xee93e9b0) = 0 I need to do some more tests with my application and linux-dmabuf extension. Colour management is not yet supported in Weston, but a topic we are working on. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel Thank you very much, Santiago Otero ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: DRM page-flip with damage for weston
On Fri, 20 Jul 2018 12:26:22 +0100 Daniel Stone wrote: > Hi Deepak, > > On Fri, 20 Jul 2018 at 12:21, Deepak Singh Rawat wrote: > > In brief the damage is in frame-buffer coordinate of attached fb to the > > plane. > > Unlike plane src coordinates, damage clips are not in 16.16 fixed point. > > Damage > > during page flip is helpful for some drivers like vmwgfx where each > > framebuffer > > change needs to be transmitted over network, usb, etc. > > > > Now that I have some code ready and got it working for vmwgfx driver, the > > next step is to change weston to send damage during page flip. With my > > current > > understanding of weston I think the damage received during > > weston_output.repaint() is exactly what I am looking for ? Does this damage > > region during weston_output.repaint() is in frame-buffer coordinate ? > > The damage region received during output repaint is in Weston's global > co-ordinate space. To shift to CRTC co-ordinates, you need to > translate the damage region by (-output->x, -output->y). When we are > using the renderer, there is no scaling, so CRTC co-ordinates and > framebuffer co-ordinates are guaranteed to be equal. This only > accounts for the primary plane; damage to views on other planes is > considered separately. Hi, that explanation misses the output transform and scale, which need to be taken into account when converting from the global damage space into the framebuffer damage space. To see how to get the renderer damage in framebuffer coordinates, see gl_renderer_repaint_output() and how the path using swap_buffers_with_damage works. Mind, that EGL damage coordinate system might be y-flipped compared to what you need. The pixman renderer has similar code to handle damage and might be easier to follow: region_global_to_output(). Thanks, pq pgp7mNe2OoimU.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3 weston 4/5] tests: add test for setting gamma
Hi Harsha, On Tue, 24 Jul 2018 at 10:11, Harsha Manjula Mallikarjun (RBEI/ECF3) wrote: > > So, I understand this would be a manual test where the user would > > visually verify that the gamma is changing in the way they would > > expect? I have no problem with that, but it would be nice to see this > > documented with an example as to what the user should be seeing with > > each step. > > An application showing gamma value on screen along with the image would > be very nice I thought. Due to lack of time I did this simple plugin which > just changes Gamma/CTM irrespective of any application that is running. User > has to run an app manually though. > I can document with comments in code what is expected on display, with > each step increment in CTM and gamma values. Would this be fine? That would be great, thankyou! > > Also, lastly, is there a public libweston user for this new API? > > There is a plan to use this from wayland-ivi-extension. Then a demo > app will also come along :-). > > > It would be nice to have this be configurable. > I did not get this point. Do you mean that the inclusion of this test would be > configurable during build time? OR this feature of Gamma and CTM itself needs > to included based on configuration? Ah no - always building the support is definitely the right thing to do! What I meant was some support for loading the configuration of the degamma LUT + CTM + gamma LUT, either from weston.ini, or udev properties, or some other file. This way people could calibrate and then statically configure systems to have the correct values when they are not required to change dynamically. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston default pixel format
Hi Santiago, On Fri, 3 Aug 2018 at 09:28, Santiago Otero wrote: > El 03/08/18 a las 09:35, Pekka Paalanen escribió: >> No, you cannot use another KMS application at the same time as Weston >> is active. The kernel DRM core will forbid access (denies DRM Master >> status) if there is already something using KMS, so at any time you can >> only run either Weston or some other DRM KMS app. >> >> The fact that you think it is possible suggests that you are using a >> deliberately broken downstream kernel. A normal upstream kernel would >> deny this. > > I think there's no need to get DRM Master if you only want to use another > different plane for drawing (/dev/dri/controlD64). I've got it working this > way. Control nodes have been removed from upstream kernels a couple of years ago: https://cgit.freedesktop.org/drm/drm-tip/commit/?id=8a357d10043c75e980e7fcdb60d2b913491564af From the commit message, it sounds like your downstream kernel tree has some changes to allow control nodes to be used in this way, since they did not work out of the box. It will also not work with modern atomic drivers anymore. >> My recommendation instead is to rearchitect your software stack so that >> Weston will be the only KMS app in the system, and video players push >> their content via Wayland through Weston, using e.g. the Wayland dmabuf >> extension and Weston's support for overlays (and underlays, if someone >> implements them). > > I've tried to make it work with Wayland dmabuf with little success. The > performance was bad, there was tearing and it didn't work for HDR video due > to some KMS/DRM properties that I need to set. Using patched Weston and my > player with KMS, now it's working right. We've had good success with this in the past: the performance has been completely fine, and tearing is just a result of missing synchronisation, which at a guess could be improper handling of buffer release events. GStreamer's waylandsink is a good example of how to correctly use the interface if that helps. Colour management is not yet supported in Weston, but a topic we are working on. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/2] Automatically build docs through GitLab CI
Hi, On Fri, 3 Aug 2018 at 09:21, Pekka Paalanen wrote: > On Mon, 16 Jul 2018 14:14:33 -0300 Matheus Santana wrote: > > There is an issue for this: https://gitlab.freedesktop. > > org/wayland/wayland/issues/48 > > > > For now, this series builds wayland within the site's pipeline by cloning > > the repository and building everything just like in wayland's CI itself. > > Basically the same approach used for libinput's docs. > > > > We still need to automate docs publishing for weston and wayland-protocols > > but I couldn't find any related docs already published in the site. Are > > they already published? > > thanks for working on this, much appreciated. > > These patches are: > Acked-by: Pekka Paalanen > > The CI stuff is still pretty new to me, so I'd leave pushing and > verifying these for Daniel if that's ok. Strictly thinking we'd need to > wait for the final Wayland release before merging these, but I'd be ok > landing these earlier too, the patches do not touch Wayland bits but > only the CI bits. I was waiting for the changes Peter requested; with those changes, the series looks good to me and for anyone to push when ready is: Acked-by: Daniel Stone Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston default pixel format
El 03/08/18 a las 09:35, Pekka Paalanen escribió: On Thu, 12 Jul 2018 13:49:06 +0200 Santiago Otero wrote: Hi all, I have a display device that supports up to three different display buffers: one graphic layer and two video layers. The graphic layer is at the top (zpos=2). I'm using Weston (DRM backend) with a Qt5 application at full screen (graphic layer). Weston is using pixel format XR24 even if Qt5 is using AR24. Hi, that is intentional, yes. Weston's renderers have been designed to produce opaque framebuffers, because it assumes the primary plane is the bottom-most for now. Weston so far does not support underlays and it might be a lot of work to support them, but I also think it would be nice to have if it can be done with "generic userspace" i.e. not having any driver specific knowledge coded in Weston or weston.ini. Hi, I was able to make it work with two changes: 1-Force Weston to use a ARGB format with option "gbm-format=argb" 2-Patch gl-renderer.c to render with alpha: glBlendFunc(GL_ONE, GL_ZERO) => glBlendFunc(GL_SRC_ALPHA, GL_SRC_ALPHA); In another application I have a video player application that renders by DRM into a video layer (zpos=1). The problem is that the HW alpha composition is not working due to Weston pixel format and because of that I'm unable to see the video layer. No, you cannot use another KMS application at the same time as Weston is active. The kernel DRM core will forbid access (denies DRM Master status) if there is already something using KMS, so at any time you can only run either Weston or some other DRM KMS app. The fact that you think it is possible suggests that you are using a deliberately broken downstream kernel. A normal upstream kernel would deny this. I think there's no need to get DRM Master if you only want to use another different plane for drawing (/dev/dri/controlD64). I've got it working this way. Is there any configuration option to force Weston to use AR24? Sorry, no, we will not take changes into Weston upstream that depend on features that the kernel upstream specifically rejects (multiple DRM masters or the equivalent on the same DRM device). You could get around the single DRM master limitation by using DRM leases, but AFAIK, you cannot lease just some planes of a CRTC, you have to lease the CRTC as a whole, which means you still cannot have one process driving one plane and another process driving another plane on the same CRTC (output). Yet. If it becomes bossible via DRM leases in upstream kernel, then we can discuss this again. However, bare in mind, that the design is that Weston will be in full control of all outputs it touches, which means that leasing out a plane instead of a whole CRTC will need a glitch-free synchronization protocol between Weston and the app. My recommendation instead is to rearchitect your software stack so that Weston will be the only KMS app in the system, and video players push their content via Wayland through Weston, using e.g. the Wayland dmabuf extension and Weston's support for overlays (and underlays, if someone implements them). I've tried to make it work with Wayland dmabuf with little success. The performance was bad, there was tearing and it didn't work for HDR video due to some KMS/DRM properties that I need to set. Using patched Weston and my player with KMS, now it's working right. Thanks, pq Thank you very much. ___ 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: [PATCH 0/2] Automatically build docs through GitLab CI
On Mon, 16 Jul 2018 14:14:33 -0300 Matheus Santana wrote: > Hello! > > There is an issue for this: https://gitlab.freedesktop. > org/wayland/wayland/issues/48 > > For now, this series builds wayland within the site's pipeline by cloning > the repository and building everything just like in wayland's CI itself. > Basically the same approach used for libinput's docs. > > We still need to automate docs publishing for weston and wayland-protocols > but I couldn't find any related docs already published in the site. Are > they already published? Hi, thanks for working on this, much appreciated. These patches are: Acked-by: Pekka Paalanen The CI stuff is still pretty new to me, so I'd leave pushing and verifying these for Daniel if that's ok. Strictly thinking we'd need to wait for the final Wayland release before merging these, but I'd be ok landing these earlier too, the patches do not touch Wayland bits but only the CI bits. Weston and wayland-protocols docs are not yet published. I haven't even checked how they would look like, there might be work to improve them before they become useful for publishing. I'm not sure wayland-protocols even has build rules to make docs. Thanks, pq pgpTpL5gdphdO.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston default pixel format
On Thu, 12 Jul 2018 13:49:06 +0200 Santiago Otero wrote: > Hi all, > > I have a display device that supports up to three different display > buffers: one graphic layer and two video layers. The graphic layer is at > the top (zpos=2). > > I'm using Weston (DRM backend) with a Qt5 application at full screen > (graphic layer). Weston is using pixel format XR24 even if Qt5 is using > AR24. Hi, that is intentional, yes. Weston's renderers have been designed to produce opaque framebuffers, because it assumes the primary plane is the bottom-most for now. Weston so far does not support underlays and it might be a lot of work to support them, but I also think it would be nice to have if it can be done with "generic userspace" i.e. not having any driver specific knowledge coded in Weston or weston.ini. > In another application I have a video player application that renders by > DRM into a video layer (zpos=1). The problem is that the HW alpha > composition is not working due to Weston pixel format and because of > that I'm unable to see the video layer. No, you cannot use another KMS application at the same time as Weston is active. The kernel DRM core will forbid access (denies DRM Master status) if there is already something using KMS, so at any time you can only run either Weston or some other DRM KMS app. The fact that you think it is possible suggests that you are using a deliberately broken downstream kernel. A normal upstream kernel would deny this. > Is there any configuration option to force Weston to use AR24? Sorry, no, we will not take changes into Weston upstream that depend on features that the kernel upstream specifically rejects (multiple DRM masters or the equivalent on the same DRM device). You could get around the single DRM master limitation by using DRM leases, but AFAIK, you cannot lease just some planes of a CRTC, you have to lease the CRTC as a whole, which means you still cannot have one process driving one plane and another process driving another plane on the same CRTC (output). Yet. If it becomes bossible via DRM leases in upstream kernel, then we can discuss this again. However, bare in mind, that the design is that Weston will be in full control of all outputs it touches, which means that leasing out a plane instead of a whole CRTC will need a glitch-free synchronization protocol between Weston and the app. My recommendation instead is to rearchitect your software stack so that Weston will be the only KMS app in the system, and video players push their content via Wayland through Weston, using e.g. the Wayland dmabuf extension and Weston's support for overlays (and underlays, if someone implements them). Thanks, pq pgpjmeMXnADdq.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
