(mac osx port) apple remote support

[mythtv@…]

My apologies if I've misunderstood the correct process; this is a feature request but since it includes a patch my understanding from the guide & other pages is that it belongs in trac rather than just the wiki or dev mailing list.

The attached patch adds native support for the apple remote that comes with late-model intel macs into mythfrontend.

I've made an effort to play nice with existing code, but this is my first patch for this project so bear with me. The apple remote code ties into the application using the same 'custom event' method that Lirc support uses.

The remote buttons map to

+/-	Up/Down
<< / >>	Left / Right
Play	Enter
Menu	Esc
hold << / hold >>	Home / End
hold Play	P
hold Menu	M

I would have liked to map 'hold + / hold -" to volume up/down on the mac, so that functionality wouldn't be missed, but the apple event system doesn't track long holds on those buttons, like it does the others.

I didn't provide a way to customize the key bindings in this go 'round. Since there are so few buttons, I didn't think that feature would be worth the trouble. There aren't a lot of spare buttons that could take on custom functionality.

[mythtv@…]

patch file (created with 'svn diff')

[mythtv@…]

made a couple of minor fixes to the patch

[Bailey]

Is it possible to get this back-ported into the 0.19.1 branch? Since 0.20 still seems to not work on x86 Macs...

[mythtv@…]

This patch was developed against 0.19, so it applies cleanly there already.

For 0.20, the patch doesn't apply cleanly, however the rejected hunks are in code that was removed, so the patch still works fine in 0.20.

[anonymous]

I must admit, I failed to get it working. Using the osx-packager script, and then patching the source (as at 10651) from the trunk, results in:

