On Jul 10, 2013, at 3:03 PM, Scott Wood wrote:
> On 07/09/2013 10:36:37 PM, Programmingkid wrote:
>> On Jul 9, 2013, at 1:32 PM, Scott Wood wrote:
>> > On 07/04/2013 09:58:04 AM, Programmingkid wrote:
>> >> On Jul 4, 2013, at 10:51 AM, Stefan Hajnoczi wrote:
>> >> > On Thu, Jul 4, 2013 at 4:45 PM, Alexander Graf
<address@hidden> wrote:
>> >> >>
>> >> >> On 04.07.2013, at 16:40, Programmingkid wrote:
>> >> >>
>> >> >>> We have made a lot of progress in the last month with
making Mac OS X run in QEMU. A lot of people are to thank for this
milestone. To everyone involved, thank you.
>> >> >>>
>> >> >>> There is one thing that we have to figure out. That is the
command key issue. This key is a very important on the Macintosh. It
is used to send keyboard shortcuts to applications.
>> >> >>>
>> >> >>> What I propose is adding a menu item to QEMU's menu called
"Map Command key to ALT". This would allow a user to be able to send
Macintosh applications command key shortcuts from both a PC and Mac
keyboard.
>> >> >>>
>> >> >>> I welcome any and all ideas to solve this problem.
>> >> >>
>> >> >> This is the wrong mailing list for this. Your proposal would
touch non-PPC code in QEMU, so this needs to go to qemu-devel.
>> >> >>
>> >> >> Keep in mind that the same thing arises with x86 Mac OS X
running in QEMU.
>> >> >
>> >> > When I VNC into a Mac I find that the "Windows key" becomes
the
>> >> > Command key. And the same probably happens when you plug a
non-Apple
>> >> > USB keyboard into a Mac.
>> >> I was thinking about the Windows key. It would be the perfect
substitute - if it was available on all keyboards.
>> >> >
>> >> > If you are using a keyboard with a "Windows key" then that
would be
>> >> > the most natural option. If you don't have that key then you
really
>> >> > need to map something else...
>> >> >
>> >> > Stefan
>> >> Maybe there should be two menu items:
>> >> "Map command key to ALT" and "Map command key to Windows key".
>> >> They would be mutually exclusive of course.
>> >
>> > Isn't the Windows key already the same thing as the Command key,
in terms of the actual keycode generated?
>> I don't think so. The command key is equal to 0x37. The windows
key is equal to 0x5B. This is my source:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).aspx
>
> That says 0x37 is the 7 key. The word "command" does not appear.
Sorry, but this is my source for a Mac keyboard:
http://boredzo.org/blog/wp-content/uploads/2007/05/imtx-virtual-keycodes.png.
The values you see on the keys are in decimal. 55 in base 10 is equal
to 37 in base 16.
>> I also want to state that I decided against the adding menu items
idea. Instead I am currently planning to use a command line option.
You just pass the key value you want to use to act as the command
key. Here's an example:
>> qemu-system-ppc -command-key 0x37.
>> The user could pick one of the functions keys as the command key
if desired.
>
> If you're going to get into remapping keys, wouldn't it be better
to have a generalized mechanism so the user could do whatever remaps
they want? Other targets may have their own special keys.
>
> -Scott
That does sound like a good idea. There would be a lot of things we
would have to consider and agree upon. This is what I think you want,
a command line option that specifies a key what it maps to.
Example:
qemu-system-ppc -a-key 0x0 -b-key 0x11 ...
Basically you specify a key, then state the raw keyboard value for
it. Is that what you mean by generalized mechanism? This way could
work, but I think using a file might be better.
Example:
file: keyboard-layout.txt
a 0x0
b 0x11
c 0x8
command 0x37
option 0x3A
control 0x3B
....