Plans for Weston surface remoting for IVI

[Florian Haenel]

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

On 04/07/2016 03:13 AM, Pekka Paalanen wrote:
> Hi all,
>
> I have written a rough design on how to implement per-surface remoting
> on Weston, primarily over network:
> https://people.collabora.com/~pq/Adit/Weston-IVI-remoting.pdf
>
> 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
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160419/8369d5b2/attachment.html>