[PATCH] get-key-map implementation

[Programmingkid]

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

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

[Amadeusz Sławiński]

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

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);
>
> +}

[Mark Cave-Ayland]

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.

[Programmingkid]

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
>
> 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.

[Programmingkid]

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.