Fix for #115

[sivar2311]

This fixes #115

[T-vK]

Sorry for letting you wait for so long. I'm currently thinking about creating some sort of beta branch that I can use to accept PRs faster and then also create beta releases for those PRs. This way we can have new (beta) releases without testing them on all platforms. And those beta releases can then be turned into a stable release once they have been tested for all platforms.

[sivar2311]

Apology accepted ;)

The idea sounds good.
What would the workflow look like?
Do I have to create a new branch in a fork?

[T-vK]

I'm not sure yet. My initial idea was that I simply add a branch called beta and then you could merge your branch into that beta branch via PR. But maybe it would be a better idea to simply say that the master by itself is not stable and if you want a stable version of the source code, you have to checkout a release tag.

[sivar2311]

But maybe it would be a better idea to simply say that the master by itself is not stable and if you want a stable version of the source code, you have to checkout a release tag.

I think that's the usual way. The master is the "development environment" and stable versions are tagged. Afaik both the ArduinoIDE Library Manager and PlatformIO use the release labels.

[T-vK]

Okay let's do it that way then. I've merged the PR and created a beta tag and a beta release for it now.

You seem to be quite interested in this project. I would like to add you as a collaborator, so you don't have to create PRs all the time and wait for me. What do you think?

[sivar2311]

Thank you for the offer. It sounds interesting. I'm in. :)

I would also be interested in direct contact (WhatsApp / Telegram) - What do you think?

[sivar2311]

BTW: I'm still trying to figure out the HID stuff. I would also be very interested in sending special characters. I am from Germany and I am missing the "Umlaute" (äöüß).

[T-vK]

I'm not comfortable sharing my phone number, but you can hit me up on [email protected] if you want.
Regarding keyboard layouts, I'm not sure how we should solve this yet. It's important to me to not break compatibility with the Arduino keyboard library, so the default will have to stay the US layout.
It would probably make sense to save every keyboard layout in its own header file and let the user pick one by specifying it using something like #define KEYBOARD_LAYOUT us.

At the moment the layout is hardcoded here:

ESP32-BLE-Keyboard/BleKeyboard.cpp

