ircatch.o and DVD playback control on 5.1.1b

[alldeadhomiez]

I recently examined the ircatch.o module on the latest version of the Toshiba SD-H400 software, 5.1.1b. My goal was to gain a better understanding of how this kernel module works, and to produce a version which accepts both Toshiba and Philips remote codes.

On 5.x, the huxley process opens up /dev/ircatch0, which is a character device, major 127 minor 0. It then performs a blocking 0x20 byte read on the device, waiting for a remote code. The ircatch module passes all recognized TiVo IR codes to the application, allowing the application to filter out the uninteresting ones.

When in DVD mode, the Linux software on the Toshiba is not directly responsible for playing the DVD. In fact, if you force the MIPS processor to reboot during DVD playback, the DVD will continue playing until the hardware is reset during the later stages of the startup sequence. All remote commands appear to be passed through myworld, however; a myworld thread receives the IR commands from huxley through the router.o interface, and passes them to the Toshiba DVD playback board through /dev/ttyS0. During my trials, the myworld thread responsible for this could be identified by looking for "Bus_myworld" in /tmp/tmkpidmap. If you "strace -p" this process, you will see the communication with the DVD player.

The DVD playback facility on ttyS0 appeared to be a simple, "interactive" interface running at 115200bps. myworld sends '\n' and gets a '>' prompt back, then sends a command followed by '\n'. The command is echoed back to myworld. Some of the commands I found were:

R15: play
R0C: pause
R19: rewind
R13: fast forward
RDE: dvd top menu
R24: track forward
E: exit dvd playback
I: resume dvd playback

These commands can be issued "out of band" with a command like:

echo "R15" > /dev/ttyS0

Getting back to the ircatch/huxley interface, I determined that the IR data returned from the read() syscall has the following format:

struct remote_event
{
        uint32_t        event;          /* 0 */
        uint32_t        protocol;       /* 4 */
        uint32_t        type;           /* 8 */
        uint32_t        unk0;           /* c: tosh=9001fc01, philips=80028d50 */
        uint64_t        jiffies;        /* 10 */
        uint16_t        id;             /* 18: remote address */
        uint16_t        unk1[3];        /* 1a */
};

The event is the button pressed; see Table 1 in the next post.

The protocol field (Sony, Philips, Toshiba, "Takara") is defined in Table 2.

In my experience, all Philips/peanut remotes I tried were recognized as code 0x02. When browsing through the ircatch code, I did not find the functions (if any) that produced codes 0x03-0x05.

"type" refers to whether the button is being pushed or released:

#define		TYPE_DOWN		0
#define		TYPE_UP			1

"jiffies" refers to the absolute time when the event took place.

"id" refers to the remote address. 0 on the remote or on the TiVo is a wildcard which causes any address to be accepted.

ircatch.o has debugging facilities, which I activated by hand before I allowed the TiVo software to boot:

modprobe ircatch IrLedDebug=1 IrHpkDebug=1 IrDebugLevel=65535 IrNecDebug=1 IrSonyDebug=1 IrNavDebug=1

Looking at the ircatch.o code with IDA, I found the following interesting functions:

.text:1d44: called with $a0=pointer to event struct, by all four protocol handlers

.text:2570: handler for Jyounetsu (Toshiba) remote actions
.text:2488: handler for NEC_UNKNOWN (Philips) remote actions
.text:3028: handler for Sony remote actions

I found that by changing the word at 2544 (file offset 0x2594) from 8c430000 to 2403000c, all Philips remote events (protocol 0x02) are passed to the software as Toshiba remote events (protocol 0x0c). I suspect that the following modifications will allow the use of a Sony remote on this unit:
- .text:2ff4: 24030007 -> 2403000c (make sony SA remote look like toshiba)
- .text:3014: 24030006 -> 2403000c (make sony combo remote look like toshiba)

The peanut remote lacks several of the extra buttons added to the Toshiba remote for DVD playback, but the bare essentials are there. There may be ways to add mappings for these new buttons.

[alldeadhomiez]

Table 1: Remote event codes (these are the same for all protocols as they have been translated from "native" codes):

#define		EVT_TIVO		0x01
#define		EVT_RECORD		0x02
#define		EVT_PLAY		0x03
#define		EVT_PAUSE		0x04
#define		EVT_REVERSE		0x05
#define		EVT_FORWARD		0x06
#define		EVT_REPLAY		0x07
#define		EVT_SLOW		0x08
#define		EVT_ADVANCE		0x09
#define		EVT_THUMBSUP		0x0a
#define		EVT_THUMBSDOWN		0x0b
#define		EVT_CLEAR		0x0c
#define		EVT_ENTER		0x0d
#define		EVT_CHANNELUP		0x0e
#define		EVT_CHANNELDOWN		0x0f
#define		EVT_LIVETV		0x10
#define		EVT_GUIDE		0x11
#define		EVT_DISPLAY		0x12
#define		EVT_SKIPPED_1		0x13
#define		EVT_MENU		0x14
#define		EVT_DVDMENU		0x15
#define		EVT_DOWN		0x16
#define		EVT_LEFT		0x17
#define		EVT_RIGHT		0x18
#define		EVT_SELECT		0x19
#define		EVT_STANDBY		0x1a
#define		EVT_NUM0		0x1b
#define		EVT_NUM1		0x1c
#define		EVT_NUM2		0x1d
#define		EVT_NUM3		0x1e
#define		EVT_NUM4		0x1f
#define		EVT_NUM5		0x20
#define		EVT_NUM6		0x21
#define		EVT_NUM7		0x22
#define		EVT_NUM8		0x23
#define		EVT_NUM9		0x24
#define		EVT_DELIMITER		0x25
#define		EVT_VOLUMEUP		0x26
#define		EVT_VOLUMEDOWN		0x27
#define		EVT_MUTE		0x28
#define		EVT_TVPOWER		0x29
#define		EVT_TVINPUT		0x2a
#define		EVT_INFO		0x2b
#define		EVT_WINDOW		0x2c
#define		EVT_PLUS10		0x2d
#define		EVT_SKIPPED_2		0x2e
#define		EVT_DVDSETUP		0x2f
#define		EVT_OPENCLOSE		0x30
#define		EVT_STOP		0x31
#define		EVT_SKIPREVERSE		0x32
#define		EVT_SKIPFORWARD		0x33
#define		EVT_DVDTOPMENU		0x34
#define		EVT_RETURN		0x35
#define		EVT_PROGRESSIVE		0x36
#define		EVT_ANGLE		0x37
#define		EVT_SUBTITLE		0x38
#define		EVT_AUDIO		0x39
#define		EVT_SEARCH		0x3a
#define		EVT_NAVI		0x3b
#define		EVT_VREMOTE		0x3c
#define		EVT_FLSELECT		0x3d
#define		EVT_FLDIMMER		0x3e
#define		EVT_VCRPLUS		0x3f

Table 2: Available protocols

#define         PROT_NAVCLUSTER              0x01
#define         PROT_NEC_UNKNOWN             0x02       /* dtivo philips */
#define         PROT_NEC_STANDALONE_US       0x03
#define         PROT_NEC_STANDALONE_EURO     0x04
#define         PROT_NEC_COMBO_GEN1          0x05
#define         PROT_SONY_COMBO              0x06
#define         PROT_SONY_STANDALONE         0x07
#define         PROT_NEC_COMBO_GEN2          0x08
#define         PROT_NEC_ATT_34              0x09
#define         PROT_NEC_ACCESSORY_36        0x0a
#define         PROT_NEC_GRYPHON_34          0x0b
#define         PROT_NEC_JYOUNETSU           0x0c       /* toshiba sd-h400 */
#define         PROT_NEC_TAKARA              0x0d
#define         PROT_NEC_TAKARA_AV           0x0e
#define         PROT_NEC_DIRECTV_CENTRAL     0x0f

