tmk/tmk_keyboard

Keyboard firmwares for Atmel AVR and Cortex-M

TMK Keyboard Firmware Collection

This repository includes keyboard and converter firmware projects built with tmk_core keyboard library.

The latest source code is available here: http://github.com/tmk/tmk_keyboard

Documentation

Refer to wiki pages for further info.

https://github.com/tmk/tmk_keyboard/wiki

License

GPLv2 or later. Some protocol files are under Modified BSD License.

Third party libraries like LUFA, PJRC and V-USB have their own license respectively.

tmk_keyboard's Issues

Debouncing support

macway/matrix.c should have debouncing code.
This will also be ported for other mechanical keyboards.

USB protocol stack behaviour on boot time or BIOS

I didn't test my firmware under boot/reboot, BIOS or boot selector like ntldr, grub and etc, and my code is not completely conformed to USB/HID spec. So I'm sure problems can remain to exist in my code.

NOTE: This issue comes form my work, not original PJRC/LUFA. I must say this for honor of them.

USB NKRO on LUFA

NKRO is supported only on PJRC USB stack currently.

Macro doesn't support Media key

Macro supports only usage page 0x07 at this time.
Other keys including media keys(consumer page) will be supported later.

ps2_usb converter missing interrupt based ps2 files

The readme for ps2_usb converter says to use Makefile.pjrc_intr, but I do not see this file. It also says to look at ps2_intr.c for more interrupt info. I would like to use interrupt mode so I can improve power efficiency. Is this mode still available somehow?

USB spec confromance

NOTE: These are not issues devired from LUFA or PJRC code, just problems of tmk_keyboard.

lufa stack

• HID_GET_REPORT must be supported on all interface. (HID_1.11 Appendix G)
  boot keyboard interface is only supported now. Other interface does not work on host which not support interrupt transaction.

prjc stack

Will NOT updated from this time. Use lufa stack from now on.

Non-QWERTY host and special characters handling in single layer

If you have a QWERTZ host system many special characters have different locations and may also need different modifiers, many with RALT aka AltGr.

@ = RALT + q
| = RALT + <    (which is NUBS)
! = RSFT + 1    and so on.

The mapping to different keycodes is solved easily in the keymap, it is just not as readable anymore as names do not match the actual key behind it.

Adding different modifiers to keys on a single layer also works by using the appropriate action macros to define for example FN12 as

ACTION_RMOD_KEY(KC_RALT, KC_Q) // "@" on qwertz host

I was just wondering if I was overlooking something, or if defining all the 20 extra characters that need this special treatment is the right way to go?
I also saw ACTION_FUNCTION_TAP(), but could not get it to work on my gh60-based codebase yet.

In my own custom firmware I worked around this by also storing necessary modifiers with a key, but that is clearly not a solution here, as neither is re-defining the hid-usage codes.

Slow performance when built for ErgoDox

I don't know if you ever look at forks, but if you do... perhaps you could take a look at cub-uanic's for the ErgoDox? There's a thread going over here for it: http://geekhack.org/index.php?topic=48106.new#new

The problem I've had with it is that keyboard responsiveness is horrible with the build. Which sucks as I'd really like to use the features in it. Not sure if you can help, but thought I'd ask. Thanks!

HID listen not showing debug information

I hate to write an ID10T bug, given that I work in QA, but I can't get any output from my Teensy 2.0 in the HID listen application on my mac.
I've compiled and loaded the adb_usb code and the keyboard works properly as an ADB keyboard. I want to add some keymap layer stuff to it(the matias half-qwerty from the hhkb example keymap) and that doesn't work. I tried to get HID listen to give me some debug information, but i cant even get that to show me anything.
I just see "Waiting for Device..."

Is there something in config.h that needs to be set for it to send debug information to HID Listen?

Debounce is not enough

Not defining CONSOLE_ENABLE option in Makefile may causes key bounce.
Debouncing time may not be enough. Hardware timer should be used instead of using counter and wait.
Alps and Cherry spec say its max bounce time is 5ms.

