On 07/10/2013 02:54:19 PM, Programmingkid wrote:
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
agraf@suse.de 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).as...
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.
You're comparing apples to oranges. Both of those are "virtual keycodes" defined by some OS. Note that all the other keys are different as well between the two.
I assume you mean "The alt and control key are not used very
much...".
Maybe the user doesn't mind -- but maybe they do mind and would
rather swap the two than end up with both ALT and the OS key being Command. When I used MacOS X I use control and alt quite a bit, in console and X11 apps.
That's not a problem. The user would be free to decide which key acts as the command key. A function key could be used. The alt and control key can be left alone.
If I want to use the alt key as the command key, then with your proposal, how would I get the OS key to act as the alt key?
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 ....
Yes, something like that. It would be nice if existing infrastructure could be used, such as using X11 keycodes (or whatever else is native to the host) rather than making up a new namespace for keys.
qemu-system-ppc -keyboard-layout-file ./keyboard-layout.txt
There is one issue that still bothers me. Should we assume an ascii keyboard is attached to the QEMU emulated machine? We might want to consider unicode in the future. Not every user speaks english. Are there any non-native english users who would like to see unicode support in QEMU?
Keyboards don't generally speak ASCII (or Unicode). They produce keycodes, which are generally translated into some sort of event by the host's input layer (e.g. the X server). It's up to the guest software to translate those keycodes into either ASCII or Unicode (or whatever else it wants).
-Scott