This patch is an improvement upon the last get-key-map patch. This patch makes the code more 64bit friendly. It also fixes some whitespace damage.
The get-key-map word is used by bootx to see if any keys are being held down.
signed-off-by: John Arbuckle programmingkidx@gmail.com
Index: drivers/adb_kbd.c =================================================================== --- drivers/adb_kbd.c (revision 1078) +++ drivers/adb_kbd.c (working copy) @@ -24,7 +24,7 @@ #include "libc/byteorder.h" #include "libc/vsprintf.h" #include "kbd.h" - +#include <math.h> #include "adb_bus.h" #include "adb_kbd.h"
@@ -42,11 +42,13 @@ }
static void keyboard_read(void); +static void getKeyMap(void);
NODE_METHODS( keyboard ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read }, + { "get-key-map", getKeyMap }, };
/* VT100 escape sequences */ @@ -566,3 +568,65 @@ } PUSH(i); } + +// 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. + +static void getKeyMap(void) +{ + #define sizeOfArray 8 // 8 bytes (32 bits) in size + uint32_t keyPushed, *keyMapArray, offset; + const uint32_t modifierKeyIndex = 7; + const uint32_t commandKeyValue = pow(2,28); + const uint32_t shiftKeyValue = pow(2,30); + const uint32_t theAKeyValue = pow(2,27); + + keyMapArray = (uint32_t *) 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((uint32_t)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((uint32_t) keyMapArray); +}
This patch takes us a lot further along while booting Mac OS X. Here is the CIF.
============================================================= OpenBIOS 1.0 [Dec 12 2012 20:16] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,750
Welcome to OpenBIOS v1.0 built on Dec 12 2012 20:16 Trying hd:,\:tbxi... Trying hd:,\ppc\bootinfo.txt... No valid state has been set by load or init-program
0 > boot cd:,\:tbxi >> finddevice("/openprom") = 0xfff49f40
getprop(0xfff49f40, "model", 0x0565f68c, 255) = 15 0x0565f68c 4f 70 65 6e 46 69 72 6d 77 61 72 65 20 33 00 __ OpenFirmware 3. peer(0x00000000) = 0xfff49d80 getprop(0xfff49d80, "#address-cells", 0x056579d0, 4) = 4 0x056579d0 00 00 00 01 __ __ __ __ __ __ __ __ __ __ __ __ .... peer(0x00000000) = 0xfff49d80 getprop(0xfff49d80, "#size-cells", 0x056579d4, 4) = 4 0x056579d4 00 00 00 01 __ __ __ __ __ __ __ __ __ __ __ __ .... of_client_interface: interpret 05616674 interpret hex unselect-dev " /packages" find-device new-device " sl_words" device-name : open true ; : close ; 0 value outputLevel : slw_set_output_level dup 0= if 0 stdout ! then to outputLevel ; : slw_emit 2 outputLevel <= if emit else drop then ; : slw_cr 2 outputLevel <= if cr then ; 0 value keyboardIH 20 buffer: keyMap : slw_init_keymap to keyboardIH keyMap dup 20 0 fill ; : slw_update_keymap { ; dpth } depth -> dpth keyboardIH if " get-key-map" keyboardIH $call-method depth dpth - 1 = if 20 then 4 / 0 do dup i 4 * + l@ keyMap i 4 * + tuck l@ or swap l! loop drop then ; 0 value screenIH 0 value cursorAddr 0 value cursorX 0 value cursorY 0 value cursorW 0 value cursorH 0 value cursorFrames 0 value cursorPixelSize 0 value cursorStage 0 value cursorTime 0 value cursorDelay : slw_spin screenIH 0<> cursorAddr 0<> and if get-msecs dup cursorTime - cursorDelay >= if to cursorTime slw_update_keymap cursorStage 1+ cursorFrames mod dup to cursorStage handle_calls return: 00000000 07c5b098 finddevice("/options") = 0xfff4a0e8 finddevice("/chosen") = 0xfff4a160 of_client_interface: interpret 056133e4 interpret dev /chosen new-device " memory-map" device-name active-package device-end ([1] -- [2]) handle_calls return: 00000000 fff57a90 getprop(0xfff4a160, "mmu", 0x056579ec, 4) = 4 0x056579ec 07 c5 a8 2c __ __ __ __ __ __ __ __ __ __ __ __ .Ũ, getprop(0xfff4a160, "memory", 0x056579f0, 4) = 4 0x056579f0 07 c5 ae 58 __ __ __ __ __ __ __ __ __ __ __ __ .ŮX peer(0x00000000) = 0xfff49d80 of_client_interface: interpret 05616db8 fff49d80 0000000a 056131d4 interpret get-package-property if 0 0 then ([4] -- [3]) handle_calls return: 00000000 00000019 fff56d04 getprop(0xfff4a160, "stdout", 0x056579f4, 4) = 4 0x056579f4 07 c5 af 5c __ __ __ __ __ __ __ __ __ __ __ __ .ů\ instance-to-package(0x07c5af5c) = 0xfff567a4 getprop(0xfff4a160, "stdin", 0x056579f8, 4) = 4 0x056579f8 07 c5 b0 64 __ __ __ __ __ __ __ __ __ __ __ __ .Űd instance-to-package(0x07c5b064) = 0xfff567a4 getprop(0xfff567a4, "name", 0x0565f81c, 31) = 5 0x0565f81c 63 68 2d 62 00 __ __ __ __ __ __ __ __ __ __ __ ch-b. open("keyboard") = 0x07c5b49c of_client_interface: call-method 05616d78 07c5b098 07c5b49c call-method slw_init_keymap ([3] -- [2]) handle_calls return: 00000000 fff57558 of_client_interface: call-method 05616d88 07c5b098 call-method slw_update_keymap ([2] -- [1]) handle_calls return: 00000000 getprop(0xfff4a0e8, "security-mode", 0x0565f83c, 32) = -1 of_client_interface: call-method 05616d60 07c5b098 00000000 call-method slw_set_output_level ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c70 07c5b098 call-method slw_cr ([2] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c70 07c5b098 call-method slw_cr ([2] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c78 07c5b098 0000004d call-method slw_emit ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c78 07c5b098 00000061 call-method slw_emit ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c78 07c5b098 00000063 call-method slw_emit ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c78 07c5b098 00000020 call-method slw_emit ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c78 07c5b098 0000004f call-method slw_emit ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c78 07c5b098 00000053 call-method slw_emit ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c78 07c5b098 00000020 call-method slw_emit ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c78 07c5b098 00000058 call-method slw_emit ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c78 07c5b098 00000020 call-method slw_emit ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c78 07c5b098 0000004c call-method slw_emit ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c78 07c5b098 0000006f call-method slw_emit ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c78 07c5b098 00000061 call-method slw_emit ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c78 07c5b098 00000064 call-method slw_emit ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c78 07c5b098 00000065 call-method slw_emit ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c78 07c5b098 00000072 call-method slw_emit ([3] -- [1]) handle_calls return: 00000000 of_client_interface: call-method 05613c70 07c5b098 call-method slw_cr ([2] -- [1]) handle_calls return: 00000000 claim(0x05000000, 4194304, 0) = 0x05000000 claim(0x05400000, 2097152, 0) = 0x05400000 claim(0x04000000, 16777216, 0) = 0x04000000 claim(0x00004000, 67092480, 0) = 0x00004000
On Thu, Dec 13, 2012 at 03:57:54PM -0500, Programmingkid wrote:
This patch is an improvement upon the last get-key-map patch. This patch makes the code more 64bit friendly. It also fixes some whitespace damage.
The get-key-map word is used by bootx to see if any keys are being held down.
signed-off-by: John Arbuckle programmingkidx@gmail.com
This patch caused some issues while I was doing some tests. It seemed to go in infinte loop.
Anyway, do we even need to remap control as command?
From what I tested it boots fine in verbose when I pass it '-v' in boot-args
-boot order=d -prom-env 'boot-args=-v' and I'm pretty sure other arguments can also be passed this way.
Still because we need get-key-map, some comments inline.
Index: drivers/adb_kbd.c
--- drivers/adb_kbd.c (revision 1078) +++ drivers/adb_kbd.c (working copy) @@ -24,7 +24,7 @@ #include "libc/byteorder.h" #include "libc/vsprintf.h" #include "kbd.h"
+#include <math.h> #include "adb_bus.h" #include "adb_kbd.h"
@@ -42,11 +42,13 @@ }
static void keyboard_read(void); +static void getKeyMap(void);
NODE_METHODS( keyboard ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read },
- { "get-key-map", getKeyMap },
};
/* VT100 escape sequences */ @@ -566,3 +568,65 @@ } PUSH(i); }
+// 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.
+static void getKeyMap(void) +{
- #define sizeOfArray 8 // 8 bytes (32 bits) in size
- uint32_t keyPushed, *keyMapArray, offset;
- const uint32_t modifierKeyIndex = 7;
- const uint32_t commandKeyValue = pow(2,28);
- const uint32_t shiftKeyValue = pow(2,30);
- const uint32_t theAKeyValue = pow(2,27);
pow() needs another header, can't you just give it numbers it wants 0x10000000; 0x40000000; 0x08000000; or at least 1<<28; 1<<30; 1<<27; both seem clearer to me seeing as it is encoded value
- keyMapArray = (uint32_t *) malloc(sizeOfArray);
malloc() ... is it freed anywhere? I'm pretty sure it just eats memory on each call, there may be not much calls, but still
- 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((uint32_t)keyMapArray); // returns the address of keyMapArray
return;
- }
- feval("key");
- keyPushed = POP();
- if(keyPushed > 0 && keyPushed < 27) // control key combination
- {
offset = 1;
keyMapArray[modifierKeyIndex] = commandKeyValue;
- }
I think that pretending that some keys are others is really bad idea and when you boot emulated OS you will be still missing key, it should just be fixed in emulator. Also I haven't tested this but there is chance that sdl backend works properly (ie it uses meta keys which from what I read are mapped to command on Macs).
- 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((uint32_t) keyMapArray);
+}
On 21/12/12 01:40, Amadeusz Sławiński wrote:
This patch caused some issues while I was doing some tests. It seemed to go in infinte loop.
Anyway, do we even need to remap control as command?
From what I tested it boots fine in verbose when I pass it '-v' in boot-args
-boot order=d -prom-env 'boot-args=-v' and I'm pretty sure other arguments can also be passed this way.
Yes, it's fine to use -prom-env in this way.
Still because we need get-key-map, some comments inline.
Index: drivers/adb_kbd.c
--- drivers/adb_kbd.c (revision 1078) +++ drivers/adb_kbd.c (working copy) @@ -24,7 +24,7 @@ #include "libc/byteorder.h" #include "libc/vsprintf.h" #include "kbd.h"
+#include<math.h> #include "adb_bus.h" #include "adb_kbd.h"
@@ -42,11 +42,13 @@ }
static void keyboard_read(void); +static void getKeyMap(void);
NODE_METHODS( keyboard ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read },
{ "get-key-map", getKeyMap }, };
/* VT100 escape sequences */
@@ -566,3 +568,65 @@ } PUSH(i); }
+// 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.
+static void getKeyMap(void) +{
- #define sizeOfArray 8 // 8 bytes (32 bits) in size
- uint32_t keyPushed, *keyMapArray, offset;
- const uint32_t modifierKeyIndex = 7;
- const uint32_t commandKeyValue = pow(2,28);
- const uint32_t shiftKeyValue = pow(2,30);
- const uint32_t theAKeyValue = pow(2,27);
pow() needs another header, can't you just give it numbers it wants 0x10000000; 0x40000000; 0x08000000; or at least 1<<28; 1<<30; 1<<27; both seem clearer to me seeing as it is encoded value
- keyMapArray = (uint32_t *) malloc(sizeOfArray);
malloc() ... is it freed anywhere? I'm pretty sure it just eats memory on each call, there may be not much calls, but still
- 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((uint32_t)keyMapArray); // returns the address of keyMapArray
return;
- }
- feval("key");
- keyPushed = POP();
- if(keyPushed> 0&& keyPushed< 27) // control key combination
- {
offset = 1;
keyMapArray[modifierKeyIndex] = commandKeyValue;
- }
I think that pretending that some keys are others is really bad idea and when you boot emulated OS you will be still missing key, it should just be fixed in emulator. Also I haven't tested this but there is chance that sdl backend works properly (ie it uses meta keys which from what I read are mapped to command on Macs).
- 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);
I'm much more interested to know where you found this algorithm? BootX source has this function:
static long TestForKey(long key) { long keyNum; long bp; char tc;
if (gOFVersion < kOFVersion3x) { switch(key) { case 'a' : keyNum = 7; break; case 's' : keyNum = 6; break; case 'v' : keyNum = 14; break; case 'y' : keyNum = 23; break; case kCommandKey : keyNum = 48; break; case kOptKey : keyNum = 61; break; case kShiftKey : keyNum = 63; break; case kControlKey : keyNum = 49; break; default : keyNum = -1; break; } } else { switch(key) { case 'a' : keyNum = 3; break; case 's' : keyNum = 17; break; case 'v' : keyNum = 30; break; case 'y' : keyNum = 27; break; case kCommandKey : keyNum = 228; break; case kOptKey : keyNum = 229; break; case kShiftKey : keyNum = 230; break; case kControlKey : keyNum = 231; break; case kDeleteKey : keyNum = 45; break; default : keyNum = -1; break; }
// Map the right modifier keys on to the left. gKeyMap[28] |= gKeyMap[28] << 4; }
if (keyNum == -1) return 0;
bp = keyNum & 7; tc = gKeyMap[keyNum >> 3];
return (tc & (1 << bp)) != 0; }
Is keyNum the hardware scancode? If so, can it be related to the translation tables in drivers/adb_kdb.c?
ATB,
Mark.
On Dec 21, 2012, at 5:12 AM, Mark Cave-Ayland wrote:
On 21/12/12 01:40, Amadeusz Sławiński wrote:
This patch caused some issues while I was doing some tests. It seemed to go in infinte loop.
Anyway, do we even need to remap control as command?
From what I tested it boots fine in verbose when I pass it '-v' in boot-args
-boot order=d -prom-env 'boot-args=-v' and I'm pretty sure other arguments can also be passed this way.
Yes, it's fine to use -prom-env in this way.
Still because we need get-key-map, some comments inline.
Index: drivers/adb_kbd.c
--- drivers/adb_kbd.c (revision 1078) +++ drivers/adb_kbd.c (working copy) @@ -24,7 +24,7 @@ #include "libc/byteorder.h" #include "libc/vsprintf.h" #include "kbd.h"
+#include<math.h> #include "adb_bus.h" #include "adb_kbd.h"
@@ -42,11 +42,13 @@ }
static void keyboard_read(void); +static void getKeyMap(void);
NODE_METHODS( keyboard ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read },
- { "get-key-map", getKeyMap },
};
/* VT100 escape sequences */ @@ -566,3 +568,65 @@ } PUSH(i); }
+// 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.
+static void getKeyMap(void) +{
- #define sizeOfArray 8 // 8 bytes (32 bits) in size
- uint32_t keyPushed, *keyMapArray, offset;
- const uint32_t modifierKeyIndex = 7;
- const uint32_t commandKeyValue = pow(2,28);
- const uint32_t shiftKeyValue = pow(2,30);
- const uint32_t theAKeyValue = pow(2,27);
pow() needs another header, can't you just give it numbers it wants 0x10000000; 0x40000000; 0x08000000; or at least 1<<28; 1<<30; 1<<27; both seem clearer to me seeing as it is encoded value
- keyMapArray = (uint32_t *) malloc(sizeOfArray);
malloc() ... is it freed anywhere? I'm pretty sure it just eats memory on each call, there may be not much calls, but still
- 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((uint32_t)keyMapArray); // returns the address of keyMapArray
return;
- }
- feval("key");
- keyPushed = POP();
- if(keyPushed> 0&& keyPushed< 27) // control key combination
- {
offset = 1;
keyMapArray[modifierKeyIndex] = commandKeyValue;
- }
I think that pretending that some keys are others is really bad idea and when you boot emulated OS you will be still missing key, it should just be fixed in emulator. Also I haven't tested this but there is chance that sdl backend works properly (ie it uses meta keys which from what I read are mapped to command on Macs).
- 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);
I'm much more interested to know where you found this algorithm? BootX source has this function:
static long TestForKey(long key) { long keyNum; long bp; char tc;
if (gOFVersion < kOFVersion3x) { switch(key) { case 'a' : keyNum = 7; break; case 's' : keyNum = 6; break; case 'v' : keyNum = 14; break; case 'y' : keyNum = 23; break; case kCommandKey : keyNum = 48; break; case kOptKey : keyNum = 61; break; case kShiftKey : keyNum = 63; break; case kControlKey : keyNum = 49; break; default : keyNum = -1; break; } } else { switch(key) { case 'a' : keyNum = 3; break; case 's' : keyNum = 17; break; case 'v' : keyNum = 30; break; case 'y' : keyNum = 27; break; case kCommandKey : keyNum = 228; break; case kOptKey : keyNum = 229; break; case kShiftKey : keyNum = 230; break; case kControlKey : keyNum = 231; break; case kDeleteKey : keyNum = 45; break; default : keyNum = -1; break; }
// Map the right modifier keys on to the left. gKeyMap[28] |= gKeyMap[28] << 4; }
if (keyNum == -1) return 0;
bp = keyNum & 7; tc = gKeyMap[keyNum >> 3];
return (tc & (1 << bp)) != 0; }
Is keyNum the hardware scancode? If so, can it be related to the translation tables in drivers/adb_kdb.c?
I studied the output of get-key-map and figured out what it was doing by pushing down different keys when it was called.
I'm not sure if keyNum is the hardware scancode.
On Dec 20, 2012, at 8:40 PM, Amadeusz Sławiński wrote:
On Thu, Dec 13, 2012 at 03:57:54PM -0500, Programmingkid wrote:
This patch is an improvement upon the last get-key-map patch. This patch makes the code more 64bit friendly. It also fixes some whitespace damage.
The get-key-map word is used by bootx to see if any keys are being held down.
signed-off-by: John Arbuckle programmingkidx@gmail.com
This patch caused some issues while I was doing some tests. It seemed to go in infinte loop.
Anyway, do we even need to remap control as command? From what I tested it boots fine in verbose when I pass it '-v' in boot-args -boot order=d -prom-env 'boot-args=-v' and I'm pretty sure other arguments can also be passed this way.
Still because we need get-key-map, some comments inline.
Index: drivers/adb_kbd.c
--- drivers/adb_kbd.c (revision 1078) +++ drivers/adb_kbd.c (working copy) @@ -24,7 +24,7 @@ #include "libc/byteorder.h" #include "libc/vsprintf.h" #include "kbd.h"
+#include <math.h> #include "adb_bus.h" #include "adb_kbd.h"
@@ -42,11 +42,13 @@ }
static void keyboard_read(void); +static void getKeyMap(void);
NODE_METHODS( keyboard ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read },
- { "get-key-map", getKeyMap },
};
/* VT100 escape sequences */ @@ -566,3 +568,65 @@ } PUSH(i); }
+// 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.
+static void getKeyMap(void) +{
- #define sizeOfArray 8 // 8 bytes (32 bits) in size
- uint32_t keyPushed, *keyMapArray, offset;
- const uint32_t modifierKeyIndex = 7;
- const uint32_t commandKeyValue = pow(2,28);
- const uint32_t shiftKeyValue = pow(2,30);
- const uint32_t theAKeyValue = pow(2,27);
pow() needs another header, can't you just give it numbers it wants 0x10000000; 0x40000000; 0x08000000; or at least 1<<28; 1<<30; 1<<27; both seem clearer to me seeing as it is encoded value
- keyMapArray = (uint32_t *) malloc(sizeOfArray);
malloc() ... is it freed anywhere? I'm pretty sure it just eats memory on each call, there may be not much calls, but still
- 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((uint32_t)keyMapArray); // returns the address of keyMapArray
return;
- }
- feval("key");
- keyPushed = POP();
- if(keyPushed > 0 && keyPushed < 27) // control key combination
- {
offset = 1;
keyMapArray[modifierKeyIndex] = commandKeyValue;
- }
I think that pretending that some keys are others is really bad idea and when you boot emulated OS you will be still missing key, it should just be fixed in emulator. Also I haven't tested this but there is chance that sdl backend works properly (ie it uses meta keys which from what I read are mapped to command on Macs).
- 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((uint32_t) keyMapArray);
+}
Pretty much every body hates my get-key-map patch. I think I will just give up on it. After some recent test, I'm not even sure we need a get-key-map word. Still, it would be nice to have.
I also want the command key sent to the emulator, but it doesn't look like any one is going to step forward and make this happen. :(
Let me know if the SDL backend works better than with the cocoa option.