Lines 215 to 349 in 4d93a04

	const uint8_t _asciimap[128] PROGMEM;
	#define SHIFT 0x80
	const uint8_t _asciimap[128] =
	{
	0x00, // NUL
	0x00, // SOH
	0x00, // STX
	0x00, // ETX
	0x00, // EOT
	0x00, // ENQ
	0x00, // ACK
	0x00, // BEL
	0x2a, // BS Backspace
	0x2b, // TAB Tab
	0x28, // LF Enter
	0x00, // VT
	0x00, // FF
	0x00, // CR
	0x00, // SO
	0x00, // SI
	0x00, // DEL
	0x00, // DC1
	0x00, // DC2
	0x00, // DC3
	0x00, // DC4
	0x00, // NAK
	0x00, // SYN
	0x00, // ETB
	0x00, // CAN
	0x00, // EM
	0x00, // SUB
	0x00, // ESC
	0x00, // FS
	0x00, // GS
	0x00, // RS
	0x00, // US
	0x2c, // ' '
	0x1e|SHIFT, // !
	0x34|SHIFT, // "
	0x20|SHIFT, // #
	0x21|SHIFT, // $
	0x22|SHIFT, // %
	0x24|SHIFT, // &
	0x34, // '
	0x26|SHIFT, // (
	0x27|SHIFT, // )
	0x25|SHIFT, // *
	0x2e|SHIFT, // +
	0x36, // ,
	0x2d, // -
	0x37, // .
	0x38, // /
	0x27, // 0
	0x1e, // 1
	0x1f, // 2
	0x20, // 3
	0x21, // 4
	0x22, // 5
	0x23, // 6
	0x24, // 7
	0x25, // 8
	0x26, // 9
	0x33|SHIFT, // :
	0x33, // ;
	0x36|SHIFT, // <
	0x2e, // =
	0x37|SHIFT, // >
	0x38|SHIFT, // ?
	0x1f|SHIFT, // @
	0x04|SHIFT, // A
	0x05|SHIFT, // B
	0x06|SHIFT, // C
	0x07|SHIFT, // D
	0x08|SHIFT, // E
	0x09|SHIFT, // F
	0x0a|SHIFT, // G
	0x0b|SHIFT, // H
	0x0c|SHIFT, // I
	0x0d|SHIFT, // J
	0x0e|SHIFT, // K
	0x0f|SHIFT, // L
	0x10|SHIFT, // M
	0x11|SHIFT, // N
	0x12|SHIFT, // O
	0x13|SHIFT, // P
	0x14|SHIFT, // Q
	0x15|SHIFT, // R
	0x16|SHIFT, // S
	0x17|SHIFT, // T
	0x18|SHIFT, // U
	0x19|SHIFT, // V
	0x1a|SHIFT, // W
	0x1b|SHIFT, // X
	0x1c|SHIFT, // Y
	0x1d|SHIFT, // Z
	0x2f, // [
	0x31, // bslash
	0x30, // ]
	0x23|SHIFT, // ^
	0x2d|SHIFT, // _
	0x35, // `
	0x04, // a
	0x05, // b
	0x06, // c
	0x07, // d
	0x08, // e
	0x09, // f
	0x0a, // g
	0x0b, // h
	0x0c, // i
	0x0d, // j
	0x0e, // k
	0x0f, // l
	0x10, // m
	0x11, // n
	0x12, // o
	0x13, // p
	0x14, // q
	0x15, // r
	0x16, // s
	0x17, // t
	0x18, // u
	0x19, // v
	0x1a, // w
	0x1b, // x
	0x1c, // y
	0x1d, // z
	0x2f|SHIFT, // {
	0x31|SHIFT, // |
	0x30|SHIFT, // }
	0x35|SHIFT, // ~
	0 // DEL
	};

and potentially also here:

ESP32-BLE-Keyboard/BleKeyboard.h

Lines 29 to 76 in 4d93a04

	const uint8_t KEY_LEFT_CTRL = 0x80;
	const uint8_t KEY_LEFT_SHIFT = 0x81;
	const uint8_t KEY_LEFT_ALT = 0x82;
	const uint8_t KEY_LEFT_GUI = 0x83;
	const uint8_t KEY_RIGHT_CTRL = 0x84;
	const uint8_t KEY_RIGHT_SHIFT = 0x85;
	const uint8_t KEY_RIGHT_ALT = 0x86;
	const uint8_t KEY_RIGHT_GUI = 0x87;
	const uint8_t KEY_UP_ARROW = 0xDA;
	const uint8_t KEY_DOWN_ARROW = 0xD9;
	const uint8_t KEY_LEFT_ARROW = 0xD8;
	const uint8_t KEY_RIGHT_ARROW = 0xD7;
	const uint8_t KEY_BACKSPACE = 0xB2;
	const uint8_t KEY_TAB = 0xB3;
	const uint8_t KEY_RETURN = 0xB0;
	const uint8_t KEY_ESC = 0xB1;
	const uint8_t KEY_INSERT = 0xD1;
	const uint8_t KEY_DELETE = 0xD4;
	const uint8_t KEY_PAGE_UP = 0xD3;
	const uint8_t KEY_PAGE_DOWN = 0xD6;
	const uint8_t KEY_HOME = 0xD2;
	const uint8_t KEY_END = 0xD5;
	const uint8_t KEY_CAPS_LOCK = 0xC1;
	const uint8_t KEY_F1 = 0xC2;
	const uint8_t KEY_F2 = 0xC3;
	const uint8_t KEY_F3 = 0xC4;
	const uint8_t KEY_F4 = 0xC5;
	const uint8_t KEY_F5 = 0xC6;
	const uint8_t KEY_F6 = 0xC7;
	const uint8_t KEY_F7 = 0xC8;
	const uint8_t KEY_F8 = 0xC9;
	const uint8_t KEY_F9 = 0xCA;
	const uint8_t KEY_F10 = 0xCB;
	const uint8_t KEY_F11 = 0xCC;
	const uint8_t KEY_F12 = 0xCD;
	const uint8_t KEY_F13 = 0xF0;
	const uint8_t KEY_F14 = 0xF1;
	const uint8_t KEY_F15 = 0xF2;
	const uint8_t KEY_F16 = 0xF3;
	const uint8_t KEY_F17 = 0xF4;
	const uint8_t KEY_F18 = 0xF5;
	const uint8_t KEY_F19 = 0xF6;
	const uint8_t KEY_F20 = 0xF7;
	const uint8_t KEY_F21 = 0xF8;
	const uint8_t KEY_F22 = 0xF9;
	const uint8_t KEY_F23 = 0xFA;
	const uint8_t KEY_F24 = 0xFB;

