[Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Mulyadi Santosa]

IMO, it would be faster if we provide keyboard shortcuts that will
stop and resume VM execution right from SDL guest interface, rather
than switching to console monitor first and type "s" or "c"
respectively.

Note: I simply skip checking the keys in encrypted block devices when
resuming the VM. Not sure whether we really need it or not.

Signed-off-by: Mulyadi Santosa <mulyadi.santosa@gmail.com>

sdl.c |    9 +++++++++
 1 file changed, 9 insertions(+)

--- sdl.c.bak	2009-08-02 16:00:28.000000000 +0700
+++ sdl.c	2009-10-18 22:53:59.000000000 +0700
@@ -440,6 +440,7 @@ static void sdl_refresh(DisplayState *ds
                 if (gui_key_modifier_pressed) {
                     int keycode;
                     keycode = sdl_keyevent_to_keycode(&ev->key);
+                    //fprintf(stderr,"scan code of key pressed is
%d\n",keycode);
                     switch(keycode) {
                     case 0x21: /* 'f' key on US keyboard */
                         toggle_full_screen(ds);
@@ -456,6 +457,14 @@ static void sdl_refresh(DisplayState *ds
                         }
                         gui_keysym = 1;
                         break;
+                    case 0x1f: /* 's' key -- stopping VM */
+                        vm_stop(16); /* 16 is EXCP_INTERRUPT */
+                        gui_keysym = 1;
+                        break;
+                    case 0x2e: /* 'c' key -- resuming VM */
+                        vm_start(); /* we skip checking encrypted
block drive */
+                        gui_keysym = 1;
+                        break;
                     default:
                         break;
                     }

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Anthony Liguori]

Mulyadi Santosa wrote:
> IMO, it would be faster if we provide keyboard shortcuts that will
> stop and resume VM execution right from SDL guest interface, rather
> than switching to console monitor first and type "s" or "c"
> respectively.
>   

Is this really common of an operation that you would need an escape key 
for it?

Why are you so frequently stopping and continuing a guest?

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Mulyadi Santosa]

Hi Anthony...

On Tue, Oct 20, 2009 at 5:20 AM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Mulyadi Santosa wrote:
>>
>> IMO, it would be faster if we provide keyboard shortcuts that will
>> stop and resume VM execution right from SDL guest interface, rather
>> than switching to console monitor first and type "s" or "c"
>> respectively.
>>
>
> Is this really common of an operation that you would need an escape key for
> it?
>
> Why are you so frequently stopping and continuing a guest?

Thanks for giving a review.

One of the use case is to pause guest at a specific moment relatively
fast. For example, I boot a guest and I want to capture at a certain
moment when the guest kernel initialize and print something in the
screen.

As these message scrolls fast, I find it more intuitive if we could
just press a key to pause the guest, giving us enough time to capture
the display and resume the execution. If we switch to qemu monitor
first, most of the time we already lost the moment.


-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Gerd Hoffmann]

On 10/20/09 05:16, Mulyadi Santosa wrote:
> As these message scrolls fast, I find it more intuitive if we could
> just press a key to pause the guest, giving us enough time to capture
> the display and resume the execution. If we switch to qemu monitor
> first, most of the time we already lost the moment.

I'd find it more intuitive to setup a serial console in the guest, then 
simply log everything to a file ...

cheers,
   Gerd

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Daniel P. Berrange]

On Tue, Oct 20, 2009 at 10:16:09AM +0700, Mulyadi Santosa wrote:
> Hi Anthony...
> 
> On Tue, Oct 20, 2009 at 5:20 AM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> > Mulyadi Santosa wrote:
> >>
> >> IMO, it would be faster if we provide keyboard shortcuts that will
> >> stop and resume VM execution right from SDL guest interface, rather
> >> than switching to console monitor first and type "s" or "c"
> >> respectively.
> >>
> >
> > Is this really common of an operation that you would need an escape key for
> > it?
> >
> > Why are you so frequently stopping and continuing a guest?
> 
> Thanks for giving a review.
> 
> One of the use case is to pause guest at a specific moment relatively
> fast. For example, I boot a guest and I want to capture at a certain
> moment when the guest kernel initialize and print something in the
> screen.
> 
> As these message scrolls fast, I find it more intuitive if we could
> just press a key to pause the guest, giving us enough time to capture
> the display and resume the execution. If we switch to qemu monitor
> first, most of the time we already lost the moment.

If its too slow to switch to the monitor virtual console,then don't
configure the monitor in that way. Set it up to be on stdio, or one
of the other backends. That lets you have both the monitor & SDL
display visible at the same time & would be just as fast to type
in 'stop'  at the appropriate time.

If its kernel text output you need to see then a serial port + logging
is the best option here as Gerd suggests. If its video output you need
to see, then VNC along with something like vnc2swf which will record the
entire VNC data stream to a movie, which you can then play back and
easily pause at any point.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Kevin Wolf]

Am 20.10.2009 00:20, schrieb Anthony Liguori:
> Mulyadi Santosa wrote:
>> IMO, it would be faster if we provide keyboard shortcuts that will
>> stop and resume VM execution right from SDL guest interface, rather
>> than switching to console monitor first and type "s" or "c"
>> respectively.
>>   
> 
> Is this really common of an operation that you would need an escape key 
> for it?
> 
> Why are you so frequently stopping and continuing a guest?

Why are you all trying to explain to him that actually he doesn't want
to have this feature? I could have used it, too, at times (stop the
guest to have enough time to attach gdb, for example). There are other
ways to do it (although they are not as simple) and I used them, but
that doesn't make this feature less useful.

Does it take anything away for you? Or do you have plans to use those
keys otherwise? If not, why not add a feature that some might find
useful, even though others don't?

Kevin

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Anthony Liguori]

Kevin Wolf wrote:
> Am 20.10.2009 00:20, schrieb Anthony Liguori:
>   
>> Mulyadi Santosa wrote:
>>     
>>> IMO, it would be faster if we provide keyboard shortcuts that will
>>> stop and resume VM execution right from SDL guest interface, rather
>>> than switching to console monitor first and type "s" or "c"
>>> respectively.
>>>   
>>>       
>> Is this really common of an operation that you would need an escape key 
>> for it?
>>
>> Why are you so frequently stopping and continuing a guest?
>>     
>
> Why are you all trying to explain to him that actually he doesn't want
> to have this feature? I could have used it, too, at times (stop the
> guest to have enough time to attach gdb, for example). There are other
> ways to do it (although they are not as simple) and I used them, but
> that doesn't make this feature less useful.
>
> Does it take anything away for you? Or do you have plans to use those
> keys otherwise? If not, why not add a feature that some might find
> useful, even though others don't?
>   

There is such a thing as feature bloat.  It leads to very confusing 
behavior for users.  It also increases the testing matrix.

