[OpenBIOS] [Qemu-ppc] [Qemu-devel] Mac OS X on QEMU

[Scott Wood]

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 at 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).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.

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