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

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

[Alexander Graf]

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.


Alex

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

[Stefan Hajnoczi]

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.

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

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

[Programmingkid]

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. 

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

[Scott Wood]

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

-Scott

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

[Programmingkid]

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

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

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

[Tarl Neustaedter]

On 2013-Jul-9 23:36 , Programmingkid wrote:
> 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

Err, no.

USB keyboards generate standard codes for keypresses, regardless of 
whether they are labeled "windows" or "command" (or "meta"). It's a 
major pain in the ass that vendors sell keyboards with completely 
different markings and absolutely no difference in the codes they 
generate. Sun keyboards produced a byte saying what markings were on the 
keyboard so we could set up the right tables, but standard USB keyboards 
don't. So we have to ask - one of the few conventions is that the 
numbers 0-9 are fixed, so we can at least ask for a number to be typed.

In any case, about the Command/Windows/Meta key:

http://en.wikipedia.org/wiki/Command_key#On_other_keyboards

"On a keyboard made with MS Windows logo, the Windows key is mapped to 
act as the Command key"

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

[Programmingkid]

On Jul 10, 2013, at 12:10 AM, Tarl Neustaedter wrote:

> On 2013-Jul-9 23:36 , Programmingkid wrote:
>> 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
> 
> Err, no.
> 
> USB keyboards generate standard codes for keypresses, regardless of whether they are labeled "windows" or "command" (or "meta"). It's a major pain in the ass that vendors sell keyboards with completely different markings and absolutely no difference in the codes they generate. Sun keyboards produced a byte saying what markings were on the keyboard so we could set up the right tables, but standard USB keyboards don't. So we have to ask - one of the few conventions is that the numbers 0-9 are fixed, so we can at least ask for a number to be typed.
> 
> In any case, about the Command/Windows/Meta key:
> 
> http://en.wikipedia.org/wiki/Command_key#On_other_keyboards
> 
> "On a keyboard made with MS Windows logo, the Windows key is mapped to act as the Command key"

This information is good to hear. Those with a Windows key on their keyboard shouldn't have a problem using it as the command key. Those who don't have a Windows key can use the -command-key option to set it to any key they want. 

The only problem I have now is how to send more than one key value at a time to the guest OS. Any ideas would be great. 

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

[Scott Wood]

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

That says 0x37 is the 7 key.  The word "command" does not appear.

It also looks like that table for something that Windows produces, not  
the raw output of the keyboard.

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

> 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

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

[Programmingkid]

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

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? 

Re: [Qemu-devel] [Qemu-ppc] 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@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

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

[Programmingkid]

On Jul 10, 2013, at 4:17 PM, Scott Wood wrote:

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

That would involve detecting the key, then looking up what the user wants the key to act as. Then sending that translation to the guest OS. Since most keyboards have duplicate alt, control and command/windows keys, giving up one of them should be ok. 


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

Do you have any documentation that should be used as a reference?

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

Thanks for this info. The ascii system does work on a PC environment. The Mac adds a command key that isn't a part of the ascii standard. We can't just add an offset to a letter character and send it to the guest OS like the alt or control keys. Since QEMU appears to use a serial console as its input, trying to tell the guest OS that the command key is down is going to be challenging. I'm hoping it won't require a rewrite of QEMU's input system.  Anybody have any ideas on how to send the guest OS the command key and another letter key at the same time? 

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

[Scott Wood]

On 07/10/2013 03:55:46 PM, Programmingkid wrote:
> 
> On Jul 10, 2013, at 4:17 PM, Scott Wood wrote:
> 
> > On 07/10/2013 02:54:19 PM, Programmingkid wrote:
> >> On Jul 10, 2013, at 3:03 PM, Scott Wood wrote:
> >> > 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?
> 
> That would involve detecting the key, then looking up what the user  
> wants the key to act as. Then sending that translation to the guest  
> OS. Since most keyboards have duplicate alt, control and  
> command/windows keys, giving up one of them should be ok.

Just because you'd be happy with it doesn't mean others would.

> > 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.
> 
> Do you have any documentation that should be used as a reference?

No, sorry.

> >> 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).
> 
> Thanks for this info. The ascii system does work on a PC environment.  
> The Mac adds a command key that isn't a part of the ascii standard.

No, it's the same on PCs.  There's no ASCII code for Shift (except in  
combination with certain keys), Control (except in combination with  
certain keys), Alt, Windows, Menu, Arrows, NumLock, PrintScreen,  
Insert, volume keys, etc.  Some of those things may have escape  
sequences that are encodable in ASCII (not actually part of the ASCII  
standard), but those are generated by the OS, not the hardware.

