Plans for Weston surface remoting for IVI

Wed Apr 20 09:07:54 UTC 2016

(Adding back CCs.)

On Tue, 19 Apr 2016 16:52:02 -0700
Florian Haenel <florian.haenel at heeen.de> wrote:

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

Hi,

that's very interesting!

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

Which interface, exactly?

The Transmitter interface is completely standalone and could be used by
any shell plugin. Unfortunately Transmitter also needs to know about
shell protocol specifics. That's why I split the public Transmitter API
into two: generic and shell-specific.

Even the design doc mentions this could be used for desktop shell, but
not without substantial work of encoding and relaying all the
shell-specific state. Additionally, desktop shell would need something
different from ivi-layout API to control the remoting. Turning it into
something an end-user could use would be even more work.

No other shell plugin has an API layer like ivi-layout. I am not
building Transmitter to assume ivi-layout, it is just the API that ivi
controllers (hmi-controller) must use.

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

By 'ec' you mean weston_surface I suppose, not weston_compositor?

It is true there might be an invalid state, but weston core does need
to know which the forced_output is. Surface->output has unfortunately
more semantics tied to it (is surface mapped), so I chose to not
overload it with even more.

We can dribble asserts to make sure the state is consistent where it
makes sense. I might even claim that this allows to detect accidental
changes to surface->output, because that field is manually poked by
shell plugins, IIRC, as part of mapping a surface. Or maybe it is views
nowadays.

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

Yes! That is actually on the roadmap, but just a long way in the future
for us.

Getting the renderer hand out buffer handles is what I had in mind for
the hardware accelerated case. Making it support custom buffer types is
possible, and since you patch the renderer, you can also patch
Transmitter to deal with them.

Thanks,
pq

> 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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160420/36a28f9c/attachment.sig>