• some failed hunks (as mentioned)
• failed compilation :(

mythdialogs.cpp: In function 'void* SpawnAppleRemote(void*)':
mythdialogs.cpp:39: error: 'MythMainWindow' was not declared in this scope
mythdialogs.cpp:39: error: 'main_window' was not declared in this scope
mythdialogs.cpp:39: error: expected primary-expression before ')' token
mythdialogs.cpp:39: error: expected `;' before 'param'
mythdialogs.cpp:40: error: no matching function for call to 'AppleRemoteListener::AppleRemoteListener(<type error>)'
AppleRemoteListener.h:10: note: candidates are: AppleRemoteListener::AppleRemoteListener(QObject*)
AppleRemoteListener.h:8: note:                 AppleRemoteListener::AppleRemoteListener(const AppleRemoteListener&)
mythdialogs.cpp: At global scope:
mythdialogs.cpp:37: warning: unused parameter 'param'
mythdialogs.cpp:37: warning: 'void* SpawnAppleRemote(void*)' defined but not used
make[2]: *** [mythdialogs.o] Error 1
make[1]: *** [sub-libmyth] Error 2
make: *** [sub-libs] Error 2
[osx-pkg] Failed system call: " /usr/bin/make " with error code 2
Died at ./osx-packager.pl line 843.

[mythtv@…]

My apologies, it is also necessary to 'svn revert libs/libmyth/mythdialogs.cpp' to back out the hunks that do succeed in that file.

In other words, the patch includes changes to libs/libmyth/mythdialogs.cpp, some of which fail and none of which are needed in 0.20. They are only relevant for 0.19

[mythtv@…]

patch trimmed down for 0.20

[Bailey]

Much obliged sir. This kind of stuff isn't massively materially important, but it makes a huge difference to my day-to-day usage of surely one of the coolest OS projects around.

[mythtv@…]

update 0.19.fixes patch, with 'release remote' fix

[mythtv@…]

'release remote' version for 0.20

[mythtv@…]

The two new patches just uploaded replace the previous ones.

These patches contain a fix to make myth's apple remote support 'friendlier' with other applications. When mythtv is not the active application, it will release control of the remote. So, for example, if you start Front Row using cmd-esc while myth is running, frontrow will be able to use the remote.

This opens the way for a myth plugin that will activate frontrow, which I may write myself if I can find the time.

[Nigel]

(In [10864]) See #2017

[Nigel]

I had just started checking this in when I discovered that findAppleRemoteDevice is never called. Was that just for debugging? Can I remove it?

[Nigel]

Er, make that isRemoteAvailable, not findAppleRemoteDevice

[Nigel]

(In [10867]) See #2017

[mythtv@…]

This code originated as a conversion of an existing Objective C class, so I probably just missed cleaning that up. It should be safe to remove it.

I notice the checkin has the changes to mythmainwindow, but doesn't include the new AppleRemote.* files. I'm guessing you forgot to 'svn add' them. (I do that all the time...) It'll probably cause breakage till those go in.

Thanks!

[anonymous]

Also, there are changes to the libmyth .pro file, to add the AppleRemote module, and IIRC to add some LIRC classes to the mac build.

[Nigel]

(In [10877]) See #2017

[Nigel]

(In [10879]) Enable Apple Remote on Darwin. See #2017

[Nigel]

OK, after some small tidyup, this is now in SVN. There is some configure stuff to enable it, so you will have to ./configure --previous. I have tested compilation on PPC Mac and x86 Linux, but because I don't have an Intel Mac, I await confirmation that it actually works, or big fixes.
Since this is an enhancement, it isn't appropriate to add it to 0.19-fixes, but if 0.20 doesn't get into shape for Intel Macs (or PPC for that matter, playback is broken for me) then I may apply to that branch too

[Paul Bailey pdbailey (at) gmail]

The remote code works exactly as advertised for me, on an Intel iMac

[mythtv@…]

I realize that this is a long-closed ticket, so I apologize if this should be submitted as a new ticket rather than posted to an existing ticket.

It appears that the internal codes used by Apple for the remote have changed in Leopard (​Reference. I browsed around in the AppleRemote.cpp file and it looks like they're nicely bundled into the AppleRemote::_initCookieMap method, but I don't know what the new codes are - nor how to best retain backwards compatibility.

[Nigel]

Something like the following will dump out the raw codes:

% svn diff AppleRemote.cpp
Index: AppleRemote.cpp
===================================================================
--- AppleRemote.cpp     (revision 14784)
+++ AppleRemote.cpp     (working copy)
@@ -332,6 +332,8 @@
 {
     std::map<std::string,AppleRemote::Event>::iterator ii;
 
+std::cerr << "AppleRemote got cookieString: " << cookieString << std::endl;
+
     ii = cookieToButtonMapping.find(cookieString);
     if (ii != cookieToButtonMapping.end() && _listener)
     {

Make that change, run the frontend under 10.5, and note all the new key codes while playing with the remote

[Myth]

FYI, the mplayer svn code works with apple remote in Leopard. The relevant code snippet (including remote codes for both Tiger and Leopard) is as follows (hopefully it is ok to cut and paste it here):

typedef struct cookie_keycode_map {
    char *cookies;
    int seq_len;
    int keycode;
} cookie_keycode_map_t;

/* On tiger, 5 always follows 6; on leopard, 18 always follows 19.
 * On leopard, there seems to be no cookie value of 5 or 6.
 * Following is the shortened cookie sequence list
 * keycode      cookies_on_tiger cookies_on_leopard *down_state
 * AR_PREV_HOLD 14+6+3+2         31+19+3+2          yes
 * AR_NEXT_HOLD 14+6+4+2         31+19+4+2          yes
 * AR_MENU_HOLD 14+6+14+6        31+19+31+19
 * AR_VUP       14+12+11+6       31+29+28+19        yes
 * AR_VDOWN     14+13+11+6       31+30+28+19        yes
 * AR_MENU      14+7+6+14+7+6    31+20+19+31+20+19
 * AR_PLAY      14+8+6+14+8+6    31+21+19+31+21+19
 * AR_NEXT      14+9+6+14+9+6    31+22+19+31+22+19
 * AR_PREV      14+10+6+14+10+6  31+23+19+31+23+19
 * AR_PLAY_HOLD 18+14+6+18+14+6  35+31+19+35+31+19
 *
 * *down_state: A button with this feature has a pressed event and
 * a released event, with which we can trace the state of the button.
 * A button without this feature will only return one release event.
 *
 * hidden keys currently not implemented:
 * hold for 5 secs
 * MENU_NEXT_HOLD  15+14+6+15+14+6
 * MENU_PREV_HOLD  16+14+6+16+14+6
 * MENU_VUP_HOLD   20+14+6+20+14+6
 * MENU_VDOWN_HOLD 19+14+6+19+14+6
 *
 * It seems that pressing 'menu' and 'play' on the Apple Remote for
 * 5 seconds will trigger the make-pair function of the remote.
 * MENU_PLAY_HOLD  21+15+14+6+15+14+6
 */

static const cookie_keycode_map_t ar_codes_tiger[] = {
    { "\x0E\x06\x03\x02",         4, AR_PREV_HOLD     },
    { "\x0E\x06\x04\x02",         4, AR_NEXT_HOLD     },
    { "\x0E\x06\x0E\x06",         4, AR_MENU_HOLD     },
    { "\x0E\x0C\x0B\x06",         4, AR_VUP           },
    { "\x0E\x0D\x0B\x06",         4, AR_VDOWN         },
    { "\x0E\x07\x06\x0E\x07\x06", 6, AR_MENU          },
    { "\x0E\x08\x06\x0E\x08\x06", 6, AR_PLAY          },
    { "\x0E\x09\x06\x0E\x09\x06", 6, AR_NEXT          },
    { "\x0E\x0A\x06\x0E\x0A\x06", 6, AR_PREV          },
    { "\x12\x0E\x06\x12\x0E\x06", 6, AR_PLAY_HOLD     },
    { NULL,                       0, MP_INPUT_NOTHING },
};

static const cookie_keycode_map_t ar_codes_leopard[] = {
    { "\x1F\x13\x03\x02",         4, AR_PREV_HOLD     },
    { "\x1F\x13\x04\x02",         4, AR_NEXT_HOLD     },
    { "\x1F\x13\x1F\x13",         4, AR_MENU_HOLD     },
    { "\x1F\x1D\x1C\x13",         4, AR_VUP           },
    { "\x1F\x1E\x1C\x13",         4, AR_VDOWN         },
    { "\x1F\x14\x13\x1F\x14\x13", 6, AR_MENU          },
    { "\x1F\x15\x13\x1F\x15\x13", 6, AR_PLAY          },
    { "\x1F\x16\x13\x1F\x16\x13", 6, AR_NEXT          },
    { "\x1F\x17\x13\x1F\x17\x13", 6, AR_PREV          },
    { "\x23\x1F\x13\x23\x1F\x13", 6, AR_PLAY_HOLD     },
    { NULL,                       0, MP_INPUT_NOTHING },
};

Current version of the code is ​here.

[Nigel]

Leopard codes should now be in latest code [15227]. Merry Christmas!

[tim@…]

Using the other 10.5 patch knocking about I built on leopard and tried to use the remote but no joy. So in summary I do not think that this worked.

[Nigel]

Tim, maybe you could apply the "cookieString" patch from 2 months ago, and report a few of the strings you get from remote button presses?

[tim@…]

This is the following order Up, Down, Left, Right, OK, Menu I think it missed out the up and down though as I could hear the volume noises from OSX behind the frontend.

AppleRemote got cookieString: 19_ AppleRemote got cookieString: 31_29_28_18_ AppleRemote got cookieString: 19_ AppleRemote got cookieString: 31_29_28_18_ AppleRemote got cookieString: 19_ AppleRemote got cookieString: 31_30_28_18_ AppleRemote got cookieString: 19_ AppleRemote got cookieString: 31_30_28_18_ AppleRemote got cookieString: 19_ AppleRemote got cookieString: 19_ AppleRemote got cookieString: 31_23_18_31_23_18_ AppleRemote got cookieString: 19_ AppleRemote got cookieString: 19_ AppleRemote got cookieString: 31_22_18_31_22_18_ AppleRemote got cookieString: 19_ AppleRemote got cookieString: 19_ AppleRemote got cookieString: 31_21_18_31_21_18_ AppleRemote got cookieString: 19_ AppleRemote got cookieString: 19_ AppleRemote got cookieString: 31_20_18_31_20_18_

[tim@…]

leopard codes

[tim@…]

Have done some hacking about with the codes and what nigel suggested and the patch is the result. Tim

[Nigel]

(In [15279]) Working Mac OS X 10.5 codes (dunno why the 19,18 sequence is partly filtered out in 10.5, but the 6,5 sequence isn't in 10.4). Anyway, thanks Tim. Happy New Year! Closes #2017.

[anonymous]

Please consider back porting this into the 0.21 fixes branch. From the looks of it, this is a very safe set of changes to make to that branch.

[anonymous]

whoops, I meant 0.20

[Nigel]

(In [15615]) Remote codes for Mac OS 10.5. See #2017