As it turns out, there's a better way to do what he's looking for that 
requires no changes.  Had we just taken this patch, then that's another 
feature that has to be tested for SDL whenever there's a change there.  
It also means there will be differing behavior for VNC so it probably 
needs to be supported there.  But then for something like libvirt, it's 
not going to expect that something else pauses/starts a VM.

Features are not free.  They have long term maintenance costs so we 
should consider whether a feature really offers value.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Daniel P. Berrange]

On Tue, Oct 20, 2009 at 12:40:08PM +0200, Kevin Wolf wrote:
> Am 20.10.2009 00:20, schrieb Anthony Liguori:
> > Mulyadi Santosa wrote:
> >> IMO, it would be faster if we provide keyboard shortcuts that will
> >> stop and resume VM execution right from SDL guest interface, rather
> >> than switching to console monitor first and type "s" or "c"
> >> respectively.
> >>   
> > 
> > Is this really common of an operation that you would need an escape key 
> > for it?
> > 
> > Why are you so frequently stopping and continuing a guest?
> 
> Why are you all trying to explain to him that actually he doesn't want
> to have this feature? I could have used it, too, at times (stop the
> guest to have enough time to attach gdb, for example). There are other
> ways to do it (although they are not as simple) and I used them, but
> that doesn't make this feature less useful.
> 
> Does it take anything away for you? Or do you have plans to use those
> keys otherwise? If not, why not add a feature that some might find
> useful, even though others don't?

The problem with adding lots of magic key-sequences, is that the more
you add, the more likely they are to clash with something that the 
guest OS wants to use. You may make this use case work, but break
someone else's use case. Thus, IMHO, magic key sequences should be kept
to the bare minimum neccessary to access functionality for which there
is no other viable access method.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Mulyadi Santosa]

Hi...

On Wed, Oct 21, 2009 at 12:08 AM, Daniel P. Berrange
<berrange@redhat.com> wrote:
> The problem with adding lots of magic key-sequences, is that the more
> you add, the more likely they are to clash with something that the
> guest OS wants to use. You may make this use case work, but break
> someone else's use case. Thus, IMHO, magic key sequences should be kept
> to the bare minimum neccessary to access functionality for which there
> is no other viable access method.

Thanks for the insights from all of you. The rule "to keep the magic
keys at the bare minimum" is something I fairly agree. So probably in
maintenance and development robustness's point of view, this patch
should just live outside of main tree... well unless there are lot of
supporter

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Kevin Wolf]

Am 20.10.2009 19:08, schrieb Daniel P. Berrange:
> On Tue, Oct 20, 2009 at 12:40:08PM +0200, Kevin Wolf wrote:
>> Am 20.10.2009 00:20, schrieb Anthony Liguori:
>>> Mulyadi Santosa wrote:
>>>> IMO, it would be faster if we provide keyboard shortcuts that will
>>>> stop and resume VM execution right from SDL guest interface, rather
>>>> than switching to console monitor first and type "s" or "c"
>>>> respectively.
>>>>   
>>>
>>> Is this really common of an operation that you would need an escape key 
>>> for it?
>>>
>>> Why are you so frequently stopping and continuing a guest?
>>
>> Why are you all trying to explain to him that actually he doesn't want
>> to have this feature? I could have used it, too, at times (stop the
>> guest to have enough time to attach gdb, for example). There are other
>> ways to do it (although they are not as simple) and I used them, but
>> that doesn't make this feature less useful.
>>
>> Does it take anything away for you? Or do you have plans to use those
>> keys otherwise? If not, why not add a feature that some might find
>> useful, even though others don't?
> 
> The problem with adding lots of magic key-sequences, is that the more
> you add, the more likely they are to clash with something that the 
> guest OS wants to use. You may make this use case work, but break
> someone else's use case. Thus, IMHO, magic key sequences should be kept
> to the bare minimum neccessary to access functionality for which there
> is no other viable access method.

Ok, you have a point there. But why do we have key sequences for
fullscreen and resizing the SDL window back to its original size then?
Both are things that could be accessed through monitor commands as well.
And you don't need the right timing for resizing the window - unlike
stopping the VM. So I would be really happy with swapping those for a
"stop VM" shortcut.

Kevin

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Glauber Costa]

On Wed, Oct 21, 2009 at 5:27 AM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 20.10.2009 19:08, schrieb Daniel P. Berrange:
>> On Tue, Oct 20, 2009 at 12:40:08PM +0200, Kevin Wolf wrote:
>>> Am 20.10.2009 00:20, schrieb Anthony Liguori:
>>>> Mulyadi Santosa wrote:
>>>>> IMO, it would be faster if we provide keyboard shortcuts that will
>>>>> stop and resume VM execution right from SDL guest interface, rather
>>>>> than switching to console monitor first and type "s" or "c"
>>>>> respectively.
>>>>>
>>>>
>>>> Is this really common of an operation that you would need an escape key
>>>> for it?
>>>>
>>>> Why are you so frequently stopping and continuing a guest?
>>>
>>> Why are you all trying to explain to him that actually he doesn't want
>>> to have this feature? I could have used it, too, at times (stop the
>>> guest to have enough time to attach gdb, for example). There are other
>>> ways to do it (although they are not as simple) and I used them, but
>>> that doesn't make this feature less useful.
>>>
>>> Does it take anything away for you? Or do you have plans to use those
>>> keys otherwise? If not, why not add a feature that some might find
>>> useful, even though others don't?
>>
>> The problem with adding lots of magic key-sequences, is that the more
>> you add, the more likely they are to clash with something that the
>> guest OS wants to use. You may make this use case work, but break
>> someone else's use case. Thus, IMHO, magic key sequences should be kept
>> to the bare minimum neccessary to access functionality for which there
>> is no other viable access method.
>
> Ok, you have a point there. But why do we have key sequences for
> fullscreen and resizing the SDL window back to its original size then?
> Both are things that could be accessed through monitor commands as well.
> And you don't need the right timing for resizing the window - unlike
> stopping the VM. So I would be really happy with swapping those for a
> "stop VM" shortcut.

Why don't we provide a mechanism to make a macro out of a sequence of
monitor commands, and let the user assign whatever he wants out of that?


-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Mulyadi Santosa]

On Wed, Oct 21, 2009 at 8:52 PM, Glauber Costa <glommer@gmail.com> wrote:
> Why don't we provide a mechanism to make a macro out of a sequence of
> monitor commands, and let the user assign whatever he wants out of that?

Presto! never thought about that....what are we supposed to do in
order to provide such mechanism? Who knows, perhaps I can lend a hand
(again) here....

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Glauber Costa]

On Wed, Oct 21, 2009 at 2:04 PM, Mulyadi Santosa
<mulyadi.santosa@gmail.com> wrote:
> On Wed, Oct 21, 2009 at 8:52 PM, Glauber Costa <glommer@gmail.com> wrote:
>> Why don't we provide a mechanism to make a macro out of a sequence of
>> monitor commands, and let the user assign whatever he wants out of that?
>
> Presto! never thought about that....what are we supposed to do in
> order to provide such mechanism? Who knows, perhaps I can lend a hand
> (again) here....
You can provide a monitor command to do that

