This patch adds the get-key-map word to the keyboard node. This patch is an improvement on the last get-key-map patch. It adds a keyboard node to /aliases and fixes a bug with the getKeyMap() function. If you wish to test out this patch, the program below will show you what key you pushed. The output will display hex values and text. The hex values in the middle tells you which key is being pushed.
: myword { ; keyboardDevice } " keyboard" open-dev -> keyboardDevice begin " get-key-map" keyboardDevice $call-method 32 dump 10000 ms \ update speed again ;
signed-off-by: John Arbuckle programmingkidx@gmail.com
--- drivers/adb_kbd.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 files changed, 82 insertions(+), 4 deletions(-)
diff --git a/drivers/adb_kbd.c b/drivers/adb_kbd.c index e38798a..e799704 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 */ @@ -545,7 +547,8 @@ void *adb_kbd_new (char *path, void *private) set_property(ph, "reg", (char *)&props, sizeof(props));
aliases = find_dev("/aliases"); - set_property(aliases, "adb-keyboard", buf, strlen(buf) + 1); + set_property(aliases, "adb-keyboard", buf, strlen(buf) + 1); + set_property(aliases, "keyboard", buf, strlen(buf) + 1);
return kbd; } @@ -566,3 +569,78 @@ 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 = (int *) malloc(sizeOfArray); + if(!keyMapArray) // if failed to allocate memory + { + printk("Failed to allocate memory for keyMapArray!\n"); + PUSH(0); + 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((int)keyMapArray); // returns the address of keyMapArray + return; + } + + 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((int) keyMapArray); +} \ No newline at end of file
On 15/11/12 02:03, Programmingkid wrote:
This patch adds the get-key-map word to the keyboard node. This patch is an improvement on the last get-key-map patch. It adds a keyboard node to /aliases and fixes a bug with the getKeyMap() function. If you wish to test out this patch, the program below will show you what key you pushed. The output will display hex values and text. The hex values in the middle tells you which key is being pushed.
(cut)
I think you may have misunderstood what the get-key-map word does - my guess from browsing the source code is that it's related to locale, and even better there is already a version of it included in OpenBIOS (MOL section).
Take a look at arch/ppc/mol/methods.c to see how it's done there. It should be fairly easy to port this to the qemu under arch/ppc/qemu.
Similarly you can see how MOL sets up the keyboard alias by looking at arch/ppc/mol/mol.fs - you'll need to point it towards adb-keyboard but otherwise it looks correct. With both of these in place you should hopefully find that the keyboard becomes responsive and boot progresses further.
HTH,
Mark.
On Nov 15, 2012, at 3:40 PM, Mark Cave-Ayland wrote:
On 15/11/12 02:03, Programmingkid wrote:
This patch adds the get-key-map word to the keyboard node. This patch is an improvement on the last get-key-map patch. It adds a keyboard node to /aliases and fixes a bug with the getKeyMap() function. If you wish to test out this patch, the program below will show you what key you pushed. The output will display hex values and text. The hex values in the middle tells you which key is being pushed.
(cut)
I think you may have misunderstood what the get-key-map word does - my guess from browsing the source code is that it's related to locale, and even better there is already a version of it included in OpenBIOS (MOL section).
How did you come to this conclusion that I don't know what get-key-map does? The program I made to test get-key-map on OpenBIOS is the same program I used to test on actual hardware. The results show my patch works.
Test results:
Holding down Command-v in Apple's Open Firmware:
ff8f2460: 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 |...@............| ff8f2470: 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 |................|
Holding down Control-v (simulated Command-v) in OpenBIOS:
1fc9c9e8 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ 1fc9c9f8 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 ................
The 40 you see in the top row indicates the v key is being held down. The 10 you see in the second row indicates the Command key is being held down. Both sets of data show this. This data shows the patch works.
The only key combinations that Bootx looks for is Command-v (verbose mode) and Command-s (single user mode). This is all the get-key-map word is used for. I'm not sure what more you want.
Take a look at arch/ppc/mol/methods.c to see how it's done there. It should be fairly easy to port this to the qemu under arch/ppc/qemu.
Similarly you can see how MOL sets up the keyboard alias by looking at arch/ppc/mol/mol.fs - you'll need to point it towards adb-keyboard but otherwise it looks correct. With both of these in place you should hopefully find that the keyboard becomes responsive and boot progresses further.
This problem has already been solved by this line of code: set_property(aliases, "keyboard", buf, strlen(buf) + 1);
It adds keyboard to the /aliases node. After applying my patch, I was able to see that Bootx was able to obtain the keyboard instance handle successfully.
Thank you.
On 15/11/12 21:16, Programmingkid wrote:
I think you may have misunderstood what the get-key-map word does - my guess from browsing the source code is that it's related to locale, and even better there is already a version of it included in OpenBIOS (MOL section).
How did you come to this conclusion that I don't know what get-key-map does? The program I made to test get-key-map on OpenBIOS is the same program I used to test on actual hardware. The results show my patch works.
Test results:
Holding down Command-v in Apple's Open Firmware:
ff8f2460: 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 |...@............| ff8f2470: 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 |................|
Holding down Control-v (simulated Command-v) in OpenBIOS:
1fc9c9e8 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ 1fc9c9f8 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 ................
The 40 you see in the top row indicates the v key is being held down. The 10 you see in the second row indicates the Command key is being held down. Both sets of data show this. This data shows the patch works.
The only key combinations that Bootx looks for is Command-v (verbose mode) and Command-s (single user mode). This is all the get-key-map word is used for. I'm not sure what more you want.
(Goes and looks again)... okay in that case I take it back. I'm getting confused between the keyboard map and the keymap which are two different things :/
Take a look at arch/ppc/mol/methods.c to see how it's done there. It should be fairly easy to port this to the qemu under arch/ppc/qemu.
Similarly you can see how MOL sets up the keyboard alias by looking at arch/ppc/mol/mol.fs - you'll need to point it towards adb-keyboard but otherwise it looks correct. With both of these in place you should hopefully find that the keyboard becomes responsive and boot progresses further.
This problem has already been solved by this line of code: set_property(aliases, "keyboard", buf, strlen(buf) + 1);
I've committed this part as a separate patch - see r1073.
It adds keyboard to the /aliases node. After applying my patch, I was able to see that Bootx was able to obtain the keyboard instance handle successfully.
Thank you.
Again - please take the get-key-map routine in arch/ppc/mol/methods.c as a starting point and make the *minimum* alterations for it to work under QEMU, and repost the patch. It should be just a case of changing the key detection functions, and so in that case I'd be happy to accept it as a patch.
ATB,
Mark.
On Nov 24, 2012, at 1:01 PM, Mark Cave-Ayland wrote:
On 15/11/12 21:16, Programmingkid wrote:
I think you may have misunderstood what the get-key-map word does - my guess from browsing the source code is that it's related to locale, and even better there is already a version of it included in OpenBIOS (MOL section).
How did you come to this conclusion that I don't know what get-key-map does? The program I made to test get-key-map on OpenBIOS is the same program I used to test on actual hardware. The results show my patch works.
Test results:
Holding down Command-v in Apple's Open Firmware:
ff8f2460: 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 |...@............| ff8f2470: 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 |................|
Holding down Control-v (simulated Command-v) in OpenBIOS:
1fc9c9e8 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ 1fc9c9f8 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 ................
The 40 you see in the top row indicates the v key is being held down. The 10 you see in the second row indicates the Command key is being held down. Both sets of data show this. This data shows the patch works.
The only key combinations that Bootx looks for is Command-v (verbose mode) and Command-s (single user mode). This is all the get-key-map word is used for. I'm not sure what more you want.
(Goes and looks again)... okay in that case I take it back. I'm getting confused between the keyboard map and the keymap which are two different things :/
Take a look at arch/ppc/mol/methods.c to see how it's done there. It should be fairly easy to port this to the qemu under arch/ppc/qemu.
Similarly you can see how MOL sets up the keyboard alias by looking at arch/ppc/mol/mol.fs - you'll need to point it towards adb-keyboard but otherwise it looks correct. With both of these in place you should hopefully find that the keyboard becomes responsive and boot progresses further.
This problem has already been solved by this line of code: set_property(aliases, "keyboard", buf, strlen(buf) + 1);
I've committed this part as a separate patch - see r1073.
It adds keyboard to the /aliases node. After applying my patch, I was able to see that Bootx was able to obtain the keyboard instance handle successfully.
Thank you.
Again - please take the get-key-map routine in arch/ppc/mol/methods.c as a starting point and make the *minimum* alterations for it to work under QEMU, and repost the patch. It should be just a case of changing the key detection functions, and so in that case I'd be happy to accept it as a patch.
What advantage would this code have over mine?
A problem with this code is it was made for virtualization in mind. Qemu will be "emulating" a PowerMac. What this means is detecting the command key isn't possible with this code as is. My code already handles this situation.
On 30/11/12 21:57, Programmingkid wrote:
Again - please take the get-key-map routine in arch/ppc/mol/methods.c as a starting point and make the *minimum* alterations for it to work under QEMU, and repost the patch. It should be just a case of changing the key detection functions, and so in that case I'd be happy to accept it as a patch.
What advantage would this code have over mine?
It's not an advantage per se, it's to do with maintainability. If the codebases are similar then any bugfixes to your code can be applied to the MOL code with relative ease (and while I'm not convinced people are still using it, I'd like to not break it if possible).
A problem with this code is it was made for virtualization in mind. Qemu will be "emulating" a PowerMac. What this means is detecting the command key isn't possible with this code as is. My code already handles this situation.
Are you sure about this? I'd be surprised if there wasn't already some kind of workaround in place. As mentioned before, OpenBIOS is designed to be able to run on real hardware with minimal modifications and so I'm not greatly keen to do this. Have you asked the developers on the qemu/qemu-ppc mailing lists how to emulate the command key on a non-Mac?
ATB,
Mark.
On Dec 3, 2012, at 3:32 PM, Mark Cave-Ayland wrote:
On 30/11/12 21:57, Programmingkid wrote:
Again - please take the get-key-map routine in arch/ppc/mol/methods.c as a starting point and make the *minimum* alterations for it to work under QEMU, and repost the patch. It should be just a case of changing the key detection functions, and so in that case I'd be happy to accept it as a patch.
What advantage would this code have over mine?
It's not an advantage per se, it's to do with maintainability. If the codebases are similar then any bugfixes to your code can be applied to the MOL code with relative ease (and while I'm not convinced people are still using it, I'd like to not break it if possible).
A problem with this code is it was made for virtualization in mind. Qemu will be "emulating" a PowerMac. What this means is detecting the command key isn't possible with this code as is. My code already handles this situation.
Are you sure about this? I'd be surprised if there wasn't already some kind of workaround in place. As mentioned before, OpenBIOS is designed to be able to run on real hardware with minimal modifications and so I'm not greatly keen to do this.
On real hardware? I'm not too sure about that. This page seems to disagree as well: http://www.openfirmware.info/OpenBIOS
"Do not try to put OpenBIOS in a real boot ROM, it will not work and may damage your hardware!"
Have you asked the developers on the qemu/qemu-ppc mailing lists how to emulate the command key on a non-Mac?
No I haven't. All the PowerPC developers are busy making some target called P series. I really doubt they have the time or interest in emulating the command key.
I have looked at the code QEMU uses to handle key strokes and see no code that sends the command key to the emulated environment. The file itself is called cocoa.m.
Here is the code from cocoa.m that handles the keyboard:
case NSKeyDown:
// forward command Key Combos if ([event modifierFlags] & NSCommandKeyMask) { [NSApp sendEvent:event]; return; }
// default keycode = cocoa_keycode_to_qemu([event keyCode]);
// handle control + alt Key Combos (ctrl+alt is reserved for QEMU) if (([event modifierFlags] & NSControlKeyMask) && ([event modifierFlags] & NSAlternateKeyMask)) { switch (keycode) {
// enable graphic console case 0x02 ... 0x0a: // '1' to '9' keys console_select(keycode - 0x02); break; }
The line below "// forward command key combos" is what filters out the command key. I see no code to emulate the command key.
On 03/12/12 20:51, Programmingkid wrote:
Are you sure about this? I'd be surprised if there wasn't already some kind of workaround in place. As mentioned before, OpenBIOS is designed to be able to run on real hardware with minimal modifications and so I'm not greatly keen to do this.
On real hardware? I'm not too sure about that. This page seems to disagree as well: http://www.openfirmware.info/OpenBIOS
"Do not try to put OpenBIOS in a real boot ROM, it will not work and may damage your hardware!"
You missed the part about minimal modifications; the hardware initialisation routines need to be changed (to probe directly rather than taking information supplied via the QEMU API) but we know from recent emails on the list that some people are actually using OpenBIOS in this way.
Have you asked the developers on the qemu/qemu-ppc mailing lists how to emulate the command key on a non-Mac?
No I haven't. All the PowerPC developers are busy making some target called P series. I really doubt they have the time or interest in emulating the command key.
Sure they are now, but I'm reasonably confident that at least a couple of them have worked on the Mac emulation in the past. Even if they don't know the answer, they will be able to point you directly to the part of the code you need to modify, and if a patch is required, exactly what you would need to do in order for it to be accepted. But without asking, we don't even know anything yet.
I have looked at the code QEMU uses to handle key strokes and see no code that sends the command key to the emulated environment. The file itself is called cocoa.m.
Here is the code from cocoa.m that handles the keyboard:
case NSKeyDown:
// forward command Key Combos if ([event modifierFlags] & NSCommandKeyMask) { [NSApp sendEvent:event]; return; }
// default keycode = cocoa_keycode_to_qemu([event keyCode]);
// handle control + alt Key Combos (ctrl+alt is reserved for QEMU) if (([event modifierFlags] & NSControlKeyMask) && ([event modifierFlags] & NSAlternateKeyMask)) { switch (keycode) {
// enable graphic console case 0x02 ... 0x0a: // '1' to '9' keys console_select(keycode - 0x02); break; }
The line below "// forward command key combos" is what filters out the command key. I see no code to emulate the command key.
I'm afraid I've never programmed a Mac, and so cannot really offer any advice here.
ATB,
Mark.
On Dec 3, 2012, at 4:06 PM, Mark Cave-Ayland wrote:
On 03/12/12 20:51, Programmingkid wrote:
Are you sure about this? I'd be surprised if there wasn't already some kind of workaround in place. As mentioned before, OpenBIOS is designed to be able to run on real hardware with minimal modifications and so I'm not greatly keen to do this.
On real hardware? I'm not too sure about that. This page seems to disagree as well: http://www.openfirmware.info/OpenBIOS
"Do not try to put OpenBIOS in a real boot ROM, it will not work and may damage your hardware!"
You missed the part about minimal modifications; the hardware initialisation routines need to be changed (to probe directly rather than taking information supplied via the QEMU API) but we know from recent emails on the list that some people are actually using OpenBIOS in this way.
Have you asked the developers on the qemu/qemu-ppc mailing lists how to emulate the command key on a non-Mac?
No I haven't. All the PowerPC developers are busy making some target called P series. I really doubt they have the time or interest in emulating the command key.
Sure they are now, but I'm reasonably confident that at least a couple of them have worked on the Mac emulation in the past. Even if they don't know the answer, they will be able to point you directly to the part of the code you need to modify, and if a patch is required, exactly what you would need to do in order for it to be accepted. But without asking, we don't even know anything yet.
I asked the list. I would like the command key sent to the guest OS also, but that would probably require a patch sent to the QEMU list. Even if one was sent, there is no guarantee it would be accepted. There is also the problem of requiring users to upgrade their version of QEMU to use the patch. There are still a lot of people who are just fine using versions of QEMU from one to two years ago. Using the patch as is would mean everyone would be able to enjoy the patch - not just the latest alpha testers.
Would you settle for a patch that checks to see if the command key is down and also maps the control key to the command? It would mean both backwards and forward compatibility. If someone changed QEMU to detect the command key, this patch would still work unaltered.
On 03/12/12 21:43, Programmingkid wrote:
Would you settle for a patch that checks to see if the command key is down and also maps the control key to the command? It would mean both backwards and forward compatibility. If someone changed QEMU to detect the command key, this patch would still work unaltered.
I'm not philosophically against it as long as it doesn't break compatibility for anything else in the bootloader - Alex/Andreas do you know if this is the case?
ATB,
Mark.
On Dec 4, 2012, at 4:20 PM, Mark Cave-Ayland wrote:
On 03/12/12 21:43, Programmingkid wrote:
Would you settle for a patch that checks to see if the command key is down and also maps the control key to the command? It would mean both backwards and forward compatibility. If someone changed QEMU to detect the command key, this patch would still work unaltered.
I'm not philosophically against it as long as it doesn't break compatibility for anything else in the bootloader - Alex/Andreas do you know if this is the case?
After doing some research I found out detecting the command key will be difficult at best. The key word can't do it. The reason why the control, and shift key can be detected using the key word is because the control and shift key add to the value of the letter key being pushed. It is just a matter of knowing the range that each letter key will be in when pushed with a modifier key. The command key does not alter the value of a letter key when pushed, so detected it being pushed with the key word isn't an option.
The only work around that actually works with QEMU right now is to detect the control key as the command key. I know you don't like this idea very much, but it does actually work and doesn't break any thing. Also, no patch is permanent. If someone does figure out a way to integrate the command key into QEMU, I can always change the get-key-map word to use the command key.
We should stick with the get-key-map patch for now.
-
Mark Cave-Ayland -
Programmingkid