[alldeadhomiez]

I have noticed that my Philips "guide" button is interpreted as "live tv" by the TiVo when I have patched ircatch.o.

In the module, I have located a translation table at .data:244, file offset 0x4864, which is used to map Philips native device codes to common "EVT_" codes:

    2488:       00108880        sll     s1,s0,0x2
    248c:       3c020000        lui     v0,0x0
                        248c: R_MIPS_HI16       .data
    2490:       00511021        addu    v0,v0,s1
    2494:       8c420244        lw      v0,580(v0)
                        2494: R_MIPS_LO16       .data
    2498:       30a3000f        andi    v1,a1,0xf
    249c:       2e040010        sltiu   a0,s0,16
    24a0:       afa20010        sw      v0,16(sp)

The table is 0x400 bytes long, taking 4 bytes for each possible input code. Judging from a quick spot check, the input codes, used as an index into the array, correspond with the "OBC" codes found in JP1 remote definition files:

OBC 0x00 (0) = 0x01 EVT_TIVO
OBC 0x01 (1) = 0x01 EVT_TIVO
OBC 0x02 (2) = 0x01 EVT_TIVO
OBC 0x03 (3) = 0x01 EVT_TIVO
OBC 0x04 (4) = 0x01 EVT_TIVO
OBC 0x05 (5) = 0x01 EVT_TIVO
OBC 0x06 (6) = 0x01 EVT_TIVO
OBC 0x07 (7) = 0x01 EVT_TIVO
OBC 0x08 (8) = 0x01 EVT_TIVO
OBC 0x09 (9) = 0x01 EVT_TIVO
OBC 0x0a (10) = 0x01 EVT_TIVO
OBC 0x0b (11) = 0x01 EVT_TIVO
OBC 0x0c (12) = 0x01 EVT_TIVO
OBC 0x0d (13) = 0x01 EVT_TIVO
OBC 0x0e (14) = 0x01 EVT_TIVO
OBC 0x0f (15) = 0x01 EVT_TIVO
OBC 0x10 (16) = 0x29 EVT_TVPOWER
OBC 0x11 (17) = 0x10 EVT_LIVETV
OBC 0x12 (18) = 0x14 EVT_MENU
OBC 0x13 (19) = 0x12 EVT_DISPLAY
OBC 0x14 (20) = 0x15 EVT_DVDMENU
OBC 0x15 (21) = 0x18 EVT_RIGHT
OBC 0x16 (22) = 0x16 EVT_DOWN
OBC 0x17 (23) = 0x17 EVT_LEFT
OBC 0x18 (24) = 0x0b EVT_THUMBSDOWN
OBC 0x19 (25) = 0x19 EVT_SELECT
OBC 0x1a (26) = 0x0a EVT_THUMBSUP
OBC 0x1b (27) = 0x28 EVT_MUTE
OBC 0x1c (28) = 0x26 EVT_VOLUMEUP
OBC 0x1d (29) = 0x27 EVT_VOLUMEDOWN
OBC 0x1e (30) = 0x0e EVT_CHANNELUP
OBC 0x1f (31) = 0x0f EVT_CHANNELDOWN
OBC 0x20 (32) = 0x02 EVT_RECORD
OBC 0x21 (33) = 0x03 EVT_PLAY
OBC 0x22 (34) = 0x05 EVT_REVERSE
OBC 0x23 (35) = 0x04 EVT_PAUSE
OBC 0x24 (36) = 0x06 EVT_FORWARD
OBC 0x25 (37) = 0x08 EVT_SLOW
OBC 0x26 (38) = 0x07 EVT_REPLAY
OBC 0x27 (39) = 0x09 EVT_ADVANCE
OBC 0x28 (40) = 0x1c EVT_NUM1
OBC 0x29 (41) = 0x1d EVT_NUM2
OBC 0x2a (42) = 0x1e EVT_NUM3
OBC 0x2b (43) = 0x1f EVT_NUM4
OBC 0x2c (44) = 0x20 EVT_NUM5
OBC 0x2d (45) = 0x21 EVT_NUM6
OBC 0x2e (46) = 0x22 EVT_NUM7
OBC 0x2f (47) = 0x23 EVT_NUM8
OBC 0x30 (48) = 0x24 EVT_NUM9
OBC 0x31 (49) = 0x1b EVT_NUM0
OBC 0x32 (50) = 0x0c EVT_CLEAR
OBC 0x33 (51) = 0x0d EVT_ENTER
OBC 0x34 (52) = 0x2a EVT_TVINPUT
OBC 0x35 (53) = 0x1a EVT_STANDBY
OBC 0x36 (54) = 0x11 EVT_GUIDE
OBC 0x44 (68) = 0x2c EVT_WINDOW
OBC 0x45 (69) = 0x2e EVT_SKIPPED_2
OBC 0x46 (70) = 0x34 EVT_DVDTOPMENU
OBC 0x47 (71) = 0x35 EVT_RETURN
OBC 0x48 (72) = 0x31 EVT_STOP
OBC 0x49 (73) = 0x3f EVT_VCRPLUS