something in the lines of:
- add_macro <key> <command_list>
- remove_macro <key>
- list_macros

then you could keep the assigned keys in a list, and convert the
command list to a list of functions and arguments.
For compatibility, the current assigned keystrokes would be then
converted to default macros, that could be removed,
if requested

It would be nice if you could find a way to update it on all displays,
not only SDL, at once.

this requires a little bit more work than what you did, but at least
from my point of view,
would be a nice feature, and overcome the limitations that people mentioned.



-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Mulyadi Santosa]

On Wed, Oct 21, 2009 at 11:24 PM, Glauber Costa <glommer@gmail.com> wrote:
> You can provide a monitor command to do that
>
> something in the lines of:
> - add_macro <key> <command_list>
> - remove_macro <key>
> - list_macros

Please CMIIW, "command_list" here refers to at least one of monitor
commands, right? meaning, i.e one could do:
add_macro ctrl_alt_shift_s "stop"

or extend that so it does:
add_macro ctrl_alt_shift_s "stop print $pc"

so, it stops the VM followed by printing program counter.
-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Glauber Costa]

On Wed, Oct 21, 2009 at 2:44 PM, Mulyadi Santosa
<mulyadi.santosa@gmail.com> wrote:
> On Wed, Oct 21, 2009 at 11:24 PM, Glauber Costa <glommer@gmail.com> wrote:
>> You can provide a monitor command to do that
>>
>> something in the lines of:
>> - add_macro <key> <command_list>
>> - remove_macro <key>
>> - list_macros
>
> Please CMIIW, "command_list" here refers to at least one of monitor
> commands, right? meaning, i.e one could do:
> add_macro ctrl_alt_shift_s "stop"
>
> or extend that so it does:
> add_macro ctrl_alt_shift_s "stop print $pc"
>
> so, it stops the VM followed by printing program counter.

yes, this is what I meant. But notice that this is just a suggestion.
The internet is a free country,
and if you are indeed implementing this, you are free to add your own spice.

-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Jamie Lokier]

Mulyadi Santosa wrote:
> On Wed, Oct 21, 2009 at 11:24 PM, Glauber Costa <glommer@gmail.com> wrote:
> > You can provide a monitor command to do that
> >
> > something in the lines of:
> > - add_macro <key> <command_list>
> > - remove_macro <key>
> > - list_macros
> 
> Please CMIIW, "command_list" here refers to at least one of monitor
> commands, right? meaning, i.e one could do:
> add_macro ctrl_alt_shift_s "stop"
> 
> or extend that so it does:
> add_macro ctrl_alt_shift_s "stop print $pc"
> 
> so, it stops the VM followed by printing program counter.

If the monitor accepted ";" as a command separator, to put multiple
commands on a single line, <command_list> could just be a quoted
string which is processed as a line.

If we're going to have keyboard macros, it would be nice and probably
very easy to have monitor macros too - monitor commands which expand
to a line in the same way.

The number of times I've typed things like send_key control-alt-del
and would have appreciated a "cad" macro...

Syntax idea comes to mind is:

    - Add ";" as command separator.

    - add_macro <name> <command-string>
    - remove_macro <name>
    - list_macros

    - add_key key <key> <command-string>
    - remove_key <key> <command-string>
    - list_keys

(If I were starting from nothing it'd be macro_add, macro_remove
etc. or maybe "macro add", but the above seems more consistent with
the existing monitor)

-- Jamie

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Luiz Capitulino]

On Wed, 21 Oct 2009 19:35:03 +0100
Jamie Lokier <jamie@shareable.org> wrote:

> Mulyadi Santosa wrote:
> > On Wed, Oct 21, 2009 at 11:24 PM, Glauber Costa <glommer@gmail.com> wrote:
> > > You can provide a monitor command to do that
> > >
> > > something in the lines of:
> > > - add_macro <key> <command_list>
> > > - remove_macro <key>
> > > - list_macros
> > 
> > Please CMIIW, "command_list" here refers to at least one of monitor
> > commands, right? meaning, i.e one could do:
> > add_macro ctrl_alt_shift_s "stop"
> > 
> > or extend that so it does:
> > add_macro ctrl_alt_shift_s "stop print $pc"
> > 
> > so, it stops the VM followed by printing program counter.
> 
> If the monitor accepted ";" as a command separator, to put multiple
> commands on a single line, <command_list> could just be a quoted
> string which is processed as a line.

 Why is ";" needed?

> If we're going to have keyboard macros, it would be nice and probably
> very easy to have monitor macros too - monitor commands which expand
> to a line in the same way.
> 
> The number of times I've typed things like send_key control-alt-del
> and would have appreciated a "cad" macro...

 Yeah, I agree.

 When testing migration, for example, I have to type 'migrate -d tcp:0:4444'
several times... Maybe there's a smarter way to do this, but the monitor
macros idea seems interesting to me.

> Syntax idea comes to mind is:
> 
>     - Add ";" as command separator.

 Not difficult, but not trivial.

>     - add_macro <name> <command-string>
>     - remove_macro <name>
>     - list_macros

 Why not macro_add?

> 
>     - add_key key <key> <command-string>
>     - remove_key <key> <command-string>
>     - list_keys

 What's key?

 Anyway, below there's a patch with an initial implementation. I've
implemented it using the "old" monitor style because I didn't want
to think about the right "object model" for this yet..

 If people think this is interesting I will work on a serious
implementation for submission.

 Ah, it doesn't have macro_del and if we use QObjects we can
consider saving its json representation in file so that we can
have macro_load.

commit e7fa305f82f4f99168166bda437e86d3a6343064
Author: Luiz Capitulino <lcapitulino@redhat.com>
Date:   Thu Oct 22 12:26:06 2009 -0200

    monitor: Add macro support
    
    This is a buggy, untested, initial implementation, which only supports
    "macro_add" and "macro_list".
    
    Example:
    
    (qemu) macro_add mi "migrate -d tcp:localhost:4444"
    
    Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>

diff --git a/monitor.c b/monitor.c
index 2566f4a..f8e2844 100644
--- a/monitor.c
+++ b/monitor.c
@@ -107,6 +107,15 @@ struct Monitor {
     QLIST_ENTRY(Monitor) entry;
 };
 
+typedef struct MonitorMacro {
+    QTAILQ_ENTRY(MonitorMacro) entry;
+    const char *name;
+    const char *command_line;
+} MonitorMacro;
+
+static QTAILQ_HEAD(monitor_macros, MonitorMacro) monitor_macros = 
+    QTAILQ_HEAD_INITIALIZER(monitor_macros);
+
 static QLIST_HEAD(mon_list, Monitor) mon_list;
 
 static const mon_cmd_t mon_cmds[];
