3 Commits

Author SHA1 Message Date
bb09cd8d9a Discard MSC_SCAN events
Given that only EV_KEY events are being mapped, without their scancode
counterparts, we just drop all scancode events to avoid having to map
them too, to syncing it with the corresponding mapped keys. This is
expected to be harmless.
2017-12-04 02:54:55 -02:00
0d88388a9e Add note about Ubuntu/Debian installation 2017-11-30 13:46:42 -02:00
9f353f96c6 Another evdev protocol infringement
Even though Peter Hutterer commented that it's not technically needed to
send SYN/delay when the sequence of events is of different keys, it
seems to be shown necessary to do so, otherwise events are dropped in
random situations.
2017-11-30 01:58:02 -02:00
2 changed files with 11 additions and 0 deletions

View File

@ -56,6 +56,12 @@ I'm maintaining an Archlinux package on AUR:
- <https://aur.archlinux.org/packages/interception-caps2esc> - <https://aur.archlinux.org/packages/interception-caps2esc>
I don't use Ubuntu and recommend Archlinux instead, as it provides the AUR, so I
don't maintain PPAs. For more information on Ubuntu/Debian installation check
this:
- <https://askubuntu.com/questions/979359/how-do-i-install-caps2esc>
## Caveats ## Caveats
As always, there's always a caveat: As always, there's always a caveat:

View File

@ -39,6 +39,9 @@ int main(void) {
setbuf(stdin, NULL), setbuf(stdout, NULL); setbuf(stdin, NULL), setbuf(stdout, NULL);
while (read_event(&input)) { while (read_event(&input)) {
if (input.type == EV_MSC && input.code == MSC_SCAN)
continue;
if (input.type != EV_KEY) { if (input.type != EV_KEY) {
write_event(&input); write_event(&input);
continue; continue;
@ -66,6 +69,8 @@ int main(void) {
if (!esc_give_up && input.value) { if (!esc_give_up && input.value) {
esc_give_up = 1; esc_give_up = 1;
write_event(&ctrl_down); write_event(&ctrl_down);
write_event(&syn);
usleep(20000);
} }
} else if (equal(&input, &capslock_down)) { } else if (equal(&input, &capslock_down)) {
capslock_is_down = 1; capslock_is_down = 1;