Presumably, my remote is generating OBC 0x11 = EVT_LIVETV (0x10) instead of EVT_GUIDE (0x11). To fix this, I might change the word EVT_LIVETV (0x10) to EVT_GUIDE (0x11) at file offset 0x48a8 in ircatch.o.

[Juppers]

Did you find anything about how the Tivo decides which protocol is the native one? We know it used to be in MFS, but noone has been able to find it there since 4.x came out. I still think it HAS to be in there somewhere, part of the swsystem slice. ircatch has to know the default from somewhere. Tivoapp, proc, env, something.

As for gettinng it to accept philips and toshiba codes, how is it structuring the decoded commands? Is it filtering by protocol id, then if that matches running down the OBC codes to find a match? If you could array the filtering command, that should make multiple remote codes work. Then again, it may already be prepared for that as some remotes do span multiple protocols, nothing tivo has does that, but they may have prepared for it in the module.

Lastly, are the OBCs universal against all tivo remotes regardless of protocol, or did you only dump one OBC table? I didn't think they were. I will have to check my JP1 stuff and see.

[alldeadhomiez]

Did you find anything about how the Tivo decides which protocol is the native one? We know it used to be in MFS, but noone has been able to find it there since 4.x came out. I still think it HAS to be in there somewhere, part of the swsystem slice. ircatch has to know the default from somewhere. Tivoapp, proc, env, something.

ircatch doesn't care; it sends everything it sees to the user process. I did not look into how it works on the tivoapp side, but I would imagine it's not too hard to change the way the filters work. It might take a little more work to see where it's getting the settings from instead of just overriding the checks.

As for gettinng it to accept philips and toshiba codes, how is it structuring the decoded commands? Is it filtering by protocol id, then if that matches running down the OBC codes to find a match? If you could array the filtering command, that should make multiple remote codes work. Then again, it may already be prepared for that as some remotes do span multiple protocols, nothing tivo has does that, but they may have prepared for it in the module.

ircatch returns a "struct remote_event" (my name, not theirs) for every event it receives for any protocol. If you wish, you could modify ircatch.o as I did to change the protocol element of that struct so that both protocols are reported to be Toshiba events. Or, you can find a way to change the behavior on the tivoapp side, as has been done on 3.x.

Lastly, are the OBCs universal against all tivo remotes regardless of protocol, or did you only dump one OBC table? I didn't think they were. I will have to check my JP1 stuff and see.

OBC codes should not be the same across protocols, which is why they are translated into the common EVT codes before they are passed to the user process.

[sky12]

This is a perfect solution for my situation.
(Old SA phillips TiVo and Tosh sd-h400)
I bought one of those dual ID remotes back when I had a DtiVo and the SATiVo and since replacing the DTiVo with the H400, I haven't been able to use it.
This change works just fine, except for one thing, the remote ID.
Is there anything in ircatch to filter based on ID, or does this have to be done in TiVoapp itself?

