From: Samuel Thibault <samuel.thibault@eu.citrix.com>
To: Dushmanta Mohapatra <dushmanta.mohapatra@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Xen frame buffer related
Date: Fri, 4 Apr 2008 16:40:53 +0200 [thread overview]
Message-ID: <20080404144053.GE4075@implementation> (raw)
In-Reply-To: <46009afb0804030657rd1c2443jc3d4406235633417@mail.gmail.com>
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
next prev parent reply other threads:[~2008-04-04 14:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-03 13:57 Xen frame buffer related Dushmanta Mohapatra
2008-04-04 14:40 ` Samuel Thibault [this message]
2008-04-04 15:59 ` Markus Armbruster
2008-04-04 19:20 ` Dushmanta Mohapatra
2008-04-05 8:22 ` Markus Armbruster
2008-04-04 19:59 ` Jeremy Fitzhardinge
2008-04-05 7:43 ` Markus Armbruster
-- strict thread matches above, loose matches on Subject: below --
2008-04-03 14:21 Dushmanta Mohapatra
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=20080404144053.GE4075@implementation \
--to=samuel.thibault@eu.citrix.com \
--cc=dushmanta.mohapatra@gmail.com \
--cc=xen-devel@lists.xensource.com \
/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.