Closed Build-0-Matic closed 2 years ago
Thanks for opening your first issue here! 🎉
👉 Be sure to:
1. 📖 Have a look at the Wiki and README for information
2. 🔍 Search for similar issues (open and closed)
3. ✍️ Provide enough information to understand, recreate and help out with your problem
4. ℹ️ Let us know if you find a solution
5. 📕 Close the issue when your problem has been solved
Hello, thank you for your feedback I actually noticed during my modification for French keyboard, I did not find a solution because the US keyboard does not have an accent, I will look into the question if you have anything new do not hesitate :)
I have something new! I tried to copy the whole const uint8_t utf8_gb[] PROGMEM = {
and for my part in "é" I had "€" so I modified the keys for my language and it's good I have an "é"
GB > const uint8_t utf8_gb[] PROGMEM = {
Here is my solution to adapt for the CA keyboard
WEBSITE FOR CODE: https://www.utf8-chartable.de/unicode-utf8-table.pl?utf8=0x look HEXA look LATIN CAPITAL LETTER
My CODE:
const uint8_t utf8_fr[] PROGMEM = {
0xc3, 0xa8, 0x00, 0x00, KEY_NONE, KEY_7, // è
0xc3, 0xa9, 0x00, 0x00, KEY_NONE, KEY_2, // é
0xc3, 0xa0, 0x00, 0x00, KEY_NONE, KEY_0, // à
0xc3, 0xb9, 0x00, 0x00, KEY_NONE, KEY_APOSTROPHE, // ù
0xc2, 0xb5, 0x00, 0x00, KEY_MOD_LSHIFT, KEY_BACKSLASH, // µ
0xc3, 0xa7, 0x00, 0x00, KEY_NONE, KEY_9 // ç
};
https://i.ibb.co/3W92V9y/image.jpg https://i.ibb.co/dWmsB4c/1.jpg
I'll have to try this out. I was looking at the German keyboard to try and figure out how the heck this all worked. I must say it's not exactly clear... I did manage to get the regular keys converted through trial and error... but I would have rather done it while actually understanding how it works. I think the command position in the list is important, but I don't know what it relates to. And then the extended ascii and utf8 controls... still a mystery.
Thanks for the hard work.
OK, I think I figure it out. The hex values are for the character you actually want to print and the key presses are the combo you need to do to get the character. If that's how it works, it really should be updated in the instructions!
yes that's how you find your hex code for the character here: https://www.utf8-chartable.de/unicode-utf8-table.pl?utf8=0x and you say if this character is spotted then make this combination
example:
0xc3, 0xa8, 0x00, 0x00, KEY_NONE, KEY_7, // è
0xc3, 0xa8, 0x00, 0x00, = the character 'é' KEY_NONE, KEY_7, = the key clicked if this character is found
Cool. Thanks! I'll work a bit on it this afternoon ☺
Worked on it a bit and for some reason it just won't work. here's the code
`const uint8_t utf8_ca_fr[] PROGMEM = { 0xc3, 0xa0, 0x00, 0x00, KEY_APOSTROPHE, KEY_A, // à 0xc3, 0xa2, 0x00, 0x00, KEY_LEFTBRACE, KEY_A, // â 0xc3, 0xa4, 0x00, 0x00, KEY_RIGHTBRACE, KEY_A, // ä
0xc3, 0xa7, 0x00, 0x00, KEY_RIGHTBRACE, KEY_C, // ç
0xc3, 0xa9, 0x00, 0x00, KEY_NONE, KEY_SLASH, // é
0xc3, 0xa8, 0x00, 0x00, KEY_APOSTROPHE, KEY_E, // è
0xc3, 0xaa, 0x00, 0x00, KEY_LEFTBRACE, KEY_E, // ê
0xc3, 0xab, 0x00, 0x00, KEY_RIGHTBRACE, KEY_E, // ë
0xc3, 0xaf, 0x00, 0x00, KEY_RIGHTBRACE, KEY_I, // ï
0xc3, 0xae, 0x00, 0x00, KEY_LEFTBRACE, KEY_I, // î
0xc3, 0xb4, 0x00, 0x00, KEY_LEFTBRACE, KEY_O, // ô
0xc3, 0xb6, 0x00, 0x00, KEY_RIGHTBRACE, KEY_O, // ö
0xc3, 0xbb, 0x00, 0x00, KEY_RIGHTBRACE, KEY_U, // ü
0xc3, 0x89, 0x00, 0x00, KEY_MOD_LSHIFT, KEY_SLASH, // É
0xc3, 0x88, 0x00, 0x00, KEY_APOSTROPHE, KEY_E, // È
0xc3, 0x8a, 0x00, 0x00, KEY_LEFTBRACE, KEY_E, // Ê
0xc3, 0x8b, 0x00, 0x00, KEY_RIGHTBRACE, KEY_E, // Ë
};`
so nothing out of the ordinary there. But when I send it the following
LOCALE CA_FR WINDOWS r STRING notepad ENTER DELAY 1000 STRING #1234567890-=qwertyuiopasdfghjkl;«zxcvbnm,.é ENTER STRING |!"/$%?&*()_+QWERTYUIOPASDFGHJKL:»ZXCVBNM'.É ENTER STRING \±@£¢¤¬¦²³¼½¾§¶[]~{}°¯´ ENTER STRING âäàçêëèîïôöûÙüÂÄÀÇÊËÈÎÏÔÖÛÙÜ ENTER
all I get is this
`|1234567890-=qwertyuiopasdfghjkl;zxcvbnm,.
!"/$%?&*()_+QWERTYUIOPASDFGHJKL:ZXCVBNM'. \@[]~^¨
`
I added this at the end (which is not needed by the US keyboard I started with)
static hid_locale_t locale_ca_fr { (uint8_t*)ascii_ca_fr, 128, (uint8_t*)utf8_ca_fr, sizeof(utf8_ca_fr) / 6 };
but it didn't do anything...
I do not really understand the problem otherwise on my github you have my files for the adaptation for French keyboard try to copy the base of my file and adapt it
I'm going to have to do that as I really don't understand what's going on... Besides, replacing the stock FR keyboard is something that should be done anyways.
I'll take a look and post my findings.
TqSent from my Huawei Mobile-------- Original Message --------Subject: Re: [SpacehuhnTech/WiFiDuck] Keyboard Locale Programming (#77)From: Build-0-Matic To: SpacehuhnTech/WiFiDuck CC: Subscribed I'm going to have to do that as I really don't understand what's going on... Besides, replacing the stock FR keyboard is something that should be done anyways. I'll take a look and post my findings.
—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe. [ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/SpacehuhnTech/WiFiDuck/issues/77#issuecomment-907827870", "url": "https://github.com/SpacehuhnTech/WiFiDuck/issues/77#issuecomment-907827870", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]
I think I'm slowly starting to figure it out... it looks like the key press combos can't be just anything. In the USB_HID file I found the following
* Modifier masks - used for the first byte in the HID report.
* NOTE: The second byte in the report is reserved, 0x00
#define KEY_MOD_LCTRL 0x01
#define KEY_MOD_LSHIFT 0x02
#define KEY_MOD_LALT 0x04
#define KEY_MOD_LMETA 0x08
#define KEY_MOD_RCTRL 0x10
#define KEY_MOD_RSHIFT 0x20
#define KEY_MOD_RALT 0x40
#define KEY_MOD_RMETA 0x80
So the modifiers have to be those keys. Since here in Canada we use A LOT of modifiers for our keyboard, which is essentially a US keyboard with a whole bunch of other characters jammed on it, the duck can't handle it all.
I wonder if this is a bug or not? I'll have to see if I can't add more keys as modifiers...
I don't think it's a bug
Doesn't look like it... But at least I managed to get all the very important characters working. The rest is just a minor annoyance. But I'll keep trying things out. Maybe I can figure out a workaround.
Hey there! I can help, but it's a bit hard for me to follow this thread. Can you tell me where exactly are you stuck right now? It would also help a lot if you can you share the progress you made so far (the full locale_ca_fr.h)!
Right now, I've pretty much given-up on the CA-FR locale at maybe 90% functionality. To get things working I essentially dropped the support for the characters that combine with characters to make the â ê ç ï ö è à letters. The problem I found is that these keys don't combine with a regular modifier (except for the shift key) but combine with another letter. And many times when you do a simultaneous press of the keys it comes out all wonky. And I don't know how to do sequential key presses... or if it's even remotely possible. Though I'm starting to wonder if using the left ALT key and the ascii code from the charmap would work? Here's where I'm at right now... this is over 90% good. https://github.com/Build-0-Matic/Duckduino-CA-FR-locale
Hi, just pushed the CA-FR Layout. This is my test script.
LOCALE ca-fr
DELAY 5000
STRING -,;./=0123456789aàbcçdeèéfghijklmnopqrstuùvwxyz_:!?'"()@*\&#%+$AÀBCÇDEÈÉFGHIJKLMNOPQRSTUÙVWXYZ«»[]{}°<>¬|~¤€`^¨âÂäÄĉĈêÊëËĝĜĥĤîÎïÏìÌĵĴôÔöÖòÒŝŜûÛüÜŵŴŷŶÿŸ
https://github.com/SpacehuhnTech/WiFiDuck/blob/master/atmega_duck/locale_cafr.h
Wow! This is a lot of additional characters! Thanks for pulling this the rest of the way. I'm sure it's going to be useful for people who also have the strange characters in their language as it's a good starting point for re-mapping.
I'll test this out as soon as I get a chance.
OK, I just did a test run. I sent the duck the following: LOCALE CAFR WINDOWS r DELAY 500 STRING notepad ENTER DELAY 1000 STRING #1234567890-=qwertyuiopasdfghjkl;zxcvbnm,. ENTER STRING |!"/$%?&*()+QWERTYUIOPASDFGHJKL:ZXCVBNM'. ENTER STRING éÉçÇêÊëËèÈïÏîÎôÔöÖ ENTER STRING \@[]~{}<>éɱ£¢¤¬¦²³¼½¾§¶°¯´«» ENTER
But to my surprise, the output gave me the following: /1234567890-=qwertyuiopasdfghjkl;zxcvbnm,.
!
é$%É&*()_+QWERTYUIOPASDFGHJKL:ZXCVBNM
.
<"^¸|^¨'.
Notice the missing accents line... I'll have to compare with the file I had made to see what the big difference is.
OK, I think I'm starting to figure this out... the keymap that was posted is I believe for the Canadian Multilingual keymap, which is different than what I'm working on...
Hmm that's disappointing. I set Windows to french canadian and it gave me the canadian multilingual layout by default. I assumed this would be the correct one. Which one are you using, and is it different from the regular french layout?
It's very different from the French (from France) layout. We have what is essentially a QWERTY with some characters grafted on. The hard part are characters that require double combo keys. like è is actually like pressing [ ' ] + [ e ]. But doing È involves [ ' ] + [ shift e ]. And pressing the combos at the same time doesn't seem to work. It's like if there was a millisecond delay between the key strokes that was required in order for it to work properly. For some characters like @ ~ { } [ ] \ ± £ ¢ ¤ ¬ ¦ ² ³ ¼ ½ ¾ ¯ ° it's pretty easy as you just need to use the [ AltCar ] key. But as soon as you combine [ AltCar ] + [ shift ] + whatever character needs it, it becomes a big nightmare.
Could it be this? Canadian French (legacy)
Looks like it's also called FRCA
Here's the one we use around here . One trick to know if you have the right one is to test the ç key. If you press the ] key on a US keyboard (second one after the p on the qwerty line), you should not get anything until you press [ c ]. If you instantly get the ç you have the wrong keymap.
While this keymap is OK to use, the presence of sticky keys for the accents makes it a bit of a nightmare to program on both the original duck and this one...
Thanks! I think I found the right layout now. My mistake was that I set windows to French (Canadian) instead of English (Canadian) and therefore had a different selection of keyboard layouts. I'll update the layout soon.
Ok, it's updated now. Hopefully, it will be correct this time! My test script:
LOCALE CA-FR
DELAY 5000
STRING -,;.«#¸<=0123456789abcdeéfghijklmnopqrstuvwxyz_:!?'"»()*/&%¨+>|$ABCDEÉFGHIJKLMNOPQRSTUVWXYZ[]{}§¶@\¯°±¬¦~¤¢£½¼²³¾`´^âÂàÀáÁêÊèÈîÎìÌíÍôÔòÒóÓûÛùÙúÚýÝ
Thanks! I'm going to give the new code a try and see.
YES! That now works perfectly! I didn't think that it could be doable without resorting to inserting characters by using the alt ascii codes from the character map. Thanks!
Hi! I'm trying to create a keyboard locale for the CA_FR keyboard and I'm really struggling. While I did manage to convert most of the keyboard layout, I'm really struggling with the accented letters. For the éÉ keys (which should be the easiest since they're available in the extended ASCII tables, I found the code, converted it to hex in the following fashion
const uint8_t extended_ascii_ca_fr[] PROGMEM = { 0x82, KEY_NONE, KEY_SLASH, // é 0x90, KEY_MOD_LSHIFT, KEY_SLASH, // É };
but the letters just won't print on the screen when I send them to the duck.Also, we have a bunch of letters (èêëôîçï) which are made using "sticky keys" where you first press the accent key and then the letter you want accented ^+e=ê How in the world do I program those?
Thanks!