-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ADB German Keyboard layout ^ and < reversed (Windows) #35
Comments
Hmm, Actually I want to know what codes German keyboard sends for those keys. Though that'll be difficult or need some hassle... |
yes, a windows keyboard (logitech) connected to my macbook -> keys work correct if you explain what is required, i will try to help |
i have loaded an usb monitor software on my windows machine and as expected, when having the adb_usb teensy connected, it behaves the other way round... edit: i think i found the issue.....actually i was... Those two keys should be interchanged in adb_usb. Sorry for reporting it wrong in the first place. The keyboard layout can be reset by deleting the /Library/Preferences/com.apple.keyboardtype.plist file. Then restart. Mac OS X now brings up the keyboard assistant again. With the correct adb_usb keyboard layout, after using this assistant, the keys should also work correct then. |
I seemed to be confused about those keys, if I can get them correctlly they should be like following table, right?
|
i am really 100% sure. As it is now in the keycode.c file it is not correct for the german keyboard. It will work under OS X, but it will turn out wrong on Windows etc. |
Looks like two solutions can exist.
French AZERTY has same problem. |
OSX can recognize its layout(ANSI, ISO or JIS) automatically for Apple products only so that faithful users doens't need 'Keyboard Setup Assistant' to start using it. Meanwhile third party products including TMK are handled as ANSI layout by default unless user specified its layout in some way. OSX checks only Apple USB vendor/product ID.(and ADB product ID, probably.) See IOHIDKeyboard::handlerID. OSX uses ADB scan codes as internal key codes and USB codes(usages) should be converted into ADB codes. This file defines USB-ADB code convert table. OSX checks only Apple USB vendor/product ID and ADB product ID, probably.(See IOHIDKeyboard::handlerID) And the table is patched when Apple ISO keyboard is using. This circumvents the key swap problem.(See IOHIDKeyboard::deviceType) But our keyboard is handled as ANSI layout so we suffer from the key swap problem. [DELETE] Problem is USB-ADB convert table to support both ISO and ANSI ADB keyboard layouts which are incompatile with eatch other. ANSI uses ADB code 0x32 to register '^'(left of '1') while ISO uses 0x32 for '<'(right of Left Shift) and 0x0A for '^'. How iMate resolves this? Maybe solution 2. Methinks. Just two cents. |
Use ISO keymap with ADB ISO keyboard has weird layout which swaps key on left of 1(_a) and key on right of Shift(_b). We need to use keymap for this ISO layout.
|
* upstream/master: (93 commits) Add ISO keymap(issue tmk#35) and use new keymap API Fix set LED for NKRO keyboard interface Unused endpoint of console OUT is commentout'd Add Makefiles for TMK converters. Fix remotewakeup of PJRC stack(Fix tmk#121) Check if LUFA-git really exists(Fix tmk#118) NKRO is disable when SET_PROTOCOL(boot) Make NKRO deafult when it is available Change MCU setting to ATmega32U2 Fix description of pin usage Add LUFA git repository(release 140302) Move macro definitions from lufa.c to lufa.h Fix 'Shift Parentheses' example Change LUFA build options Return when ready check loop is timeouted(Fix tmk#115) Change PollingIntervalMS to 10ms(Fix tmk#114) New macro: ACTION_BACKLIGHT_LEVEL(level) Show correct function name for default layer set Added Lightsaber FN-layer Lightsaber clean ups ...
I found this post, seems 'Griffin iMate' and 'New Motion uKey' also have similar or worse problem with ISO keyboards. |
how to determine keyboard layout with handler id. |
Added auto detection of ISO layout and swap of the problematic scan codes. I hope this works for ISO keyboards. |
As for this ISO keyboard auto detection test and report from ISO users are required. Informations like your OS version, keyboard layout setting on OS and etc would be uselful. |
I don’t know if this is still an issue. I have an AEKII ISO German and use Pins 4 and 5 of a Teensy 2.0 for Data and Power. I didn’t change anything in the tmk code, so it should expect Data and Power on Pins 0 and 1 (in adb_usb/config.h). It works almost perfect with Linux Mint 17.3. Only »problem«: The equal sign on the Numpad generates an accent (»´«). I’d prefer a dot (».«, as alternative to the comma). < and ^ work as expected. Same with Windows 8.1. |
I changed the code to Pins 4 and 5, now < and ^ are switched. I changed it back to 0 and 1, but the Teensy only would go into bootloops and make the mouse pointer jump. After several tries and with Pins 4 and 5 in config.h it’s working again, < and ^ not switched. Weird. |
After another programming of the Teensy < and ^ were switched again, plugging off and on the AEKII on the Teensy switched them back. |
I too have this issue with my German AEKII: NUBS and GRV are switched after programming the micro-controller. Once the keyboard is unplugged they are switched again, to whatever is defined in the keymap. It seems like the auto detection only works if the keyboard is being programmed. |
@kuerb yes, you are right. It detects ISO keyboard only once. Fix and improvement for this is welcomed. EDIT: ADB conveter checks ISO keyboard only at startup, if you have ISO keyboard you will have to plug it into the converter before pluggin computer. |
I have the same problem as a previous commentator where the EQUAL key on the numpad, registers as ‘ on an AEK2 iso. Mapped it as iso |
@egla89 did you try firmware got from keyboard editor? |
I flashed a teensy in my iso-de aek2 with ‘make -f Makefile.teensy KEYMAP=iso‘. Os is macOS 10.13 and I ran the layout recognition (so the < and ^ are in the right spot). Every other key works correctly |
OK, then, |
And is this pic what you referred as 'iso-de aek2'? if not can you post pic of your aek2? |
thanks for the pic and it makes sense. anyway, you can change keymap as you want, there is no universal keymap for everyone. |
Ok yes that makes sense. I‘ll change my layout accordingly. Thanks a lot! |
Just for future reference, |
Open new issue if you have problem. |
This is more or less a follow up on the older bug #22 that was fixed in the adb_usb converter.
I have now noticed something else. While these keys work as expected on my mac, They are reversed when the keyboard is plugged in on Windows (M3501 Extended II keyboard).
So when i press the ^ key (left of the 1 key), i get <.
If i press <, i get ^.
I thought it to be some kind of issue with Windows, so i googled and found this site (it is german though), but it might be helpful in analyzing this issue.
He describes some low level patch for the keyboard driver of Mac OS X.
http://snark.de/mac/usbkbpatch/
As it is already in the adb_usb code, he describes the adb keyboard codes as
0x32 <
0x0a ^
but he has an interesting note on the usb codes for these keys:
0x64 ^ (caret - on wintel-usb switched with < (smaller) )
0x35 < (smaller - on wintel-usb switched with ^ (caret) )
Not sure what this means though. But there seems some kind of difference how Mac OS X interpretes these keys.
Switching the ADB code in the keymap.c obviously did the trick, but i guess a better solution exists, since other keyboards do not have this issue.
The text was updated successfully, but these errors were encountered: