From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ux1ga-0001iI-TM for qemu-devel@nongnu.org; Wed, 10 Jul 2013 17:12:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ux1gY-0006ic-DG for qemu-devel@nongnu.org; Wed, 10 Jul 2013 17:12:28 -0400 Date: Wed, 10 Jul 2013 16:12:13 -0500 From: Scott Wood In-Reply-To: (from programmingkidx@gmail.com on Wed Jul 10 15:55:46 2013) Message-ID: <1373490733.8183.231@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 03:55:46 PM, Programmingkid wrote: >=20 > On Jul 10, 2013, at 4:17 PM, Scott Wood wrote: >=20 > > 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 =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. > >> That's not a problem. The user would be free to decide which key =20 > acts as the command key. A function key could be used. The alt and =20 > control 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? >=20 > That would involve detecting the key, then looking up what the user =20 > wants the key to act as. Then sending that translation to the guest =20 > OS. Since most keyboards have duplicate alt, control and =20 > 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 =20 > infrastructure could be used, such as using X11 keycodes (or whatever =20 > else is native to the host) rather than making up a new namespace for =20 > keys. >=20 > 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 =20 > ascii keyboard is attached to the QEMU emulated machine? We might =20 > want to consider unicode in the future. Not every user speaks =20 > english. Are there any non-native english users who would like to see =20 > unicode 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 =20 > the host's input layer (e.g. the X server). It's up to the guest =20 > software to translate those keycodes into either ASCII or Unicode (or =20 > whatever else it wants). >=20 > Thanks for this info. The ascii system does work on a PC environment. =20 > 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 =20 combination with certain keys), Control (except in combination with =20 certain keys), Alt, Windows, Menu, Arrows, NumLock, PrintScreen, =20 Insert, volume keys, etc. Some of those things may have escape =20 sequences that are encodable in ASCII (not actually part of the ASCII =20 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 =20 > 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 =20 > be challenging. No different than connecting to a real Mac via a USB serial port, or =20 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 =20 real keyboard as well. > I'm hoping it won't require a rewrite of QEMU's input system. =20 > Anybody have any ideas on how to send the guest OS the command key =20 > and another letter key at the same time? It never happens at the same exact time, at least as reported by the =20 keyboard. Whichever one happens first gets sent first, and there's a =20 separate notification when a key is released. -Scott=