@@ -1909,6 +1918,25 @@ static void do_closefd(Monitor *mon, const QDict *qdict)
                    fdname);
 }
 
+static void do_macro_add(Monitor *mon, const QDict *qdict)
+{
+    MonitorMacro *macro;
+
+    macro = qemu_mallocz(sizeof(*macro));
+    macro->name = qemu_strdup(qdict_get_str(qdict, "name"));
+    macro->command_line = qemu_strdup(qdict_get_str(qdict, "command"));
+
+    QTAILQ_INSERT_TAIL(&monitor_macros, macro, entry);
+}
+
+static void do_macro_list(Monitor *mon, const QDict *qdict)
+{
+    MonitorMacro *macro;
+
+    QTAILQ_FOREACH(macro, &monitor_macros, entry)
+        monitor_printf(mon, "%s: \"%s\"\n", macro->name, macro->command_line);
+}
+
 static void do_loadvm(Monitor *mon, const QDict *qdict)
 {
     int saved_vm_running  = vm_running;
@@ -2902,6 +2930,45 @@ static char *key_get_info(const char *type, char **key)
     return ++p;
 }
 
+static const mon_cmd_t *find_command(const char *cmdname)
+{
+    const mon_cmd_t *cmd;
+
+    /* find the command */
+    for (cmd = mon_cmds; cmd->name != NULL; cmd++) {
+        if (compare_cmd(cmdname, cmd->name))
+            return cmd;
+    }
+
+    return NULL;
+}
+
+static const mon_cmd_t *find_macro(char *cmdname, size_t len, const char **pos)
+{
+    const char *p;
+    MonitorMacro *macro;
+    const mon_cmd_t *cmd;
+
+    QTAILQ_FOREACH(macro, &monitor_macros, entry) {
+        if (strcmp(macro->name, cmdname) == 0)
+            break;
+    }
+
+    if (!macro)
+        return NULL;
+
+    p = get_command_name(macro->command_line, cmdname, len);
+    if (!p)
+        return NULL;
+
+    cmd = find_command(cmdname);
+    if (!cmd)
+        return NULL;
+
+    *pos = p;
+    return cmd;
+}
+
 static int default_fmt_format = 'x';
 static int default_fmt_size = 4;
 
@@ -2927,15 +2994,13 @@ static const mon_cmd_t *monitor_parse_command(Monitor *mon,
     if (!p)
         return NULL;
 
-    /* find the command */
-    for(cmd = mon_cmds; cmd->name != NULL; cmd++) {
-        if (compare_cmd(cmdname, cmd->name))
-            break;
-    }
-
-    if (cmd->name == NULL) {
-        monitor_printf(mon, "unknown command: '%s'\n", cmdname);
-        return NULL;
+    cmd = find_macro(cmdname, sizeof(cmdname), &p);
+    if (!cmd) {
+        cmd = find_command(cmdname);
+        if (!cmd) {
+            monitor_printf(mon, "unknown command: '%s'\n", cmdname);
+            return NULL;
+        }
     }
 
     /* parse the parameters */
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index 29999c6..37561be 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -1031,6 +1031,30 @@ Close the file descriptor previously assigned to @var{fdname} using the
 used by another monitor command.
 ETEXI
 
+    {
+        .name       = "macro_add",
+        .args_type  = "name:s,command:s",
+        .params     = "name command",
+        .help       = "add a new monitor macro",
+        .mhandler.cmd = do_macro_add,
+    },
+
+STEXI
+@item macro_add @var{name} @var{command}
+ETEXI
+
+    {
+        .name       = "macro_list",
+        .args_type  = "",
+        .params     = "",
+        .help       = "list monitor macros",
+        .mhandler.cmd = do_macro_list,
+    },
+
+STEXI
+@item macro_list
+ETEXI
+
 STEXI
 @end table
 ETEXI

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Kevin Wolf]

Am 22.10.2009 16:40, schrieb Luiz Capitulino:
> On Wed, 21 Oct 2009 19:35:03 +0100
> Jamie Lokier <jamie@shareable.org> wrote:
>> If the monitor accepted ";" as a command separator, to put multiple
>> commands on a single line, <command_list> could just be a quoted
>> string which is processed as a line.
> 
>  Why is ";" needed?

How else would you specify multiple commands for one macro?

>>
>>     - add_key key <key> <command-string>
>>     - remove_key <key> <command-string>
>>     - list_keys
> 
>  What's key?

Some kind of key binding. If we allowed all keys, it would probably make
sense to use the sendkeys style format, but I assume we'll only support
ctrl-alt-<letter> which already has a special meaning.

>  Ah, it doesn't have macro_del and if we use QObjects we can
> consider saving its json representation in file so that we can
> have macro_load.

You are thinking about having this to avoid typing in the macro each
time you start a VM? For something the user might want to touch I'd
prefer a simple solution like reading ~/.qemurc or something like that
and executing it as a "monitor script".

Kevin

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Luiz Capitulino]

On Thu, 22 Oct 2009 17:02:29 +0200
Kevin Wolf <kwolf@redhat.com> wrote:

> Am 22.10.2009 16:40, schrieb Luiz Capitulino:
> > On Wed, 21 Oct 2009 19:35:03 +0100
> > Jamie Lokier <jamie@shareable.org> wrote:
> >> If the monitor accepted ";" as a command separator, to put multiple
> >> commands on a single line, <command_list> could just be a quoted
> >> string which is processed as a line.
> > 
> >  Why is ";" needed?
> 
> How else would you specify multiple commands for one macro?

 Let me rephrase this better: what use cases do we have for
multiple commands in one line/macro?

> >>     - add_key key <key> <command-string>
> >>     - remove_key <key> <command-string>
> >>     - list_keys
> > 
> >  What's key?
> 
> Some kind of key binding. If we allowed all keys, it would probably make
> sense to use the sendkeys style format, but I assume we'll only support
> ctrl-alt-<letter> which already has a special meaning.

 Ah, I see now. Would have to think about this.

> >  Ah, it doesn't have macro_del and if we use QObjects we can
> > consider saving its json representation in file so that we can
> > have macro_load.
> 
> You are thinking about having this to avoid typing in the macro each
> time you start a VM?

 Yes.

> For something the user might want to touch I'd
> prefer a simple solution like reading ~/.qemurc or something like that
> and executing it as a "monitor script".

 That's right, asking the user to edit json doesn't seem like
a good idea.. I guess I'm working too much with it. :)

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Anthony Liguori]

Luiz Capitulino wrote:
>  Yeah, I agree.
>
>  When testing migration, for example, I have to type 'migrate -d tcp:0:4444'
> several times... Maybe there's a smarter way to do this, but the monitor
> macros idea seems interesting to me.
>   

