From: Oleksandr Grytsov <al1img@gmail.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Juergen Gross <jgross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
Oleksandr Andrushchenko <andr2000@gmail.com>,
Oleksandr Grytsov <oleksandr_grytsov@epam.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 0/2] libxl: add PV display device driver interface
Date: Fri, 14 Apr 2017 13:12:44 +0300 [thread overview]
Message-ID: <CACvf2oVYmNAx5ovkPEeh7iTPyV5EHCS-CcVOor=sKabyt8oa1A@mail.gmail.com> (raw)
In-Reply-To: <22767.29980.104677.299910@mariner.uk.xensource.com>
On Thu, Apr 13, 2017 at 3:54 PM, Ian Jackson <ian.jackson@eu.citrix.com> 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@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-04-14 10:12 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-05 10:03 [PATCH v1 0/2] libxl: add PV display device driver interface Oleksandr Grytsov
2017-04-05 10:03 ` [PATCH v1 1/2] " Oleksandr Grytsov
2017-04-05 10:03 ` [PATCH v1 2/2] xl: add PV display device commands Oleksandr Grytsov
2017-04-05 11:05 ` [PATCH v1 0/2] libxl: add PV display device driver interface Ian Jackson
2017-04-05 12:25 ` al1img .
2017-04-05 13:49 ` Ian Jackson
2017-04-05 14:00 ` Konrad Rzeszutek Wilk
2017-04-05 14:18 ` Oleksandr Grytsov
2017-04-05 14:28 ` Oleksandr Grytsov
2017-04-05 14:28 ` Ian Jackson
2017-04-05 14:53 ` Oleksandr Grytsov
2017-04-05 15:50 ` Ian Jackson
2017-04-06 9:22 ` Oleksandr Grytsov
2017-04-06 11:17 ` Ian Jackson
2017-04-06 12:42 ` Oleksandr Grytsov
2017-04-06 13:03 ` Ian Jackson
2017-04-06 13:27 ` Oleksandr Grytsov
2017-04-10 10:58 ` Oleksandr Grytsov
2017-04-12 16:48 ` Wei Liu
2017-04-13 8:41 ` Oleksandr Grytsov
2017-04-13 12:54 ` Ian Jackson
2017-04-14 10:12 ` Oleksandr Grytsov [this message]
2017-04-26 10:15 ` Oleksandr Grytsov
2017-05-02 14:28 ` Ian Jackson
2017-05-03 15:08 ` Oleksandr Grytsov
2017-05-03 15:13 ` Ian Jackson
2017-05-04 8:49 ` Oleksandr Grytsov
2017-05-12 12:12 ` Oleksandr Grytsov
2017-05-18 11:42 ` Oleksandr Grytsov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACvf2oVYmNAx5ovkPEeh7iTPyV5EHCS-CcVOor=sKabyt8oa1A@mail.gmail.com' \
--to=al1img@gmail.com \
--cc=andr2000@gmail.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jgross@suse.com \
--cc=oleksandr_grytsov@epam.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).