Skip to content
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

Fails with Caps-Lock=On or Key-Layout=LT #1

Open
sskras opened this issue Jul 16, 2020 · 4 comments
Open

Fails with Caps-Lock=On or Key-Layout=LT #1

sskras opened this issue Jul 16, 2020 · 4 comments

Comments

@sskras
Copy link

sskras commented Jul 16, 2020

Trouble generating correct input with Caps Lock=On:
image

Or when the current keyboard layout uses numeric keys for different symbols:

image

@sskras
Copy link
Author

sskras commented Jul 16, 2020

Is this the actual lines present in the Firmware I got with the device?

      Keyboard.print(":q!");
      delay(1);
      Keyboard.send_now();

I ask because 5 lines above exhibits sending a key/scan code KEY_ESC:

      Keyboard.set_key1(KEY_ESC);
      Keyboard.send_now();

... which is different from the Keyboard.print() which seems to be designed to send logical symbols instead of physical key/scan-codes.

As we get wrong symbols in our case, I am lost about what Keyboard.print() actually does.

@ABLomas
Copy link
Owner

ABLomas commented Jul 16, 2020

Problem with caps lock could probably be solved by changing line
Keyboard.print(":q!");
into

  Keyboard.print(":");  
  Keyboard.press(KEY_Q);
  Keyboard.release(KEY_Q);
  Keyboard.set_modifier(MODIFIERKEY_ALT);
  Keyboard.send_now();
  Keyboard.set_key1(KEYPAD_3);
  Keyboard.send_now();
  Keyboard.set_key1(0);
  Keyboard.send_now();
  Keyboard.set_key1(KEYPAD_3);
  Keyboard.send_now();
  Keyboard.set_key1(0);
  Keyboard.send_now();

(in other words - sending "literal symbol q" and after typing alt + 33, which is exclamation mark - i'm not sure that alt+code combo will work on exotic systems)
I do not have spare teensy2 anymore, only teensy3 around so need to re-work trigger code a bit to test...

@sskras
Copy link
Author

sskras commented Jul 21, 2020

If keyboard can sending key/scan codes only (as you imply), then I think you've got it vice-versa:

  • char generated by pressing KEY_Q will depending on the Caps state.
    (So you should send the KEYPAD escape sequence for it too)
  • char generated by pressing KEY_1 with MODIFIERKEY_SHIFT set will depend on the current keyboard driver map.
    (which you snippet tries to handle already)

AFAICS, your workaround should apply not only to the 2nd case, but to the 1st one too.

@sskras
Copy link
Author

sskras commented Jul 21, 2020

On the side note, can you tell whether this:

  Keyboard.press(KEY_Q);
  Keyboard.release(KEY_Q);

... would be different to this?

  Keyboard.set_key1(KEY_Q);
  Keyboard.send_now();
  Keyboard.set_key1(0);
  Keyboard.send_now();

IOW, why do you use the Keyboard.press() for pressing KEY_Q but not for KEYPAD_3 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants