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

[Oleksandr Grytsov <al1img@xxxxxxxxx>]

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"):
>> Backend and frontend operate with connectors (virtual displays). They
>> are identified by connector index.
>> The virtual display layouts, orders, on which physical display they
>> are located, resolustions etc. are configured
>> on backend side through backend configuration file. The matching
>> between frontend connector index and
>> backend virtual dispaly is done with the same configuration file.
>> Configuration example:
>
> Oh!
>
>>     doms = (
>>         { name = "Dom1"; devId = 0; connectors = ["display0", "display1"]; },
>>         { name = "Dom1"; devId = 1; connectors = ["display2"]; },
>>         { name = "Dom2"; devId = 0; connectors = ["display3"]; }
>>     );
>>     connectors = (
>>         { name = "display0"; screen = 0; x = 0; y = 0; w = 320; h =
>> 240; z = 10; },
>>         { name = "display1"; screen = 1; x = 320; y = 0; w = 320; h =
>> 240; z = 100; },
>>         { name = "display2"; x = 320; y = 0; w = 320; h = 240; }
>>         { name = "display3"; x = 320; y = 0; w = 320; h = 240; }
>>     );
>>
>> Backend understands that for frontend "Dom1" devId = 0 it should
>> provide virtual display "display0"
>> which located on physical screen 0, at coordinates (0,0) and size
>> 320x240 (z - is z-order).
>> Once frontend from "Dom1" is connected backend sets corresponding
>> connector resolution in xen store:
>
> Right.  I understand.  Thanks for the explanation.
>
> The normal approach, for any kind of backend, with xl/libxl would be
> that the xl domain configuration file (and the libxl domain
> configuration struct) would specify the backend configuration
> information.
>
> 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.

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

>> 1. DRM mode:
>>
>> In this mode the backend exclusively opens DRM device. It can be done
>> only without any windowing system.
>> We can't do match in this mode. We can't share the screen between
>> different domains. The backend can only
>> map virtual connector to physical one and provide it for frontend. For
>> example on the host we have a video adapter
>> with HDMI0, HDM1, VGA output. In this case the backend can provide
>> HDMI0 to "Dom1", HDMI1 to "Dom2" etc.
>
> That makes sense.  But your example configuration above doesn't seem
> to specify HDMI ports, just locations on the screen.  How is this
> configured, then ?
>
> 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.

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

>> 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; },
);

> Please forgive me if none of this seems to make sense...

Your comments are valuable. I really appreciate it.

>
> Thanks,
> Ian.

-- 
Best Regards,
Oleksandr Grytsov.

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