When we have QMP, we can create a QMP socket at a well known location 
based on the -name parameter.  We could also introduce a qm command that 
allowed one to execute monitor commands from the shell.  That allows 
people to write whatever crazy shell scripts they want.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Luiz Capitulino]

On Thu, 22 Oct 2009 10:40:54 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Luiz Capitulino wrote:
> >  Yeah, I agree.
> >
> >  When testing migration, for example, I have to type 'migrate -d tcp:0:4444'
> > several times... Maybe there's a smarter way to do this, but the monitor
> > macros idea seems interesting to me.
> >   
> 
> When we have QMP, we can create a QMP socket at a well known location 
> based on the -name parameter.  We could also introduce a qm command that 
> allowed one to execute monitor commands from the shell.  That allows 
> people to write whatever crazy shell scripts they want.

 Yes.

 What about the macros idea? Are you against it?

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Anthony Liguori]

Luiz Capitulino wrote:
> On Thu, 22 Oct 2009 10:40:54 -0500
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>
>   
>> Luiz Capitulino wrote:
>>     
>>>  Yeah, I agree.
>>>
>>>  When testing migration, for example, I have to type 'migrate -d tcp:0:4444'
>>> several times... Maybe there's a smarter way to do this, but the monitor
>>> macros idea seems interesting to me.
>>>   
>>>       
>> When we have QMP, we can create a QMP socket at a well known location 
>> based on the -name parameter.  We could also introduce a qm command that 
>> allowed one to execute monitor commands from the shell.  That allows 
>> people to write whatever crazy shell scripts they want.
>>     
>
>  Yes.
>
>  What about the macros idea? Are you against it?
>   

I'm concerned that it's a snowball of complexity waiting to happen for 
very little benefit.

I think we're trying to solve a non-existent problem.

Regards,

Anthony Liguori

[Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Kevin Wolf]

Am 23.10.2009 01:55, schrieb Juan Quintela:
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>> Luiz Capitulino wrote:
>>> On Thu, 22 Oct 2009 10:40:54 -0500
>>> Anthony Liguori <anthony@codemonkey.ws> wrote:
>>>
>>>   
>>>> Luiz Capitulino wrote:
>>>>     
>>>>>  Yeah, I agree.
>>>>>
>>>>>  When testing migration, for example, I have to type 'migrate -d tcp:0:4444'
>>>>> several times... Maybe there's a smarter way to do this, but the monitor
>>>>> macros idea seems interesting to me.
>>>>>         
>>>> When we have QMP, we can create a QMP socket at a well known
>>>> location based on the -name parameter.  We could also introduce a
>>>> qm command that allowed one to execute monitor commands from the
>>>> shell.  That allows people to write whatever crazy shell scripts
>>>> they want.
>>>>     
>>>
>>>  Yes.
>>>
>>>  What about the macros idea? Are you against it?
>>>   
>>
>> I'm concerned that it's a snowball of complexity waiting to happen for
>> very little benefit.
>>
>> I think we're trying to solve a non-existent problem.
> 
> I fully agree.  If we have a had to issue commands to the monitor, we
> can use whatever shell/interpreter/... that we like.

But I can't bind a keyboard shortcut to such a script which is exactly
what this thread is about... What I want to have in the end is my "VM
stop" shortcut, dynamically binding keys to monitor commands is just a
way to achieve this.

I really hate this "You don't need this, I know it better" attitude. If
it were only for the technical arguments, okay - I can understand that
you don't want to add another magic key, and yes, doing it dynamically
comes with some complexity. But all this talking about "non-existent
problems" makes me think that you don't... really care about what users
want if they are the wrong users (yes, I admit, this one is useful more
likely for developers and plain qemu users than for those running their
servers in KVM - but they are still users, right?)

Kevin

[Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Mulyadi Santosa]

On Fri, Oct 23, 2009 at 2:40 PM, Kevin Wolf <kwolf@redhat.com> wrote:
> I really hate this "You don't need this, I know it better" attitude. If
> it were only for the technical arguments, okay - I can understand that
> you don't want to add another magic key, and yes, doing it dynamically
> comes with some complexity. But all this talking about "non-existent
> problems" makes me think that you don't... really care about what users
> want if they are the wrong users (yes, I admit, this one is useful more
> likely for developers and plain qemu users than for those running their
> servers in KVM - but they are still users, right?)

OK, everybody, please calm down.... please remember that this thread
started from my simple patch that wants to implement something that I
personally feel useful.

So, from both pros and cons side, I try to read and study your arguments.

Meanwhile, I have another idea. I admit I never redirect Qemu monitor
to certain char device. perhaps, if I could simply write a HOWTO on
how to use this feature to implement simple monitor shortcuts, then it
will be acceptable solution.

I imagine the steps would be:
1. redirect monitor to a certain char device
2. make a script that send commands to this device
3. bind new  KDE or GNOME shortcuts to call this script.

Critics?


-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

[Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Kevin Wolf]

Am 23.10.2009 13:23, schrieb Mulyadi Santosa:
> On Fri, Oct 23, 2009 at 2:40 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>> I really hate this "You don't need this, I know it better" attitude. If
>> it were only for the technical arguments, okay - I can understand that
>> you don't want to add another magic key, and yes, doing it dynamically
>> comes with some complexity. But all this talking about "non-existent
>> problems" makes me think that you don't... really care about what users
>> want if they are the wrong users (yes, I admit, this one is useful more
>> likely for developers and plain qemu users than for those running their
>> servers in KVM - but they are still users, right?)
> 
> OK, everybody, please calm down.... please remember that this thread
> started from my simple patch that wants to implement something that I
> personally feel useful.
> 
> So, from both pros and cons side, I try to read and study your arguments.
> 
> Meanwhile, I have another idea. I admit I never redirect Qemu monitor
> to certain char device. perhaps, if I could simply write a HOWTO on
> how to use this feature to implement simple monitor shortcuts, then it
> will be acceptable solution.
> 
> I imagine the steps would be:
> 1. redirect monitor to a certain char device
> 2. make a script that send commands to this device
> 3. bind new  KDE or GNOME shortcuts to call this script.

Well, the whole point of a keyboard shortcut was for me to make things
easier. Having to pass -monitor with the right magic file, writing a
script and assigning a global (!) shortcut isn't exactly what I would
call easier. I can keep using the monitor manually on TCP then.

Kevin

Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Anthony Liguori]

Kevin Wolf wrote:
> Well, the whole point of a keyboard shortcut was for me to make things
> easier.

This is something of a classic debate between providing power users 
every possible knob and function verses overwhelming non-power users 
with so many features/options that they cannot even get started.

My big problem with keyboard shortcuts is that they are a really awful 
user interface for anything because they are not discoverable (without 
consulting documentation) and they provide no obvious feedback as to 
what state they are in.

For instance, imagine creating a shortcut based on a monitor macro of 
'migrate "exec:dd of=snapshot.img"' and you tie it to ctrl-alt-e.

