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

[Oleksandr Grytsov <al1img@xxxxxxxxx>]

On Tue, May 2, 2017 at 5:28 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 13, 2017 at 3:54 PM, Ian Jackson <ian.jackson@xxxxxxxxxxxxx> 
>> wrote:
>> > 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.
>
> That seems to make some kind of sense.  However, surely that means
> that the backend needs to be told the "identifier or attribute" to
> assign to the surfaces it is creating ?
>
> Ie that would have to be in here somewhere
>  vdispl = [ 'backend=0, devId=0, beAlloc=1, connectors=800x600,1024x768' ]
>
>> > 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.
>
> Or to put my comment above another way: if there are several such
> surfaces, how does the window manager tell which is intended for
> what ?
>
>> 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.
>
> xl.cfg normally also contains information necessary for plumbing the
> virtual device back to some physical hardware.
>
> So for example, the disk specification specifies not only the names of
> the virtual devices, but also the corresponding host physical devices
> (or files), host data storage format, etc.
>
> As I say I think in this case we probably want the configuration file
> to assign names or ids to the backend surfaces.
>
> Ian.
>
> PS: Sorry for the slow reply.

I considered that frontend domain name and surface index is a unique surface
identifier. Like following:

Surface with index 0 from DomU should be placed at x, y, display 0  etc.

Surely, we can add identifier into xl.cfg to make it more generic or more
readable from user point of view. In this case the config line could look like:

vdispl = [ 'backend=0, devId=0, beAlloc=1,
connectors=id0:800x600,id1:1024x768' ]

id0, id1 could be either integer id or string name. For example in our case it
could be wayland surface id.



-- 
Best Regards,
Oleksandr Grytsov.

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