diff mbox

[v2] Adds the ability to use the command key in the guest operating system.

Message ID CAKyx-3MMkqKw3GXxSR=NizeBHhE+pYyONUX+0mtOgu5h3kix9g@mail.gmail.com
State New
Headers show

Commit Message

Programmingkid Aug. 3, 2013, 10:52 p.m. UTC
This patch adds the ability to use the command key in the guest
 operating system. Just add -command-key 55 to the command line
 options sent to QEMU to use this feature.

I have checked the patch by sending it thru checkpatch.pl this time. I also
made a bunch of style changes to more closely match QEMU's suggested coding
style.

signed-off-by: John Arbuckle <programmingkidx@gmail.com>

---
 ui/cocoa.m |  114
++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 104 insertions(+), 10 deletions(-)

+ }
+}

 /*
  ------------------------------------------------------
@@ -491,6 +558,11 @@ QemuCocoaView *cocoaView;
     int keycode;
     NSPoint p = [event locationInWindow];

+    // The key used to send QEMU commands (e.g. Quit, Full Screen).
+    // Change this if you don't like using the ALT key.
+    // Possible values: NSShiftKeyMask, NSControlKeyMask,
NSFunctionKeyMask, NSAlternateKeyMask
+    const int substitute_key_mask = NSAlternateKeyMask;
+
     switch ([event type]) {
         case NSFlagsChanged:
             keycode = cocoa_keycode_to_qemu([event keyCode]);
@@ -499,12 +571,13 @@ QemuCocoaView *cocoaView;
                     kbd_put_keycode(keycode);
                     kbd_put_keycode(keycode | 0x80);
                 } else if (qemu_console_is_graphic(NULL)) {
-                    if (keycode & 0x80)
-                        kbd_put_keycode(0xe0);
-                    if (modifiers_state[keycode] == 0) { // keydown
+              if (keycode & 0x80) {            // if keycode >= 0x80, for
those keycodes that need a 0xe0 sent first
+                  kbd_put_keycode(0xe0);
+              }
+                    if (modifiers_state[keycode] == 0) {     // keydown
                         kbd_put_keycode(keycode & 0x7f);
                         modifiers_state[keycode] = 1;
-                    } else { // keyup
+                    } else {                                 // keyup
                         kbd_put_keycode(keycode | 0x80);
                         modifiers_state[keycode] = 0;
                     }
@@ -517,13 +590,33 @@ QemuCocoaView *cocoaView;
             }
             break;
         case NSKeyDown:
+            // if substituting for the host command key and the substitute
key is being held down - have QEMU handle it
+            if((substituting_for_command_key == true) && ([event
modifierFlags] & substitute_key_mask)) {
+               // recreate the event with the command key as the modifier
+               int modifiers = [event modifierFlags];
+               modifiers = modifiers | NSCommandKeyMask;  // set the
command key
+               modifiers = modifiers ^ substitute_key_mask; // unset the
substitute key
+
+               event = [NSEvent keyEventWithType: [event type] location:
[event locationInWindow] modifierFlags: modifiers
+                       timestamp: [event timestamp] windowNumber: [event
windowNumber] context: [event context] characters: [event characters]
+                       charactersIgnoringModifiers: [event
charactersIgnoringModifiers] isARepeat: [event isARepeat] keyCode: [event
keyCode] ];
+               [NSApp sendEvent:event];
+               return;
+            }

-            // forward command Key Combos
-            if ([event modifierFlags] & NSCommandKeyMask) {
+            // if the command key is held down and we want QEMU to handle
the event - not the guest OS
+            else if([event modifierFlags] & NSCommandKeyMask &&
substituting_for_command_key == false) {
                 [NSApp sendEvent:event];
                 return;
             }

+            // if the command key is held down and we want the guest OS to
handle it
+            if(([event modifierFlags] & NSCommandKeyMask) &&
(substituting_for_command_key == true)) {
+                kbd_put_keycode(219); // command key
+                kbd_put_keycode(cocoa_keycode_to_qemu([event keyCode]));
// any other keys
+                return;
+            }
+
             // default
             keycode = cocoa_keycode_to_qemu([event keyCode]);

@@ -584,7 +677,7 @@ QemuCocoaView *cocoaView;
             if (qemu_console_is_graphic(NULL)) {
                 if (keycode & 0x80)
                     kbd_put_keycode(0xe0);
-                kbd_put_keycode(keycode | 0x80); //add 128 to signal
release of key
+                kbd_put_keycode(keycode | 0x80); //add 128 (0x80) to
signal release of key
             }
             break;
         case NSMouseMoved:
@@ -812,6 +905,7 @@ QemuCocoaView *cocoaView;
     COCOA_DEBUG("QemuCocoaAppController: startEmulationWithArgc\n");

     int status;
+    handleCommandKeyOption(&argc, argv);
     status = qemu_main(argc, argv, *_NSGetEnviron());
     exit(status);
 }
@@ -1046,4 +1140,4 @@ void cocoa_display_init(DisplayState *ds, int
full_screen)

     // register cleanup function
     atexit(cocoa_cleanup);
-}
+}
\ No newline at end of file

Comments

Peter Maydell Aug. 3, 2013, 11:06 p.m. UTC | #1
On 3 August 2013 23:52, G 3 <programmingkidx@gmail.com> wrote:
> This patch adds the ability to use the command key in the guest
>  operating system. Just add -command-key 55 to the command line
>  options sent to QEMU to use this feature.
>
> I have checked the patch by sending it thru checkpatch.pl this time. I also
> made a bunch of style changes to more closely match QEMU's suggested coding
> style.
>
> signed-off-by: John Arbuckle <programmingkidx@gmail.com>
>
> ---
>  ui/cocoa.m |  114
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
>  1 files changed, 104 insertions(+), 10 deletions(-)

This definitely isn't "trivial".

I'm also really unconvinced that this is the right way to handle
this: adding a new cocoa-UI-only command line option which takes
a magic number looks very odd.

thanks
-- PMM
Programmingkid Aug. 3, 2013, 11:43 p.m. UTC | #2
On Aug 3, 2013, at 7:06 PM, Peter Maydell wrote:

> On 3 August 2013 23:52, G 3 <programmingkidx@gmail.com> wrote:
>> This patch adds the ability to use the command key in the guest
>> operating system. Just add -command-key 55 to the command line
>> options sent to QEMU to use this feature.
>> 
>> I have checked the patch by sending it thru checkpatch.pl this time. I also
>> made a bunch of style changes to more closely match QEMU's suggested coding
>> style.
>> 
>> signed-off-by: John Arbuckle <programmingkidx@gmail.com>
>> 
>> ---
>> ui/cocoa.m |  114
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
>> 1 files changed, 104 insertions(+), 10 deletions(-)
> 
> This definitely isn't "trivial".
> 
> I'm also really unconvinced that this is the right way to handle
> this: adding a new cocoa-UI-only command line option which takes
> a magic number looks very odd.
> 
> thanks
> -- PMM

Why don't you think it is trivial? There aren't many cocoa-ui users. This patch falls into a very small and little used area of QEMU. I think that makes this patch a trivial one. 

The way of how to handle send the command key into the guest operating system has already been discussed. This way lets the user decide at runtime how best to handle the command key. The magic number you talk about is actually a virtual key value. Every key has their own virtual key.

Do you have your own idea as to how to handle the command key?
Peter Maydell Aug. 4, 2013, 9:39 a.m. UTC | #3
On 4 August 2013 00:43, Programmingkid <programmingkidx@gmail.com> wrote:
>
> On Aug 3, 2013, at 7:06 PM, Peter Maydell wrote:
>
>> On 3 August 2013 23:52, G 3 <programmingkidx@gmail.com> wrote:
>>> This patch adds the ability to use the command key in the guest
>>> operating system. Just add -command-key 55 to the command line
>>> options sent to QEMU to use this feature.
>>>
>>> I have checked the patch by sending it thru checkpatch.pl this time. I also
>>> made a bunch of style changes to more closely match QEMU's suggested coding
>>> style.
>>>
>>> signed-off-by: John Arbuckle <programmingkidx@gmail.com>
>>>
>>> ---
>>> ui/cocoa.m |  114
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
>>> 1 files changed, 104 insertions(+), 10 deletions(-)
>>
>> This definitely isn't "trivial".
>>
>> I'm also really unconvinced that this is the right way to handle
>> this: adding a new cocoa-UI-only command line option which takes
>> a magic number looks very odd.

> Why don't you think it is trivial?

It's over 100 lines long; it's not "obviously correct"; it adds
a new command line switch; cocoa.m has a listed maintainer.

> The way of how to handle send the command key into the guest operating
> system has already been discussed. This way lets the user decide at
> runtime how best to handle the command key. The magic number you talk
> about is actually a virtual key value. Every key has their own
> virtual key.

Right, but I don't have to specify anything about any other
key on the keyboard, why should command be special?

> Do you have your own idea as to how to handle the command key?

"Should the QEMU UI use the menu-accelerator key for menus or
should it pass it through to the guest" is a generic UI front-end
problem; any solution should not be specific to a single UI,
we should handle it the same way for all front-ends.

-- PMM
Anthony Liguori Aug. 4, 2013, 11:58 a.m. UTC | #4
On Sun, Aug 4, 2013 at 4:39 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> "Should the QEMU UI use the menu-accelerator key for menus or
> should it pass it through to the guest" is a generic UI front-end
> problem; any solution should not be specific to a single UI,
> we should handle it the same way for all front-ends.

The right way to handle this would be to access the hardware keycode
and avoid the keymap table entirely.  I'm sure there is such an API in
Cocoa...

Regards,

Anthony Liguori

> -- PMM
>
Programmingkid Aug. 4, 2013, 5:53 p.m. UTC | #5
On Aug 4, 2013, at 5:39 AM, Peter Maydell wrote:

> On 4 August 2013 00:43, Programmingkid <programmingkidx@gmail.com> wrote:
>> 
>> On Aug 3, 2013, at 7:06 PM, Peter Maydell wrote:
>> 
>>> On 3 August 2013 23:52, G 3 <programmingkidx@gmail.com> wrote:
>>>> This patch adds the ability to use the command key in the guest
>>>> operating system. Just add -command-key 55 to the command line
>>>> options sent to QEMU to use this feature.
>>>> 
>>>> I have checked the patch by sending it thru checkpatch.pl this time. I also
>>>> made a bunch of style changes to more closely match QEMU's suggested coding
>>>> style.
>>>> 
>>>> signed-off-by: John Arbuckle <programmingkidx@gmail.com>
>>>> 
>>>> ---
>>>> ui/cocoa.m |  114
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
>>>> 1 files changed, 104 insertions(+), 10 deletions(-)
>>> 
>>> This definitely isn't "trivial".
>>> 
>>> I'm also really unconvinced that this is the right way to handle
>>> this: adding a new cocoa-UI-only command line option which takes
>>> a magic number looks very odd.
> 
>> Why don't you think it is trivial?
> 
> It's over 100 lines long; it's not "obviously correct"; it adds
> a new command line switch; cocoa.m has a listed maintainer.
> 
>> The way of how to handle send the command key into the guest operating
>> system has already been discussed. This way lets the user decide at
>> runtime how best to handle the command key. The magic number you talk
>> about is actually a virtual key value. Every key has their own
>> virtual key.
> 
> Right, but I don't have to specify anything about any other
> key on the keyboard, why should command be special?

The command key is used to send commands to an application. When the user runs Mac OS X in QEMU, and the host operating system is Mac OS X, this can cause problems. Users like me want to use the command key in the guest operating system, but we also need to send commands to QEMU. So this causes problems. Every user is going to have their own idea on how to solve this problem. So the way to fix this problem is to have the user decide which key should act as the command key. 

> 
>> Do you have your own idea as to how to handle the command key?
> 
> "Should the QEMU UI use the menu-accelerator key for menus or
> should it pass it through to the guest" is a generic UI front-end
> problem; any solution should not be specific to a single UI,
> we should handle it the same way for all front-ends.

?
Peter Maydell Aug. 4, 2013, 6:07 p.m. UTC | #6
On 4 August 2013 18:53, Programmingkid <programmingkidx@gmail.com> wrote:
> On Aug 4, 2013, at 5:39 AM, Peter Maydell wrote
>> Right, but I don't have to specify anything about any other
>> key on the keyboard, why should command be special?
>
> The command key is used to send commands to an application. When
> the user runs Mac OS X in QEMU, and the host operating system is
> Mac OS X, this can cause problems.

Yes, I understand the problem. Why is this any different to
the similar issue with the menu-key or the Windows key in Windows
(where you also might want to pass it through to the guest,
or have it handled outside the guest).

>>> Do you have your own idea as to how to handle the command key?
>>
>> "Should the QEMU UI use the menu-accelerator key for menus or
>> should it pass it through to the guest" is a generic UI front-end
>> problem; any solution should not be specific to a single UI,
>> we should handle it the same way for all front-ends.
>
> ?

See above.

-- PMM
Programmingkid Aug. 4, 2013, 6:22 p.m. UTC | #7
On Aug 4, 2013, at 7:58 AM, Anthony Liguori wrote:

> On Sun, Aug 4, 2013 at 4:39 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> 
>> "Should the QEMU UI use the menu-accelerator key for menus or
>> should it pass it through to the guest" is a generic UI front-end
>> problem; any solution should not be specific to a single UI,
>> we should handle it the same way for all front-ends.
> 

Ok. I guess that sounds like a good idea, but hard to implement. I don't think any single piece of code could be applied to all the different UI's. There is SDL, GTK, Cocoa, and who knows what else to handle. Each UI library would need its own code to deal with the meta key issue. 

> The right way to handle this would be to access the hardware keycode
> and avoid the keymap table entirely.  I'm sure there is such an API in
> Cocoa...
> 
> Regards,
> 
> Anthony Liguori

Your idea does have a few issues with it. This might work with a Mac guest on a Mac host, but what about a PC guest on a Mac host? A PC operating system like Windows 95 would probably not be able to recognize a Macintosh keyboard. The current strategy in cocoa.m is to emulate a pc/xt keyboard. This kind of keyboard works for a lot of different guest operating systems - including Mac OS X.
Programmingkid Aug. 4, 2013, 6:52 p.m. UTC | #8
On Aug 4, 2013, at 2:07 PM, Peter Maydell wrote:

> On 4 August 2013 18:53, Programmingkid <programmingkidx@gmail.com> wrote:
>> On Aug 4, 2013, at 5:39 AM, Peter Maydell wrote
>>> Right, but I don't have to specify anything about any other
>>> key on the keyboard, why should command be special?
>> 
>> The command key is used to send commands to an application. When
>> the user runs Mac OS X in QEMU, and the host operating system is
>> Mac OS X, this can cause problems.
> 
> Yes, I understand the problem. Why is this any different to
> the similar issue with the menu-key or the Windows key in Windows
> (where you also might want to pass it through to the guest,
> or have it handled outside the guest).

I don't use QEMU on a PC, so I don't have experience with this issue. But it does sound like the problem I had on Mac OS X. For anyone who uses QEMU on Windows, is the control key used to send commands to QEMU, and sent to the guest operating system? I'm wondering if someone out there uses a Windows guest on a Windows host can help us with this issue. 

> 
>>>> Do you have your own idea as to how to handle the command key?
>>> 
>>> "Should the QEMU UI use the menu-accelerator key for menus or
>>> should it pass it through to the guest" is a generic UI front-end
>>> problem; any solution should not be specific to a single UI,
>>> we should handle it the same way for all front-ends.

The problem with this idea is each UI has its own implementation library: SDL, GTK, Cocoa. Each UI would have to have its solution coded differently. There is no one size fits all solution. I honestly don't know if this is an issue with the SDL and GTK UI's.
Alexander Graf Aug. 14, 2013, 6:02 p.m. UTC | #9
On 04.08.2013, at 20:52, Programmingkid wrote:

> 
> On Aug 4, 2013, at 2:07 PM, Peter Maydell wrote:
> 
>> On 4 August 2013 18:53, Programmingkid <programmingkidx@gmail.com> wrote:
>>> On Aug 4, 2013, at 5:39 AM, Peter Maydell wrote
>>>> Right, but I don't have to specify anything about any other
>>>> key on the keyboard, why should command be special?
>>> 
>>> The command key is used to send commands to an application. When
>>> the user runs Mac OS X in QEMU, and the host operating system is
>>> Mac OS X, this can cause problems.
>> 
>> Yes, I understand the problem. Why is this any different to
>> the similar issue with the menu-key or the Windows key in Windows
>> (where you also might want to pass it through to the guest,
>> or have it handled outside the guest).
> 
> I don't use QEMU on a PC, so I don't have experience with this issue. But it does sound like the problem I had on Mac OS X. For anyone who uses QEMU on Windows, is the control key used to send commands to QEMU, and sent to the guest operating system? I'm wondering if someone out there uses a Windows guest on a Windows host can help us with this issue. 
> 
>> 
>>>>> Do you have your own idea as to how to handle the command key?
>>>> 
>>>> "Should the QEMU UI use the menu-accelerator key for menus or
>>>> should it pass it through to the guest" is a generic UI front-end
>>>> problem; any solution should not be specific to a single UI,
>>>> we should handle it the same way for all front-ends.
> 
> The problem with this idea is each UI has its own implementation library: SDL, GTK, Cocoa. Each UI would have to have its solution coded differently. There is no one size fits all solution. I honestly don't know if this is an issue with the SDL and GTK UI's. 

The argument is that the user experience and configuration methods should be as close as possible / reasonable across the different UI backends.


Alex
Anthony Liguori Aug. 14, 2013, 8:44 p.m. UTC | #10
I'm confident there's a way to get hardware keycodes on OS X.  There
is on every other UI platform that I know of.  That's the best way to
solve this.

Regards,

Anthony Liguori

On Wed, Aug 14, 2013 at 1:02 PM, Alexander Graf <agraf@suse.de> wrote:
>
> On 04.08.2013, at 20:52, Programmingkid wrote:
>
>>
>> On Aug 4, 2013, at 2:07 PM, Peter Maydell wrote:
>>
>>> On 4 August 2013 18:53, Programmingkid <programmingkidx@gmail.com> wrote:
>>>> On Aug 4, 2013, at 5:39 AM, Peter Maydell wrote
>>>>> Right, but I don't have to specify anything about any other
>>>>> key on the keyboard, why should command be special?
>>>>
>>>> The command key is used to send commands to an application. When
>>>> the user runs Mac OS X in QEMU, and the host operating system is
>>>> Mac OS X, this can cause problems.
>>>
>>> Yes, I understand the problem. Why is this any different to
>>> the similar issue with the menu-key or the Windows key in Windows
>>> (where you also might want to pass it through to the guest,
>>> or have it handled outside the guest).
>>
>> I don't use QEMU on a PC, so I don't have experience with this issue. But it does sound like the problem I had on Mac OS X. For anyone who uses QEMU on Windows, is the control key used to send commands to QEMU, and sent to the guest operating system? I'm wondering if someone out there uses a Windows guest on a Windows host can help us with this issue.
>>
>>>
>>>>>> Do you have your own idea as to how to handle the command key?
>>>>>
>>>>> "Should the QEMU UI use the menu-accelerator key for menus or
>>>>> should it pass it through to the guest" is a generic UI front-end
>>>>> problem; any solution should not be specific to a single UI,
>>>>> we should handle it the same way for all front-ends.
>>
>> The problem with this idea is each UI has its own implementation library: SDL, GTK, Cocoa. Each UI would have to have its solution coded differently. There is no one size fits all solution. I honestly don't know if this is an issue with the SDL and GTK UI's.
>
> The argument is that the user experience and configuration methods should be as close as possible / reasonable across the different UI backends.
>
>
> Alex
>
>
Peter Maydell Aug. 14, 2013, 8:52 p.m. UTC | #11
On 14 August 2013 21:44, Anthony Liguori <anthony@codemonkey.ws> wrote:
> I'm confident there's a way to get hardware keycodes on OS X.  There
> is on every other UI platform that I know of.  That's the best way to
> solve this.

Sure, but that doesn't answer the fundamental question of "when
should the OS's window/menu accelerator operate the OS menu and
when should it be passed to the guest as a raw key". However you
get the keycodes you still have that choice.

-- PMM
Alexander Graf Aug. 14, 2013, 8:58 p.m. UTC | #12
On 14.08.2013, at 22:52, Peter Maydell wrote:

> On 14 August 2013 21:44, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> I'm confident there's a way to get hardware keycodes on OS X.  There
>> is on every other UI platform that I know of.  That's the best way to
>> solve this.
> 
> Sure, but that doesn't answer the fundamental question of "when
> should the OS's window/menu accelerator operate the OS menu and
> when should it be passed to the guest as a raw key". However you
> get the keycodes you still have that choice.

The normal rule of thumb IIRC is when mouse grab is active, everything goes into the guest.


Alex
Programmingkid Aug. 15, 2013, 1:31 a.m. UTC | #13
On Aug 14, 2013, at 4:58 PM, Alexander Graf wrote:

> 
> On 14.08.2013, at 22:52, Peter Maydell wrote:
> 
>> On 14 August 2013 21:44, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>> I'm confident there's a way to get hardware keycodes on OS X.  There
>>> is on every other UI platform that I know of.  That's the best way to
>>> solve this.

I know you want to use hardware keycodes, but here are (IMHO) the reasons why we should stick with the PC/XT layout:
1) Simple - only one keyboard layout to deal with.
2) Compatible - This layout works with operating systems from MS-DOS 1.0 to Ubuntu Linux 12. 
3) Less work - no major code changes.
4) Good enough - does work with Mac OS X. 
5) Would Mac keyboard keycodes work with Windows, AIX, Solaris, and OS/2? Doubt it. Guess which keyboard layout would work.

>> 
>> Sure, but that doesn't answer the fundamental question of "when
>> should the OS's window/menu accelerator operate the OS menu and
>> when should it be passed to the guest as a raw key". However you
>> get the keycodes you still have that choice.
> 
> The normal rule of thumb IIRC is when mouse grab is active, everything goes into the guest.

That is a good idea. I am thinking of eliminating the -command-key option and just doing the above suggestion. 

Anybody else have their own idea for solving the command key issue?
diff mbox

Patch

diff --git a/ui/cocoa.m b/ui/cocoa.m
index be49179..99d65bf 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -70,6 +70,7 @@  static DisplayChangeListener *dcl;

 int gArgc;
 char **gArgv;
+bool substituting_for_command_key = false;

 // keymap conversion
 int keymap[] =
@@ -129,8 +130,8 @@  int keymap[] =
     14, //  51      0x33    0x0e            BKSP    QZ_BACKSPACE
     0,  //  52      0x34    Undefined
     1,  //  53      0x35    0x01            ESC     QZ_ESCAPE
-    0,  //  54      0x36                            QZ_RMETA
-    0,  //  55      0x37                            QZ_LMETA
+    219, //  54     0x36                            QZ_RMETA
+    219, //  55     0x37                            QZ_LMETA
     42, //  56      0x38    0x2a            L SHFT  QZ_LSHIFT
     58, //  57      0x39    0x3a            CAPS    QZ_CAPSLOCK
     56, //  58      0x3A    0x38            L ALT   QZ_LALT
@@ -249,6 +250,72 @@  static int cocoa_keycode_to_qemu(int keycode)
 }


+// Used to map the guest OS's command key to a key on the host keyboard.
+// Uses the -command-key option.
+static void handleCommandKeyOption(int * argc, char * argv[])
+{
+ bool foundOption = false;
+ int new_command_key_button_value, i;
+
+ #define BUFFER_SIZE 10
+ #define LEFT_COMMAND_KEY 0x37
+ #define RIGHT_COMMAND_KEY 0x36
+ #define GUEST_COMMAND_KEY 219
+
+ char key_value_string[BUFFER_SIZE];
+
+ for(i = 0; i < *argc; i++) {
+    if(strcmp(argv[i], "-command-key") == 0) {
+        foundOption = true;
+           break;
+    }
+ }
+
+ // if the -command-key option is found
+ if(foundOption == true)
+ {
+ snprintf(key_value_string, BUFFER_SIZE, "%s", argv[i+1]);
+ if(strlen(key_value_string) == 0) {
+ printf("Usage: -command-key <host keyboard key value>\n");
+ printf("This page will help:
http://boredzo.org/blog/wp-content/uploads/2007/05/imtx-virtual-keycodes.png\n
");
+ exit(-1000);
+ }
+
+ // if using hexadecimal notation (e.g. 0x37)
+ if(key_value_string[0] == '0' && toupper(key_value_string[1]) == 'X') {
+ sscanf(key_value_string, "%x", &new_command_key_button_value);
+ }
+
+ // for decimal notation
+ else {
+ new_command_key_button_value = atoi(key_value_string);
+ }
+
+ //in case the key specified is a negative value
+ if(new_command_key_button_value < 0) {
+ printf("\aCan't use a negative value for the command key!\n");
+ exit(-1001);
+ }
+
+ // if the guest OS command key is set to the host keyboard's left or
right command key
+ if(new_command_key_button_value == LEFT_COMMAND_KEY ||
new_command_key_button_value == RIGHT_COMMAND_KEY) {
+ substituting_for_command_key = true;
+ printf("\nNote: since you are using the host command key, the ALT key can
be used to send QEMU commands.\n");
+ printf("Example: use ALT-q to quit QEMU.\n\n");
+ }
+
+ // do the mapping
+ keymap[new_command_key_button_value] = GUEST_COMMAND_KEY;
+
+ // Remove -command-key from the argument list.
+ // QEMU will complain if we don't.
+ for(int x = i; x < *argc - 2; x=x+2) {
+ argv[x] = argv[x+2];
+ argv[x+1] = argv[x+3];
+ }
+ *argc = *argc - 2;