From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ux0pU-0007Ix-K4 for qemu-devel@nongnu.org; Wed, 10 Jul 2013 16:17:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ux0pR-0006DG-E9 for qemu-devel@nongnu.org; Wed, 10 Jul 2013 16:17:36 -0400 Date: Wed, 10 Jul 2013 15:17:18 -0500 From: Scott Wood In-Reply-To: (from programmingkidx@gmail.com on Wed Jul 10 14:54:19 2013) Message-ID: <1373487438.8183.225@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-ppc] Mac OS X on QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Programmingkid Cc: Stefan Hajnoczi , The OpenBIOS Mailinglist , "qemu-ppc@nongnu.org list:PowerPC" , qemu-devel qemu-devel On 07/10/2013 02:54:19 PM, Programmingkid wrote: >=20 > On Jul 10, 2013, at 3:03 PM, Scott Wood wrote: >=20 > > 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 =20 > wrote: > >> >> >> > >> >> >> On 04.07.2013, at 16:40, Programmingkid wrote: > >> >> >> > >> >> >>> We have made a lot of progress in the last month with =20 > making Mac OS X run in QEMU. A lot of people are to thank for this =20 > milestone. To everyone involved, thank you. > >> >> >>> > >> >> >>> There is one thing that we have to figure out. That is the =20 > command key issue. This key is a very important on the Macintosh. It =20 > is used to send keyboard shortcuts to applications. > >> >> >>> > >> >> >>> What I propose is adding a menu item to QEMU's menu called =20 > "Map Command key to ALT". This would allow a user to be able to send =20 > Macintosh applications command key shortcuts from both a PC and Mac =20 > keyboard. > >> >> >>> > >> >> >>> I welcome any and all ideas to solve this problem. > >> >> >> > >> >> >> This is the wrong mailing list for this. Your proposal would =20 > 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 =20 > running in QEMU. > >> >> > > >> >> > When I VNC into a Mac I find that the "Windows key" becomes =20 > the > >> >> > Command key. And the same probably happens when you plug a =20 > non-Apple > >> >> > USB keyboard into a Mac. > >> >> I was thinking about the Windows key. It would be the perfect =20 > substitute - if it was available on all keyboards. > >> >> > > >> >> > If you are using a keyboard with a "Windows key" then that =20 > would be > >> >> > the most natural option. If you don't have that key then you =20 > 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, =20 > in terms of the actual keycode generated? > >> I don't think so. The command key is equal to 0x37. The windows =20 > key is equal to 0x5B. This is my source: =20 > http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=3Dvs.8= 5).aspx > > > > That says 0x37 is the 7 key. The word "command" does not appear. >=20 > Sorry, but this is my source for a Mac keyboard: > http://boredzo.org/blog/wp-content/uploads/2007/05/imtx-virtual-keycodes.= png. >=20 > The values you see on the keys are in decimal. 55 in base 10 is equal =20 > to 37 in base 16. You're comparing apples to oranges. Both of those are "virtual =20 keycodes" defined by some OS. Note that all the other keys are =20 different as well between the two. > > I assume you mean "The alt and control key are not used very =20 > much...". > > > > Maybe the user doesn't mind -- but maybe they do mind and would =20 > rather swap the two than end up with both ALT and the OS key being =20 > Command. When I used MacOS X I use control and alt quite a bit, in =20 > console and X11 apps. >=20 > That's not a problem. The user would be free to decide which key acts =20 > as the command key. A function key could be used. The alt and control =20 > key can be left alone. If I want to use the alt key as the command key, then with your =20 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 =20 > idea. Instead I am currently planning to use a command line option. =20 > You just pass the key value you want to use to act as the command =20 > key. Here's an example: > >> qemu-system-ppc -command-key 0x37. > >> The user could pick one of the functions keys as the command key =20 > if desired. > > > > If you're going to get into remapping keys, wouldn't it be better =20 > to have a generalized mechanism so the user could do whatever remaps =20 > they want? Other targets may have their own special keys. > > > > -Scott >=20 > That does sound like a good idea. There would be a lot of things we =20 > would have to consider and agree upon. This is what I think you want, =20 > a command line option that specifies a key what it maps to. > Example: >=20 > qemu-system-ppc -a-key 0x0 -b-key 0x11 ... >=20 > Basically you specify a key, then state the raw keyboard value for =20 > it. Is that what you mean by generalized mechanism? This way could =20 > work, but I think using a file might be better. >=20 > Example: >=20 > 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 =20 could be used, such as using X11 keycodes (or whatever else is native =20 to the host) rather than making up a new namespace for keys. > qemu-system-ppc -keyboard-layout-file ./keyboard-layout.txt >=20 > There is one issue that still bothers me. Should we assume an ascii =20 > keyboard is attached to the QEMU emulated machine? We might want to =20 > consider unicode in the future. Not every user speaks english. Are =20 > there any non-native english users who would like to see unicode =20 > support in QEMU? Keyboards don't generally speak ASCII (or Unicode). They produce =20 keycodes, which are generally translated into some sort of event by the =20 host's input layer (e.g. the X server). It's up to the guest software =20 to translate those keycodes into either ASCII or Unicode (or whatever =20 else it wants). -Scott=