Opened 18 years ago
Closed 16 years ago
Last modified 16 years ago
#2017 closed enhancement (fixed)
(mac osx port) apple remote support
Reported by: | Owned by: | Nigel | |
---|---|---|---|
Priority: | minor | Milestone: | 0.20 |
Component: | mythtv | Version: | head |
Severity: | medium | Keywords: | patch osx mac remote |
Cc: | Ticket locked: | no |
Description
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.
Attachments (6)
Change History (36)
Changed 18 years ago by
Attachment: | appleremote.patch added |
---|
comment:1 Changed 18 years ago by
Milestone: | 0.19.1 → 0.20 |
---|---|
Owner: | changed from Isaac Richards to Nigel |
Changed 18 years ago by
Attachment: | appleremote.2.patch added |
---|
made a couple of minor fixes to the patch
comment:2 Changed 18 years ago by
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...
comment:3 Changed 18 years ago by
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.
comment:4 Changed 18 years ago by
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.
comment:5 Changed 18 years ago by
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
comment:6 Changed 18 years ago by
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.
Changed 18 years ago by
Attachment: | appleremote0.19_friendly.patch added |
---|
update 0.19.fixes patch, with 'release remote' fix
Changed 18 years ago by
Attachment: | appleremote0.20_friendly.patch added |
---|
'release remote' version for 0.20
comment:7 Changed 18 years ago by
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.
comment:9 Changed 18 years ago by
Status: | new → assigned |
---|
I had just started checking this in when I discovered that findAppleRemoteDevice is never called. Was that just for debugging? Can I remove it?
comment:12 Changed 18 years ago by
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!
comment:13 Changed 18 years ago by
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.
comment:16 Changed 18 years ago by
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
comment:17 Changed 18 years ago by
The remote code works exactly as advertised for me, on an Intel iMac
comment:18 Changed 18 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:19 Changed 16 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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.
comment:20 Changed 16 years ago by
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
comment:21 Changed 16 years ago by
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.
comment:22 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Leopard codes should now be in latest code [15227]. Merry Christmas!
comment:23 Changed 16 years ago by
Resolution: | fixed |
---|---|
Status: | closed → new |
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.
comment:24 Changed 16 years ago by
Status: | new → infoneeded_new |
---|
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?
comment:25 Changed 16 years ago by
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_
comment:26 Changed 16 years ago by
Have done some hacking about with the codes and what nigel suggested and the patch is the result. Tim
comment:27 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | infoneeded_new → closed |
comment:28 Changed 16 years ago by
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.
patch file (created with 'svn diff')