(I'm not sure if those keys actually differ in different layouts though.)

[sivar2311]

Yes, I know those lines.

I am still not quite clear about the conversion of ascii codes to HID codes.

My idea would be to work with a std::vector instead of a static array. Alternatively, we could use a pointer to an array internally (which points to the fixed ascii table by default), but which can be changed to a custom table by the user.

[T-vK]

I think the name of the variable _asciimap (which I just copied from the USB Keyboard library) is a bit misleading because it contains keyboard scan codes and not a classic ascii table. We basically just need a different mapping for each keyboard layout. I'm not sure what would be the best way of doing it, but I would vote for a way that only compiles the wanted keyboard layout so that we don't end up with memory issues again in the future.
You probably know better than me if std:vector, an array or a pointer would be the best way to achieve this.

[sivar2311]

The name is suitable. The array maps the Ascii code to the corresponding scan code.
I have two problems to understand this.
First, I don't know the meaning of the scan codes. For example, what is the scan code for "ö"?
Second, in the press function the _ascii map is limited to 128: } else if (k >= 128) { // it's a modifier key

So ascii codes > 128 are not possible at all. But exactly there are the umlauts and characters of other languages.

[sivar2311]

Ok, i think begin to get a feeling for this.
To get xyzäöü i need to send xzy';[ (US-Layout)

[T-vK]

Yes, exactly.
z is y,
y is z,
; is ö
etc...

[sivar2311]

Thank's for the images!

I am thinking about using a std::map instead of a fixed array.
This map can be initialized with standard us-codes and modified later.
Here you can see what i mean - fist (and very basic) approach.
Looks like this topic is much more complicated because it is related to ASCII codes, code pages and HID key codes.

Edit:
Maybe the press / release function needs to be modified because this would deal with ASCII codes above 127.

[sivar2311]

I think i've found a solution - check the new branch Layout (still in my repository)

_asciimap is now a member of BleKeyboard and of type KbdLayout which is a std::map<uint8_t, uint8_t>
The map takes the ascii code as first parameter and the hid key-code as second parameter and is initialized with the US layout.
The function modifyKbdLayout has been implemented to alter the keyboard mapping - see GermanKeyboard.ino example
The functions press and release have been changed to accept ascii codes > 127

[T-vK]

Nice, I like it. Maybe it can be improved further in a way that the user doesn't have to worry about the layout code. Something like this maybe:

#include "Layouts/German.h"

bleKeyboard.setLayout(DE_LAYOUT);

[sivar2311]

Sure, this can be outsourced to individual header files.
The most difficult thing will be to define the layouts.

[T-vK]

I think so far no one has asked me for layouts other than DE and FR. So that would probably already be pretty valueable for the community. Other layouts could be added in the future. I don't think it would be necessary to add all layouts now.