Am 10.07.2013 um 21:54 schrieb Programmingkid <programmingk...@gmail.com>:
> > 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 <ag...@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. > >> >> It also looks like that table for something that Windows produces, not the >> raw output of the keyboard. > > That could be the case. > >> >>>> And you'd still want to have an actual ALT key available... The option >>>> should just be whether to swap the Command/Windows and ALT keys for better >>>> ergonomics. >>> That might not be true. The user might not mind giving up the alt or >>> control keys. The options and control key are not used very much on Mac OS >>> X. >> >> 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. > >> >>> 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 > .... > > qemu-system-ppc -keyboard-layout-file ./keyboard-layout.txt That's exactly what -k does today already, no? Alex > > 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? > >