Sky

Edit:
Never mind, the Toshiba obeys the same rule as the old SAs.
If you remote around in the system information page, it'll set the remote ID. (it just doesn't bother displaying it)

[raydog153]

ircatch doesn't care; it sends everything it sees to the user process. I did not look into how it works on the tivoapp side, but I would imagine it's not too hard to change the way the filters work. It might take a little more work to see where it's getting the settings from instead of just overriding the checks.

ircatch returns a "struct remote_event" (my name, not theirs) for every event it receives for any protocol. If you wish, you could modify ircatch.o as I did to change the protocol element of that struct so that both protocols are reported to be Toshiba events. Or, you can find a way to change the behavior on the tivoapp side, as has been done on 3.x.

I am looking for a way to capture remote control key presses on 4.x. Maybe I an wrong here, but it looks as if this is the place to do that. How are you getting the data from ircatch? Is there something that can be coded here that would allow something to capture the key presses and send them to tivoapp or whatever and send them to another app for processing? I am looking to get TCS working on v4.x. THanks for any help.

[mrpenguin]

Would this information help in activating a 30sec skip button on the toshiba? Either by re-mapping an existing key not used by you or by using philips commands with a programmable remote or something. I also noticed a ircatch.conf in /etc which had basically the list above in table 1. Wonder what changing some of those things maybe mess with how the remote interacts. gotta try some playing.

[mrblack51]

Would this information help in activating a 30sec skip button on the toshiba? Either by re-mapping an existing key not used by you or by using philips commands with a programmable remote or something. I also noticed a ircatch.conf in /etc which had basically the list above in table 1. Wonder what changing some of those things maybe mess with how the remote interacts. gotta try some playing.

nope. there is no "30-sec skip button", its just mapped onto the advance button by tivoapp via the backdoor code. I dont think its an actual mapping, but more a change in how the code runs for that given button...but then again who knows. This would make sense since there is only a "EVT_ADVANCE" button event. There is a EVT_SKIPPED2 event though.

[mrpenguin]

oh, sorry wrong wording and I forgot to mention I had a toshiba sd-h400. The toshiba does not have the advance button on the remote, so, even with the 30 sec skip activated, you cannot skip. so, if you can have the tivo recognize the advance button with the other remotes, you can have the advance working, and therefore the 30 second skip. Basically, my remote does not have the advance button and I would like to add it.

[kelsky]

Originally Posted by alldeadhomiez
Looking at the ircatch.o code with IDA, I found the following interesting functions:

Can you specify the patches to enable the debugging on this and where it stores the debug information? I would like to run a seperate program to do specific tasks based on what the remote has just sent. I am on 6.2 and TCS doesn't function on it.

[mrpenguin]

All I did (7.1a) is changed the proper file in the /etc/rc.d/StageA_PreKickstart/rc.Sequence_550.LoadIrReceiveDriver.Platform_****.sh file for your system, _jyounetsu being the one for toshiba, setting the debug values as above. then reboot.
Then just keep tail'ing the tvlog, Messages or one of those (forgot which one) for the output. It was usefull in telling me that editing the /etc/ircatch.profile to remap keys didn't do a dang thing!

[kelsky]

I found the appropriate file to edit and made the changes to the debug attirbutes and rebooted. Well, I get see that entries are logged in the kernel and tvlog file, but nothing that I can figure out a pattern of. Each log file contains a little information, but it is all the same no matter what key on the remote I press. Maybe the version I have doesn't log it like before. I even tried different combinations on the 65535 setting but still nothing I could use. Any additional information on this is appreciated.

[mrpenguin]

hmm. When I set the values, I got traces like Num2 was pressed, Num2 was released, etc (all in tech verbage though). I could definately see sorta what was going on for the intake for like what you were wanting to look for.

[kelsky]

Yep, that is what I want. Nothing close to that in these log files. I am on 6.2 so there must be some differences.