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

[Oleksandr Grytsov <al1img@xxxxxxxxx>]

On Thu, Apr 6, 2017 at 4:03 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 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.

We use wayland-ivi-extension in this case.  This is special Weston shell
and surfaces which can move, scale surfaces by ivi layer management.

https://github.com/GENIVI/wayland-ivi-extension
https://at.projects.genivi.org/wiki/display/WIE/01.+Quick+start

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

Great. I will do it in this way.

Thank you.

> Regards,
> Ian.



-- 
Best Regards,
Oleksandr Grytsov.

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