AT90USB162(ATmega16U2/32U2) not supported on pjrc stack

Original PJRC code has no problem but modified version of tmk_keyboard has bug.

Endpoint configure may be its reason. These controllers doesn't support double buffer feature on endpoint 1 and 2, though tmk_keyboard code specify the option. I don't have the controller to test this.

Endpoint configure in lufa stack specify single buffer(bank) for those endpoints, it may not cause this problem. Though I can't confirm it at this time.

From datasheets,
ATmega32U4/16U4, AT90USB64/128
• Endpoint 0:programmable size FIFO up to 64 bytes, default control endpoint
• Endpoints 1 programmable size FIFO up to 256 bytes in ping-pong mode.
• Endpoints 2 to 6: programmable size FIFO up to 64 bytes in ping-pong mode.

AT90USB82/162, ATmega8U2/16U2/32U2
• Endpoint 0:programmable size FIFO up to 64 bytes, default control endpoint
• Endpoints 1 and 2: programmable size FIFO up to 64 bytes.
• Endpoints 3 and 4: programmable size FIFO up to 64 bytes with ping-pong mode.

Where ping-pong mode means double buffer feature.

REFACTOR: Tapping/Dual role key

Dual role key discussion

http://geekhack.org/index.php?topic=41685.0

current implementation

action_tapping.c:
https://github.com/tmk/tmk_keyboard/blob/master/common/action_tapping.c
Doc:
https://github.com/tmk/tmk_keyboard/blob/master/doc/keymap.md#4-tapping

problems

• rearrage tapping rules
• buffer queuing

research other implementations

*xcapeX11

• lydell's dualAHK
• BigCtrlAHK
• Space 2 ControlX11
• At home modifierX11
• KeyRemap4MacBookMac

improper debouncing code causes key stuck

Key release event is missed when flipping a key very quickly. You will suffer random key stuck occasionally.

This problem will affect most of keyboard projects except for hhkb.
macway, hbkb and gh60 were fixed at commit 2795b7a. See this commit if you suffer from this problem.

hhkb: not affected
macway: fixed
hbkb: fixed
gh60: fixed
IIgs: TO BE FIXED
hib_liber: fixed(681e019)
phantom: fixed(a505daf)
mm60: TO BE FIXED

IDEA: remap and configure with Mass storage

Just an idea.

To change setting user can replace(or edit) the file and can also copy it for backup.

Controller serves a binary file with Mass storage(human readable ASCII if possible) which contains keymap and configure setting. Contoller keep those settings actually in flash or eeprom. No external component for memory like SD card.

User can edit the file with keymap configurator(web/native application) and just place the result file into keyboard folder with OS standard way. (If the file is ASCII user can use favorite text editor.)

https://github.com/abcminiuser/lufa/tree/master/Demos/Device/ClassDriver/MassStorage
https://github.com/abcminiuser/lufa/tree/master/Bootloaders/MassStorage
http://elasticsheep.com/2010/04/teensy2-usb-mass-storage-with-an-sd-card/

To program flash memroy from firmware I think we should call functions of Atmel DFU bootloader in bootloader section. This will not work for Teensy.

http://blog.komar.be/using-atmels-dfu-bootloader-abi-on-atmega32u4-in-avr-gcc/

Note

• This depends completely on AVR chip and its bootloader. Not portable to ARM or PIC.
• Fancy GUI/Web app is needed.

Dual USB/iWRAP output

I'm just digging into the code, so maybe this is already available, but I want to make a controller that can function as an iWRAP device, but will switch over to LUFA (or PJRC) USB when connected. I have an ATmega32u4 and a WT-12 breakout. The TMK keyboard firmware seems to have many great features (not least of which is a developer community). If this isn't something already possible, I will look into adding it.

Additionally, I was curious if it is easy to add an external device as a mouse (I have a digital I2C joystick I want to use). Perhaps this is better suited for a separate issue.

German layout Apple Extended Keyboard II M3501 ^ key not working

