waylandsink touch shell

[xp21987]

Hello:I'm a newer to use wayland. Now I use wayland sink to play video, 
there're  two small cases want to confirm. First, I want to confirm does 
wayland sink support ivi shell?Second, how should I get touch event for the 
video surface in the application of playing video?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston v2 1/1] compositor-drm: Unref current & pending fb when deactivating the session

[Miguel A. Vico]

With

 commit 47224cc9312fef05c1a523ea0da0a1aae66f100d
 Author: Daniel Stone 
 Date:   Sat Nov 5 08:04:07 2016 +

 compositor-drm: Delete drm_backend_set_modes

we stopped forcing a modeset when restoring the session. The motivation
was that we would use a stale fb, so better to let the next repaint
handle it.

However, if drm_output::fb_current != NULL, we won't issue a modeset
upon repaint.

This change unreferences both drm_output::fb_current and
drm_output::fb_pending when deactivating the current session. This
ensures the very first repaint after restoring the session will issue a
modeset.

Signed-off-by: Miguel A Vico Moya 
---
 libweston/compositor-drm.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 8e1e788f..63153271 100644
--- a/libweston/compositor-drm.c
+++ b/libweston/compositor-drm.c
@@ -3164,6 +3164,14 @@ session_notify(struct wl_listener *listener, void *data)
wl_list_for_each(output, >output_list, base.link) {
output->base.repaint_needed = false;
drmModeSetCursor(b->drm.fd, output->crtc_id, 0, 0, 0);
+   if (output->fb_current != NULL) {
+   drm_fb_unref(output->fb_current);
+   output->fb_current = NULL;
+   }
+   if (output->fb_pending != NULL) {
+   drm_fb_unref(output->fb_pending);
+   output->fb_pending = NULL;
+   }
}
 
output = container_of(compositor->output_list.next,
-- 
2.13.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Make DRM plane-assignment algorithm tolerant of more than one fullscreen opaque surface?

[Matt Hoosier]

Currently the DRM backend ends up picking the bottom-most view which meets
all the checks for eligibility, for direct scanout usage. If more than one
such view exists, we get a visual result counter to expectations -- it
should be the highest-sorted such view that the user sees.

The big loop in drm_assign_planes() that assigns views to planes iterates
top-down through the weston_layer's, and the particular way that the
results are progressively stored in variables means that if more than one
pass through the loop encounters a view which is fullscreen and opaque then
the last (bottom-most) of these passes is the one whose results are
preserved upon exit from the loop.

This normally isn't a problem because mostly only the desktop shell has a
notion of fullscreen surfaces. desktop-shell takes care (whether
intentionally or not I can't tell) that when running full-screen only the
logical topmost view is actively left in a visible weston_layer.

Is it informally expected that the shell must not allow more than one
fullscreen view at a time? Would there be interest in a patch to
drm_assign_planes() that adds a bit more awareness to the plane assignment
so that only the topmost fullscreen opaque view is picked for scanout?
___
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

[Jonas Ådahl]

On Thu, Aug 10, 2017 at 10:44:30AM +0200, Marco Martin wrote:
> On Thu, Aug 10, 2017 at 3:47 AM, Jonas Ådahl  wrote:
> > On Wed, Aug 09, 2017 at 01:42:51PM +0200, Marco Martin wrote:
> >> On Wednesday 27 July 2016 15:54:58 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.
> >>
> >> a quick feedback while trying on implementing it in kde side.
> >> since we use c++, the file generated by wayland-scanner, won't compile due 
> >> to
> >> the request called "export" which is a reserved keyword in c++11.
> >> could the request be renamed to something else, even just a bit more 
> >> redundant
> >> as export_surface which would be safer as compilers are concerned?
> >
> > Ah. Would make sense with a test case for this in wayland-scanner I'd
> > say, so we don't add other things that would make it not compile with a
> > c++ compiler.
> >
> > 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.
> >
> 
> yeah, export_toplevel/import_toplevel sounds good.
> if there is a continuous integration somewhere, could be nice just
> make it try compiling the file resulting from wayland-scanner with g++
> -std=c++14 or something like that

There is a very tiny test suite in wayland-protocols. It could be
extended to test build for various variants of C and C++. Currently it
just tests that wayland-scanner doesn't complain.


Jonas

> 
> --
> 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

[Marco Martin]

On Thu, Aug 10, 2017 at 3:47 AM, Jonas Ådahl  wrote:
> On Wed, Aug 09, 2017 at 01:42:51PM +0200, Marco Martin wrote:
>> On Wednesday 27 July 2016 15:54:58 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.
>>
>> a quick feedback while trying on implementing it in kde side.
>> since we use c++, the file generated by wayland-scanner, won't compile due to
>> the request called "export" which is a reserved keyword in c++11.
>> could the request be renamed to something else, even just a bit more 
>> redundant
>> as export_surface which would be safer as compilers are concerned?
>
> Ah. Would make sense with a test case for this in wayland-scanner I'd
> say, so we don't add other things that would make it not compile with a
> c++ compiler.
>
> 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.
>

yeah, export_toplevel/import_toplevel sounds good.
if there is a continuous integration somewhere, could be nice just
make it try compiling the file resulting from wayland-scanner with g++
-std=c++14 or something like that

--
Marco Martin
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel