Xen frame buffer related

Xen frame buffer related

[Dushmanta Mohapatra]

[-- Attachment #1.1: Type: text/plain, Size: 4288 bytes --]

Hi,

Thanks for the response. It really helps. I have a few more questions.

First of all I do not know what PVOPS means. I searched for it but did not
find any thing convincing. So is that only for the official linux tree? In
Xen website  we still get the linux 2.6.18 kernel which gets patched for
Xen.  So  for this 2.6.18 Xeno-Linux version do I need your patches for
correct operation. Can I use the PVOPS tree at present for my Dom0? As far
as I know only 2.6.18 version of Dom0 is currently available. I have read
that we can use recent kernels like 2.6.23 etc for DomU though I myself use
the same kernel for both Dom0 and DomU.

I see two xenfb.c files in the Xen (3.2) source. One in tools/ioemu/hw/ and
the other in linux-2.6.18-xen.hg/drivers/xen/fbfront/. So I think the first
one is the userspace-backend and the second one is the kernel-space
front-end.  I do not understand why originally the back-end was not made a
part of kernel like other devices? Also could you  please tell me how to use
this backend  userspace tool.  Any  pointer  will do.

If I have understood it correctly then in Xen 3.1, this  back end tool  uses
VNCServer for displaying  the contents  of  Frontend  frambuffer.  So what
has changed with the use of QEMU. Also I did not understand what you meant
by "to avoid having two VNC servers".
Is it related to one for FV and another for PV.

Finally just to give you an idea about my project:  Lets suppose a domU gets
migrated from a Physical machine having a display of X1xY1 to another
physical machine having a display of X2xY2. So our project tries to
dynamically configure the front end/ back-end so that the user does not
notice a difference. Also a similar example can be a domU getting migrated
from a machine having one type of keyboard to a machine having another type
of keyboard.  So  do you think  support for this  is already available in
Xen 3.2.  Are we  doing some  thing that  others have already done?  If I
see Xen 3.2 code in the user space backend framebuffer code
(/tools/ioemu/hw/xenfb.c) I see functions like "static int
xenfb_read_frontend_fb_config(struct xenfb *xenfb)" and "static int
xenfb_read_frontend_kbd_config(struct xenfb *xenfb)". So I am just wondering
what  these functions are for?

I am sorry that the mail is a bit long. I really appreciate all your help.

Thanks,
Dushmanta



Hello,
>
>
> I have been investigating about Xen Frame Buffer regarding a project that
I
> am involved with.

I'm curious, can you tell me about it?

> I am facing some problems. So while searching on the net I found your post
> at
http://lists.xensource.com/archives/html/xen-devel/2008-02/msg00717.html

This is the pvops para-virtual framebuffer (PVFB).  The patch is for
Linus's tree.

> Now browsing through the source I find xenfb frontend related files at
> linux-2.6.18-xen.hg/drivers/xen/fbfront/xenfb.c (also xenkbd.c).  (I use
Xen
> 3.2 compiled from source).

This is the old, non-pvops Xen Linux tree.

This tree is much too old (2.6.18) to be useful for our users.  We
used to extract the Xen patch from that tree and forward-port it to
less obsolete kernel versions, but that was not sustainable, so we
stopped.

The only future for Xen's Linux part, as far as I'm concerned, is
going upstream, into Linus's tree.  That means porting it to the pvops
interface.  Still a work in progress: domU is usable, but dom0 needs
more work.  The patch you quoted above is part of that work in
progress.

I recommend to base any new work on pvops kernels, if at all
practical.

> So what exactly are the files you are referring to in your post.
>
> Also could you please give me a brief idea about the interaction between
> QEMU and xenfb in Xen 3.2 and what exactly has changed from Xen 3.1.
>
>
> Thanks,
> Dushmanta

I don't remember exact timing of changes.  Peruse the Mercurial
repository.

PVFB consists of a frontend in domU (device driver in kernel space),
and a backend in dom0 user space.

The initial version implemented backend as a separate program (source
in xen-unstable.hg/tools/xenfb/).  Later on, we merged it into QEMU,
chiefly to avoid having two different VNC servers.

If you have more questions, consider asking on the mailing list, where
more people than just you can profit from my answers :)

Markus

[-- Attachment #1.2: Type: text/html, Size: 5061 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Xen frame buffer related

[Samuel Thibault]

Hello,

Dushmanta Mohapatra, le Thu 03 Apr 2008 09:57:11 -0400, a écrit :
> I see two xenfb.c files in the Xen (3.2) source. One in tools/ioemu/hw/ and the
> other in linux-2.6.18-xen.hg/drivers
> /xen/fbfront/. So I think the first one is the userspace-backend and the second
> one is the kernel-space front-end.

That's it.

> I do not understand why originally the
> back-end was not made a part of kernel like other devices?

Why should it be?  In the case of PVFB, he backend is responsible for
actually showing the frame buffer.  A userspace X11 application or VNC
server is thus the logical way.

> Also could you please tell me how to use this backend userspace tool.

You just need to add

vfb = [ 'type=sdl' ]

if you want to have an SDL window showing up when you start your domain,
or

vfb = [ 'type=vnc' ]

if you want to have a VNC server started instead.

> If I have understood it correctly then in Xen 3.1, this  back end tool  uses
> VNCServer for displaying  the contents  of  Frontend  frambuffer.  So what has
> changed with the use of QEMU.

There is now the SDL choice.

> Finally just to give you an idea about my project:  Lets suppose a domU gets
> migrated from a Physical machine having a display of X1xY1 to another physical
> machine having a display of X2xY2.

In the unstable tree, there is an OpenGL rendering which can accomodate
with this by rescaling the frame buffer.

> Also a similar example can be a domU getting migrated from a machine
> having one type of keyboard to a machine having another type of
> keyboard.

Mmm, you may have a problem here, because PVFB uses Linux keycodes, not
keysyms.  I.e. whatever the configuration of the host machine, the guest
keyboard configuration will be used.

> If I see Xen
> 3.2 code in the user space backend framebuffer code (/tools/ioemu/hw/xenfb.c) I
> see functions like "static int xenfb_read_frontend_fb_config(struct xenfb
> *xenfb)" and "static int xenfb_read_frontend_kbd_config(struct xenfb *xenfb)".

That's to get the initial size, but in the unstable tree we now have a
PVFB event that permits the guest to change the size dynamically.

Samuel

Re: Xen frame buffer related

[Markus Armbruster]

[Quoting fixed]

"Dushmanta Mohapatra" <dushmanta.mohapatra@gmail.com> writes:

> Markus Armbruster <armbru@redhat.com> writes:
> 
> > "Dushmanta Mohapatra" <dmpatra@gmail.com> writes:
> >
> >> Hello,
> >>
> >> I am Dushmanta, a PhD student at Georgia Tech.
> >>
> >> I have been investigating about Xen Frame Buffer regarding a project that I
> >> am involved with.
> >
> > I'm curious, can you tell me about it?
> >
> >> I am facing some problems. So while searching on the net I found your post
> >> at http://lists.xensource.com/archives/html/xen-devel/2008-02/msg00717.html
> >
> > This is the pvops para-virtual framebuffer (PVFB).  The patch is for
> > Linus's tree.
> >
> >> Now browsing through the source I find xenfb frontend related files at
> >> linux-2.6.18-xen.hg/drivers/xen/fbfront/xenfb.c (also xenkbd.c).  (I use Xen
> >> 3.2 compiled from source).
> >
> > This is the old, non-pvops Xen Linux tree.
> >
> > This tree is much too old (2.6.18) to be useful for our users.  We
> > used to extract the Xen patch from that tree and forward-port it to
> > less obsolete kernel versions, but that was not sustainable, so we
> > stopped.
> >
> > The only future for Xen's Linux part, as far as I'm concerned, is
> > going upstream, into Linus's tree.  That means porting it to the pvops
> > interface.  Still a work in progress: domU is usable, but dom0 needs
> > more work.  The patch you quoted above is part of that work in
> > progress.
> >
> > I recommend to base any new work on pvops kernels, if at all
> > practical.
> >
> >> So what exactly are the files you are referring to in your post.
> >>
> >> Also could you please give me a brief idea about the interaction between
> >> QEMU and xenfb in Xen 3.2 and what exactly has changed from Xen 3.1.
> >>
> >>
> >> Thanks,
> >> Dushmanta
> >
> > I don't remember exact timing of changes.  Peruse the Mercurial
> > repository.
> >
> > PVFB consists of a frontend in domU (device driver in kernel space),
> > and a backend in dom0 user space.
> >
> > The initial version implemented backend as a separate program (source
> > in xen-unstable.hg/tools/xenfb/).  Later on, we merged it into QEMU,
> > chiefly to avoid having two different VNC servers.
> >
> > If you have more questions, consider asking on the mailing list, where
> > more people than just you can profit from my answers :)
> >
> > Markus
> >
> Hi,
>
> Thanks for the response. It really helps. I have a few more questions.
>
> First of all I do not know what PVOPS means. I searched for it but did not
> find any thing convincing. So is that only for the official linux tree? In
> Xen website  we still get the linux 2.6.18 kernel which gets patched for
> Xen.  So  for this 2.6.18 Xeno-Linux version do I need your patches for
> correct operation. Can I use the PVOPS tree at present for my Dom0? As far
> as I know only 2.6.18 version of Dom0 is currently available. I have read
> that we can use recent kernels like 2.6.23 etc for DomU though I myself use
> the same kernel for both Dom0 and DomU.

pvops is short for paravirt_ops.  That's how the Linux kernel talks to
Hypervisors.  Check out http://lwn.net/Articles/194543/ for a brief
introduction.

linux-2.6.18-xen.hg is essentially a fork of Linux 2.6.18, which
predates pvops, modified for para-virtual Xen.  2.6.18 is much too old
to be useful in the real world (at least the one I inhabit).

linux-2.6.18-xen.hg contains a working PVFB.

Recent Linux kernels work for para-virtual domU, and people are
working hard to make them work fully for dom0.

I'm working on getting PVFB upstream, i.e. into the current Linux
kernel.  I call that version of PVFB "pvops PVFB".  It is cleaner and
smaller than what we have in linux-2.6.18-xen.hg, and has a bunch of
bugs fixed (all very unlikely to bite, but bugs still).

> I see two xenfb.c files in the Xen (3.2) source. One in tools/ioemu/hw/ and
> the other in linux-2.6.18-xen.hg/drivers/xen/fbfront/. So I think the first
> one is the userspace-backend and the second one is the kernel-space
> front-end.

Correct.

>             I do not understand why originally the back-end was not made a
> part of kernel like other devices? Also could you  please tell me how to use
> this backend  userspace tool.  Any  pointer  will do.

Xend starts it on behalf of a domain that needs it.  Start with
createDeviceModel() in tools/python/xen/xend/image.py.

Putting this backend into dom0 kernel space would make no sense,
because the service it provides to the frontend (acting as a VNC
server for it) can and really should be done entirely in user space.

> If I have understood it correctly then in Xen 3.1, this  back end tool  uses
> VNCServer for displaying  the contents  of  Frontend  frambuffer.  So what
> has changed with the use of QEMU. Also I did not understand what you meant
> by "to avoid having two VNC servers".
> Is it related to one for FV and another for PV.

We used to use LibVNCServer for PVFB, and qemu-dm's VNC server
implementation for fully virtual domains.  By integrating the PVFB
backend into qemu-dm, we got rid of the dependency on LibVNCServer.
Which is, by the way, among the most "interesting" pieces of code I
had the "privilege" to work with.  Good riddance.

> Finally just to give you an idea about my project:  Lets suppose a domU gets
> migrated from a Physical machine having a display of X1xY1 to another
> physical machine having a display of X2xY2. So our project tries to
> dynamically configure the front end/ back-end so that the user does not
> notice a difference. Also a similar example can be a domU getting migrated
> from a machine having one type of keyboard to a machine having another type
> of keyboard.  So  do you think  support for this  is already available in
> Xen 3.2.  Are we  doing some  thing that  others have already done?  If I
> see Xen 3.2 code in the user space backend framebuffer code
> (/tools/ioemu/hw/xenfb.c) I see functions like "static int
> xenfb_read_frontend_fb_config(struct xenfb *xenfb)" and "static int
> xenfb_read_frontend_kbd_config(struct xenfb *xenfb)". So I am just wondering
> what  these functions are for?

These are part of the Xenbus state machine.  I don't think you should
mess with those.

The PVFB frontend supports the usual Linux framebuffer API for
dynamically changing resolutions.  Check out xenfb_check_var() and
xenfb_set_par().  Actual resolution change is initiated by user space.

This is a fairly new feature, and I haven't merged it into pvops PVFB
yet, because I don't want to rock that boat right now by modifying the
patch (it's being reviewed and hopefully gets merged).

Different keyboards should just work.  If you find some that don't, we
take patches.

> I am sorry that the mail is a bit long. I really appreciate all your help.
>
> Thanks,
> Dushmanta

Happy digging through the code!

Re: Xen frame buffer related

[Dushmanta Mohapatra]

[-- Attachment #1.1: Type: text/plain, Size: 2057 bytes --]

Thanks for the detailed reply. Makes the things a lot more clearer to me.

But I have got a few more questions.

How do I use the VNC/SDL to view domU's console.  I saw a thread
http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00351.html
related to this and followed the approach.
(I assume all the 10 patches mentioned in this series are available in Xen
3.2. Am I right?)

In my domU config file I use options like this;

vfb = [ 'type=sdl' ]
#vfb = ['type=vnc ']
#extra = "xencons=tty video=xenfb"
extra = 'xencons=ttyS0 console=ttyS0 video=xenfb'

The domU starts booting and stops after printing some texts to the tty
console (I think it waits for the back-end to come-up)

Then I execute the command <qemu-dm -M xenpv -d domid>. Then a black screen
flashes for a fraction of a second and goes away.
Nothing happens. So am I doing the write things. Or am I supposed to do some
thing different?

(Do I need to start a VNC viewer in dom0 in case I am using the VNC option)


in Xen 3.1 there was a tool vncfb . But that is missing in 3.2. I assume all
of that functionality has been put into qemu-dm.

In the thread
http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00351.html  it
is mentioned about merging xenfb and xenconsoled into qemu-dm. So what is
the purpose of xenconsoled . If I look through my system I find binaries
like (/usr/bin/xencons , /usr/sbin/xenconsoled
/usr/lib64/xen/bin/xenconsole). Could you please give me an idea what are
these used for?

Finally a logistics question:
Like you have said in your reply 2.6.18 kernel is not usable for many
purposes. But Xen website does not provide support for any later version of
kernel for dom0. Are the Xen guys planning  to  provide  port for a later
kernel like 2.6.23 /24?

So I am wondering if I use the Xen that comes inbuilt with Linux
distributions like Fedora8 do I get all the pvops features that you are
mentioning? But I guess Fedora8 has Xen 3.1.  And the current hypervisor is
3.2 . So all this make the whole thing a bit confusing.

Thanks,
Dushmanta

[-- Attachment #1.2: Type: text/html, Size: 2425 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Xen frame buffer related

[Markus Armbruster]

"Dushmanta Mohapatra" <dushmanta.mohapatra@gmail.com> writes:

> Thanks for the detailed reply. Makes the things a lot more clearer to me.
>
> But I have got a few more questions.
>
> How do I use the VNC/SDL to view domU's console.  I saw a thread
> http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00351.html
> related to this and followed the approach.
> (I assume all the 10 patches mentioned in this series are available in Xen
> 3.2. Am I right?)
>
> In my domU config file I use options like this;
>
> vfb = [ 'type=sdl' ]
> #vfb = ['type=vnc ']
> #extra = "xencons=tty video=xenfb"
> extra = 'xencons=ttyS0 console=ttyS0 video=xenfb'

I've never tried video=xenfb, no idea what it does.  I prefer to
compile both xenfb and xenkbd in (not module).

I don't use any extra kernel arguments.  But I use Fedora kernels and
upstream kernels, not unpatched 2.6.18-xen.hg.  The latter at some
time needed and may still need:

* xencons=xvc to stop the Xen console from mugging the serial console
  driver.

* console=xvc to get a working console when PVFB is disabled.  By
  default, only console tty is enabled, which is a useless dummy
  without PVFB.

* console=xvc console=tty when PVFB is enabled, to enable both console
  tty (PVFB) and the Xen console xvc.

> The domU starts booting and stops after printing some texts to the tty
> console (I think it waits for the back-end to come-up)
>
> Then I execute the command <qemu-dm -M xenpv -d domid>. Then a black screen
> flashes for a fraction of a second and goes away.
> Nothing happens. So am I doing the write things. Or am I supposed to do some
> thing different?

Xend should start the backend automatically for you.  If it doesn't,
check its log for hints on what went wrong.  Also check qemu logs.

> (Do I need to start a VNC viewer in dom0 in case I am using the VNC option)

Yes.  The VNC option makes more sense in most circumstances.  For
instance, closing the viewer window doesn't kill your guest dead.

If you use a distro that provides virt-manager (a GUI to control your
virtual machines): virt-manager comes with an integrated viewer.

> in Xen 3.1 there was a tool vncfb . But that is missing in 3.2. I assume all
> of that functionality has been put into qemu-dm.

Correct.

> In the thread
> http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00351.html  it
> is mentioned about merging xenfb and xenconsoled into qemu-dm. So what is
> the purpose of xenconsoled . If I look through my system I find binaries
> like (/usr/bin/xencons , /usr/sbin/xenconsoled
> /usr/lib64/xen/bin/xenconsole). Could you please give me an idea what are
> these used for?

xenconsoled receives logs from hypervisor and guests and writes them
to log files, commonly in /var/lib/xen/

> Finally a logistics question:
> Like you have said in your reply 2.6.18 kernel is not usable for many
> purposes. But Xen website does not provide support for any later version of
> kernel for dom0. Are the Xen guys planning  to  provide  port for a later
> kernel like 2.6.23 /24?

The pvops effort is about getting Xen kernel bits integrated into
upstream Linux, so that we never again have to port them to later
kernel versions.

> So I am wondering if I use the Xen that comes inbuilt with Linux
> distributions like Fedora8 do I get all the pvops features that you are
> mentioning? But I guess Fedora8 has Xen 3.1.  And the current hypervisor is
> 3.2 . So all this make the whole thing a bit confusing.
>
> Thanks,
> Dushmanta

The Fedora 8 Xen kernel is a port to 2.6.21, but that's pretty much as
outdated and useless as .18.  Fedora 9 and later will provide Xen
through pvops in a *current* kernel.

Hypervisor version and domU kernel version are not closely coupled.
I would expect a pvops kernel guest to run fine both under a 3.1 and
3.2 hypervisor.

Re: Xen frame buffer related

[Jeremy Fitzhardinge]

Markus Armbruster wrote:
> The PVFB frontend supports the usual Linux framebuffer API for
> dynamically changing resolutions.  Check out xenfb_check_var() and
> xenfb_set_par().  Actual resolution change is initiated by user space.
>
> This is a fairly new feature, and I haven't merged it into pvops PVFB
> yet, because I don't want to rock that boat right now by modifying the
> patch (it's being reviewed and hopefully gets merged).
>   

Ingo has taken it into his tree, and I don't see anything blocking from 
going into 2.6.26 (you got the fb people to review it, right?).

If you do an incremental patch to add resizing then we can add that too.

BTW, does tablet mode work with the pvops patches?

    J

Re: Xen frame buffer related

[Markus Armbruster]

Jeremy Fitzhardinge <jeremy@goop.org> writes:

> Markus Armbruster wrote:
>> The PVFB frontend supports the usual Linux framebuffer API for
>> dynamically changing resolutions.  Check out xenfb_check_var() and
>> xenfb_set_par().  Actual resolution change is initiated by user space.
>>
>> This is a fairly new feature, and I haven't merged it into pvops PVFB
>> yet, because I don't want to rock that boat right now by modifying the
>> patch (it's being reviewed and hopefully gets merged).
>>   
>
> Ingo has taken it into his tree, and I don't see anything blocking
> from going into 2.6.26 (you got the fb people to review it, right?).

Everything was cc: linux-fbdev-devel.  The dependency on the fb defio
fix was sorted out there.  No comment from there otherwise; my code
must be perfect ;)

> If you do an incremental patch to add resizing then we can add that too.

That's the plan, but one step at a time.

> BTW, does tablet mode work with the pvops patches?
>
>    J

I definitely should, as pvops' xen-kbdfront is functionally equivalent
to 2.6.18-xen's xenkbd.

Xen frame buffer related

[Dushmanta Mohapatra]

[-- Attachment #1.1: Type: text/plain, Size: 4288 bytes --]

Hi,

Thanks for the response. It really helps. I have a few more questions.

First of all I do not know what PVOPS means. I searched for it but did not
find any thing convincing. So is that only for the official linux tree? In
Xen website  we still get the linux 2.6.18 kernel which gets patched for
Xen.  So  for this 2.6.18 Xeno-Linux version do I need your patches for
correct operation. Can I use the PVOPS tree at present for my Dom0? As far
as I know only 2.6.18 version of Dom0 is currently available. I have read
that we can use recent kernels like 2.6.23 etc for DomU though I myself use
the same kernel for both Dom0 and DomU.

I see two xenfb.c files in the Xen (3.2) source. One in tools/ioemu/hw/ and
the other in linux-2.6.18-xen.hg/drivers/xen/fbfront/. So I think the first
one is the userspace-backend and the second one is the kernel-space
front-end.  I do not understand why originally the back-end was not made a
part of kernel like other devices? Also could you  please tell me how to use
this backend  userspace tool.  Any  pointer  will do.

If I have understood it correctly then in Xen 3.1, this  back end tool  uses
VNCServer for displaying  the contents  of  Frontend  frambuffer.  So what
has changed with the use of QEMU. Also I did not understand what you meant
by "to avoid having two VNC servers".
Is it related to one for FV and another for PV.

Finally just to give you an idea about my project:  Lets suppose a domU gets
migrated from a Physical machine having a display of X1xY1 to another
physical machine having a display of X2xY2. So our project tries to
dynamically configure the front end/ back-end so that the user does not
notice a difference. Also a similar example can be a domU getting migrated
from a machine having one type of keyboard to a machine having another type
of keyboard.  So  do you think  support for this  is already available in
Xen 3.2.  Are we  doing some  thing that  others have already done?  If I
see Xen 3.2 code in the user space backend framebuffer code
(/tools/ioemu/hw/xenfb.c) I see functions like "static int
xenfb_read_frontend_fb_config(struct xenfb *xenfb)" and "static int
xenfb_read_frontend_kbd_config(struct xenfb *xenfb)". So I am just wondering
what  these functions are for?

I am sorry that the mail is a bit long. I really appreciate all your help.

Thanks,
Dushmanta



Hello,
>
>
> I have been investigating about Xen Frame Buffer regarding a project that
I
> am involved with.

I'm curious, can you tell me about it?

> I am facing some problems. So while searching on the net I found your post
> at
http://lists.xensource.com/archives/html/xen-devel/2008-02/msg00717.html

This is the pvops para-virtual framebuffer (PVFB).  The patch is for
Linus's tree.

> Now browsing through the source I find xenfb frontend related files at
> linux-2.6.18-xen.hg/drivers/xen/fbfront/xenfb.c (also xenkbd.c).  (I use
Xen
> 3.2 compiled from source).

This is the old, non-pvops Xen Linux tree.

This tree is much too old (2.6.18) to be useful for our users.  We
used to extract the Xen patch from that tree and forward-port it to
less obsolete kernel versions, but that was not sustainable, so we
stopped.

The only future for Xen's Linux part, as far as I'm concerned, is
going upstream, into Linus's tree.  That means porting it to the pvops
interface.  Still a work in progress: domU is usable, but dom0 needs
more work.  The patch you quoted above is part of that work in
progress.

I recommend to base any new work on pvops kernels, if at all
practical.

> So what exactly are the files you are referring to in your post.
>
> Also could you please give me a brief idea about the interaction between
> QEMU and xenfb in Xen 3.2 and what exactly has changed from Xen 3.1.
>
>
> Thanks,
> Dushmanta

I don't remember exact timing of changes.  Peruse the Mercurial
repository.

PVFB consists of a frontend in domU (device driver in kernel space),
and a backend in dom0 user space.

The initial version implemented backend as a separate program (source
in xen-unstable.hg/tools/xenfb/).  Later on, we merged it into QEMU,
chiefly to avoid having two different VNC servers.

If you have more questions, consider asking on the mailing list, where
more people than just you can profit from my answers :)

Markus

[-- Attachment #1.2: Type: text/html, Size: 5061 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel