[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.