Re: [RFC wayland-protocols] presentation-time: Add request to subscribe to wl_output presentation timings
On 17/08/17 05:10 PM, Pekka Paalanen wrote: > On Mon, 7 Aug 2017 19:00:40 +0300 > Alexandros Frantzis wrote: > >> + >> + > + summary="high 32 bits of the seconds part of the new >> presentation timebase"/> >> + > + summary="low 32 bits of the seconds part of the new presentation >> timebase"/> >> + > + summary="nanoseconds part of the new presentation timebase"/> >> + > + summary="new presentation interval in nanoseconds"/> > > I wonder if people would find use for MSC counter in this event? Roman > Gilg for Xwayland/Present perhaps? Yes, that would be useful, since PresentCompleteNotify events always include an MSC value. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
wl_shm_format documentation
Hi, I noticed that the documentation for wl_shm_format doesn't specify whether formats use premultiplied alpha or not. Is that intentional or an oversight? Regards, Fredrik ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 1/2] text-backend: Allow client hiding of input panel
On Fri, 2017-08-04 at 22:04 +0200, jana...@gmail.com wrote:
> On Sat, 2017-06-24 at 16:03 -0500, Joshua Watt wrote:
> > Previously, the hide_input_panel and show_input_panel messages for
> > the text
> > input protocol were limited to specific cases, such as showing the
> > panel on
> > activation, or making the panel visible after activation. Now,
> > clients are
> > allowed to toggle the panel visiblity at will as long as they are
> > the
> > currently
> > active client
> >
> > Signed-off-by: Joshua Watt
>
> Thanks, both patches are improving the implementation in the right
> way:
Any further update on this?
>
> Reviewed-by: Jan Arne Petersen
>
> > ---
> > compositor/text-backend.c | 22 --
> > 1 file changed, 12 insertions(+), 10 deletions(-)
> >
> > diff --git a/compositor/text-backend.c b/compositor/text-backend.c
> > index bf5c45c..6add101 100644
> > --- a/compositor/text-backend.c
> > +++ b/compositor/text-backend.c
> > @@ -64,7 +64,7 @@ struct text_input_manager {
> > struct wl_global *text_input_manager_global;
> > struct wl_listener destroy_listener;
> >
> > - struct text_input *current_panel;
> > + struct text_input *current_text_input;
> >
> > struct weston_compositor *ec;
> > };
> > @@ -140,11 +140,15 @@ deactivate_input_method(struct input_method
> > *input_method)
> > input_method->context = NULL;
> >
> > if (wl_list_empty(&text_input->input_methods) &&
> > - text_input->input_panel_visible) {
> > + text_input->input_panel_visible &&
> > + text_input->manager->current_text_input == text_input)
> > {
> > wl_signal_emit(&ec->hide_input_panel_signal, ec);
> > text_input->input_panel_visible = false;
> > - text_input->manager->current_panel = NULL;
> > }
> > +
> > + if (text_input->manager->current_text_input == text_input)
> > + text_input->manager->current_text_input = NULL;
> > +
> > zwp_text_input_v1_send_leave(text_input->resource);
> > }
> >
> > @@ -206,12 +210,11 @@ text_input_activate(struct wl_client *client,
> >
> > input_method_context_create(text_input, input_method);
> >
> > - current = text_input->manager->current_panel;
> > + current = text_input->manager->current_text_input;
> >
> > if (current && current != text_input) {
> > current->input_panel_visible = false;
> > wl_signal_emit(&ec->hide_input_panel_signal, ec);
> > - text_input->manager->current_panel = NULL;
> > }
> >
> > if (text_input->input_panel_visible) {
> > @@ -219,8 +222,8 @@ text_input_activate(struct wl_client *client,
> >text_input->surface);
> > wl_signal_emit(&ec->update_input_panel_signal,
> >&text_input->cursor_rectangle);
> > - text_input->manager->current_panel = text_input;
> > }
> > + text_input->manager->current_text_input = text_input;
> >
> > zwp_text_input_v1_send_enter(text_input->resource,
> > text_input->surface-
> > >resource);
> > @@ -335,7 +338,8 @@ text_input_show_input_panel(struct wl_client
> > *client,
> >
> > text_input->input_panel_visible = true;
> >
> > - if (!wl_list_empty(&text_input->input_methods)) {
> > + if (!wl_list_empty(&text_input->input_methods) &&
> > + text_input == text_input->manager->current_text_input)
> > {
> > wl_signal_emit(&ec->show_input_panel_signal,
> >text_input->surface);
> > wl_signal_emit(&ec->update_input_panel_signal,
> > @@ -353,10 +357,8 @@ text_input_hide_input_panel(struct wl_client
> > *client,
> > text_input->input_panel_visible = false;
> >
> > if (!wl_list_empty(&text_input->input_methods) &&
> > - text_input == text_input->manager->current_panel) {
> > - text_input->manager->current_panel = NULL;
> > + text_input == text_input->manager->current_text_input)
> > wl_signal_emit(&ec->hide_input_panel_signal, ec);
> > - }
> > }
> >
> > static void
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2] Introduce xdg-foreign protocol
On Wed, Jul 27, 2016 at 9:54 AM, Jonas Ådahl wrote: > xdg-foreign is a protocol meant to enable setting up inter surface > relationships across clients. Potential use cases are out-of-process > dialogs, such as file dialogs, meant to be used by sandboxed processes > that may not have the access it needs to implement such dialogs. one question about set_parent_of: what is the cardinality of parent/child relationship? can an imported surface be parent of more than one child? a child i suppose can't have more than one parent? is the server supposed to take care of it? (silently replacing the old relationships or sending protocol errors?) -- Marco Martin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2] Introduce xdg-foreign protocol
On Thu, Aug 10, 2017 at 3:47 AM, Jonas Ådahl wrote: > > Anyhow, "export_surface" or maybe even "export_toplevel" (as that is the only > thing we allow exporting anyway) seems fine to me. The "import" request > should be renamed in a similar manner as well then. here attached a patch to rename the calls to export_toplevel and import_toplevel, is that ok? -- Marco Martin From 79a050a0a22cb9f04d7679fe2fcd28e797e6957c Mon Sep 17 00:00:00 2001 From: Marco Martin Date: Thu, 17 Aug 2017 16:58:33 +0200 Subject: [PATCH] rename export and import calls as export is a reserved keyword in C++, in order for the output generated by wayland_scanner to compile correctly rename export to export_toplevel and import to import_toplevel Signed-off-by: Marco Martin --- unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml index 062b090..6d5e1f1 100644 --- a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml @@ -69,7 +69,7 @@ - + The export request exports the passed surface so that it can later be imported via xdg_importer. When called, a new xdg_exported object will @@ -101,7 +101,7 @@ - + The import request imports a surface from any client given a handle retrieved by exporting said surface using xdg_exporter.export. When -- 2.7.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] presentation-time: Add request to subscribe to wl_output presentation timings
On Thu, Aug 17, 2017 at 11:10:12AM +0300, Pekka Paalanen wrote: > On Mon, 7 Aug 2017 19:00:40 +0300 > Alexandros Frantzis wrote: > > > The presentation.timing request creates an object that informs the > > client about the presentation timing of an wl_output in a precise and > > low-overhead way, without the need to submit any surface content updates. > > Hi Alf, > > the last time I looked at a similar feature was in 2014, the > refresh_stream interface mentioned in > https://lists.freedesktop.org/archives/wayland-devel/2014-March/013598.html > > However, I like your / the Chromium design much better, because it doesn't > spam events on every refresh. > > This is a good proposal. Hi Pekka, thank you very much for the feedback. I have replied to your comments in-line. > > This functionality can be useful, among others, for clients that want to > > know > > the output timings before submitting any frames, and also for clients that > > want to synchronize with server presentation timings using a simpler and > > lower > > overhead way compared to the presentation.feedback objects. > > Yes, I suppose this is justification enough, and particularly as CrOS > is already using it. > > > This functionality is inspired by the vsync-feedback protocol used in > > Chromium OS ([1]), and, hopefully, with such an addition, Chromium OS may > > be able to transition to the upstream protocol. > > > > It may be useful to add a flags argument to the presentation_timing.updated > > event, containing information that can be used to assess the reliability > > (and > > other aspects) of the provided information, in a manner similar to the > > 'kind' > > flags for the presentation_feedback.presented event. > > I think adding flags would be nice indeed, even if we cannot specify > any at the moment. Flags can be added in later revisions but only if > the argument already exists, otherwise we would need to add a new event. Ack. I will add a flags argument to the event. > > A proof-of-concept implementation for Weston can be found at: > > > > https://git.collabora.com/cgit/user/alf/weston.git/log/?h=presentation-time-v2 > > > > [1] > > https://chromium.googlesource.com/chromium/src/third_party/+/master/wayland-protocols/unstable/vsync-feedback/vsync-feedback-unstable-v1.xml > > > > --- > > stable/presentation-time/presentation-time.xml | 68 > > -- > > 1 file changed, 65 insertions(+), 3 deletions(-) > > > > This is written as an evolution of wp_presentation global interface > which has already been declared stable. There is the question whether > that is fine or should the new feature be an independent extension. > > To me this question is more about the ability to extend the > interface(s) later and a feature being optional or mandatory. If the > request is added in wp_presentation interface, then we intend it to be > an integral part of wp_presentation, and that if a compositor wants to > expose wp_presentation, then it will also want to expose the new > feature. The rationale is that if a second new feature is added to > wp_presentation, it is not possible to support it without also > implementing the first new feature. > > IOW, the question is, would anyone realistically need the option to not > implement wp_presentation_timing while they do implement wp_presentation? > > My initial feeling is "no", which would favour adding this in > wp_presentation. > > Also, adding to wp_presentation makes it easy to define things with the > presentation clock provided by wp_presentation. > > All in all, good. > > > diff --git a/stable/presentation-time/presentation-time.xml > > b/stable/presentation-time/presentation-time.xml > > index a46994c..56a9c9b 100644 > > --- a/stable/presentation-time/presentation-time.xml > > +++ b/stable/presentation-time/presentation-time.xml > > @@ -3,7 +3,7 @@ > > > > > > > > -Copyright © 2013-2014 Collabora, Ltd. > > +Copyright © 2013-2017 Collabora, Ltd. > > Just checking, the Chromium extension's copyrights don't need to be > added here, do they? Actually, I think we should add them, since the proposed additions are heavily based on the Chromium protocol, I just forgot to do so for this RFC. > > Permission is hereby granted, free of charge, to any person obtaining a > > copy of this software and associated documentation files (the > > "Software"), > > @@ -25,8 +25,8 @@ > > DEALINGS IN THE SOFTWARE. > > > > > > - > > - > > + > > + > > > > > > > > @@ -49,6 +49,16 @@ > >presentation time can differ from the compositor's predicted > >display update time and the update's target time, especially > >when the compositor misses its target vertical blanking period. > > + > > + > > + > > + In some cases it's also useful for clients to know about the > > + presentation timing of an output without having submitted a > > + surface content update. For this purpose the '
[wayland+ILM] Understanding crash in wayland lib with media playback
Dear All, I am observing crash with following callstack. Is this known issue to anyone here and fixed with latest version? How should one debug such issues? Any inputs, comments or suggestion to debug and fix this issue would be very helpful. I am suspecting it is related to bug https://bugs.freedesktop.org/show_bug.cgi?id=91273 but how to confirm it? I am planing to test with wayland/weston/wayland-ivi-extension 1.11.0. Use-case: This is with video playback and clicking on next menu for next video multiple times. We are using i.MX6 based target on linux 4.1 and following packages with fbdev-backend and ivi-shell with ivi-controller.so. In one configuration ILM (client and control apis are used directly) in gui application while with other configuration there is central controller (layer manager) for managinf view of gui. However with both the configuration this is observed. wayland 1.9.0 weston 1.9.0 waylandivi-extension 1.9.1 qtwayland 5.5.1 media playback framework: cinemo or gstreamer (with both the framework we observed the crash) with wayland/ILM support. Callsatck: (gdb) bt #0 0x68f4a384 in wl_list_insert (list=0x68eace68, elm=0x617c3c48, elm@entry=0x68f472d0 ) at /usr/src/debug/wayland/1.9.0-r0/wayland-1.9.0/src/wayland-util.c:51 #1 0x68f47310 in queue_event (len=24, display=0xc) at /usr/src/debug/wayland/1.9.0-r0/wayland-1.9.0/src/wayland-client.c:1127 #2 read_events (display=0xc) at /usr/src/debug/wayland/1.9.0-r0/wayland-1.9.0/src/wayland-client.c:1212 #3 0x68f47e40 in wl_display_read_events (display=0x614fd178) at /usr/src/debug/wayland/1.9.0-r0/wayland-1.9.0/src/wayland-client.c:1324 #4 0x4ba52a5c in control_thread (p_ret=) at /usr/src/debug/wayland-ivi-extension/1.9.1-r0/git/ivi-layermanagement-api/ilmControl/src/ilm_control_wayland_platform.c:1234 #5 0x4af9607c in start_thread (arg=0x677df3b0) at pthread_create.c:339 #6 0x4af20a20 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.s from /data/work/vmp/workspace/sdk/sysroots/cortexa9hf-vfp-neon-elina-linux-gnueabi/lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thanking you for your time in advance. Thanks & Regards, Vikash ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] presentation-time: Add request to subscribe to wl_output presentation timings
On Mon, 7 Aug 2017 19:00:40 +0300 Alexandros Frantzis wrote: > The presentation.timing request creates an object that informs the > client about the presentation timing of an wl_output in a precise and > low-overhead way, without the need to submit any surface content updates. Hi Alf, the last time I looked at a similar feature was in 2014, the refresh_stream interface mentioned in https://lists.freedesktop.org/archives/wayland-devel/2014-March/013598.html However, I like your / the Chromium design much better, because it doesn't spam events on every refresh. This is a good proposal. > This functionality can be useful, among others, for clients that want to know > the output timings before submitting any frames, and also for clients that > want to synchronize with server presentation timings using a simpler and lower > overhead way compared to the presentation.feedback objects. Yes, I suppose this is justification enough, and particularly as CrOS is already using it. > This functionality is inspired by the vsync-feedback protocol used in > Chromium OS ([1]), and, hopefully, with such an addition, Chromium OS may > be able to transition to the upstream protocol. > > It may be useful to add a flags argument to the presentation_timing.updated > event, containing information that can be used to assess the reliability (and > other aspects) of the provided information, in a manner similar to the 'kind' > flags for the presentation_feedback.presented event. I think adding flags would be nice indeed, even if we cannot specify any at the moment. Flags can be added in later revisions but only if the argument already exists, otherwise we would need to add a new event. > A proof-of-concept implementation for Weston can be found at: > > https://git.collabora.com/cgit/user/alf/weston.git/log/?h=presentation-time-v2 > > [1] > https://chromium.googlesource.com/chromium/src/third_party/+/master/wayland-protocols/unstable/vsync-feedback/vsync-feedback-unstable-v1.xml > > --- > stable/presentation-time/presentation-time.xml | 68 > -- > 1 file changed, 65 insertions(+), 3 deletions(-) > This is written as an evolution of wp_presentation global interface which has already been declared stable. There is the question whether that is fine or should the new feature be an independent extension. To me this question is more about the ability to extend the interface(s) later and a feature being optional or mandatory. If the request is added in wp_presentation interface, then we intend it to be an integral part of wp_presentation, and that if a compositor wants to expose wp_presentation, then it will also want to expose the new feature. The rationale is that if a second new feature is added to wp_presentation, it is not possible to support it without also implementing the first new feature. IOW, the question is, would anyone realistically need the option to not implement wp_presentation_timing while they do implement wp_presentation? My initial feeling is "no", which would favour adding this in wp_presentation. Also, adding to wp_presentation makes it easy to define things with the presentation clock provided by wp_presentation. All in all, good. > diff --git a/stable/presentation-time/presentation-time.xml > b/stable/presentation-time/presentation-time.xml > index a46994c..56a9c9b 100644 > --- a/stable/presentation-time/presentation-time.xml > +++ b/stable/presentation-time/presentation-time.xml > @@ -3,7 +3,7 @@ > > > > -Copyright © 2013-2014 Collabora, Ltd. > +Copyright © 2013-2017 Collabora, Ltd. Just checking, the Chromium extension's copyrights don't need to be added here, do they? > > Permission is hereby granted, free of charge, to any person obtaining a > copy of this software and associated documentation files (the > "Software"), > @@ -25,8 +25,8 @@ > DEALINGS IN THE SOFTWARE. > > > - > - > + > + > > > > @@ -49,6 +49,16 @@ >presentation time can differ from the compositor's predicted >display update time and the update's target time, especially >when the compositor misses its target vertical blanking period. > + > + > + > + In some cases it's also useful for clients to know about the > + presentation timing of an output without having submitted a > + surface content update. For this purpose the 'timing' request > + creates an object that is used to inform the client about > + the presentation timing of an wl_output in a precise and > + low-overhead way. > + > > > > @@ -122,6 +132,22 @@ > > > > + > + > + > + > +Create a new timing object that represents a subscription to > +presentation timing updates on the given wl_output object. > + > +The newly created object will signal an update to notify the > subscriber > +of initial timing parameters as soon as these become available. If the o