What feedback do you get that the command has completed?  What happens 
if you try to run the command again while another is running?  Does it 
get queued, does it get dropped?  I can imagine a user sitting there 
hitting ctrl-alt-e repeatedly not realizing anything is happening.  I 
know I find myself doing this sometimes with ctrl-a when using -nographic.

Your answer may be, this is for a developer and they'll be aware of all 
the short comings/gotchas but this ends up being a rather user-hostile 
interface.  People are never as aware of short comings/gotchas as we'd 
like them to be.  If there was no other way for a developer to do this, 
I'd be more inclined to find a way to support this but it's just a 
matter of writing a script or if you really need a short cut, you can do 
it with standard gnome short cuts or write a very simple vnc client 
based on gvncviewer (we're talking a dozen lines of added code) to do 
this for you.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Kevin Wolf]

Am 23.10.2009 15:59, schrieb Anthony Liguori:
> Kevin Wolf wrote:
>> Well, the whole point of a keyboard shortcut was for me to make things
>> easier.
> 
> This is something of a classic debate between providing power users 
> every possible knob and function verses overwhelming non-power users 
> with so many features/options that they cannot even get started.

You mean the additional monitor commands would overwhelm the non-power
users who can cope with the existing commands? This is a subjective
thing, so I can't contradict, but I'm not sure if I come to the same
conclusion. Do non-power users even use the monitor?

> 
> My big problem with keyboard shortcuts is that they are a really awful 
> user interface for anything because they are not discoverable (without 
> consulting documentation) and they provide no obvious feedback as to 
> what state they are in.

Right, with our interface they are not discoverable. I didn't know about
Ctrl-Alt-U, for example. But if I can list them in the monitor and even
more if I'm defining the shortcuts myself I'm pretty confident that I
can remember them.

> For instance, imagine creating a shortcut based on a monitor macro of 
> 'migrate "exec:dd of=snapshot.img"' and you tie it to ctrl-alt-e.
> 
> What feedback do you get that the command has completed?  What happens 
> if you try to run the command again while another is running?  Does it 
> get queued, does it get dropped?  I can imagine a user sitting there 
> hitting ctrl-alt-e repeatedly not realizing anything is happening.  I 
> know I find myself doing this sometimes with ctrl-a when using -nographic.

The user has created that ctrl-alt-e mapping himself, so he should know
how to use the monitor. He even knows the syntax of migrate, so chances
are that he also knows what it's doing.

> Your answer may be, this is for a developer and they'll be aware of all 
> the short comings/gotchas but this ends up being a rather user-hostile 
> interface.  People are never as aware of short comings/gotchas as we'd 
> like them to be.  If there was no other way for a developer to do this, 
> I'd be more inclined to find a way to support this but it's just a 
> matter of writing a script or if you really need a short cut, you can do 
> it with standard gnome short cuts or write a very simple vnc client 
> based on gvncviewer (we're talking a dozen lines of added code) to do 
> this for you.

No, sorry, before I start writing a VNC viewer I'd rather keep a local
patch around. ;-)

But I really don't feel like continuing this discussion as I don't see
anyone who could be convinced to change his opinion. I have one opinion,
you have a different one, maintainer wins. Let's move on to more
productive things.

Kevin

Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Avi Kivity]

On 10/23/2009 03:59 PM, Anthony Liguori wrote:
> Your answer may be, this is for a developer and they'll be aware of 
> all the short comings/gotchas but this ends up being a rather 
> user-hostile interface.  People are never as aware of short 
> comings/gotchas as we'd like them to be.  If there was no other way 
> for a developer to do this, I'd be more inclined to find a way to 
> support this but it's just a matter of writing a script or if you 
> really need a short cut, you can do it with standard gnome short cuts 
> or write a very simple vnc client based on gvncviewer (we're talking a 
> dozen lines of added code) to do this for you.
>

vncviewer based displays may work now, but they are inefficient and will 
likely fall apart if/when we have 3D support.

I'd much rather see a real GUI client, perhaps implemented by scripting 
QObjects or QMP.

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

Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Luiz Capitulino]

On Sun, 25 Oct 2009 17:28:33 +0200
Avi Kivity <avi@redhat.com> wrote:

> On 10/23/2009 03:59 PM, Anthony Liguori wrote:
> > Your answer may be, this is for a developer and they'll be aware of 
> > all the short comings/gotchas but this ends up being a rather 
> > user-hostile interface.  People are never as aware of short 
> > comings/gotchas as we'd like them to be.  If there was no other way 
> > for a developer to do this, I'd be more inclined to find a way to 
> > support this but it's just a matter of writing a script or if you 
> > really need a short cut, you can do it with standard gnome short cuts 
> > or write a very simple vnc client based on gvncviewer (we're talking a 
> > dozen lines of added code) to do this for you.
> >
> 
> vncviewer based displays may work now, but they are inefficient and will 
> likely fall apart if/when we have 3D support.
> 
> I'd much rather see a real GUI client, perhaps implemented by scripting 
> QObjects or QMP.

 A natural step for existing ones, they could also provide a shell by
their own.

 An interesting question is whether we should remove features from the
current shell when the time comes..

Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Anthony Liguori]

Avi Kivity wrote:
> On 10/23/2009 03:59 PM, Anthony Liguori wrote:
>> Your answer may be, this is for a developer and they'll be aware of 
>> all the short comings/gotchas but this ends up being a rather 
>> user-hostile interface.  People are never as aware of short 
>> comings/gotchas as we'd like them to be.  If there was no other way 
>> for a developer to do this, I'd be more inclined to find a way to 
>> support this but it's just a matter of writing a script or if you 
>> really need a short cut, you can do it with standard gnome short cuts 
>> or write a very simple vnc client based on gvncviewer (we're talking 
>> a dozen lines of added code) to do this for you.
>>
>
> vncviewer based displays may work now, but they are inefficient and 
> will likely fall apart if/when we have 3D support.

If it's chromium based (which I suspect it will be), you could certainly 
tunnel it via vnc.

> I'd much rather see a real GUI client, perhaps implemented by 
> scripting QObjects or QMP.

I'm with you 100% here.  I'd rather see our focus put into a proper gui 
based on QMP than to tack on features to SDL.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Avi Kivity]

On 10/26/2009 03:45 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
>> On 10/23/2009 03:59 PM, Anthony Liguori wrote:
>>> Your answer may be, this is for a developer and they'll be aware of 
>>> all the short comings/gotchas but this ends up being a rather 
>>> user-hostile interface.  People are never as aware of short 
>>> comings/gotchas as we'd like them to be.  If there was no other way 
>>> for a developer to do this, I'd be more inclined to find a way to 
>>> support this but it's just a matter of writing a script or if you 
>>> really need a short cut, you can do it with standard gnome short 
>>> cuts or write a very simple vnc client based on gvncviewer (we're 
>>> talking a dozen lines of added code) to do this for you.
>>>
>>
>> vncviewer based displays may work now, but they are inefficient and 
>> will likely fall apart if/when we have 3D support.
>
> If it's chromium based (which I suspect it will be), you could 
> certainly tunnel it via vnc.

