Media keys not working on OSX

Status
Not open for further replies.

Wraithan

Member
Code:
#include <Bounce.h>
#include <Encoder.h>

int rot_led = 9;
int rot_btn = 14;
int top_left_btn = 17;
int top_right_btn = 16;
int bot_btn = 15;
int enc_a = 20;
int enc_b = 19;
int enc_val = 0;
int enc_divider = 7;
int ms_delay = 1;
int debounce = 10;
bool led_on = false;
bool last = false;

Bounce btn1 = Bounce(rot_btn, debounce);
Bounce btn2 = Bounce(top_left_btn, debounce);
Bounce btn3 = Bounce(top_right_btn, debounce);
Bounce btn4 = Bounce(bot_btn, debounce);
Encoder enc = Encoder(enc_a, enc_b);

void setup() {                
  pinMode(rot_led, OUTPUT);
  pinMode(rot_btn, INPUT_PULLUP);
  pinMode(top_left_btn, INPUT_PULLUP);
  pinMode(top_right_btn, INPUT_PULLUP);
  pinMode(bot_btn, INPUT_PULLUP);
}

void send_key(uint8_t key, uint8_t modifier) {
  Serial.print(key);
  Serial.print(" ");
  Serial.println(modifier);
  Keyboard.set_key1(key);
  Keyboard.set_modifier(modifier);
  Keyboard.send_now();
  Keyboard.set_key1(0);
  Keyboard.set_modifier(0);
  Keyboard.send_now();
}

void send_media(uint8_t key) {
  Keyboard.set_media(key);
  Keyboard.send_now();
  Keyboard.set_media(0);
  Keyboard.send_now();
}

// the loop routine runs over and over again forever:
void loop() {
  btn1.update();
  btn2.update();
  btn3.update();
  btn4.update();
  enc_val = enc.read();
  if (enc_val/enc_divider > 0) {
    Serial.println("volume up");
    send_media(KEY_MEDIA_VOLUME_INC);
    enc.write(enc_val-enc_divider);
  } else if (enc_val/enc_divider < 0) {
    Serial.println("volume down");
    send_media(KEY_MEDIA_VOLUME_DEC);
    enc.write(enc_val+enc_divider);
  }
  
  if (led_on && led_on != last) {
    last = led_on;
    digitalWrite(rot_led, HIGH);
    Serial.println("on");
  } else if (led_on != last) {
    last = led_on;
    digitalWrite(rot_led, LOW);
    Serial.println("off");
  }

  if (btn1.fallingEdge()) {
    led_on = !led_on;
    send_media(KEY_MEDIA_MUTE);
  }

  if (btn2.fallingEdge()) {
    send_media(KEY_MEDIA_PREV_TRACK);
  }   

  if (btn3.fallingEdge()) {
    send_media(KEY_MEDIA_PLAY_PAUSE);
  }

  if (btn4.fallingEdge()) {
    send_media(KEY_MEDIA_NEXT_TRACK);
  }

  delay(ms_delay);
}

I am using a Teensy 3.0, Teensyduino 1.15, OSX 10.7. I can get other keycodes to send, but I can't seem to get the media ones to fire.

Any help with this would be welcomed.

Thanks,
Wraithan
 
Last edited:
Media keys aren't implemented in Teensyduino for Teensy 3.0

The following adds it. Because it is similar to the implementation for Teensy{1,2} I suspect it has the same problems and doesn't work with Windows but I am not near a windows box to test that theory. If it doesn't work there, I'll attempt another patch that adds that functionality.

Code:
diff -Naur teensy3/usb_dev.h teensy3-custom/usb_dev.h
--- teensy3/usb_dev.h	2013-07-25 23:50:31.000000000 -0700
+++ teensy3-custom/usb_dev.h	2013-07-25 23:49:37.000000000 -0700
@@ -78,6 +78,7 @@
 #ifdef KEYBOARD_INTERFACE
 extern uint8_t keyboard_modifier_keys;
 extern uint8_t keyboard_keys[6];
+extern uint8_t keyboard_media_keys;
 extern uint8_t keyboard_protocol;
 extern uint8_t keyboard_idle_config;
 extern uint8_t keyboard_idle_count;
diff -Naur teensy3/usb_keyboard.c teensy3-custom/usb_keyboard.c
--- teensy3/usb_keyboard.c	2013-07-25 23:50:23.000000000 -0700
+++ teensy3-custom/usb_keyboard.c	2013-07-25 23:49:37.000000000 -0700
@@ -46,6 +46,8 @@
 // which keys are currently pressed, up to 6 keys may be down at once
 uint8_t keyboard_keys[6]={0,0,0,0,0,0};
 
+uint8_t keyboard_media_key=0;
+
 // protocol setting from the host.  We use exactly the same report
 // either way, so this variable only stores the setting since we
 // are required to be able to report which setting is in use.
@@ -468,7 +470,7 @@
 		yield();
 	}
 	*(tx_packet->buf) = keyboard_modifier_keys;
-	*(tx_packet->buf + 1) = 0;
+	*(tx_packet->buf + 1) = keyboard_media_key;
 	memcpy(tx_packet->buf + 2, keyboard_keys, 6);
 	tx_packet->len = 8;
 	usb_tx(KEYBOARD_ENDPOINT, tx_packet);