I have recently build the adapter and it works well so far. What i noticed is that pressing the ^ key (left from the "1" key) is not being registered by the system. Tried both on a Macbook and my Windows 7 machine.
I booted up my old Centris 650 to confirm this is not a hardware issue with the keyboard. The key is working fine there.

Using a Teensy 2.0 with latest revision of adb_usb cf1eb8f
All other keys seem to work without issues.

Please clarify hhkb.txt statements

I would like to try this project out with a Teensy++ for an hhkb2 that isn't functioning, but I'm not sure what this line means:

"This is just a proof of concept for replacing controller of HHKB, not a complete firmware."

What does "not a complete firmware" mean? Will the code work? Is it usable?

Thanks!

Layer switcing delay time

LAYER_ENTER_DELAY in layer.c defines delay time(ms) before layer switching.
'Non dedicated layer switch key' need this delay to register its key as normal key does.
'Dedicated layer switch key' needs no delay, but it still is caused with bug.

ADB German Keyboard layout ^ and < reversed (Windows)

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.

prog_char removed from avr-libc 1.8

Hi
I'm building the firmware on Mac OS X using the toolschain provided by CrossPack.
After the latest merge cbb9c40 I can no longer build.

I get the following error when building the Phantom project.

Compiling C: keymap.c
avr-gcc -c -mmcu=atmega32u4 -gdwarf-2 -DF_CPU=16000000UL -DBOOTLOADER_SIZE=512 -DF_USB=16000000UL -DARCH=ARCH_AVR8 -D USB_DEVICE_ONLY -D USE_FLASH_DESCRIPTORS -D USE_STATIC_OPTIONS="(USB_DEVICE_OPT_FULLSPEED | USB_OPT_REG_ENABLED | USB_OPT_AUTO_PLL)" -DPROTOCOL_LUFA -DBOOTMAGIC_ENABLE -DEXTRAKEY_ENABLE -DCONSOLE_ENABLE -DCOMMAND_ENABLE -Os -funsigned-char -funsigned-bitfields -ffunction-sections -fno-inline-small-functions -fpack-struct -fshort-enums -fno-strict-aliasing -Wall -Wstrict-prototypes -Wa,-adhlns=obj_phantom_lufa/keymap.lst -I. -I../.. -I../../protocol/lufa -I../../protocol/lufa/LUFA-120730 -I../../common -std=gnu99 -include config.h -MMD -MP -MF .dep/obj_phantom_lufa_keymap.o.d  keymap.c -o obj_phantom_lufa/keymap.o 
In file included from ../../common/print.h:31:0,
                 from ../../common/debug.h:21,
                 from keymap.c:29:
../../common/xprintf.h:26:1: error: unknown type name 'prog_char'
../../common/xprintf.h:54:1: error: unknown type name 'prog_char'
../../common/xprintf.h:55:1: error: unknown type name 'prog_char'
../../common/xprintf.h:56:1: error: unknown type name 'prog_char'
make: *** [obj_phantom_lufa/keymap.o] Error 1

After a little searching I found this page http://www.tuxgraphics.org/electronics/201207/prog_char.shtml
It states that prog_char was removed in avr-libc 1.8.
And CrossPack does indeed use avr-libc 1.8 since version 2012-02-17

Incoherent behaviour with two M0110s and a M0110A

I've got three early Mac keyboards here. As title states, two M0110 (plain vanilla Mac) and one M0110A (Mac Plus).
The problem is, apart from the M0110A not working properly, which is to be expected, that one of the 0110s and specifically the (sort of) newer one works perfectly, while the second, older, one is exhibiting delays, i.e. keypresses arrive slowly. The 0110A is even worse in that respect. I'm using plain vanilla code with Teensy 2.0.
Let me explain in greater detail.
Using HID_listen, I tried to analyse the behaviour of each of the keyboards.
M0110 new:

• upon connection of the keyboard (I mean the "phone" jack, not teensy USB), no errors
• upon disconnection of the keyboard, no errors again
• keys get transferred almost instantaneously (as they should)

