Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display 
device driver interface"):
> On Thu, Apr 6, 2017 at 2:17 PM, Ian Jackson <ian.jackson@xxxxxxxxxxxxx> wrote:
> > Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV 
> > display device driver interface"):
> > I think at the very least the section "doms" there ought to be defined
> > in the libxl configuration file.
> >
> > Is there any way (in the backend) of updating this backend
> > configuration dynamically ?  If so then your libxl patch could take
> > the per-domain configuration and update the backend config
> > appropriately.
> 
> I see your point. We can keep configuration either in local for
> backend config file or in Xen store (by libxl/xl) which is more
> common way. In case Xen store it is more convenient to keep it in
> per-domain basis. Actually no need to update the config dynamically,
> the backend can read Xen store configuration as well.
> 
> We have to think about this approach.

Right.  If this can be done, I think it would be much better.  Having
the backend read xenstore would remove a layer of configuration
management and simplify the design.

> > I guess the z order is useful because either (i) the vdisplay protocol
> > supports transparency, so a "front" vdisplay can decide which bits of
> > a "rear" vdisplay show through or (ii) "front" vdisplays occlude
> > "rear" vdisplays when the appropriate connection (backend/frontend) is
> > in use, but the "rear" one shows through the rest of the time ?
> >
> > Am I right ?  If so, is it (i) or (ii) ?
> 
> I guess it is to (ii). The protocol doesn't support transparency. In
> case of vdisplays overlapping, z-order indicates which vdisplay
> should be on top.

Right.

So that would be useful for a static configuration.

> > Ideally, in this use case, one would write in the xl domain config
> > file something like this:
> >   vdisplays = ["output=HDMI1"]
> 
> In DRM case connectors section from example is not relevant. And doms
> section looks like:
>     doms = (
>         { name = "Dom1"; devId = 0; connectors = ["HDMI-A-0", "HDMI-B-0"]; },
> Where HDMI-A-0, HDMI-B-0 names of physical DRM connectors.

Right.  Sending this information to the backend via xenstore would a
best I think.

> >> 2. Wayland with Weston compositor:
> >>
> >> Weston can be launched with X11 or without. With X11 it is not so
> >> usable case because Weston looks like a X11 application:
> >> windowing system inside windowing system but it works.
> >
> > Right.  So in that case what is the function of the x/y locations
> > specified in the backend configuration ?  If you have windowing-system
> > within windowing-system then the location on the real screen is
> > determined by the outer (host) windowing system, surely.
> 
> In this case x/y locations just ignored. Window manager (Weston) decides how
> to tile the vdisplays.

Right.

> >> So we use Weston without X11. Unfortunately Weston itself doesn't
> >> allow us to configure
> >> windows position layouts etc. For this purpose we use
> >> wayland-ivi-extension and its layer management [1].
> >> It allows to put windows at any position, order, screen etc.
> >
> > So this is for what is sometimes called "seamless" integration, where
> > the individual guest applications each have their own window on the
> > host display ?  Again, I don't see how this relates to the example
> > backend configuration file you showed above.
> >
> > I would expect that in this configuration one would write in the xl
> > domain config file something like
> >   vdisplays=["output=wayland0,seamless"]
> 
> Example:
> 
> - host with backend has one display with 1024х768 resolution;
> - there two domains (with name "Dom1", "Dom2") with frontends
>   and they would like to share the screen like this: [][]
> - in this case the example configuration will look like:
> 
> doms = (
>     { name = "Dom1"; devId = 0; connectors = ["display0"]; },
>     { name = "Dom2"; devId = 0; connectors = ["display1"]; },
> );
> connectors = (
>     { name = "display0"; screen = 0; x = 0; y = 0; w = 512; h = 768; z = 0; },
>     { name = "display1"; screen = 0; x = 512; y = 0; w = 512 h = 768; z = 0; 
> },
> );

But surely the outer window manager would want to move the individual
guest windows about ?  How is that done ?  Again, the x/y coordinates
in the backend configuration seem unhelpful.

> > Please forgive me if none of this seems to make sense...
> 
> Your comments are valuable. I really appreciate it.

You're welcome.  I hope that you don't mind me making all these rather
design-level comments at this stage.

I would suggest that before you go away and rework the code, it would
be a good idea to come up with a sketch of the configuration flows,
xenstore layouts, xl config file fragments, etc.

Then we can discuss the best way to configure things, without having
to iterate on a lot of code.

Regards,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel