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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
