From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: xen-devel@lists.xen.org
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Boris Brezillon <boris.brezillon@free-electrons.com>,
Ian Campbell <ijc@hellion.org.uk>
Subject: Sharing display between guests
Date: Thu, 2 Jul 2015 13:13:29 +0200 [thread overview]
Message-ID: <20150702111329.GA19261@lukather> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2154 bytes --]
Hi,
I've started using Xen on an Allwinner A33, which works great as an
headless device using the latest PSCI patches in U-Boot.
However, we would like to do something more with it, and we would need
to have two VMs accessing the display at once, each one drawing in its
own part of the framebuffer.
Something that would look like this:
Framebuffer
+---------------+
| |
| Guest 1 |
| |
+---------------+
| |
| |
| |
| Guest 2 |
| |
| |
| |
+---------------+
Where thing start to get interesting is that the second guest would be
running Android, and as such would need OpenGL support, and access to
the GPU, and that ideally the first guest would need to be able to
draw over all the screen to create some kind of a drop-down menu.
Our first thought was to use two different planes of a DRM/KMS driver,
one for each VM, with the second guest having the primary plane, and
the first guest having an overlay, and we would set it up in dom0.
That would mean that we would have a static "composition", that would
be setup once and we could forget about it during the life of the
system.
This way, we would also have a fixed size framebuffer assigned to
Android, which is much easier to support, and since we have total
control over the application in the first guest, we would be able to
control how much "transparency" we want to leave (== how much of
Android do we want to be displayed), and we would be able to create
our drop-down menu.
Now the hard part: is such a setup possible at all with Xen? Can we
export a single plane to a guest and let it be the only user of it? If
that is possible, how would that interact with the 3D acceleration?
If not, is it something that is conceptually flawed, or does one just
need to write the appropriate amount of code? Do you have a better
solution to this problem?
Thanks a lot for your feedback,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next reply other threads:[~2015-07-02 11:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-02 11:13 Maxime Ripard [this message]
2015-07-02 12:18 ` Sharing display between guests Dario Faggioli
2015-07-06 11:39 ` Maxime Ripard
2015-07-06 15:14 ` Dario Faggioli
2015-07-09 9:31 ` Maxime Ripard
2015-07-06 11:53 ` Ian Campbell
2015-07-06 12:26 ` Maxime Ripard
2015-07-06 12:41 ` Ian Campbell
2015-07-06 14:10 ` Maxime Ripard
2015-07-06 14:23 ` Ian Campbell
2015-07-09 9:24 ` Maxime Ripard
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=20150702111329.GA19261@lukather \
--to=maxime.ripard@free-electrons.com \
--cc=boris.brezillon@free-electrons.com \
--cc=ijc@hellion.org.uk \
--cc=thomas.petazzoni@free-electrons.com \
--cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.