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

[Oleksandr Grytsov <al1img@xxxxxxxxx>]

On Wed, Apr 5, 2017 at 6:50 PM, Ian Jackson <ian.jackson@xxxxxxxxxxxxx> wrote:
> Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV 
> display device driver interface"):
>> On Wed, Apr 5, 2017 at 5:28 PM, Ian Jackson <ian.jackson@xxxxxxxxxxxxx> 
>> wrote:
>> > Who starts the display backend ?  I'm obviously missing some of the
>> > plumbing.  Sorry again for asking all these daft questions.
>>
>> Currently it is launched in the host startup script. I guess it will
>> be normal case.
>
> OK.  You said it put the virtual display on the local Wayland or MIR
> display.  How does it know which local display to display on, and
> how to interact with the windowing system, and so on ?

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:

    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:

/local/domain/1/device/vdispl/0/0/resolution = "320x240"
/local/domain/1/device/vdispl/0/1/resolution = "320x240"

Actually for frontend only resolution matters.

Interacting with windowing system:

There are few different cases:

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.

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.

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.

[1] https://github.com/GENIVI/wayland-ivi-extension

>> > I didn't find the protocol in tree when I looked.  If you need to
>> > repost the patches, you can combine them into the same series.
>>
>> Actually the protocol patch is submitted by Oleksandr Andrushchenko
>> (we are working together on protocol/backend/frontend).
>
> I'm very sorry that I didn't notice the difference in your surnames!
> How embarrassing!  My apologies!
>
>> And it has passed review process already and about to be committed. I
>> can add link to the protocol patch in following reposts.
>
> Sure.
>
> Ian.



-- 
Best Regards,
Oleksandr Grytsov.

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