<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi, I'm new to weston but have worked with qtwayland for some time now implementing a qml compositor, so forgive me if my remarks are naive as I haven't followed discussions around weston. For our hackathon I implemented something like your proposal, only for shm buffers and without considerations for things like surface should only be visible on one output. Have you considered making this a standalone interface - not part of ivi? I could imagine spaces outside of automotive finding this feature useful - e.g. as an option for people missing network transparency from x11. I think having both ec->forced_output and ec->output allows a surface to enter an invalid state of them being different, where a bool flag that says that the current output is locked does not allow such an invalid state. How do you feel about custom buffer types being closely tied to the renderer (e.g. imx6 gal2d) but the transmitter either needing a user memory buffer or, better, forwarding the gpu specific buffer to the hw video encoder (e.g. VPU on imx6) to minimize copies? I feel like a registry where renderers could offer their buffer conversion API could be useful to allow the streaming backend choose the most efficient one. E.g.: gal2d renderer could offer shm conversion via copy as well as a custom type without copy. streaming sink queries and chooses gal2d to hand over to the vpu for encoding. Florian <div class="moz-cite-prefix">On 04/07/2016 03:13 AM, Pekka Paalanen wrote: </div> <blockquote cite="mid:20160407131335.19fdf87c@eldfell" type="cite"> <pre wrap="">Hi all, I have written a rough design on how to implement per-surface remoting on Weston, primarily over network: <a class="moz-txt-link-freetext" href="https://people.collabora.com/~pq/Adit/Weston-IVI-remoting.pdf">https://people.collabora.com/~pq/Adit/Weston-IVI-remoting.pdf</a> Before you get carried away, I must note that this will not work on desktops without considerable work. The design is written for ivi-shell which has a trivial Wayland protocol extension. The design could support desktops too, in theory, but you will need to think how to get all the desktop shell protocol features implemented, and you probably want something friendly to control the remoting, too. What this design does do, is give a plan how to remote the essentials of the core Wayland protocol. This includes creating wl_surfaces and wl_buffers, transmitting pixel data, feedback in the form of frame callbacks, and also relaying input events, and how to expose remote output and input to Wayland applications. The document is not a rigorous technical description, but a high-level plan on what we will likely be working on in the following months. You have already seen a few patches or RFCs originating from this work. Serious feedback is warmly welcome, but please keep in mind that this work is not aiming for the desktop as is. I would love to hear if you have plans for or have implemented something around the idea of remoting individual Wayland surfaces. Collabora is working on this by the request of ADIT. ADIT is joint venture company of DENSO Corporation and Bosch GmbH. Thanks, pq </pre> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ wayland-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </pre> </blockquote> </body> </html>