RE: waylandsink touch&IVI shell
Hi, No wayland-sink does not support ivi-shell. Best regards Emre Ucan Engineering Software Base (ADITG/ESB) Tel. +49 5121 49 6937 > -Original Message- > From: wayland-devel [mailto:wayland-devel- > boun...@lists.freedesktop.org] On Behalf Of xp21987 > Sent: Freitag, 11. August 2017 04:28 > To: wayland-devel > Subject: waylandsink touch&IVI shell > > 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
waylandsink touch&IVI shell
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
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, &compositor->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?
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
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
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