[Qemu-devel] Ongoing changes to the displaying code

[Qemu-devel] Ongoing changes to the displaying code

[Daniel Gutson]

Hi,
	I'm doing some development related with the displaying bits, and wanted 
to give an early notice for syncing purposes (specially in terms of 
Stefano's work).

The development I'm doing intends to add a GUI, which the following 
abilities:
	- show more than one DisplayState in a single VT (I think this was 
previously referred as 'DS multiplexing'), capable of being a mix of 
graphic/text (see below)
	- add a skin to each VT
	- provide "buttons" with associated actions (such as keyboard input)
	- define all these attributes from an XML file
	- in the case of VNC, the ability to show a different VT in each 
connection.


In order to achieve those features, I am doing the following changes:

	- TextConsole (aka QEMUConsole) is a layer above DisplayState which 
uses it for rendering glyphs. The GUI takes care about 'graphics', 
whereas TextConsole use it to show the glyphs, get keys, and do text 
terminal stuff (such as scrolling). No more GRAPHIC_CONSOLE, just fixed 
or non-fixed size text consoles.

	- Displaying backends no longer have input logic or grabbing/displaying 
pointer/mouse logic. That's been moved to the GUI bits, so the backends' 
responsibility is to render pieces of screen. (thus being simplified).

	- use of libpng

	- use of libxml (soon)

	- I also added an 'fb render engine', intended to provide common 
functionality to frame buffer devices, such as:
		- draw lines handling differences of depths,byte orders,pixel orders, 
and color orders between guest and host
		- rotation/flipping
		- palette handling

What I'm NOT addressing is:
	- text consoles rotation
	- ability to show the same VT in more than one displaying backend at 
the same time (i.e. SDL and VNC).

I'm still working hard to get all the bits together, and should be ready 
no later than Feb.

	Daniel.

-- 
Daniel Gutson

"Don't trust a computer you can't throw out a window"

Re: [Qemu-devel] Ongoing changes to the displaying code

[Anthony Liguori]

Daniel Gutson wrote:
> Hi,
>     I'm doing some development related with the displaying bits, and 
> wanted to give an early notice for syncing purposes (specially in 
> terms of Stefano's work).
>
> The development I'm doing intends to add a GUI, which the following 
> abilities:
>     - show more than one DisplayState in a single VT (I think this was 
> previously referred as 'DS multiplexing'), capable of being a mix of 
> graphic/text (see below)
>     - add a skin to each VT
>     - provide "buttons" with associated actions (such as keyboard input)
>     - define all these attributes from an XML file
>     - in the case of VNC, the ability to show a different VT in each 
> connection.

I don't think any of this is a good idea with the exception of 
supporting multiple DisplayStates.

If you want skins and such, you should just build an external GUI than 
connects to QEMU via VNC.

Regards,

Anthony Liguori

Re: [Qemu-devel] Ongoing changes to the displaying code

[Anthony Liguori]

Anthony Liguori wrote:
> Daniel Gutson wrote:
>> Hi,
>>     I'm doing some development related with the displaying bits, and 
>> wanted to give an early notice for syncing purposes (specially in 
>> terms of Stefano's work).
>>
>> The development I'm doing intends to add a GUI, which the following 
>> abilities:
>>     - show more than one DisplayState in a single VT (I think this 
>> was previously referred as 'DS multiplexing'), capable of being a mix 
>> of graphic/text (see below)
>>     - add a skin to each VT
>>     - provide "buttons" with associated actions (such as keyboard input)
>>     - define all these attributes from an XML file
>>     - in the case of VNC, the ability to show a different VT in each 
>> connection.
>
> I don't think any of this is a good idea with the exception of 
> supporting multiple DisplayStates.
>
> If you want skins and such, you should just build an external GUI than 
> connects to QEMU via VNC.

I should explain myself a bit further.

I assume you're looking to do this in order to support functionality 
like in the Android simulator.  So that if you're using QEMU to emulator 
a hand held device (cell phone, whatever), you can have something that 
looks like that device.

The problem is, your GUI is going to want all the feature of a normal 
GUI.  Context menus, perhaps a tool bar, etc.  Maybe you want animated 
button clicks or even the buttons to make noises when clicked.  
Inevitably, it'll bloat to a full blown GUI.  Not very useful for us 
virtualization folks so we'll also want our own GUI.  Then things get 
ugly because should it be one GUI or two separate ones?  Another way to 
do this is to separate out the GUI logic so it's not directly tied to 
QEMU.  This has been discussed many times and there are a lot of 
advantages to using an external GUI.  Namely, you can close the window 
without exiting the simulation.

If you build a simple app that exec()'s and connects to QEMU via VNC, 
and use something like gtk-vnc, you could build just what you're looking 
for very easily.  It's all portable to Windows too and LGPL licensed.  
You could even develop in a higher level language like Python and you'd 
get to use file dialog widgets, context menus, and all that good stuff 
without worrying about recreating that in SDL.

I think that's a better route to go for this sort of thing.  If you 
think it's generally useful, I think it'd also be worthwhile to host 
within the QEMU project.  I just don't think it's the right thing to add 
into QEMU directly.

Regards,

Anthony Liguori

> Regards,
>
> Anthony Liguori

Re: [Qemu-devel] Ongoing changes to the displaying code

[David Turner]

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

Hello everyone,

as the guy who implemented all this in the Android emulator, I'd like to
share a few thoughts.

On Fri, Jan 9, 2009 at 4:04 AM, Anthony Liguori <anthony@codemonkey.ws>wrote:

>
> I assume you're looking to do this in order to support functionality like
> in the Android simulator.  So that if you're using QEMU to emulator a hand
> held device (cell phone, whatever), you can have something that looks like
> that device.
>
> The problem is, your GUI is going to want all the feature of a normal GUI.
>  Context menus, perhaps a tool bar, etc.  Maybe you want animated button
> clicks or even the buttons to make noises when clicked.  Inevitably, it'll
> bloat to a full blown GUI.  Not very useful for us virtualization folks so
> we'll also want our own GUI.  Then things get ugly because should it be one
> GUI or two separate ones?  Another way to do this is to separate out the GUI
> logic so it's not directly tied to QEMU.  This has been discussed many times
> and there are a lot of advantages to using an external GUI.  Namely, you can
> close the window without exiting the simulation.
>

+1 to separate the emulation logic and the display/GUI one. this is exactly
what has been done in the Android emulator, even though the program uses its
own GUI for practical reasons.


> If you build a simple app that exec()'s and connects to QEMU via VNC, and
> use something like gtk-vnc, you could build just what you're looking for
> very easily.  It's all portable to Windows too and LGPL licensed.  You could
> even develop in a higher level language like Python and you'd get to use
> file dialog widgets, context menus, and all that good stuff without worrying
> about recreating that in SDL.
>



> I think that's a better route to go for this sort of thing.  If you think
> it's generally useful, I think it'd also be worthwhile to host within the
> QEMU project.  I just don't think it's the right thing to add into QEMU
> directly.
>

For my specific needs, VNC and a separate GUI application are totally
overkill. However, it is true that QEMU itself absolutely doesn't require to
support any GUI jazz (you should probably let that to forks/GUI wrappers
instead).

On the other hand, it would be nice to have a slightly better way to
decouple display/events between the emulation and user-interaction parts of
the system. For example, I've attached the framebuffer abstraction that I
currently use in the Android emulator source code (it's a well documented
header file).

It's basically a slightly better DisplayState, with explicit
producer/clients relationships and a global fifo used for
initialization/linking. I do not claim it is the absolute best way to do it,
just an example on how this can be implemented.

If someone's interested, I can probably provide a patch against the QEMU svn
sources.

Regards,

- Digit


>
> Regards,
>
> Anthony Liguori
>
>  Regards,
>>
>> Anthony Liguori
>>
>
>
>
>

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

[-- Attachment #2: framebuffer.h --]
[-- Type: text/x-chdr, Size: 7834 bytes --]

/* Copyright (C) 2007-2008 The Android Open Source Project
**
** This software is licensed under the terms of the GNU General Public
** License version 2, as published by the Free Software Foundation, and
** may be copied, distributed, and modified under those terms.
**
** This program is distributed in the hope that it will be useful,
** but WITHOUT ANY WARRANTY; without even the implied warranty of
** MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
** GNU General Public License for more details.
*/
#ifndef _QEMU_FRAMEBUFFER_H_
#define _QEMU_FRAMEBUFFER_H_

/* A simple abstract interface to framebuffer displays. this is used to
 * de-couple hardware emulation from final display.
 *
 * Each QFrameBuffer object holds a pixel buffer that is shared between
 * one 'Producer' and one or more 'Clients'
 *
 * The Producer is in charge of updating the pixel buffer from the state
 * of the emulated VRAM. A Client listens to updates to the pixel buffer,
 * sent from the producer through qframebuffer_update()/_rotate() and
 * displays them.
 *
 * note the 'rotation' field: it can take values 0, 1, 2 or 3 and corresponds
 * to a rotation that must be performed to the pixels stored in the framebuffer
 * *before* displaying them a value of 1 corresponds to a rotation of
 * 90 clockwise-degrees, when the framebuffer is rotated 90 or 270 degrees,
 * its width/height are swapped automatically
 *
 * phys_width_mm and phys_height_mm are physical dimensions expressed
 * in millimeters
 *
 * More about the client/producer relationships below.
 */
typedef struct QFrameBuffer   QFrameBuffer;


typedef enum {
    QFRAME_BUFFER_NONE   = 0,
    QFRAME_BUFFER_RGB565 = 1,
    QFRAME_BUFFER_MAX          /* do not remove */
} QFrameBufferFormat;

struct QFrameBuffer {
    int                 width;        /* width in pixels */
    int                 height;       /* height in pixels */
    int                 pitch;        /* bytes per line */
    int                 rotation;     /* rotation to be applied when displaying */
    QFrameBufferFormat  format;
    void*               pixels;       /* pixel buffer */

    int                 phys_width_mm;
    int                 phys_height_mm;

    /* extra data that is handled by the framebuffer implementation */
    void*               extra;

};

/* the default dpi resolution of a typical framebuffer. this is an average
 * between various prototypes being used during the development of the
 * Android system...
 */
#define  DEFAULT_FRAMEBUFFER_DPI   165


/* initialize a framebuffer object and allocate its pixel buffer */
/* this computes phys_width_mm and phys_height_mm assuming a 165 dpi screen */
/* returns -1 in case of error, 0 otherwise */
extern int
qframebuffer_init( QFrameBuffer*       qfbuff,
                   int                 width,
                   int                 height,
                   int                 rotation,
                   QFrameBufferFormat  format );

/* recompute phys_width_mm and phys_height_mm according to the emulated 
 * screen DPI settings */
extern void
qframebuffer_set_dpi( QFrameBuffer*   qfbuff,
                      int             x_dpi,
                      int             y_dpi );

/* alternative to qframebuffer_set_dpi where one can set the physical 
 * dimensions directly in millimeters. for the record 1 inch = 25.4 mm */
extern void
qframebuffer_set_mm( QFrameBuffer*   qfbuff,
                     int             width_mm,
                     int             height_mm );

/* the Client::Update method is called to instruct a client that a given
 * rectangle of the framebuffer pixels was updated and needs to be
 * redrawn.
 */
typedef void (*QFrameBufferUpdateFunc)( void*  opaque, int  x, int  y, 
                                                       int  w, int  h );

/* the Client::Rotate method is called to instruct the client that a
 * framebuffer's internal rotation has changed. This is the rotation
 * that must be applied before displaying the pixels.
 *
 * Note that it is assumed that all framebuffer pixels have changed too
 * so the client should call its Update method as well.
 */
typedef void (*QFrameBufferRotateFunc)( void*  opaque, int  rotation );

/* the Client::Done func tells a client that a framebuffer object was freed.
 * no more reference to its pixels should be done.
 */
typedef void (*QFrameBufferDoneFunc)  ( void*  opaque );

/* add one client to a given framebuffer.
 * the current implementation only allows one client per frame-buffer,
 * but we could allow more for various reasons (e.g. displaying the
 * framebuffer + dispatching it through VNC at the same time)
 */
extern void
qframebuffer_add_client( QFrameBuffer*           qfbuff,
                         void*                   fb_opaque,
                         QFrameBufferUpdateFunc  fb_update,
                         QFrameBufferRotateFunc  fb_rotate,
                         QFrameBufferDoneFunc    fb_done );

/* Producer::CheckUpdate is called to let the producer check the
 * VRAM state (e.g. VRAM dirty pages) to see if anything changed since the
 * last call to the method. When true, the method should call either
 * qframebuffer_update() or qframebuffer_rotate() with the appropriate values.
 */
typedef void (*QFrameBufferCheckUpdateFunc)( void*  opaque );

/* Producer::Invalidate tells the producer that the next call to
 * CheckUpdate should act as if the whole content of VRAM had changed.
 * this is normally done to force client initialization/refreshes.
 */
typedef void (*QFrameBufferInvalidateFunc) ( void*  opaque );

/* the Producer::Detach method is used to tell the producer that the
 * underlying QFrameBuffer object is about to be de-allocated.
 */
typedef void (*QFrameBufferDetachFunc)     ( void*  opaque );

/* set the producer of a given framebuffer */
extern void
qframebuffer_set_producer( QFrameBuffer*                qfbuff,
                           void*                        opaque,
                           QFrameBufferCheckUpdateFunc  fb_check,
                           QFrameBufferInvalidateFunc   fb_invalidate,
                           QFrameBufferDetachFunc       fb_detach );

/* tell a client that a rectangle region has been updated in the framebuffer
 * pixel buffer this is typically called from a Producer::CheckUpdate method
 */
extern void
qframebuffer_update( QFrameBuffer*  qfbuff, int  x, int  y, int  w, int  h );

/* rotate the framebuffer (may swap width/height), and tell all clients.
 * Should be called from a Producer::CheckUpdate method
 */
extern void
qframebuffer_rotate( QFrameBuffer*  qfbuff, int  rotation );

/* finalize a framebuffer, release its pixel buffer. Should be called
 * from the framebuffer object's owner
 */
extern void
qframebuffer_done( QFrameBuffer*   qfbuff );


/* this is called repeatedly by the emulator. for each registered framebuffer,
 * call its producer's CheckUpdate method, if any.
 */
extern void
qframebuffer_check_updates( void );

/* this is called by the emulator. for each registered framebuffer, call
 * its producer's Invalidate method, if any
 */
extern void
qframebuffer_invalidate_all( void );

/*
 * to completely separate the implementation of clients, producers, and skins,
 * we use a simple global FIFO list of QFrameBuffer objects.
 *
 * qframebuffer_fifo_add() is typically called by the emulator initialization
 * depending on the emulated device's configuration
 *
 * qframebuffer_fifo_get() is typically called by a hardware framebuffer
 * emulation.
 */

/* add a new constructed frame buffer object to our global list */
extern void
qframebuffer_fifo_add( QFrameBuffer*  qfbuff );

/* retrieve a frame buffer object from the global FIFO list */
extern QFrameBuffer*
qframebuffer_fifo_get( void );

/* */

#endif /* _QEMU_FRAMEBUFFER_H_ */

Re: [Qemu-devel] Ongoing changes to the displaying code

[Stefano Stabellini]

Daniel Gutson wrote:

> Hi,
>     I'm doing some development related with the displaying bits, and
> wanted to give an early notice for syncing purposes (specially in terms
> of Stefano's work).


My current work is pretty much done, so do not expect any other big
change from me, of course apart from the patch series sent just before Xmas.
Once that is accepted (we shouldn't be very far), the only thing I am
probably going to do that may affect you in some way is implementing
window resizing in sdl.

 
> What I'm NOT addressing is:
>     - text consoles rotation
>     - ability to show the same VT in more than one displaying backend at
> the same time (i.e. SDL and VNC).

this bit is one if the main goal of the last patch series, so again we
shouldn't interfere much.

Re: [Qemu-devel] Ongoing changes to the displaying code

[Anthony Liguori]

David Turner wrote:
>
>
>     I think that's a better route to go for this sort of thing.  If
>     you think it's generally useful, I think it'd also be worthwhile
>     to host within the QEMU project.  I just don't think it's the
>     right thing to add into QEMU directly.
>
>
> For my specific needs, VNC and a separate GUI application are totally 
> overkill. However, it is true that QEMU itself absolutely doesn't 
> require to support any GUI jazz (you should probably let that to 
> forks/GUI wrappers instead).

I would think the ability to maintain your own GUI and therefore not 
have to fork QEMU would outweigh the "overkill" factor.

What specifically, do you consider to be overkill?  Are you afraid of 
the performance overhead of VNC?  Is the lack of VNC clients a problem 
(assuming you don't want a gtk dependency)?

I hear a lot of people say "VNC is overkill" but practically, it seems 
to work pretty well for this sort of thing (as evident by virt-manager) 
so I'm wondering what people are concerned about.  If it's performance, 
there are ways we can dramatically improve the performance localhost so 
that it should be equal to SDL.  If it's the gtk dependency, then we 
probably look at splitting up gtk-vnc to make the gtk dependency 
optional and allow other display types to be easily supported.

> On the other hand, it would be nice to have a slightly better way to 
> decouple display/events between the emulation and user-interaction 
> parts of the system. For example, I've attached the framebuffer 
> abstraction that I currently use in the Android emulator source code 
> (it's a well documented header file).
>
> It's basically a slightly better DisplayState, with explicit 
> producer/clients relationships and a global fifo used for 
> initialization/linking. I do not claim it is the absolute best way to 
> do it, just an example on how this can be implemented.

I'd like to avoid introducing another remove communication mechanism in 
QEMU.  VNC is extremely flexible so we should be able to do whatever we 
need to do with it.

Regards,

Anthony Liguori

> If someone's interested, I can probably provide a patch against the 
> QEMU svn sources.
>
> Regards,
>
> - Digit 
>  
>
>
>     Regards,
>
>     Anthony Liguori
>
>         Regards,
>
>         Anthony Liguori
>
>
>
>
>

Re: [Qemu-devel] Ongoing changes to the displaying code

[David Turner]

[-- Attachment #1: Type: text/plain, Size: 2767 bytes --]

Hello Anthony,

On Fri, Jan 9, 2009 at 4:20 PM, Anthony Liguori <anthony@codemonkey.ws>wrote:

> I would think the ability to maintain your own GUI and therefore not have
> to fork QEMU would outweigh the "overkill" factor.
>
> What specifically, do you consider to be overkill?  Are you afraid of the
> performance overhead of VNC?  Is the lack of VNC clients a problem (assuming
> you don't want a gtk dependency)?
>

Given that there is only one person that works on the Android emulator (me),
and that this is unlikely to change in the near future,
I want to avoid any additional complexity with low return on investment
(development / support costs).

Simply put it:

I want something simple that "just works" on three different platforms.
I absolutely cannot use a standard VNC client.
I want to distribute the program as a single statically linked executable.
I don't want a GTK/Qt/Whatever dependency.
I can test my UI on one platform and know that it will look and behave
exactly the same on other ones
(e.g. no funky behaviour due to slightly different fonts, different versions
of the UI toolkit libs, whatever).

I could change my mind on various of these items, but this would invariably
require more (or even a lot more) development and support efforts

Finally, the program is *already* accessed and controlled by an external
Java development tool (DDMS) which has sophisticated UI elements

Fortunately for me, it's a very specific application that doesn't require a
full-blown GUI, and never will :-)
I'm not advocating this path for other projects, just explaining what I do.


>
>
>  On the other hand, it would be nice to have a slightly better way to
>> decouple display/events between the emulation and user-interaction parts of
>> the system. For example, I've attached the framebuffer abstraction that I
>> currently use in the Android emulator source code (it's a well documented
>> header file).
>>
>> It's basically a slightly better DisplayState, with explicit
>> producer/clients relationships and a global fifo used for
>> initialization/linking. I do not claim it is the absolute best way to do it,
>> just an example on how this can be implemented.
>>
>
> I'd like to avoid introducing another remove communication mechanism in
> QEMU.  VNC is extremely flexible so we should be able to do whatever we need
> to do with it.
>

Oh, this is not a remote communication scheme at all. This is only a header
used to completely decouple the emulation part of the program from the one
sending it to the display. it's only better than the current scheme because
the UI part doesn't need to include emulation-specific headers just to get
the definition of DisplayState, and the role of each party is more clearly
documented.

Regards,

- Digit

[-- Attachment #2: Type: text/html, Size: 3555 bytes --]

Re: [Qemu-devel] Ongoing changes to the displaying code

[Ian Jackson]

Anthony Liguori writes ("Re: [Qemu-devel] Ongoing changes to the displaying code"):
> David Turner wrote:
> > For my specific needs, VNC and a separate GUI application are totally 
> > overkill. However, it is true that QEMU itself absolutely doesn't 
> > require to support any GUI jazz (you should probably let that to 
> > forks/GUI wrappers instead).
...
> What specifically, do you consider to be overkill?  Are you afraid of 
> the performance overhead of VNC?  Is the lack of VNC clients a problem 
> (assuming you don't want a gtk dependency)?

I think it's fair enough for people to prefer SDL to VNC for a number
of reasons.  But why not just allow them to embed the qemu SDL window
in their application ?  This is definitely possible in X although I'm
not sure exactly how to do it with SDL.

Ian.

Re: [Qemu-devel] Ongoing changes to the displaying code

[Anthony Liguori]

Ian Jackson wrote:
> Anthony Liguori writes ("Re: [Qemu-devel] Ongoing changes to the displaying code"):
>   
>> David Turner wrote:
>>     
>>> For my specific needs, VNC and a separate GUI application are totally 
>>> overkill. However, it is true that QEMU itself absolutely doesn't 
>>> require to support any GUI jazz (you should probably let that to 
>>> forks/GUI wrappers instead).
>>>       
> ...
>   
>> What specifically, do you consider to be overkill?  Are you afraid of 
>> the performance overhead of VNC?  Is the lack of VNC clients a problem 
>> (assuming you don't want a gtk dependency)?
>>     
>
> I think it's fair enough for people to prefer SDL to VNC for a number
> of reasons.  But why not just allow them to embed the qemu SDL window
> in their application ?  This is definitely possible in X although I'm
> not sure exactly how to do it with SDL.
>   

If you search the mailing lists, I went down this route before I 
originally wrote the VNC server.  XEmbed has some serious limitations 
surrounding how events are propagated between windows.  I convinced 
myself that you couldn't do what you really wanted to do through this 
mechanism.

Of course, with the right VNC extension to support a shared memory 
transport, I still contend VNC can be just as efficient as SDL.

Regards,

Anthony Liguori

> Ian.
>
>
>   

Re: [Qemu-devel] Ongoing changes to the displaying code

[David Turner]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

On Fri, Jan 9, 2009 at 6:16 PM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> I think it's fair enough for people to prefer SDL to VNC for a number
> of reasons.  But why not just allow them to embed the qemu SDL window
> in their application ?  This is definitely possible in X although I'm
> not sure exactly how to do it with SDL.
>

to be fair, that might not be an ideal solution. QEMU emulation currently
requires frequent SIGALRM signals.
this means the application will not be able to use it for its own needs, and
a *lot* of system calls are going to
randomly return EINTR, which a *lot* of code doesn't handle properly
(*cough* *cough* libesd.so)


>
> Ian.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1221 bytes --]

Re: [Qemu-devel] Ongoing changes to the displaying code

[Riku Voipio]

On Fri, Jan 09, 2009 at 11:24:42AM -0600, Anthony Liguori wrote:
> If you search the mailing lists, I went down this route before I 
> originally wrote the VNC server.  XEmbed has some serious limitations 
> surrounding how events are propagated between windows.  I convinced 
> myself that you couldn't do what you really wanted to do through this 
> mechanism.

Howabout using passing a window xid from the GUI app to qemu with
command line paramater -parent ? This is how Xoo[1] starts Xephyr
(or Xnest) in itself:

[1] http://labs.o-hand.com/xoo/

> Of course, with the right VNC extension to support a shared memory 
> transport, I still contend VNC can be just as efficient as SDL.

It still puts a big speed and flexibility limit IMHO.

-- 
"rm -rf" only sounds scary if you don't have backups

Re: [Qemu-devel] Ongoing changes to the displaying code

[Anthony Liguori]

Riku Voipio wrote:
> On Fri, Jan 09, 2009 at 11:24:42AM -0600, Anthony Liguori wrote:
>   
>> If you search the mailing lists, I went down this route before I 
>> originally wrote the VNC server.  XEmbed has some serious limitations 
>> surrounding how events are propagated between windows.  I convinced 
>> myself that you couldn't do what you really wanted to do through this 
>> mechanism.
>>     
>
> Howabout using passing a window xid from the GUI app to qemu with
> command line paramater -parent ? This is how Xoo[1] starts Xephyr
> (or Xnest) in itself:
>
> [1] http://labs.o-hand.com/xoo/
>   

Window events won't propagate (things like focus cycling).  There is 
tons of information about why these things don't work well in practice 
out there for those interested in googling.

>> Of course, with the right VNC extension to support a shared memory 
>> transport, I still contend VNC can be just as efficient as SDL.
>>     
>
> It still puts a big speed and flexibility limit IMHO.
>   

Why?  There's no additional memory copying.  There's a very small update 
latency addition.

Re: [Qemu-devel] Ongoing changes to the displaying code

[Anthony Liguori]

David Turner wrote:
>
>
> On Fri, Jan 9, 2009 at 6:16 PM, Ian Jackson <Ian.Jackson@eu.citrix.com 
> <mailto:Ian.Jackson@eu.citrix.com>> wrote:
>
>     I think it's fair enough for people to prefer SDL to VNC for a number
>     of reasons.  But why not just allow them to embed the qemu SDL window
>     in their application ?  This is definitely possible in X although I'm
>     not sure exactly how to do it with SDL.
>
>
> to be fair, that might not be an ideal solution. QEMU emulation 
> currently requires frequent SIGALRM signals.
> this means the application will not be able to use it for its own 
> needs, and a *lot* of system calls are going to
> randomly return EINTR, which a *lot* of code doesn't handle properly 
> (*cough* *cough* libesd.so)
>

Not to mention the fact that if you block too long or have long running 
computations, you'll cause great amounts of pain to the guest.  You also 
can't use main loops which makes gui integration pretty difficult.

It's really a bad environment for GUIs.  I understand the lack of desire 
to rewrite working code, but external GUIs are really the best technical 
solution for QEMU.

Regards,

Anthony Liguori

>
>     Ian.
>
>
>

Re: [Qemu-devel] Ongoing changes to the displaying code

[Jamie Lokier]

Anthony Liguori wrote:
> >>Of course, with the right VNC extension to support a shared memory 
> >>transport, I still contend VNC can be just as efficient as SDL.
> >>    
> >
> >It still puts a big speed and flexibility limit IMHO.
> 
> Why?  There's no additional memory copying.  There's a very small update 
> latency addition.

Fwiw, I agree with Anthony.

If VNC performance is a concern (it probably should be when you want
to do to video, or 1:1 full-screen, or 3d, or vsync-locked display),
extending localhost VNC to be as good as any "native" display method
can be would be the best way forward.

Obviously this would involve (at least) shared memory with both the X
server and QEMU, to remove all image copying and conversion when possible.
Similar mechanisms can be found on Windows and MacOS X.

SDL is good at some things but it's not perfect itself.  It may even
be better to remove SDL from QEMU proper, and provide a separate
localhost-VNC-to-SDL client.  (Same for the other frontends?)
Localhost-VNC does not need to support the whole VNC protocol, only
that used in localhost-VNC mode.

The other concern with VNC might be its complexity means you really
always want to use the existing VNC client library, which may not be a
desirable dependency for some applications.  For this, localhost-VNC
being both an extension to VNC and a subset of it would be helpful, as
you wouldn't have to use a full-fledged VNC client library for local
GUI apps if that isn't wanted.

-- Jamie

Re: [Qemu-devel] Ongoing changes to the displaying code

[Anthony Liguori]

Jamie Lokier wrote:
> The other concern with VNC might be its complexity means you really
> always want to use the existing VNC client library, which may not be a
> desirable dependency for some applications.  For this, localhost-VNC
> being both an extension to VNC and a subset of it would be helpful, as
> you wouldn't have to use a full-fledged VNC client library for local
> GUI apps if that isn't wanted.
>   

As a protocol, VNC features are almost exclusively client driven. You 
can write an extremely simple client with very little code if you just 
avoid using advanced features. If all you care about is localhost using 
shared memory, this is entirely reasonable.

Admittedly, there's a learning curve simply because there is a lot in 
VNC but the vast majority of it is optional.

Regards,

Anthony Liguori

> -- Jamie
>
>
>   

Re: [Qemu-devel] Ongoing changes to the displaying code

[Avi Kivity]

Anthony Liguori wrote:
>
> I assume you're looking to do this in order to support functionality 
> like in the Android simulator.  So that if you're using QEMU to 
> emulator a hand held device (cell phone, whatever), you can have 
> something that looks like that device.
>
> The problem is, your GUI is going to want all the feature of a normal 
> GUI.  Context menus, perhaps a tool bar, etc.  Maybe you want animated 
> button clicks or even the buttons to make noises when clicked.  
> Inevitably, it'll bloat to a full blown GUI.  Not very useful for us 
> virtualization folks so we'll also want our own GUI.  Then things get 
> ugly because should it be one GUI or two separate ones?  Another way 
> to do this is to separate out the GUI logic so it's not directly tied 
> to QEMU.  This has been discussed many times and there are a lot of 
> advantages to using an external GUI.  Namely, you can close the window 
> without exiting the simulation.
>

Instant messaging clients seem to have solved this without resorting to 
multiple processes.

> If you build a simple app that exec()'s and connects to QEMU via VNC, 
> and use something like gtk-vnc, you could build just what you're 
> looking for very easily.  It's all portable to Windows too and LGPL 
> licensed.  You could even develop in a higher level language like 
> Python and you'd get to use file dialog widgets, context menus, and 
> all that good stuff without worrying about recreating that in SDL.
>
> I think that's a better route to go for this sort of thing.  If you 
> think it's generally useful, I think it'd also be worthwhile to host 
> within the QEMU project.  I just don't think it's the right thing to 
> add into QEMU directly.

Or it could be done as a separate executable that links to a libqemu.so; 
the standard qemu binary could be implemented the same way.

Applications spanning multiple processes are clunky and inefficient.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Ongoing changes to the displaying code

[Ian Jackson]

Anthony Liguori writes ("Re: [Qemu-devel] Ongoing changes to the displaying code"):
> If you search the mailing lists, I went down this route before I 
> originally wrote the VNC server.  XEmbed has some serious limitations 
> surrounding how events are propagated between windows.  I convinced 
> myself that you couldn't do what you really wanted to do through this 
> mechanism.

I had a quick look and didn't find the threads you're talking about.

> Of course, with the right VNC extension to support a shared memory 
> transport, I still contend VNC can be just as efficient as SDL.

Are there widely supported VNC extensions for accelerated graphics ?

Anthony Liguori writes ("Re: [Qemu-devel] Ongoing changes to the displaying code"):
> Window events won't propagate (things like focus cycling).  There is 
> tons of information about why these things don't work well in practice 
> out there for those interested in googling.

I'm not sure what you mean by `focus cycling'.  I often develop X GUI
programs in two halves, one of which embeds a window in the other.
This conveniently allows the two halves to be in different languages,
differently versioned, provides additional concurrency without the
need for threads, etc.

Only one of the perhaps many programs in any toplevel should put up
conventional UI elements like menus and buttons.

Ian.

Re: [Qemu-devel] Ongoing changes to the displaying code

[Ian Jackson]

David Turner writes ("Re: [Qemu-devel] Ongoing changes to the displaying code"):
> On Fri, Jan 9, 2009 at 6:16 PM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:
> > I think it's fair enough for people to prefer SDL to VNC for a number
> > of reasons.  But why not just allow them to embed the qemu SDL window
> > in their application ?  This is definitely possible in X although I'm
> > not sure exactly how to do it with SDL.
> 
> to be fair, that might not be an ideal solution. QEMU emulation
> currently requires frequent SIGALRM signals.  this means the
> application will not be able to use it for its own needs, and a
> *lot* of system calls are going to randomly return EINTR, which a
> *lot* of code doesn't handle properly (*cough* *cough* libesd.so)

I meant to embed the qemu SDL X window, by having the non-qemu
frontend create an appropriate frame and then pass the X windowid to
qemu which would run as a subprocess.

I agree that putting qemu and something else in the same process would
be troublesome.  (Tcl might be doable ...)

Ian.

Re: [Qemu-devel] Ongoing changes to the displaying code

[Ian Jackson]

Avi Kivity writes ("Re: [Qemu-devel] Ongoing changes to the displaying code"):
> Instant messaging clients seem to have solved this without resorting to 
> multiple processes.

Multiple processes are not a `resort'.  And of course an IM client
needs to do a lot less than qemu, and the things that it does do are
much less hairy.

> > I think that's a better route to go for this sort of thing.  If you 
> > think it's generally useful, I think it'd also be worthwhile to host 
> > within the QEMU project.  I just don't think it's the right thing to 
> > add into QEMU directly.
> 
> Or it could be done as a separate executable that links to a libqemu.so; 
> the standard qemu binary could be implemented the same way.

I'm not sure how well qemu's processing model will fit in with GUI
toolkits.  I wouldn't trust Qt and Gtk not to make expectations which
are reasonable in a `general purpose' program but not sensible in
qemu's context.

> Applications spanning multiple processes are clunky and inefficient.

Nonsense.

Ian.

Re: [Qemu-devel] Ongoing changes to the displaying code

[Avi Kivity]

Ian Jackson wrote:
> Avi Kivity writes ("Re: [Qemu-devel] Ongoing changes to the displaying code"):
>   
>> Instant messaging clients seem to have solved this without resorting to 
>> multiple processes.
>>     
>
> Multiple processes are not a `resort'.  And of course an IM client
> needs to do a lot less than qemu, and the things that it does do are
> much less hairy.
>   

In terms of not shutting down the app when the close button is pressed, 
a good single process solution exists.  I agree that qemu's usage of 
signals is problematic.  Perhaps switching to real-time signals instead 
of SIGALRM and SIGIO will help.

Any other hairy things in qemu?

>>> I think that's a better route to go for this sort of thing.  If you 
>>> think it's generally useful, I think it'd also be worthwhile to host 
>>> within the QEMU project.  I just don't think it's the right thing to 
>>> add into QEMU directly.
>>>       
>> Or it could be done as a separate executable that links to a libqemu.so; 
>> the standard qemu binary could be implemented the same way.
>>     
>
> I'm not sure how well qemu's processing model will fit in with GUI
> toolkits.  I wouldn't trust Qt and Gtk not to make expectations which
> are reasonable in a `general purpose' program but not sensible in
> qemu's context.
>   

You would run qemu and the gui in different threads.  If the signal 
problem is resolved, I don't see any other issues.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Ongoing changes to the displaying code

[Mark McLoughlin]

On Fri, 2009-01-09 at 12:59 -0600, Anthony Liguori wrote:
> 
> Riku Voipio wrote:
> > On Fri, Jan 09, 2009 at 11:24:42AM -0600, Anthony Liguori wrote:
> >   
> >> If you search the mailing lists, I went down this route before I 
> >> originally wrote the VNC server.  XEmbed has some serious limitations 
> >> surrounding how events are propagated between windows.  I convinced 
> >> myself that you couldn't do what you really wanted to do through this 
> >> mechanism.
> >>     
> >
> > Howabout using passing a window xid from the GUI app to qemu with
> > command line paramater -parent ? This is how Xoo[1] starts Xephyr
> > (or Xnest) in itself:
> >
> > [1] http://labs.o-hand.com/xoo/
> >   
> 
> Window events won't propagate (things like focus cycling).  There is 
> tons of information about why these things don't work well in practice 
> out there for those interested in googling.

FWIW, I got this to work well in the past with Sabayon. I've long
forgotten the details, but here's the gtk+ widget with a lot of the gory
bits:

  http://svn.gnome.org/viewvc/sabayon/trunk/admin-tool/sessionwidget.py?view=markup

Also, see this blog entry:

  http://blogs.gnome.org/markmc/2005/06/14/input-focus/

Cheers,
Mark.