qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-ppc] Mac OS X on QEMU


From: Alexander Graf
Subject: Re: [Qemu-devel] [Qemu-ppc] Mac OS X on QEMU
Date: Thu, 11 Jul 2013 00:01:48 +0200


Am 10.07.2013 um 21:54 schrieb Programmingkid <address@hidden>:

> 
> 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. 
> 
>> 
>> 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? 
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]