From: Scott Wood <scottwood@freescale.com>
To: Programmingkid <programmingkidx@gmail.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
The OpenBIOS Mailinglist <openbios@openbios.org>,
"qemu-ppc@nongnu.org list:PowerPC" <qemu-ppc@nongnu.org>,
qemu-devel qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Qemu-ppc] Mac OS X on QEMU
Date: Wed, 10 Jul 2013 14:03:20 -0500 [thread overview]
Message-ID: <1373483000.8183.222@snotra> (raw)
In-Reply-To: <22AD60BC-ADE5-4BDD-BEAC-E802085D66BC@gmail.com> (from programmingkidx@gmail.com on Tue Jul 9 22:36:37 2013)
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
next prev parent reply other threads:[~2013-07-10 19:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2E45432C-6960-4E72-9F28-9848DF8A709A@gmail.com>
2013-07-04 14:45 ` [Qemu-devel] [Qemu-ppc] Mac OS X on QEMU Alexander Graf
2013-07-04 14:51 ` Stefan Hajnoczi
2013-07-04 14:58 ` Programmingkid
2013-07-09 17:32 ` Scott Wood
2013-07-10 3:36 ` Programmingkid
2013-07-10 4:10 ` [Qemu-devel] [OpenBIOS] " Tarl Neustaedter
2013-07-10 14:16 ` Programmingkid
2013-07-10 19:03 ` Scott Wood [this message]
2013-07-10 19:54 ` [Qemu-devel] " Programmingkid
2013-07-10 20:17 ` Scott Wood
2013-07-10 20:55 ` Programmingkid
2013-07-10 21:12 ` Scott Wood
2013-07-10 23:28 ` Anthony Liguori
2013-07-11 1:43 ` Programmingkid
2013-07-10 22:01 ` Alexander Graf
2013-07-10 23:35 ` Anthony Liguori
2013-07-04 14:52 ` Programmingkid
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1373483000.8183.222@snotra \
--to=scottwood@freescale.com \
--cc=openbios@openbios.org \
--cc=programmingkidx@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.