diff -Naur teensy3/usb_keyboard.h teensy3-custom/usb_keyboard.h
--- teensy3/usb_keyboard.h	2013-07-25 23:50:16.000000000 -0700
+++ teensy3-custom/usb_keyboard.h	2013-07-25 23:49:37.000000000 -0700
@@ -50,6 +50,7 @@
 int usb_keyboard_send(void);
 extern uint8_t keyboard_modifier_keys;
 extern uint8_t keyboard_keys[6];
+extern uint8_t keyboard_media_key;
 extern uint8_t keyboard_protocol;
 extern uint8_t keyboard_idle_config;
 extern uint8_t keyboard_idle_count;
@@ -82,7 +83,7 @@
 	void set_key4(uint8_t c) { keyboard_keys[3] = c; }
 	void set_key5(uint8_t c) { keyboard_keys[4] = c; }
 	void set_key6(uint8_t c) { keyboard_keys[5] = c; }
-	void set_media(uint8_t c) { }
+	void set_media(uint8_t c) { keyboard_media_key = c; }
 	void send_now(void) { usb_keyboard_send(); }
 	void press(uint16_t n) { usb_keyboard_press_keycode(n); }
 	void release(uint16_t n) { usb_keyboard_release_keycode(n); }
 
A side note is that it would be nice if the code was up on github or somewhere like that, so I could send a proper patch using the VCS that you do, rather than posting it in a code fragment on a forum. This isn't the stone ages we have Github!
 
Bumping as other questions have been replied to in some fashion but this has not. If there is any problem with the code that is preventing it from getting merged, I'll gladly correct it.
 
Paul,

You are notorious for not accepting patches and generally ignoring folks who try to help out. At least that is what I heard speaking to other hardware folks in the Portland area. I've emailed my patch to you directly as well as posting on here, not sure how else to go about this.

Would love a reply of any sort. Maybe my code is terrible, maybe you explicitly do not want media key support. In any case, community members who try to help and get ignored, generally don't come back.

-Wraithan
 
@Wraithan,

Paul is running a business and often other things take priority. It is just good business practice to thoroughly check any patch to make sure it does not break any other functionality. That takes time and usually is not the foremost focus in running a business.

Having been around this forum pretty much since its inception I find your statements unfounded and your latent thread quite frankly rude!
 
Paul,

You are notorious for not accepting patches and generally ignoring folks who try to help out.

Based on your seven posts to this forum, I deduce that you aren't too familiar with it. If you were, you would know that Paul is in general very responsive to clear bug reports and to well-written patches that fix the problem while not introducing others. You would also know that he does a lot of testing and verification (libraries on the Teensy get substantially better QA than most Arduinoesque platforms, including the original Arduino).

If you feel your bug report and patch are bing ignored, a good way forward in future would be to post more details of investigation of the bug, and reports of sucessfully deploying and testing the patch with various Teensy boards and (where it interacts with a host computer) precise reports of OS and version tested, results and any other relevant information.

Or I guess you could descend to ad-hominem as a way to attract attention. If you were Paul, which would you prefer?
 
Incidentally, while I'm far from one of the most active or knowledgeable folks here, I have had several patches accepted and shipped in Teensyduino updates.
 
This one did actually sit for quite some time. The low power optimization turned out to be a beast of a problem that really set me far behind on everything else. By the way, if anyone reading this ever considers using any chips from Nuvoton, I would highly recommend avoiding those parts!
 
I was going to reply to this thread and try to justify the way I felt (and that it was the Portland dorkbot group that told me getting patches accepted by Paul is hard in the best of cases).

I'm just happy my patch eventually made it in. I think if there was a bit more of a formal process for this it wouldn't feel like I was shouting at the void (again I'll mention github).
 
Actually, the core library is now on github (since October 2013).

https://github.com/PaulStoffregen/cores

However, I generally take one to three months to really review most things. I know that kind of delay can be really frustrating. PJRC is just 3 people, so we all wear several hats here. Sure, much more could happen with more people, but then we couldn't operate efficiently enough to stay in business and keep making Teensy.

I'll be at the DorkbotPDX meetup tonight, if you'd like to chat in person. My guess is you likely talked with the one notoriously hot-headed person in that group who had a lot of personal issues with me (and a lot of others too), before ultimately leaving the group. Early on, he asked to collaborate on stuff that became Teensy, but he was far too difficult to work with. He only contributed strongly worded opinions, not any working code. He considers himself an expert, and he certainly has built a number of projects, but I can tell you he never submitted any code changes or improvements, not even once.
 
Last edited:
Ah cool, I didn't see that change/announcement and was going off of searching a ton when I submitted this patch. Glad to hear it is there.

I can see how the Dorkbot thing could happen. I heard it from two different people, but could just be a friend of the aforementioned.
 
I'm not involved with Dorkbot (would like to be, will have to make time) but I've been nothing short of amazed at the responsiveness Paul's given to customers here on this site. The number of things he has on his plate at once is rather impressive. He seems to juggle much more than seems reasonable, and he seems to follow through quite well and finish what he starts.

There are difficult people out there -- I've worked with a few -- but often when you hear one person complain, it's not at all clear whether it's the complainer or complainee who's the source of the problem. Sometimes a bit of both, as nobody's perfect and everyone has bad days, but I get the impression that most people here are quite happy.
 
Status
Not open for further replies.
Back
Top