HowTo: Use different RC's with HD2 FW

[Sekator500]

MIT or GPL would be fine...

[Pete]

OK, now that I've had a chance to look and play with the code, I see a lot clearer, and here's my plan for masquerading HDMI-CEC codes as IR ones. The major disappointments of course are that:
- Realtek didn't use inputdev for IR, as they should, so their IR input method is far from being friendly for external apps. If it's dealing with user input, use inputdev!
- Even worse, their venus_ir driver is read-only, so if you want to fake IR input you have to get quite creative. Gouzhuang did an awesome job with the shadow driver (and of course Sekator500 too!), but the thing that bothers me is that you must to install the shadow driver module before DvdPlayer starts, which may be a hurdle for regular users, and also, the only thing I really need from the shadow driver is the ability to write data to the IR fifo, so using shadow would be a bit of an overkill.

Therefore, what I'm going to do is:
- write my own driver (which won't actually be part of the cecd project) to hijack the venus IR fifo and add provide write operations to it, but without touching the existing driver => such a driver will be installable/removable on a running system even when DvdPlayer is running. This would be a separate driver from /dev/venus_irrp which I'll probably call /dev/venus_irwo (for write only)
- use the cecd.conf to translate HDMI-CEC keys to IR fifo data and just write those to /dev/venus_irwo

Now thanks to the good sources provided, I'm already well under way with the Venus IR FIFO hijack. I have an alpha version (called /dev/ugha, for "UGly HAck" ) that I can use to write IR codes straight into the existing FIFO, and fool the system into thinking that the data came from the remote. This requires some disputable retrieval of the venus_ir_fifo and venus_ir_read_wait addresses from the existing IR driver (through rudimentary "disassembly" of the running driver in the kernel), so this method is probably not as bulletproof as the shadow driver. But since the means of getting write access to an IR driver in order to fake RC codes on a specific system,is really something that falls outside of scope of cecd, that'll be good enough for me. And of course, the main advantage is that it can be installed/removed on the fly, even when DvdPlayer is running...

Once I have finalized venus_irwo, I'll publish the source and binary. But I don't think this new driver will be of much use for the problem of handling of different RCs. The translation of HDMI-CEC codes as IR codes, and the support of different RCs are two fundamentally different problems, that I think are better left separate...

[Pete]

Alright, driver is about as good as I want it to be. Sources available on github or as a tgz archive here. Pre-built module binary also available here. Basically the module adds /dev/venus_irrp_wo, for binary input, as well as '/sys/devices/platform/VenusIR_W/fakekey', similar to what the shadow driver does, so that you can use something like: echo 'fa05ff00' > /sys/devices/platform/VenusIR_W/fakekey to send fake control codes. Only tested with the Xtreamer so no guarantee on other platforms.

For those interested, the trick to be able to reuse the existing Venus IR driver FIFO (so that write access can be added even if DvdPlayer is already reading from /dev/venus_irrp) occurs in venus_ir_wo_init() from venus_ir_wo.c. What we do there is locate the addresses of the private variables venus_ir_fifo and venus_ir_read_wait, which we need to enqueue data, as well as wake any processes pending on new IR data. The method: locate public venus_ir_* calls, that use those variables, and look them up in the disassembly from their expected location.

The only thing I don't quite get right now is that I need to write IR codes twice for the DvdPlayer app of the Xtreamer to acknowledge them, even though the driver doesn't seem to have DOUBLE_WORD_IF set. Oh well, I can live with that for cecd...

[Sekator500]

The only thing I don't quite get right now is that I need to write IR codes twice for the DvdPlayer app of the Xtreamer to acknowledge them, even though the driver doesn't seem to have DOUBLE_WORD_IF set. Oh well, I can live with that for cecd...

Not quite good with this maybe you need consult to Gouzhuang

[tweakradje]

Nice to see some action here.

Why going the long way Pete? Wouldn't it be much better to have a irfake v5 that takes HDMI cec codes?

Like this example in possible irfake.conf:

#
# Asus O!Play R1/R3
#
"6","hdmi_cec_code01","b54a686c", play_music -> option

If irfake6 can take codes from your cec driver that would be enough.

We still need to test it on different players with different CEC TV's.

I use irfake even to translate xtreamer ir to xtreamer ir. Irfake can even execute extra shell scripts on a given ir code.

But perhaps if you are ready with your drivers someone can make irfake5 for more experienced users.

Keep up the good work.

Cheers

[Pete]

Not quite good with this maybe you need consult to Gouzhuang

I'm planning to investigate this further, but I need to get moving on with cecd first. Right now, having to write stuff twice is a very minor issue, when there's still a lot to do with the CEC code, so I'll be concentrating on that.

Nice to see some action here.

Why going the long way Pete? Wouldn't it be much better to have a irfake v5 that takes HDMI cec codes?

I think irfake is great, but the one thing I don't like is that it relies on the module being installed before DvdPlayer is launched, which means reboot. Yes it's a one of operation, but it's inconvenient. But more importantly, the generic mode of operation of cecd will be to translate CEC codes and write directly to a device or create an inputdev event, rather than rely on an external application to do so. Therefore, if I want cecd to be generic, I actually need to duplicate the functionality from irfake with regards to code translation into IR (or non IR, such as keyboard) codes. If cecd cannot pass CEC codes, outside of using irfake, it's not generic enough. For instance, if you press '0' on the TV remote, and your CEC connection is with a regular Linux platform (i.e. with keyboard input), you very much want that '0' to sent by the cecd daemon as a keyboard entry, by writing to the keyboard/tty device driver (or inputdev), and irfake cannot help there.

Thus, to have something representative of actual cecd usage, I only needed a representative input device, which I initially thought could be a slightly modified version of the shadow device with write access. But then, looking into it further, I realized that I didn't really need a lot of what the shadow device did, and that I could trim it down to provide my own write-only device that wouldn't require a reboot. This way I end up with a device that is actually representative of the kind of devices that cecd will translate and send its CEC input to, and users of cecd don't need to have irfake running for CEC codes to actually be translated. Oh, but of course, since it aims at being generic, cecd will support writing data to the irfake shadow device (through sysfs) if users have configured it so through the target device line in cecd.conf.

So, to summarize, as I previously said, while irfake and cecd do implement similar operations, they are very much dedicated to solving different problems, and should be kept separate.

[tweakradje]

Hi,

Q: can I have a type 0 and a type 1 for the same button in the conf file?

So I want to send/fake an ir command but also want to start a script with the same button/keypress.

Thanks

[Sekator500]

Hi,
Q: can I have a type 0 and a type 1 for the same button in the conf file?
So I want to send/fake an ir command but also want to start a script with the same button/keypress.
Thanks

No but you can combine all in one script. Here is an example on how-to send command from the shell:

Code: Select all

echo "0xb847686c" > /sys/devices/platform/VenusIR/fakekey

[tweakradje]

That is all I need to know. Thanks.

[john]

...
No but you can combine all in one script. Here is an example on how-to send command from the shell:

Code: Select all

echo "0xb847686c" > /sys/devices/platform/VenusIR/fakekey

Also thanks Sekator500.

Presumably that is without the leading "0x"?