M0110 old:

• upon connection of the keyboard, there's a series of errors, usually a series of send error 03 immediately followed by receive error 04; rarely, receive error 02
• upon disconnection, same thing: 03 04 03 04 03 04 03 04 and sometimes 02
• keys lag registering both key press and release; lag for each is around 0.4 second +/- 0.25sec
• randomly, there's a "received data FF" between key events
• rarely, a key release will not register, causing the system to think a key is pressed down

M0110A:

• upon connection of the keyboard, there's a series of errors, usually a series of send error 03 immediately followed by receive error 04; rarely, receive error 02
• upon disconnection, same thing: 03 04 03 04 03 04 03 04 and sometimes 02
• keys lag registering both key press and release; lag is around 0.9 second +/- 0.5sec (for each event; i.e. press and release usually last for more than 1.5secs)

I have to add that the M0110A keyboard has been thoroughly cleaned (after first connecting it and seeing the huge lag), all keys have been checked with a continuity metre and are working perfectly (and switch instantly), all lines from the keyboard microcontroller have been checked and double-checked for shorts and there's no problem there either.
On the other hand, the working M0110 hasn't been cleaned nor checked in any way, apart from replacing a couple of keys, and it was working perfectly even before that (well, apart from the aforementioned couple of problematic keys).
The cables all work perfectly. Yes, I checked them.

I'm wondering whether it's a problem with the timings, but from what I can see, all data 'events' in the code are not reliant on timing, timing is there just as a time-out, not a latch trigger.
I was also wondering whether it could be a problem with the matrix overloading, but again, I can't see the connection in the code.
I'll try to relax the timings and see if that helps any. In the meantime, please, don't hesitate to offer advice!
Thanks!

Mechanical Locking switch support for ScrollLock and NumLock

At this time CapsLock is only supported but it is possible to support ScrollLock and NumLock too.
https://github.com/tmk/tmk_keyboard#mechanical-locking-support-for-capslock

http://geekhack.org/index.php?topic=26742.msg956043#msg956043

IDEA: CDC for debug console

Use CDC instead of HID(derived from PJRC teensy code). User can more common app for console like hyperterminal, teraterm or minicom instead of PJRC hid_listen.

https://github.com/abcminiuser/lufa/tree/master/Demos/Device/ClassDriver/VirtualSerial
https://github.com/abcminiuser/lufa/tree/master/Bootloaders/CDC

Note

• In Windows driver setting is needed with INF file. No need on Mac and Linux.

Mechanical push-lock switch support for CapsLock

This feature is supported only on ADB converter now but it looks like all keyboard and converter can have this push-lock switch support. And maybe it is valid on NumLock and ScrollLock too.

By seeing state of LED(key state on OS) it will be able to prevent out-of sync between lock switch and OS.

Tapping overflow

Overflow of tap_count causes layer stucking bug.

tap_count variable is defined in acthio.h:
(keyrecord_t).(tap_t).count can be ranged only 4 bit width(0-15).
When it counts layer key tappings up to 15 and overlows unexpected layer switching causes.

---- action_exec: start -----
EVENT: 0307u(20031)
Tapping: Tap release(15)
ACTION: ACT_LAYER_TAP[5:2C] layer_state: 00000000(0) default_layer_state: 00000000(0)
KEYMAP_TAP_KEY: Tap: unregister_code
TAPPING_KEY=0307u(20031):15
processed: 0307u(20031):15


---- action_exec: start -----
EVENT: 0307d(20093)
Tapping: Tap press(0)
ACTION: ACT_LAYER_TAP[5:2C] layer_state: 00000000(0) default_layer_state: 00000000(0)
KEYMAP_TAP_KEY: No tap: On on press
layer_state: 00000000(0) to 00000020(5)
TAPPING_KEY=0307d(20093):0
processed: 0307d(20093):0


