The get-key-map word is used by Bootx to determine which key is being held down at startup time. Since the Command key can't be detected in QEMU, the Control key is used instead. If the user holds down Control-v while Mac OS X starts up in QEMU, get-key-map will report that Command-v is being held down. Allowing the user to have Mac OS X to boot up in Verbose mode.
I was able to verify that this word works when I tested it out in the file forth.c, but I don't know how to access this word here in the adb_kbd.c file. Comments, suggestions, and commits are always welcomed.
--- drivers/adb_kbd.c | 80 +++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 files changed, 77 insertions(+), 3 deletions(-)
diff --git a/drivers/adb_kbd.c b/drivers/adb_kbd.c index e38798a..82382d5 100644 --- a/drivers/adb_kbd.c +++ b/drivers/adb_kbd.c @@ -42,11 +42,13 @@ keyboard_close(int *idx) }
static void keyboard_read(void); +void getKeyMap(void);
NODE_METHODS( keyboard ) = { - { "open", keyboard_open }, - { "close", keyboard_close }, - { "read", keyboard_read }, + { "open", keyboard_open }, + { "close", keyboard_close }, + { "read", keyboard_read }, + { "get-key-map", getKeyMap }, };
/* VT100 escape sequences */ @@ -566,3 +568,75 @@ static void keyboard_read(void) } PUSH(i); } + + +// Returns the base to the exponent power +static int pow(int base, int exponent) +{ + int index, answer; + answer = base; + for(index = 1; index < exponent; index++) + { + answer = answer * base; + } + return answer; +} + +// The implementation of the get-key-map word. +// Returns an array of 32 bytes. Certain bits +// are used to determine which keys are being +// held down. + +void getKeyMap(void) +{ + int keyPushed, *keyMapArray, offset; + const int sizeOfArray = 8; + const int modifierKeyIndex = 7; + const int commandKeyValue = pow(2,28); + const int shiftKeyValue = pow(2,30); + const int theAKeyValue = pow(2,27); + + keyMapArray = (char *) malloc(sizeOfArray); + if(!keyMapArray) + { + printk("Failed to allocate memory for keyMapArray!\n"); + PUSH(NULL); + return; + } + + // Set all the elements to zero + int index; + for(index = 0; index < sizeOfArray; index++) + { + keyMapArray[index] = 0; + } + + feval("key?"); + if(POP() != -1) // if no key was pushed + PUSH(keyMapArray); // returns the address of keyMapArray + + feval("key"); + keyPushed = POP(); + + if(keyPushed > 0 && keyPushed < 27) // control key combination + { + offset = 1; + keyMapArray[modifierKeyIndex] = commandKeyValue; + } + + else if(keyPushed > 64 && keyPushed < 91) // shift key combination + { + offset = 65; + keyMapArray[modifierKeyIndex] = shiftKeyValue; + } + + else // just a letter is being held down + { + offset = 97; + } + + // Determines the value and location of a bit in the array. + *keyMapArray = theAKeyValue >> (keyPushed - offset); + + PUSH(keyMapArray); +} \ No newline at end of file
Since the Command key can't be detected in QEMU, the Control key is used instead. If the user holds down Control-v while Mac OS X starts up in QEMU, get-key-map will report that Command-v is being held down.
Fix QEMU instead of adding workarounds here.
Segher
On Nov 4, 2012, at 9:57 AM, Segher Boessenkool wrote:
Since the Command key can't be detected in QEMU, the Control key is used instead. If the user holds down Control-v while Mac OS X starts up in QEMU, get-key-map will report that Command-v is being held down.
Fix QEMU instead of adding workarounds here.
Segher
That is what I wanted to do, but about careful consideration, I decided to not go that route. The short story is things would be very difficult and confusing for the user.
On 04/11/12 03:21, Programmingkid wrote:
The get-key-map word is used by Bootx to determine which key is being held down at startup time. Since the Command key can't be detected in QEMU, the Control key is used instead. If the user holds down Control-v while Mac OS X starts up in QEMU, get-key-map will report that Command-v is being held down. Allowing the user to have Mac OS X to boot up in Verbose mode.
I agree with Segher in that there are two things here - one is the implementation of get-key-map, and the second is the mapping of the Command key within QEMU.
Have you asked on the qemu mailing list to find out whether this is already handled in a different way for other OSs? And if not, what the suggested fix should be?
ATB,
Mark.
On Nov 5, 2012, at 2:48 PM, Mark Cave-Ayland wrote:
On 04/11/12 03:21, Programmingkid wrote:
The get-key-map word is used by Bootx to determine which key is being held down at startup time. Since the Command key can't be detected in QEMU, the Control key is used instead. If the user holds down Control-v while Mac OS X starts up in QEMU, get-key-map will report that Command-v is being held down. Allowing the user to have Mac OS X to boot up in Verbose mode.
I agree with Segher in that there are two things here - one is the implementation of get-key-map, and the second is the mapping of the Command key within QEMU.
You are aware that this word is only called once during the boot sequence of Mac OS X? The only thing this patch would affect is BootX. The keyboard will still behave normally. This patch will not make the Control key be detected by the Operating System as the Command key. This patch will only make get-key-map return an array that indicates the Command key is being held down when the Control key is held down.
Have you asked on the qemu mailing list to find out whether this is already handled in a different way for other OSs? And if not, what the suggested fix should be?
I haven't contacted the QEMU mailing list. The get-key-map word appears to be an Apple added word, so other OS's will not use it. You don't like the fact the Control key is mapped as the Command key. QEMU currently does not send the Command key to the emulated system. Even if you sent in a patch to the QEMU people to fix this issue, it is not likely it will be accepted. I do know that right now, this is how QEMU works, and we have to work with it.
There are other issues to deal with if the Command key were sent to the guest OS. If QEMU was placed in full screen mode, how would the user return to windowed mode? Command-F wouldn't work any more. Another issue is what word would we use to detect the Command key? The "key" word is what I use to detect the pushed key on the keyboard. Would this word be able to detect the Command key?
I haven't contacted the QEMU mailing list. The get-key-map word appears to be an Apple added word, so other OS's will not use it. You don't like the fact the Control key is mapped as the Command key. QEMU currently does not send the Command key to the emulated system.
I suspect you're just not asking it properly.
There are other issues to deal with if the Command key were sent to the guest OS. If QEMU was placed in full screen mode, how would the user return to windowed mode? Command-F wouldn't work any more.
Nonsense.
Another issue is what word would we use to detect the Command key? The "key" word is what I use to detect the pushed key on the keyboard. Would this word be able to detect the Command key?
KEY will not do anything for the control key, either. You want EKEY (or some custom word, of course).
Segher
On Nov 5, 2012, at 6:17 PM, Segher Boessenkool wrote:
I haven't contacted the QEMU mailing list. The get-key-map word appears to be an Apple added word, so other OS's will not use it. You don't like the fact the Control key is mapped as the Command key. QEMU currently does not send the Command key to the emulated system.
I suspect you're just not asking it properly.
Asking? Asking what?
What is so bad about using the Control key in place of the Command key? Verbose mode would just be Control-V and single user mode would be Control-S. Doesn't sound so Earth shattering to me.
There are other issues to deal with if the Command key were sent to the guest OS. If QEMU was placed in full screen mode, how would the user return to windowed mode? Command-F wouldn't work any more.
Nonsense.
The Command-F sequence would go straight to the emulated environment. Not to QEMU. I suppose we could filter out one key sequence like Command-F. But this might be a terrible pain for the user. The user might push Command-F expecting one thing, but see the window mode appear and disappear unexpectedly.
Another issue is what word would we use to detect the Command key? The "key" word is what I use to detect the pushed key on the keyboard. Would this word be able to detect the Command key?
KEY will not do anything for the control key, either. You want EKEY (or some custom word, of course).
So now all we need is the EKEY word. You care to implement it?
Do you also think you could implement sending the command key to the guest OS as well? I am sure the QEMU people would love to see a patch from you.
I haven't contacted the QEMU mailing list. The get-key-map word appears to be an Apple added word, so other OS's will not use it. You don't like the fact the Control key is mapped as the Command key. QEMU currently does not send the Command key to the emulated system.
I suspect you're just not asking it properly.
Asking? Asking what?
You should ask for the raw key events, not the cooked ASCII stuff.
What is so bad about using the Control key in place of the Command key?
What is so bad about using a shoe instead of a hammer to drive in a nail? It might work for you, but you are asking everyone to use their shoe as a hammer.
Besides, you are not solving the problem at all.
l with if the Command key were sent to the guest OS. If QEMU was placed in full screen mode, how would the user return to windowed mode? Command-F wouldn't work any more.
Nonsense.
The Command-F sequence would go straight to the emulated environment. Not to QEMU.
No, it always goes to QEMU first. Or your window manager eats it, but that's a separate problem (and different on every OS / windowing system).
Another issue is what word would we use to detect the Command key? The "key" word is what I use to detect the pushed key on the keyboard. Would this word be able to detect the Command key?
KEY will not do anything for the control key, either. You want EKEY (or some custom word, of course).
So now all we need is the EKEY word. You care to implement it?
No. You want the change, you do the work.
And (as I hinted) you probably do not want EKEY but some custom stuff -- like, something very similar to the Apple OF key-map thing.
If you want to only use ASCII input devices, and emulate what Apple OF does, you should emulate what Apple OF does with ASCII input devices (like serial ports, or telnet). You can set OSX verbose boot with that as well. Adding a terribly hacky non-compatible way to be "compatible" is not going to fly, esp. not because you make it clear that you only want to do it this way because you cannot be bothered to do the work needed to do it properly.
Segher
On Nov 6, 2012, at 12:54 PM, Segher Boessenkool wrote:
I haven't contacted the QEMU mailing list. The get-key-map word appears to be an Apple added word, so other OS's will not use it. You don't like the fact the Control key is mapped as the Command key. QEMU currently does not send the Command key to the emulated system.
I suspect you're just not asking it properly.
Asking? Asking what?
You should ask for the raw key events, not the cooked ASCII stuff.
What is so bad about using the Control key in place of the Command key?
What is so bad about using a shoe instead of a hammer to drive in a nail? It might work for you, but you are asking everyone to use their shoe as a hammer.
Besides, you are not solving the problem at all.
What you want is unrealistic, and no body is going to do what you want. Not even you.
The get-key-map word is required to boot Mac OS X. It sounds like to me you would rather have nothing rather than something to build on. Not using this patch is like choosing to starve to death rather than accept a handout.
If someone does make a change to QEMU, an updated patch can always be made.
Another issue is what word would we use to detect the Command key? The "key" word is what I use to detect the pushed key on the keyboard. Would this word be able to detect the Command key?
KEY will not do anything for the control key, either. You want EKEY (or some custom word, of course).
So now all we need is the EKEY word. You care to implement it?
No. You want the change, you do the work.
It was you who wanted the change. Not me. Your suggestion to change QEMU is not going to happen.
And (as I hinted) you probably do not want EKEY but some custom stuff -- like, something very similar to the Apple OF key-map thing.
KEY will do for now.
If you want to only use ASCII input devices, and emulate what Apple OF does, you should emulate what Apple OF does with ASCII input devices (like serial ports, or telnet). You can set OSX verbose boot with that as well.
This would not be a good idea.
Adding a terribly hacky non-compatible way to be "compatible" is not going to fly, esp. not because you make it clear that you only want to do it this way because you cannot be bothered to do the work needed to do it properly.
Since it was your suggestion to change QEMU, it would be you who can't be bothered to do the required work. Blaming me won't fix the problem.