Opened 15 years ago
Closed 12 years ago
#6422 closed enhancement (Fixed)
(MacOS X port) Apple TV remote support for 2.3 and others
Reported by: | Owned by: | Nigel | |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | Ports - OSX | Version: | Master Head |
Severity: | medium | Keywords: | AppleTV, Apple tv, atv |
Cc: | Ticket locked: | no |
Description
The current Apple remote mappings appear to work only for certain versions of Mac OS X. The Apple TV version of the OS uses different mappings for different versions of the Apple TV OS. There are distinct mappings for OS X 10.4, OS X 10.5, ATV 1.x through 2.02, ATV 2.1 through 2.2, and ATV 2.3.
Example code can be found at: http://code.google.com/p/atv-xbmc-launcher/source/browse/trunk/xbmchelper/remotecontrolwrapper/AppleRemote.m
Attachments (5)
Change History (27)
Changed 15 years ago by
Attachment: | AppleRemotes.diff added |
---|
comment:1 Changed 15 years ago by
Added a patch that should add support for the rest of the remotes-- absolutely no way to test (or even compile test) so you're on your own, OS X users. :)
comment:2 Changed 15 years ago by
This patch doesn't work I'm afraid. I think the Apple remote changes in the 2.3 release were more substantial than just the cookie mappings. To begin with the device name has changed from AppleIRController to AppleTVIRReceiver (see http://www.google.com/codesearch/p?hl=en#AGQyqwdsIls/trunk/xbmchelper/remotecontrolwrapper/AppleRemote.m&q=remoteControlDeviceName%20package:http://atv-xbmc-launcher\.googlecode\.com)
I've tried changing the remote device name in this patch but it still doesn't work, having looked at the XBMC Apple Remote support there seems to have been other changes as well e.g. 'on atv >=2.3 ir handling is a bit broken. we get only non-press events, and those all the time.'
I tried to get use iremoted http://github.com/jamiew/iremoted/tree/master to dump the cookie values but it doesn't seem to work on the appletv.
comment:3 Changed 15 years ago by
I think the patch should work generally-- it may not work for 2.3, but it shoudl work for the earlier revisions. Can anyone with non-2.3 versions of the ATV please patch and try? I may be able to get my hands on some ATV hardware in the next few weeks to play, but getting this committed would be a lot easier if any apple TV users actually cared enough about it to test it (2.3 aside).
comment:4 Changed 15 years ago by
Priority: | major → minor |
---|
comment:6 Changed 15 years ago by
I have Apple TV with V2.4 and would be happy to test the MythTV frontend if anyone is still working on this. The binary of the front end I downloaded does run, but as reported, the remote doesn't work (it works for Boxee, XBMC, though). I tried compiling the front end to see if I could work on a patch, and was able to get a version that worked on my laptop but it doesn't work on the AppleTV (so, unlike the binary I downloaded). Any suggestions about how to compile it for ATV?
comment:7 Changed 14 years ago by
Basically the existing codebase worked up to 2.2 and then stopped working for 2.3 onwards. The patch doesn't fix anything.
comment:8 Changed 14 years ago by
Milestone: | unknown → 0.23 |
---|---|
Version: | 0.21-fixes → Trunk Head |
comment:9 Changed 14 years ago by
Milestone: | 0.23 → 0.23-fixes |
---|
comment:10 Changed 14 years ago by
Milestone: | 0.23-fixes → unknown |
---|
comment:11 Changed 14 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
It isn't an enhancement if there's no code that works. Nobody working on it, nobody planning to, which basically reduces this to a feature request without patch.
comment:12 Changed 14 years ago by
Resolution: | wontfix → fixed |
---|
(In [26275]) Add Apple-TV remote codes. Untested by me on that hardware, but no regressions under 10.6 on MacBook?. Closes #6422. (Sorry for the delay - I try not to commit untested code,
and was concerned about some of the cookie strings that are less exact duplicates of the existing 10.4 and 10.5 ones)
Also removed a duplicated cookie, and some trailing whitespace.
comment:19 Changed 13 years ago by
Resolution: | fixed |
---|---|
Status: | closed → new |
Okay, I've got a fix for this.
I'm assuming there's a preferred format for the diff? Could you let me know and I'll attach the patches against 0.23-fixes and 0.24-fixes.
I've also merged the changes to the 0.24 stuff back to the 0.23 version as it made more sense.
Let me know.
comment:20 Changed 13 years ago by
EmLn, git diff or svn diff is easiest. e.g.:
cd src/mythtv git diff > ~/Desktop/atv-2.3.diff
and attach the file to this ticket, or email to me. If you can also point me to the XBMC launcher code, it might help me understand what the fault is? I could only find something about AppleScript and Remote Buddy.
(I assumed problem was just missing ATV codes, which I added in commit 24275, and new device name, that I thought I added in 26282)
Changed 13 years ago by
UNTESTED patch for 0.24-fixes branch. Should work (tested on 0.23-fixes)
Changed 13 years ago by
Patch for 0.23-fixes. Test build on 10.4, executed on ATVv1 v3.02
Changed 13 years ago by
UNTESTED patch to head revision for fix with ATV >v 2.3
comment:21 Changed 13 years ago by
Nigel,
The link in the ticket description has the XBMC launcher code. I've commented the changes I made fairly heavily, but the basic change for the remote handling is that prior to v 2.3, the underlying system sent us the button events. Now, the system just sends events whenever an IR pulse is received, I think to enable use of other remote controls with the ATV.
The changes figure out if we're running on a 'qualified' ATV, and then maintain the button state. The XBMC code doesn't really support long presses (or if it does, I missed it...) but that is supported here. The events require a delayed callback, so I hooked in a QTimer as that was the path of least resistance.
I hope I got the diffs right - the only one I'm sure of is the 0.23-fixes branch. When 0.24 goes mainstream in Gentoo, I'll upgrade and test.
There were a couple of minor changes to some of the other build files too, to enable use of MMX on the OS X builds. I hope those help for other Mac users in general.
comment:22 Changed 13 years ago by
Status: | new → assigned |
---|
Note that the first two hunks of the HEAD diff above do not appear to be relevant to this ticket, and that the decoderbase change has been known to cause issues on other platforms in the past.
comment:23 Changed 12 years ago by
About to apply (with some minor tidyups), but having problems getting this to compile the MOC:
moc_AppleRemote.cpp:44: error: ‘staticMetaObject’ is not a member of ‘MThread’ /Volumes/Backups/MythTV/.osx-packager/build/include/QtCore/qobject.h: In member function ‘virtual const QMetaObject* AppleRemote::metaObject() const’: /Volumes/Backups/MythTV/.osx-packager/build/include/QtCore/qobject.h:296: error: ‘QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> > QObject::d_ptr’ is protected moc_AppleRemote.cpp:54: error: within this context /Volumes/Backups/MythTV/.osx-packager/build/include/QtCore/qobject.h:296: error: object missing in reference to ‘QObject::d_ptr’ moc_AppleRemote.cpp:54: error: from this location /Volumes/Backups/MythTV/.osx-packager/build/include/QtCore/qobject.h:296: error: ‘QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> > QObject::d_ptr’ is protected moc_AppleRemote.cpp:54: error: within this context /Volumes/Backups/MythTV/.osx-packager/build/include/QtCore/qobject.h:296: error: object missing in reference to ‘QObject::d_ptr’ moc_AppleRemote.cpp:54: error: from this location moc_AppleRemote.cpp: In member function ‘virtual void* AppleRemote::qt_metacast(const char*)’: moc_AppleRemote.cpp:62: error: ‘qt_metacast’ is not a member of ‘MThread’ moc_AppleRemote.cpp: In member function ‘virtual int AppleRemote::qt_metacall(QMetaObject::Call, int, void**)’: moc_AppleRemote.cpp:67: error: ‘qt_metacall’ is not a member of ‘MThread’ make: *** [moc_AppleRemote.o] Error 1
comment:24 follow-up: 20 Changed 12 years ago by
You may need to change the definition of class AppleRemote? to:
class AppleRemote : public QObject, public MThread
The MThread rewrite makes the threads not QObject-based, but to do some of what is in that patch (with signals), you need it to inherit QObject (which should be first in the list, and requires the Q_OBJECT macro to be first in the class definition as in the patch)
-- edit to add a code block around the class definition line
comment:19 Changed 12 years ago by
Correct wrong remote codes for AppleTV 2.3. Refs #6422
Branch: master Changeset: d6e4babb17afbb2c6b0250b4f05ae0350cb545e0
comment:20 Changed 12 years ago by
Replying to beirdo:
You may need to change the definition of class AppleRemote? to:
class AppleRemote? : public QObject, public MThread
Do'h. Thanks Gavin - I knew it was something obvious, but my 7AM brain wasn't seeing it :-)
comment:21 Changed 12 years ago by
AppleTV 2.3 remote support, thanks to Emlyn Bolton. Refs #6422.
Re-structured a bit from supplied patch to remove blocks of if (usingNewATV), a few less magic numbers - hopefully a little easier to understand/maintain. Untested on an AppleTV. Will let bake a while in HEAD before backporting.
Branch: master Changeset: 596f98b086aa457d90d4ce376be7c059ba9680a5
comment:22 Changed 12 years ago by
Resolution: | → Fixed |
---|---|
Status: | assigned → closed |
Didn't head if anyone had tested this, so won't risk backporting.
Untested, should work.