---- action_exec: start -----
EVENT: 0307u(20199)
Tapping: First tap(0->1).
TAPPING_KEY=0307d(20093):1
ACTION: ACT_LAYER_TAP[5:2C] layer_state: 00000020(5) default_layer_state: 00000000(0)
KEYMAP_TAP_KEY: Tap: register_code
waiting_buffer_enq: { [1]=0307u(20199):1  }
---- action_exec: process waiting_buffer -----
Tapping: Tap release(1)
ACTION: ACT_LAYER_TAP[5:2C] layer_state: 00000020(5) default_layer_state: 00000000(0)
KEYMAP_TAP_KEY: Tap: unregister_code
TAPPING_KEY=0307u(20199):1
processed: waiting_buffer[1] = 0307u(20199):1



---- action_exec: start -----
EVENT: 0307d(20271)
Tapping: Tap press(2)
ACTION: ACT_LAYER_TAP[5:2C] layer_state: 00000020(5) default_layer_state: 00000000(0)
KEYMAP_TAP_KEY: Tap: register_code
TAPPING_KEY=0307d(20271):2
processed: 0307d(20271):2

Bootloader jump doesn't work

Occasionally bootloader jump doesn't work and it seems to run away until replug and restart it. The more often it fails to jump the larger firmware get compiled in size.

