Ability to obtain position of a key, not just keycode

[simon-wh]

Previous to the Remapping update the raw 'HID Codes' would effectively encode the position of a key as there's only one place where that code could possibly point to. Now, the remapping allows for those keys to be anywhere (and potentially in multiple places) so we've lost the position information of keys.

To solve this there's the possibility of including the Row/Column information of the key following the keyboard matrix, to encode the key position.

The question is, how this should be implemented, with there being two main approaches:

• Include the Row/Col alongside the keycode (likely will require the most (possibly breaking) changes)
• Provide Row/Col as an alternative 'Keycode Type' (Would be simpler to implement, but limiting in terms of not being able to know the position and the keycode at the same time)

[GottZ]

lol.. i made this yesterday just for fun in my rgb sdk test code..

this is for ISO keyboards:

const int posx[] = {
    /*        0    1    2    3    4    5    6    7    8    9   10   11   12   13    14   15   16    17   18   19   20 */
    /* 0 */  17,  -1,  55,  74,  93, 112, 142, 161, 180, 199, 227, 246, 265, 284,  309, 328, 347,  371, 390, 409, 428,
    /* 1 */  17,  36,  55,  74,  93, 112, 131, 150, 169, 188, 207, 226, 245, 275,  309, 328, 347,  371, 390, 409, 428,
    /* 2 */  23,  47,  66,  85, 104, 123, 142, 161, 180, 199, 218, 237, 256,  -1,  309, 328, 347,  371, 390, 409, 428,
    /* 3 */  25,  51,  70,  89, 108, 127, 146, 165, 184, 203, 222, 241, 260, 283,   -1,  -1,  -1,  371, 390, 409,  -1,
    /* 4 */  20,  41,  60,  79,  98, 117, 136, 155, 174, 193, 212, 231,  -1, 268,   -1, 328,  -1,  371, 390, 409, 428,
    /* 5 */  20,  44,  68,  -1,  -1,  -1, 140,  -1,  -1,  -1, 211, 235, 259, 283,  309, 328, 347,   -1, 380, 409,  -1

};

const int posy[] = {
    /*        0    1    2    3    4    5    6    7    8    9   10   11   12   13    14   15   16    17   18   19   20 */
    /* 0 */  18,  -1,  18,  18,  18,  18,  18,  18,  18,  18,  18,  18,  18,  18,   18,  18,  18,   18,  18,  18,  18,
    /* 1 */  43,  43,  43,  43,  43,  43,  43,  43,  43,  43,  43,  43,  43,  43,   43,  43,  43,   43,  43,  43,  43,
    /* 2 */  62,  62,  62,  62,  62,  62,  62,  62,  62,  62,  62,  62,  62,  -1,   62,  62,  62,   62,  62,  62,  70,
    /* 3 */  81,  81,  81,  81,  81,  81,  81,  81,  81,  81,  81,  81,  81,  70,   -1,  -1,  -1,   81,  81,  81,  -1,
    /* 4 */ 100, 100, 100, 100, 100, 100, 100, 100, 100, 100, 100, 100,  -1, 100,   -1, 100,  -1,  100, 100, 100, 108,
    /* 5 */ 119, 119, 119,  -1,  -1,  -1, 119,  -1,  -1,  -1, 119, 119, 119, 119,  119, 119, 119,   -1, 119, 119,  -1
};

const int posxminbound = 8;
const int posyminbound = 9;
const int posxmaxbound = 437;
const int posymaxbound = 128;

const int posxmin = 17;
const int posymin = 18;
const int posxmax = 428;
const int posymax = 119;

// total height: 149mm
// total width: 446mm

for ansi:
posx row 4 col 0 would be 31
posx row 4 col 1 would be -1
posy row 4 col 1 would be -1
posx row 3 col 13 would be 278
posy row 3 col 13 would be 81
posx row 3 col 12 would be -1
posy row 3 col 12 would be -1
posx row 2 col 13 would be 280
posy row 2 col 13 would be 62

all numbers without warranty.
ansi values are untested.

values are in millimeters (cause nobody cares about imperial)

offsets were measured manually.
it would probably be a good idea to get a CAD extraction for the key stems relative to top left of the keyboard case.

RGB example:

    for(int i = 0, buttons = WOOTING_RGB_COLS * WOOTING_RGB_ROWS; i < buttons; i++) {
        if (posx[i] < 0) continue;

        int x = i / WOOTING_RGB_COLS;
        int y = i % WOOTING_RGB_COLS;

        double px = (double)(posx[i] - posxmin) / (posxmax - posxmin);
        double py = (double)(posy[i] - posymin) / (posymax - posymin);

        wooting_rgb_direct_set_key(x, y, px * 255, 255 - py * 255, (1 - px) * py * 255);

        usleep(20000);
    }

wich results in:

[Kristallranke]

I suggest using the keycodes/indices from the configuration interface (used by Wootility) and a mapping to cols/rows on the SDK side (sort of like in the RGB SDK). The mapped keycode could be passed alongside for the new keycode type only.

The advantages would be:

• the new keycodes would be uniform between configuration interface and analog
• you don't need to look up the key mapping (which you can't do using the official SDKs)
• on the firmware side you don't need another key mapping table

[Sainan]

This might be worth revisiting for the Wooting UwU since remapping is pretty integral to this device's usage, so any assumption about where a key is located goes right out of the window.