But you wouldn't want to.  You'd probably get decent throughput at the 
expense of greater cpu consumption.  Much better to have qemu talk to drm.

>
>> I'd much rather see a real GUI client, perhaps implemented by 
>> scripting QObjects or QMP.
>
> I'm with you 100% here.  I'd rather see our focus put into a proper 
> gui based on QMP than to tack on features to SDL.
>

Maybe slightly less than 100%.  I meant a native GUI in the same process 
as qemu, but talking to QObjects through a scripting language.

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

Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Anthony Liguori]

Avi Kivity wrote:
>>
>>> I'd much rather see a real GUI client, perhaps implemented by 
>>> scripting QObjects or QMP.
>>
>> I'm with you 100% here.  I'd rather see our focus put into a proper 
>> gui based on QMP than to tack on features to SDL.
>>
>
> Maybe slightly less than 100%.  I meant a native GUI in the same 
> process as qemu, but talking to QObjects through a scripting language.

The trouble here is that if you want to support being able to close the 
gui and open it again without killing the guest, you need the guest to 
live in a separate process.

The way VMware does it is by having a VNC extension that allows a shared 
memory transport which limits the CPU overhead.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Avi Kivity]

On 10/26/2009 05:04 PM, Anthony Liguori wrote:
>> Maybe slightly less than 100%.  I meant a native GUI in the same 
>> process as qemu, but talking to QObjects through a scripting language.
>
>
> The trouble here is that if you want to support being able to close 
> the gui and open it again without killing the guest, you need the 
> guest to live in a separate process.
>

Many applications minimize to the system tray without needing two processes.

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

Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Anthony Liguori]

Avi Kivity wrote:
> On 10/26/2009 05:04 PM, Anthony Liguori wrote:
>>> Maybe slightly less than 100%.  I meant a native GUI in the same 
>>> process as qemu, but talking to QObjects through a scripting language.
>>
>>
>> The trouble here is that if you want to support being able to close 
>> the gui and open it again without killing the guest, you need the 
>> guest to live in a separate process.
>>
>
> Many applications minimize to the system tray without needing two 
> processes.

Minimizing or hiding the window are different use cases.  Now, I'm not 
100% convinced this use-case is absolutely required but historically, 
it's always come up in discussions of improving the qemu gui.

Imagine the following:

A user starts a VM at a physical box.  Everythings fine but he wants to 
return to his workstation so he closes the window.  He goes back to his 
workstation and connects to a VNC server (on a different X server).  He 
wants to now bring up the guest's display.

This cannot be achieved with a gui in the same process as qemu.  Is it 
necessary to support?  I don't know.

I'd love to just replace the SDL display with GTK + Cairo.  I'm even 
somewhat inclined to suggest linking to python so that the gui can be 
written in python...

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Avi Kivity]

On 10/26/2009 05:49 PM, Anthony Liguori wrote:
>> Many applications minimize to the system tray without needing two 
>> processes.
>
>
> Minimizing or hiding the window are different use cases.  Now, I'm not 
> 100% convinced this use-case is absolutely required but historically, 
> it's always come up in discussions of improving the qemu gui.
>
> Imagine the following:
>
> A user starts a VM at a physical box.  Everythings fine but he wants 
> to return to his workstation so he closes the window.  He goes back to 
> his workstation and connects to a VNC server (on a different X 
> server).  He wants to now bring up the guest's display.

Users don't have boxes.  They have computers.  They don't want to open 
VNC clients and type in meaningless numerical addresses.  They do want 
GUIs which fit with the OSes theme, cut'n'paste, printing, and shared 
storage, all easily configurable.

(and before someone tells me I don't know what users want - users don't 
read qemu-devel, either).

> This cannot be achieved with a gui in the same process as qemu.  Is it 
> necessary to support?  I don't know.

In the priority list this is about 3000 places below having nice buttons 
to eject and insert a CDROM.  A user with a "box" would probably want to 
run the guest on a server (and use vnc, etc.).

> I'd love to just replace the SDL display with GTK + Cairo.  I'm even 
> somewhat inclined to suggest linking to python so that the gui can be 
> written in python...

Best would be to just export a QObject binding to scripting languages, 
which could then be used to implement GUIs outside the qemu source 
base.  The only tricky part is how to deal with the display.  Can we 
expose the display as a special QDict?

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

Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Anthony Liguori]

Avi Kivity wrote:
> On 10/26/2009 05:49 PM, Anthony Liguori wrote:
>> A user starts a VM at a physical box.  Everythings fine but he wants 
>> to return to his workstation so he closes the window.  He goes back 
>> to his workstation and connects to a VNC server (on a different X 
>> server).  He wants to now bring up the guest's display.
>
> Users don't have boxes.  They have computers.  They don't want to open 
> VNC clients and type in meaningless numerical addresses.  They do want 
> GUIs which fit with the OSes theme, cut'n'paste, printing, and shared 
> storage, all easily configurable.

You misunderstood.  The VNC session is to the users remote desktop.  But 
drop VNC for a minute, this is the same thing as just closing the window 
because the VM runs all day and you don't need to see it's display.  
Like I said, I've never been convinced that this is critical but it's 
always been a very vocal argument against more GUI functionality.

>> This cannot be achieved with a gui in the same process as qemu.  Is 
>> it necessary to support?  I don't know.
>
> In the priority list this is about 3000 places below having nice 
> buttons to eject and insert a CDROM.  A user with a "box" would 
> probably want to run the guest on a server (and use vnc, etc.).

I do agree with you.

>> I'd love to just replace the SDL display with GTK + Cairo.  I'm even 
>> somewhat inclined to suggest linking to python so that the gui can be 
>> written in python...
>
> Best would be to just export a QObject binding to scripting languages, 
> which could then be used to implement GUIs outside the qemu source 
> base.  The only tricky part is how to deal with the display.  Can we 
> expose the display as a special QDict?

I'd expose the display as a GTKWidget derivative.  We would load a 
python program and it could instantiate the widget because we've already 
loaded it.  I wouldn't bother with QObject at all.  Just setup an easy 
way to use QMP from within Python using the natural python types.

The trick only real trick is that the python script has to be launched 
from a separate thread because Python isn't asynchronous and has a big 
lock at the binding level.  But it works well if you have a socketpair 
with QMP that is used from the Python thread.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Gerd Hoffmann]

On 10/26/09 17:08, Avi Kivity wrote:
>> A user starts a VM at a physical box. Everythings fine but he wants to
>> return to his workstation so he closes the window. He goes back to his
>> workstation and connects to a VNC server (on a different X server). He
>> wants to now bring up the guest's display.
>
> Users don't have boxes. They have computers. They don't want to open VNC
> clients and type in meaningless numerical addresses.

