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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).