Function pointer call to bootloader is compiled into 'icall' AVR instruction requires word address. It has used byte address while it should use word address :(

This means it jumps to non-existent address, executes random data and goes mad.
If destinaton of jump has NOP instructions it may reach the region of bootloader luckily, I guess. I'm not sure why this code works in many case.

Fixed at this commit 0ca4150.

common/bootloader.c

-        ((void (*)(void))BOOTLOADER_START)();
+        // This is compled into 'icall', address should be in word unit, not byte.
+        ((void (*)(void))(BOOTLOADER_START/2))();

For reference,

This jump code is based on LUFA document.
http://www.fourwalledcubicle.com/files/LUFA/Doc/130901/html/_page__software_bootloader_start.html

PJRC also has a document on this topic. PJRC use inline assembly to jump.
http://www.pjrc.com/teensy/jump_to_bootloader.html

Just memo for myself...

GCC inline assembly requires byte address in mnemonic string but word address operands. Interesting and confusing. And function pointer should has world address in C.
I'm not sure about AVR architecture, don't believe me.

Extended keycodes

I modified keycodes from byte to 2 bytes to adopt general/consumer/system pages.
With this there is no need so many "if ~~ else if ~~~ ".

With this method, key extension could be easily.

Have a look my branch.

Repetition when Pressing Function Keys

If you use Fast "Key Repeat" and Short "Delay Until Repeat" like in this image:

You will randomly get repetitions for letters and backspaces, to reproduce try the following;

1. Press any letter OR backspace and immediately press FN.
2. See it repeat several times.

Example of what you should expect to see:

aaaaa
ssss
eeee
rrrrr
tttt
yyyyyy
uuuuuu
pppppp

Version identify

It is useful version command displays firmware idetity like:

• firmware version
• compile time
• keyboard/converter type
• VID:PID of USB
• git commit hash
• target controller

RGUI instead of RALT

I might be doing something terribly wrong here but inspecting xev I keep getting RGUI instead of RALT (as configured in the keymap file).

I'm sure I didn't swap rgui/ralt. This happened with every teensy2 I tried (3 so far).

Compiled version is GH60 plain lufa.

Shift(Modifiers) + Tap key doesn't produce shifted key

Commit 4d0b3aa made this bug. See #60 (comment)

This sequence should be handled as Shift+; then produce :, but in fact ';' due to the bug. The above commit processes release of Shift immediately and fails to buffer the event during tapping.

Shift  ~~~~_____~~~~~~~~~~                    
;(tap) ~~~~~~~_______~~~~~                    
             |-----------|  TAPPING_TERM

where ; is actually ACTION_LAYER_TAP_KEY(3, KC_SCLN).

About ATMEG32u4 master chip PF pin after setting the program error problem ?

In tmk_keyboard/keyboard/gh60/matrix.c , you will master chip PF pin is set low, the key matrix col8 no response , col9 button garbled .

USB -> PS/2 converter support

I was wondering about the feasibility of implementing support for a USB to PS/2 converter for this firmware, I'm not even sure it's possible with hardware like the Teensy or not. Basically you detect whether the Teensy USB cable is connected to USB or PS/2, and then use it as such. I found a technical description of how to achieve this in section 1.5 of this PDF:

https://www.moparisthebest.com/downloads/DRM014.pdf

This should allow this firmware to act as a USB or PS/2 keyboard, automatically adding support for all of the other sub-projects included in this repository, including ADB to PS/2, PS/2 to PS/2 (great for the layout switching and extra features), and all the other ones. It is needed to support older computers that don't support USB, or even somewhat newer ones that don't support USB keyboards in the BIOS or older operating systems (commonly called USB Legacy support).

Do you think this could be done with a teensy board? If so, would you be interested in doing it? Thanks much.

Anti Ghost code NOT working

keyboard/macway/matrix.c has a ghost detect code but not used now.

inline declarations in matrix.c aren't being used

Most of the keyboard/*/matrix.c files declare functions like this:

inline
bool matrix_is_on(uint8_t row, uint8_t col)
{
    return (matrix[row] & (1<<col));
}

but the header file matrix.h declares the function as:

bool matrix_is_on(uint8_t row, uint8_t col)

So there is no inline'ing happening anywhere. It might inline in matrix.c but maybe only for code after the function code.

I suggest removing these inline statements as they are misleading since it isn't really inline'ing anything. FYI - I did quick test with putting the code in the matrix.h header to it will inline properly and it makes almost no difference in the speed at which matrix_scan() is called (1% faster).

For a full discussion on inline strategies, see: http://www.greenend.org.uk/rjk/tech/inline.html

LUFA_PATH in protocol/lufa.mk is hardcoded

LUFA_PATH in protocol/lufa.mk should be overridden with its value in Makefile.

It's not possible to get momentary switch to layer lower than current.

It's not possible to get momentary switch to layer lower than current.

Following explanation is based on my own fork, specifically on file https://github.com/cub-uanic/tmk_keyboard/blob/cub_layout/keyboard/ergodox/keymap_cub.h

For example, when I'm hold FN6 or tap FN2, and layer 2 is active, then tap on FN1 does nothing, but FN3 and FN4 does momentary layer switch as expected.
Or other example: when I hold FN3 and layer 3 is active, then FN6 and FN1 does not work, but FN4 does momentary layer switch as expected and FN6 does layer switch as well.

I think this is bug in TMK itself, somewhere around momentary switching, and it's triggered only when layer number used in ACTION_LAYER_MOMENTARY macro is less than currently active layer. Macro ACTION_LAYER_SET works as expected (see 'other example' about working FN6).

Also, see forum discussion here: http://geekhack.org/index.php?topic=48106.msg1042480#msg1042480

GH60 PCB RevB or later support

tmk GH60 doesn't support RevB or later atm, I'll fix code when I receive final revision of PCB in hand.

1. RevB has changed pin usage of col9(8,I,K,M. col8 in tmk) PB0 to PB7.
   http://geekhack.org/index.php?topic=37570.msg1040414#msg1040414
2. And RevB schematic has pins(PF4-7) for support for LEDs, apparently.

MEMO: To use PF4-7 you should stop JTAG function at intialization. (See datasheet for JTD bit)

raspberry pi problem

Hi guys.

I bough a raspberry pi model b for testing then connected my key64 keyboard to it and a series of weird problems appeared like lost keys or repeated keys, here is a post from someone who experienced the same behaviour:

http://devswap.com/blog/raspberry-pi-repeating-keystrokes-when-typing

It seems raspberry pi doesn't supply enought power to usb ports, in this case (haven't tested it yet) i have to put a usb hub powered device in order to connect a key64 keyboard, i interchange the keyboard with another cherry mx keyboard i have laying around and this one worked fine, so the question is:

Can i change the power needed at the firmware level? in fact the teensy clock is so much faster for a keyboard, probably we can reduce that Mhz and it will reduce power requirements ?

Thanks.

Possible configuration issue when unselecting rows for the macway

I'm quite new to embedded electronics, so I'm not sure about this... but this line:

https://github.com/tmk/tmk_keyboard/blob/master/keyboard/macway/matrix.c#L220

Should it read like this:

DDRC  &= ~0b01000000;
PORTC &= ~0b01000000;

As you're otherwise configuring PC6 as an output pin, then setting PC6 to high, as well as setting PC7 as a pullup resistor, aren't you?

I don't think it should affect anything, as PC7 isn't used for anything, but as I said, I'm quite new to this, and not sure if this is the intended behaviour.

Fixed: ADB-USB converter misses keystrokes

2013/11/15

The problem is very complicated and comprised of various possible causes.

missing ADB singnal with interrupts by USB

During handle ADB signal the code have to be guraded from USB or other interrupts with cli(). Both receive and send signal codes needs this gurad in adb.c.
http://geekhack.org/index.php?topic=14290.msg1118206#msg1118206

mis-handle of two key events in an ADB transaction

Both of down and up event of a key can be sent with same one 16-bit ADB packet.

• http://geekhack.org/index.php?topic=14290.msg1114073#msg1114073

preventing keyboard from scaning matrix with high rate of ADB polling

If converter polls too frequently keyboard has to consume lots of controller cycles to respond to the requests and could miss change of key switch in the result. Older keyboard tends to suffer from this severely. 12ms is proper interval.
http://geekhack.org/index.php?topic=14290.msg1118206#msg1118206

Original description

This was not accurate at all:

At commit:38effe4ae4a691dcf034c31f67d1bdb2156ba7f5 the converter has this problem,
while old commit:33d58c2b5647623d2b07a210ef97a27920e5563e doesn't have it.

Incorporating i2c devices

Hi Hasu, i would like to hear your comments about the idea of connecting an i2c device to the teensy board in order to transmit keyboard data, honestly i don't know how they work, i am still in the research stage, but thinking in an improved version of the key64 keyboard and since an i2c is so cheap, another way to connect the two halves of the key64 could be using an i2c chip borrowing the same idea from the ergodox keyboard, off course i would like to be sure everything will stay working as for now, as the teensy feature a twi interface http://www.avrbeginners.net/architecture/twi/twi.html it seems just a matter of adding and i2c chipset like the MCP23018-E/SP, so do you have experience with them ? what do you think about that approach ?

About layer change

Hi.

Because I'm not good at firmware, I couldn't understand the way of changing layer.
Could you explain briefly? for example in HHKB, some key combinations could change layer (Fn? + / or ; etc..)

Remote Wakeup behaviour

To wakeup from sleep mode of PC you must use LShift+RShift+PrintScreen command at this time.
This is not behavior of keyboard most of users expected. Wakeup with any key will be more natural way.

This is suggest from yeeeargh@deskthority. Thanks.

--- common/keyboard.c   2012-11-24 21:35:47.121551900 +0900
+++ /home/noname/Downloads/keyboard.c   2012-11-24 21:39:41.294945900 +0900
@@ -45,7 +45,8 @@
     MOD_DOWN, MOD_UP,
 } keykind_t;

-typedef enum { IDLE, DELAYING, WAITING, PRESSING } kbdstate_t;
+/* added STANDBY for waking up */
+typedef enum { IDLE, DELAYING, WAITING, PRESSING, STANDBY } kbdstate_t;


 #ifdef KEYMAP_DEFAULT_LAYER
@@ -69,6 +70,7 @@
     if (state == DELAYING)  return PSTR("DELAYING");
     if (state == WAITING)   return PSTR("WAITING");
     if (state == PRESSING)  return PSTR("PRESSING");
+    if (state == STANDBY)   return PSTR("STANDBY");
     return PSTR("UNKNOWN");
 }

