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

[Oleksandr Grytsov <al1img@xxxxxxxxx>]

On Fri, Apr 14, 2017 at 1:12 PM, Oleksandr Grytsov <al1img@xxxxxxxxx> wrote:
> On Thu, Apr 13, 2017 at 3:54 PM, Ian Jackson <ian.jackson@xxxxxxxxxxxxx> 
> wrote:
>> Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV 
>> display device driver interface"):
>>> After internal discussion we think that putting positions and
>>> z-orders of virtual connectors to the Xen store and libxl
>>> configuration is not so good idea. Because their composition depends
>>> on an application and usage. We consider automotive usage.  For
>>> example one of domain drives navigation system and depends on
>>> scenario the navigation window position and size can be changed. In
>>> that case on the host should be an instance of window manager or
>>> something like that.  The window manager will decide where to put
>>> the virtual displays.
>>
>> Right.
>>
>>> If it is ok, following is libxl/xl configuration proposal:
>>
>> This looks much better to me.  (See of course Wei's point about the
>> connector list ambiguity.)
>>
>> Can you sketch out what the rest of the system does, then ?
>> Presumably there has to be a different control protocol to your
>> backend, to tell it where to put the actual displays.  I think it
>> would be good if that protocol were the same for different use cases,
>> and documented somewhere.
>
> Well, yes there will be some protocol to communicate with the window manager.
> We consider to use wayland and weston as display system.
> The idea is the backend and other applications on the host render content onto
> wayland surfaces. Each surface will have  a unique identifier or attribute
> (like multimedia, navigation etc.). The window manager based on these
> attributes, configured policies and scenarios will set positions and 
> geometries
> for the surfaces.
>
>> So for example, when a window manager moves a window, how is the
>> backend told where to display the guest output ?
>
> The backend will create the wayland surface and tell the window manager
> the attribute it has. All rest will be done by the window manager.
>
>> Your final patches should come with changese to the xl.cfg
>> documentation, but I think we can still discuss this in generalities
>> for now and then the text you write in your emails or example comments
>> will make a good starting point for the xl.cfg documentation.
>
> In my opinion the details how the virtual displays are placed on the host
> should be separated from xl configuration. Because it really depends on
> backend implementation. We have generalized display protocol (displif.h).
> There could be different frontend/backend implementations and each
> implementation will require its own configuration.
> That's why in xl.cfg should be only parameters related to display protocol
> namely resolutions of virtual connectors.
>
>
>> Thanks,
>> Ian.
>
> --
> Best Regards,
> Oleksandr Grytsov.

ping

Any objection about to have only connector's resolutions in xl.cfg?

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