tmk [Sat, 2 May 2020 06:46:16 +0000 (15:46 +0900)]
ibmpc_usb: Fix Code Set 2 for Z-150 SysRq
Zenith Z-150 AT sends scan code 0x7F for SysRq.
Accoding to i8042 translation table it maps both 0x7F and
0x84 into 0x54(Print Screen).
https://geekhack.org/index.php?topic=103648.msg2897404#msg2897404
GUI, Application, Henkan, Mehenkan, Kana used in PS/2 PC
keyboard when it is switched to Set 3
https://github.com/tmk/tmk_keyboard/wiki/IBM-PC-AT-Keyboard-Protocol#g80-3600-and-skidata2-de-in-code-set-3
Support for extra keys around cursor keys
https://deskthority.net/wiki/Cherry_G80-2551
https://geekhack.org/index.php?topic=103648.msg2893404#msg2893404
https://gist.github.com/tmk/22cb8680ca8ef854630ecd1953268c5b
Purdea Andrei [Wed, 1 Apr 2020 04:46:18 +0000 (07:46 +0300)]
tmk_core/common/timer.h: Improve code generation for TIMER_DIFF* macros
Because of integer promotion the compiler is having a hard time generating
efficient code to calculate TIMER_DIFF* macros in some situations.
In the below example, the return value is "int", and this is causing the
trouble.
00004c40 <test>:
4c40: 86 1b sub r24, r22
4c42: 90 e0 ldi r25, 0x00 ; 0
4c44: 08 95 ret
Note: the example is showing -Os but improvements can be seen at all optimization levels,
including -O0. We never use -O0, but I tested it to make sure that no extra code is
generated in that case.
Purdea Andrei [Wed, 1 Apr 2020 04:44:00 +0000 (07:44 +0300)]
tmk_core/common/timer.h: Fixing TIMER_DIFF macro to calculate difference correctly after the timer wraps.
Let's go through an example, using the following macro:
If the first timer read is 0xe4 and the second one is 0x32, the timer wrapped.
If the timer would have had more bits, it's new value would have been 0x132,
and the correct difference in time is 0x132 - 0xe4 = 0x4e
old code TIMER_DIFF_8(0x32, 0xe4) = 0xff - 0xe4 + 0x32 = 0x4d, which is wrong.
new code TIMER_DIFF_8(0x32, 0xe4) = 0xff + 1 - 0xe4 + 0x32 = 0x4e, which is correct.
This also gives a chance for a smart compiler to optimize the code using normal
integer overflow.
For example on AVR, the following C code:
uint8_t __attribute__ ((noinline)) test(uint8_t current_timer, uint8_t start_timer)
{
return TIMER_DIFF_8(current_timer, start_timer);
}
With the original code, it gets translated to the following list of instructions: 00004c6e <test>:
4c6e: 98 2f mov r25, r24
4c70: 86 1b sub r24, r22
4c72: 96 17 cp r25, r22
4c74: 08 f4 brcc .+2 ; 0x4c78 <test+0xa>
4c76: 81 50 subi r24, 0x01 ; 1
4c78: 08 95 ret
But with this commit, it gets translated to a single instruction: 00004c40 <test>:
4c40: 86 1b sub r24, r22
4c42: 08 95 ret
This unfortunately doesn't always work so nicely, for example the following C code:
int __attribute__ ((noinline)) test(uint8_t current_timer, uint8_t start_timer)
{
return TIMER_DIFF_8(current_timer, start_timer);
}
(Note: return type changed to int)
With the original code it gets translated to: 00004c6e <test>:
4c6e: 28 2f mov r18, r24
4c70: 30 e0 ldi r19, 0x00 ; 0
4c72: 46 2f mov r20, r22
4c74: 50 e0 ldi r21, 0x00 ; 0
4c76: 86 17 cp r24, r22
4c78: 20 f0 brcs .+8 ; 0x4c82 <test+0x14>
4c7a: c9 01 movw r24, r18
4c7c: 84 1b sub r24, r20
4c7e: 95 0b sbc r25, r21
4c80: 08 95 ret
4c82: c9 01 movw r24, r18
4c84: 84 1b sub r24, r20
4c86: 95 0b sbc r25, r21
4c88: 81 50 subi r24, 0x01 ; 1
4c8a: 9f 4f sbci r25, 0xFF ; 255
4c8c: 08 95 ret
Wth this commit it gets translated to: 00004c40 <test>:
4c40: 28 2f mov r18, r24
4c42: 30 e0 ldi r19, 0x00 ; 0
4c44: 46 2f mov r20, r22
4c46: 50 e0 ldi r21, 0x00 ; 0
4c48: 86 17 cp r24, r22
4c4a: 20 f0 brcs .+8 ; 0x4c54 <test+0x14>
4c4c: c9 01 movw r24, r18
4c4e: 84 1b sub r24, r20
4c50: 95 0b sbc r25, r21
4c52: 08 95 ret
4c54: c9 01 movw r24, r18
4c56: 84 1b sub r24, r20
4c58: 95 0b sbc r25, r21
4c5a: 93 95 inc r25
4c5c: 08 95 ret
There is not much performance improvement in this case, however at least with this
commit it functions correctly.
Note: The following commit will improve compiler output for the latter example.
tmk [Wed, 12 Feb 2020 23:42:37 +0000 (08:42 +0900)]
adb_usb: Fix start up delay for AEK/AEKII
Without proper delay keyboard the converter starts talking too early
before keyboard wakes up. ISO recognition and enabling Extention protocol
would be failed in the result.
https://github.com/tmk/tmk_keyboard/issues/640#issuecomment-585411393
200ms is enough for AEKs but 1000ms is used here for safety.
tmk [Sat, 28 Dec 2019 13:39:54 +0000 (22:39 +0900)]
alps64: Fix for delay time for matrix scan
Delay less than 20us can cause false key detection in some situations.
With week internal pull-up takes time to charge stray capacitance of
trace between ground fill(and fingers), perhaps?
In particular, when testing Alps64 PCB without diodes tweezer is used
to close a key and this makes trace longer, more capacitance in result.
The bootkey set in bootloader_jump() works with Pro Micro and Leonardo.
This fix doesn't seem to prevent other bootloaders, however, it can be
disabled by defining NO_BOOTLOADER_CATERINA_BOOTKEY.
projects / max / tmk_keyboard.git / log