Patchwork new SDL keyboard shortcuts to start and stop VM

login
register
mail settings
Submitter Mulyadi Santosa
Date Oct. 18, 2009, 4:24 p.m.
Message ID <f284c33d0910180924h13762eebl4f029c9606988dec@mail.gmail.com>
Download mbox | patch
Permalink /patch/36339/
State New
Headers show

Comments

Mulyadi Santosa - Oct. 18, 2009, 4:24 p.m.
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(+)

                         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;
                     }
Anthony Liguori - Oct. 19, 2009, 10:20 p.m.
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
Mulyadi Santosa - Oct. 20, 2009, 3:16 a.m.
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.
Gerd Hoffmann - Oct. 20, 2009, 7:58 a.m.
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
Daniel P. Berrange - Oct. 20, 2009, 8:12 a.m.
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
Kevin Wolf - Oct. 20, 2009, 10:40 a.m.
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
Anthony Liguori - Oct. 20, 2009, 4:59 p.m.
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
Daniel P. Berrange - Oct. 20, 2009, 5:08 p.m.
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
Mulyadi Santosa - Oct. 20, 2009, 10:14 p.m.
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
Kevin Wolf - Oct. 21, 2009, 7:27 a.m.
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
Glauber Costa - Oct. 21, 2009, 1:52 p.m.
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?
Mulyadi Santosa - Oct. 21, 2009, 4:04 p.m.
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....
Glauber Costa - Oct. 21, 2009, 4:24 p.m.
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.
Mulyadi Santosa - Oct. 21, 2009, 4:44 p.m.
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.
Glauber Costa - Oct. 21, 2009, 4:48 p.m.
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.
Anthony Liguori - Oct. 21, 2009, 4:55 p.m.
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
Mulyadi Santosa - Oct. 21, 2009, 5:01 p.m.
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.
Glauber Costa - Oct. 21, 2009, 5:04 p.m.
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.
Anthony Liguori - Oct. 21, 2009, 6:08 p.m.
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
Jamie Lokier - Oct. 21, 2009, 6:35 p.m.
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
Kevin Wolf - Oct. 22, 2009, 7:58 a.m.
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

Patch

--- 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 */