Keyboard.h and mouse.h

Projects Programming
1

Hello

I was trying to write a program that emulates mouse and keyboard using an arduino Leonardo.

If I only use #include Keyboard.h it works and it types what I want.

But when I also #include mouse.h it goes wrong. It seems there are some capitals that won't print anymore.

I've included a screenshot once without the mouse library included and once with the mouse library included.

Is there anyone who has an idea what the problem is?

I've tried to type the capitals by using Keyboard.press(KEY_LEFT_SHIFT) but that gives the same results.

Screenshot 2019-12-12 at 20.34.55.png

2

Your (useless) picture of.... text

Screenshot 2019-12-12 at 20.34.55.png

Share your codes

3

This my code currently.

As you can see I'm just trying to output all characters if I comment the line #include mouse.h everything works as expected. If I uncomment this line I get the wrong characters.

// Keyboard - Version: Latest
#include <Keyboard.h>
// Mouse - Version: Latest
#include <Mouse.h>

/*

*/

int LED = 7;
int BUTTON = 2;

// Special characters definition
#define KEY_LEFT_CTRL  0x80
#define KEY_LEFT_SHIFT 0x81
#define KEY_LEFT_ALT   0x82
#define KEY_RIGHT_CTRL 0x84
#define KEY_RIGHT_SHIFT    0x85
#define KEY_RIGHT_ALT  0x86
#define KEY_UP_ARROW   0xDA
#define KEY_DOWN_ARROW 0xD9
#define KEY_LEFT_ARROW 0xD8
#define KEY_RIGHT_ARROW    0xD7
#define KEY_BACKSPACE  0xB2
#define KEY_TAB        0xB3
#define KEY_ENTER 0xB0
#define KEY_ESC        0xB1
#define KEY_CAPS_LOCK  0xC1
#define KEY_d 0x64
#define KEY_e 0x65
#define KEY_SPACE 0x20

#define wait 250

void setup() {
  pinMode(LED, OUTPUT);
  pinMode(BUTTON, INPUT);
  Keyboard.begin();
  // Mouse.begin();
  Serial.begin(9600);
}

void repeat_key(byte key, int num, int slow = 1) {
  for (int i = 0; i < num; i++) {
    Keyboard.write(key);
    delay(wait * slow);
  }

}

void deselect () {
  for (int i = 0; i < 5; i++) {
    Mouse.move(-127, -127);
  }
  Mouse.click();
}

void loop() {
  if (digitalRead(BUTTON) == HIGH) {
    digitalWrite(LED, HIGH);
    for (int i = 32; i < 126; i++) {
      Keyboard.write(i);
      delay(100);
    }
  }
  else {
    digitalWrite(LED, LOW);
  }
  delay(100);
}
4

what happens if you use this:

#include <Keyboard.h>
#include <Mouse.h>
const byte LEDPIN = 7;
const byte BUTTONPIN = 2;

void setup() 
{
  pinMode(LEDPIN, OUTPUT);
  pinMode(BUTTONPIN, INPUT);
  Keyboard.begin();
  Mouse.begin();
}

void loop() {
  if (digitalRead(BUTTONPIN) == HIGH)
  {
    digitalWrite(LEDPIN, HIGH);
    for (char c = ' '; c < '~'; c++) {
      Keyboard.write(c);
      delay(20);
    }
  }
  else {
    digitalWrite(LEDPIN, LOW);
    delay(100);
  }
}

Please correct your post above and add code tags around your code:
[code]`` [color=blue]// your code is here[/color] ``[/code].

It should look like this:// your code is here
(Also press ctrl-T (PC) or cmd-T (Mac) in the IDE before copying to indent your code properly)

5

Thanks for your reply. I've adjusted my post above.

I tried the adjustment you suggested, but it still gives the same result.

6

what do you see?
what happens if you comment out #include <Mouse.h>

do you have something else open on that USB line?

7

I see the same things as posted in my first post. With the line commented out I get the right result. With the lne included I get the same "wrong" result.

There is nothing else open on that USB line.

8

Ok I tried some different things and it seems the problem is not with the libraries.
It's in the computer: when I test it with a Windows laptop everything works just fine, but on my chromebook (where I want to use this sketch) it gives this strange behaviour.

I will keep on looking for a solution, but it looks like this forum isn't the right place.

Thanks J-M-L for your advice, if you have a clue I would be glad to learn it if not I will be looking in other places.

9

One possible thing to try... I have heard of cases where a very short key press does not always get counted. I don't know why that might cause problems only with the shift modifier but you can try this:
Replace:   keyboard.write(value);
With

  keyboard.press(value);
  delay(10);
  keyboard.release(value);

If that makes it work, reduce the delay until the problem occurs again.

10

That trick doesn't work. But thanks for your answer.

After some more trying I think the problem lies with the buffer keyboard.h uses.

In this code the first character is always written with shift pressed, but then shift is released automatically on a chromebook.
On a windows laptop the output is as expected with shift always pressed.

// Keyboard - Version: 1.0.2
#include <Keyboard.h>

// Mouse - Version: 1.0.1
#include <Mouse.h>

// Special characters definition
#define KEY_LEFT_SHIFT 0x81
#define KEY_ENTER 0xB0

const byte LEDPIN = 7;
const byte BUTTONPIN = 2;

void setup()
{
  pinMode(LEDPIN, OUTPUT);
  pinMode(BUTTONPIN, INPUT);
  Keyboard.begin();
  // Mouse.begin();
}

void loop() {
  if (digitalRead(BUTTONPIN) == HIGH)
  {
    digitalWrite(LEDPIN, HIGH);
    for (char c = ' '; c <= '~'; c++) {
      Keyboard.press(KEY_LEFT_SHIFT);
      Keyboard.write(c);
      Keyboard.write(c);
      Keyboard.write(c);
      Keyboard.write(c);
      Keyboard.write(c);
      Keyboard.release(KEY_LEFT_SHIFT);
    }
  }
  else {
    digitalWrite(LEDPIN, LOW);
    delay(100);
  }
}

When I want to write a character with shift pressed I can use shift for every single character. I'm going to try and prgram around this problem. That should be feasible.

11

The .write() function does a .press() immediately followed by a .release(). The .press() function sets the shift flag in the USB report if the character should be shifted and the .release() function clears the shift flag in the USB report if the character was a shifted character. Since the shift flags and key codes arrive in the same message I don't see how the key can be properly interpreted as un-shifted. Looks like a software bug in the Chromebook.

12

I've ran into this exact issue while automating CrOS enrollment with the Leonardo chip.

I'm not sure I agree with the assessment that it's a software bug with CrOS. Removing Mouse.h immediately fixes the issue. Somewhere between Mouse.h and Keyboard.h is causing improper casing. As far as I know CrOS handles shift/caps lock the same as every OS. The only difference is Chromebooks do not include a CAPS LOCK key.

I'd say the bug is with the Keyboard.h and Mouse.h instead of the actual operating system. Is there a way to submit a report?

13

Here's the bug tracker for the Keyboard library:

you can submit a bug report there.

14

How does the Arduino USB infrastructure support composite devices, anyway?
Perhaps not in a way that ChromeOS likes?