@@ -353,6 +355,13 @@
     Kdebug(" code: "); Kdebug_hex(code);
     if (event.pressed) { Kdebug("d"); } else { Kdebug("u"); }
     Kdebug("\n");
+
+       /* check if keyboard is in standby. Set the state accordingly */
+#ifdef HOST_PJRC
+       if (suspend && remote_wakeup) {
+               NEXT(STANDBY);
+    }
+#endif

     switch (kbdstate) {
         case IDLE:
@@ -539,6 +548,10 @@
                     break;
             }
             break;
+        case STANDBY:
+            usb_remote_wakeup();
+            NEXT(IDLE);
+            break;
     }
 }

Shift stuck on ACTION_MODS_KEY(MOD_LSFT, KC_4)

I didn't confirm this bug myself yet, I'll do later. But I can come up with the clue.

• He can access the 'LShift+4' with using layer switching with ACTION_LAYER_MOMENTARY.
• On fast type, layer switching key tends to be released before the 'LShift+4' is released.

http://geekhack.org/index.php?topic=48106.msg1051898#msg1051898

BootMagic configured accidentally

If press some keys down accidentally during pluging cable into USB port, keymap change can be configured unintentionally. Like issue #39.
I have a plan to use key combination instead of just one key to avoid this unintentional configure.

