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

[Scott Wood <scottwood@freescale.com>]

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