> > 1 kernel fb mapping? or X server?
> The idea is that the graphical console will have "back/front"
> similar to the other devices, with a viewer in dom0 reading screen
> the guest and either displaying it, or exporting it over the network.
> The question here is: do we write a kernel framebuffer driver for this
> get the X server to use that) or implement it in the X server
I still don't get it, I'd like to make a little ASCII-art:
dom0 [graphical system]
domU_1 [graphical] domU_2 [text]
So, dom0 sees the real graphics card, and attaches to it.
Xen offers virtual graphics cards for each domU. domU_2 does not fire up
a graphical system, thus works with the emulated text buffer. domU_1
fires up its graphical system. Both domU write some data to some place,
managed by Xen (because Xen offered the vGraphicscard).
1.) Is the data actually saved as the domUs wrote them? Or is some
glue-layer in-between, converting it to .e.g VNC-compatible data, to
make the memory consumption problem go away?
Anyway, if the dom0 wants to "see" any of domU, it just asks Xen for the
data, getting a pointer or something (it just reads, anyway). It is best
if we can interact with the domUs, so we get some virtual HIDs (Human
Interface Devices)? Anyway the data is accessed, either in a "raw" way
or through some "protocol" like VNC. Still, I don't see why any of the
displaying systems, in the bottom (dom0 graphical system and/or Xen) or
the top (domU graphical systems), and their transporting systems, should
be known; In the end, all of those systems transfer data to a graphic
card, in a standard way (VGA for instance), no matter if it is a linux
framebuffer, a Unix x11, a Plan9 Rio, or any other system.
Xen-devel mailing list