WORK AROUND:

• Disable BootMagic in Makefile configuration sction
• Clear EEPROM if your keymap is mangled without intention
  You can clear EEPROM with BootMagic(Backspace).

These keys change keymap:
Swap Control and CapsLock(Left Control)
Change CapsLock to Control(Casp Lock)
Swap LeftAlt and Gui(Left Alt)
Swap RightAlt and Gui(Right Alt)
Disable Gui(Left Gui)
Swap Grave and Escape(Grave)
Swap BackSlash and BackSpace(Back Slash)
Default Layer change(0-7)

Tapping Tweaks: "bob" case in Double Tap Repeating

This problem is explained well in lydell's write up.
"bob" case in "DoublePress" https://github.com/lydell/dual#configuration
[QUOTE]
If you type "bob" really quickly, and "b" is a dual-role key, and you keep holding "b" the last time, "b" will actually start to repeat, even though another key was pressed in-between the two "b" presses. That's not really a double press, right?
[/QUOTE]

It should be cancel repeating if double tap is interrupted with other key.

multimedia/internet key support

As you can see, I've forked your excellent project and made a few changes to make it better suit me. But I've been trying to add support for keys such as play/pause, stop, next track, previous track, and internet keys like stop, home, back, forward etc. The keycodes are defined fairly well here:
http://msdn.microsoft.com/en-us/windows/hardware/gg463372
At the bottom is a link to the pdf where they are spelled out:
http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf

I have both a USB and PS/2 keyboard with these type of keys, which work fine when hooked up directly (with Linux, but that shouldn't matter), but with the circuit with this code hooked up, nothing gets passed through and I can't for the life of me figure it out. I don't know if you want to support this or not, but, if not, hopefully you can give me some pointers/ideas.

Thanks for the great code and all the work you do.
Travis

Power consumption

tmk firmware for gh60 consumes 25.8mA while stock Poker only 5.6mA!
Better power saving sterategy is needed.

1. Power Management and Sleep Modes from datasheet:
2. Sleep mode power down using watchdog interrupt(interval: 15ms, 60ms,...)
3. Power reduction register configuration

And sleep breathing LED is greedy like 17-30mA :( Of course this does not comply with USB spec... This feature should be disable by default and fun purpose only.

Testing GH60 firmware without PCB

Hi,
I am trying to make NKRO keyboard. It uses keyboard matrix with soldered wires instead of PCB board (as in the project http://blog.fsck.com/2013/04/index.html). I want to use or to modify the gh60 firmware for my needs. Is it possible to test the firmware with only one key? I am not sure that I will connect right all the wires of my matrix form the first time. I would like to minimize the errors. So I would like to know if the software works fine before I make the hardware part. It seems that the firmware scans for the matrix, but I am not sure if it will works with only one key connected to atmel AVR board (arduino micro in my case).