A qemu gui can easily hide that it actually uses vnc.  The only thing 
needed is a connection to the monitor (you'll need that anyway to have 
your fancy buttons do anything useful).  The GUI can do 'info vnc' to 
figure how to connect to the vnc server then.

> They do want GUIs
> which fit with the OSes theme, cut'n'paste, printing, and shared
> storage, all easily configurable.

You mean something like virt-manager?

BTW: you can quit and restart virt-manager while your VMs keep running.

>> This cannot be achieved with a gui in the same process as qemu. Is it
>> necessary to support? I don't know.
>
> In the priority list this is about 3000 places below having nice buttons
> to eject and insert a CDROM. A user with a "box" would probably want to
> run the guest on a server (and use vnc, etc.).

Focusing on the users needs *only* doesn't fly.  You want have users and 
hackers use the same thing, otherwise you'll have a hard time finding 
developers for the GUI.  Which in turn means placing the GUI into a 
separate process (which may even run on another machine) is a must-have.

cheers,
   Gerd

Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Avi Kivity]

On 10/27/2009 11:11 AM, Gerd Hoffmann wrote:
> On 10/26/09 17:08, Avi Kivity wrote:
>>> A user starts a VM at a physical box. Everythings fine but he wants to
>>> return to his workstation so he closes the window. He goes back to his
>>> workstation and connects to a VNC server (on a different X server). He
>>> wants to now bring up the guest's display.
>>
>> Users don't have boxes. They have computers. They don't want to open VNC
>> clients and type in meaningless numerical addresses.
>
> A qemu gui can easily hide that it actually uses vnc.  The only thing 
> needed is a connection to the monitor (you'll need that anyway to have 
> your fancy buttons do anything useful).  The GUI can do 'info vnc' to 
> figure how to connect to the vnc server then.

It can't hide the inefficiency introduced by vnc.  It doesn't matter for 
cirrus, but it will matter with more powerful vgpus.

Even if you tunnel gpu commands on vnc, you still have to be able to 
reconstruct your state on client disconnect.  With a native client, a 
disconnect is not posssible, so we can rely on client rendering.

>> They do want GUIs
>> which fit with the OSes theme, cut'n'paste, printing, and shared
>> storage, all easily configurable.
>
> You mean something like virt-manager?

Like virt-manager, but with all the things I mentioned.

> BTW: you can quit and restart virt-manager while your VMs keep running.

Sure, since we don't much care about graphics performance.

>>> This cannot be achieved with a gui in the same process as qemu. Is it
>>> necessary to support? I don't know.
>>
>> In the priority list this is about 3000 places below having nice buttons
>> to eject and insert a CDROM. A user with a "box" would probably want to
>> run the guest on a server (and use vnc, etc.).
>
> Focusing on the users needs *only* doesn't fly.  You want have users 
> and hackers use the same thing, otherwise you'll have a hard time 
> finding developers for the GUI. 

If that's so, we're doomed.  If the only itches scratched are 
deveopers', real users will be left out in the cold (or rather, in the 
evil clutches of those who will scratch their itches).

> Which in turn means placing the GUI into a separate process (which may 
> even run on another machine) is a must-have.

I don't see how this follows.  How does catering to 
developers/power-users imply that can't we have an in-process GUI?

We'll still have vnc for server deployments.

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

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Anthony Liguori]

Glauber Costa wrote:
> Why don't we provide a mechanism to make a macro out of a sequence of
> monitor commands, and let the user assign whatever he wants out of that?
>   

Really?  This seems exceedingly complicated to me.

Redirecting the kernel output to serial and logging is a considerably 
better solution.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Mulyadi Santosa]

On Wed, Oct 21, 2009 at 11:55 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Really?  This seems exceedingly complicated to me.
>
> Redirecting the kernel output to serial and logging is a considerably better
> solution.

I'll respectfully consider everybody's thought here....interesting
discussion so far though. mean while, if time permits I shall try to
improve my work and let's hear what everybody thinks.

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Glauber Costa]

On Wed, Oct 21, 2009 at 2:55 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Glauber Costa wrote:
>>
>> Why don't we provide a mechanism to make a macro out of a sequence of
>> monitor commands, and let the user assign whatever he wants out of that?
>>
>
> Really?  This seems exceedingly complicated to me.
>
> Redirecting the kernel output to serial and logging is a considerably better
> solution.
To his specific problem, yes.

But this probably don't work so well on some OSes that are less serial friendly.
Also, there are valid use cases in which one may want, for example, to pause
fast if some graphical event happens, which is an extension of what he mentioned
initially.

-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Anthony Liguori]

Glauber Costa wrote:
> On Wed, Oct 21, 2009 at 2:55 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>   
>> Glauber Costa wrote:
>>     
>>> Why don't we provide a mechanism to make a macro out of a sequence of
>>> monitor commands, and let the user assign whatever he wants out of that?
>>>
>>>       
>> Really?  This seems exceedingly complicated to me.
>>
>> Redirecting the kernel output to serial and logging is a considerably better
>> solution.
>>     
> To his specific problem, yes.
>
> But this probably don't work so well on some OSes that are less serial friendly.
> Also, there are valid use cases in which one may want, for example, to pause
> fast if some graphical event happens, which is an extension of what he mentioned
> initially.
>   

Then type "stop" in the monitor and hit enter when you need to.  Or, 
write a simple VNC client using gtk-vnc that can have any sort of crazy 
key sequences you want.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] new SDL keyboard shortcuts to start and stop VM

[Kevin Wolf]

Am 21.10.2009 20:08, schrieb Anthony Liguori:
> Glauber Costa wrote:
>> On Wed, Oct 21, 2009 at 2:55 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>   
>>> Glauber Costa wrote:
>>>     
>>>> Why don't we provide a mechanism to make a macro out of a sequence of
>>>> monitor commands, and let the user assign whatever he wants out of that?
>>>>
>>>>       
>>> Really?  This seems exceedingly complicated to me.
>>>
>>> Redirecting the kernel output to serial and logging is a considerably better
>>> solution.
>>>     
>> To his specific problem, yes.
>>
>> But this probably don't work so well on some OSes that are less serial friendly.
>> Also, there are valid use cases in which one may want, for example, to pause
>> fast if some graphical event happens, which is an extension of what he mentioned
>> initially.
>>   
> 
> Then type "stop" in the monitor and hit enter when you need to.  Or, 
> write a simple VNC client using gtk-vnc that can have any sort of crazy 
> key sequences you want.

Having two different consoles at the same time is easy. Guest graphics
in the SDL window, serial console on stdio. And now I need to add a
monitor. Means that I need to start using named pipes or TCP connections
or something. And I need to arrange the windows so that I can see qemu's
SDL window and the shell with my netcat (or whatever) gets the enter key
I hit. Yes, it's possible, but it's not nice.

I like Jamie's suggestion for macros.

Kevin