> We can't just add an offset to a letter character and send it to the  
> guest OS like the alt or control keys.

Again, it's the guest that does that.

> Since QEMU appears to use a serial console as its input,

Hmm?  You *can* do that, but you don't have to.

> trying to tell the guest OS that the command key is down is going to  
> be challenging.

No different than connecting to a real Mac via a USB serial port, or  
via ssh.  Command line programs don't use the command key.

If you're using graphics in the guest, then QEMU should be emulating a  
real keyboard as well.

> I'm hoping it won't require a rewrite of QEMU's input system.   
> Anybody have any ideas on how to send the guest OS the command key  
> and another letter key at the same time?

It never happens at the same exact time, at least as reported by the  
keyboard.  Whichever one happens first gets sent first, and there's a  
separate notification when a key is released.

-Scott

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

[Anthony Liguori]

Programmingkid <programmingkidx@gmail.com> writes:

> On Jul 10, 2013, at 4:17 PM, Scott Wood wrote:
>
>> 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).
>
> Thanks for this info. The ascii system does work on a PC environment.

This thread is confusing presumably because people are mixing up topics.

The Windows key is the same thing as the Command key.  As Scott already
mentioned, there is no physical difference between an Apple and PC
keyboard except for stickers on the keys.  On a PC keyboard, the sticker
is a Windows logo.  On an Apple keyboard, it's the Command logo.

If the Windows key is not injecting a Command key, it's a bug.  This
should work just fine with the GTK UI.  I have no idea about Cocoa if
that's what you're using.

ASCII has nothing to do with keyboards.  It's a character encoding.

Regards,

Anthony Liguori

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

[Programmingkid]

On Jul 10, 2013, at 7:28 PM, Anthony Liguori wrote:

> Programmingkid <programmingkidx@gmail.com> writes:
> 
>> On Jul 10, 2013, at 4:17 PM, Scott Wood wrote:
>> 
>>> 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).
>> 
>> Thanks for this info. The ascii system does work on a PC environment.
> 
> This thread is confusing presumably because people are mixing up topics.
> 
> The Windows key is the same thing as the Command key.  As Scott already
> mentioned, there is no physical difference between an Apple and PC
> keyboard except for stickers on the keys.  On a PC keyboard, the sticker
> is a Windows logo.  On an Apple keyboard, it's the Command logo.
> 
> If the Windows key is not injecting a Command key, it's a bug.  This
> should work just fine with the GTK UI.  I have no idea about Cocoa if
> that's what you're using.
> 
> ASCII has nothing to do with keyboards.  It's a character encoding.
> 
> Regards,
> 
> Anthony Liguori

Thank you very much for the insight. Yes, I am using the --enable-cocoa option. It does not send the guest OS the command key. It needs a lot of work. 

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

[Alexander Graf]

Am 10.07.2013 um 21:54 schrieb Programmingkid <programmingkidx@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 <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).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? 
> 
> 

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

[Anthony Liguori]

Alexander Graf <agraf@suse.de> writes:

> Am 10.07.2013 um 21:54 schrieb Programmingkid <programmingkidx@gmail.com>:
>
>> qemu-system-ppc -keyboard-layout-file ./keyboard-layout.txt 
>
> That's exactly what -k does today already, no?

No.  What we send to the guest is a scancode.  This literally
corresponds to "row 4, column 5".  With a good VNC client (like
gtk-vnc), the native GTK UI, or SDL, we're able to read these scan codes
directly from the keyboard and pass them to the guest.

So as long as you're using one of the above, you never have to think
about "-k".

However, a crappy VNC client (like realvnc) can only send symbolic key
symbols.  Literally "the D key".  However, QEMU has no idea what the
stickers are your physical keyboard.  So you have to tell it what the
symbolic key => scancode mapping is via the "-k" option.

Of course, we default to en-us which covers a lot of people.

Now, if for some goofy reason, you wanted to have rules that did:

map "row 4, column 5" => "row 6, column 9"

We would need a new interface for that.  But that's not something QEMU
should do IMHO.  I suspect this thread started because the OP is using a
crappy VNC client or a builtin UI that cannot pass through scan codes.

Regards,

Anthony Liguori

>
> Alex

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

[Programmingkid]

On Jul 4, 2013, at 10:45 AM, Alexander Graf 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.
> 
> 
> Alex

I completely forgot about x86 Mac OS X running in QEMU. I didn't know it even worked. We definitely have a lot of consider.