Re: [cecd-devel] Random CECD question

[Pete B. <pb...@gm...>]

Hi Stephen,

I'm happy yo see that there is some interest for cecd at last (and I 
apologize for not having done much development on it over the past few 
months).

On 2011.06.10 00:34, Stephen Cox wrote:
> I have just picked up a RainshadowTech (www.rainshadowtech.com) HDMI-CEC
> bridge – obviously not the intended target device of your CECD project.

I was aware of these RS232 <-> HDMI-CEC repeater boxes. And I am very 
much planning for libcec, which is part of the cecd project, to support 
as many HDMI-CEC devices as possible, so yes, this devices too would be 
an intended target for cecd/libcec.

> Do you have any plans to provide an abstraction layer between the CECD
> and the physical device? The RainshdowTech device provides a character
> based TTY device for passing/receiving CEC messages, so doesn’t use
> “native” CEC commands (ie physical device ID is stored in flash and
> hence not provided to the bridge on each command).

Well, I already provide some abstraction with libcec, but the underling 
target layer has to be able to handle HDMI-CEC data. Therefore, if your 
device converts that data into something else (which basically means 
they provide their own abstraction layer), you would first have to 
convert the HDMI-CEC data fed by libcec into your device's non-native 
format.

But cecd does provide abstraction in the form of libcec, and all you 
have to do then is add a new hardware layer, or "backend", that 
implements all of the API calls defined in the _ceci_backend struct you 
will find in libceci.h.

Therefore, I don't see a major problem with adding the RainshadowTech 
device. All you have to do is write a backend that implements init(), 
exit(), open(), close(), set_logical_address(), read_edid(), 
read_message(), write_message(), and feeds the relevant data to the 
serial port, and you should be fine.

The only potential problem you may have is if your device does not allow 
the readout of the EDID data, but you can probably work around that.

> Also, are there any plans to provide a pass-off for external programs to
> handle events? For example, I use MythTv as a PVR, and I am interested
> in using CEC from the TV remote to control the MythTv functions (

Yes there is. It's part of the stuff I still haven't completed yet.
If you look at the sample cecd.conf I provide [1], you'll see that there 
is a target device specified, which is currently set to a device, but 
doesn't necessarily have to be.

When cecd is complete, the target could be a pipe to an application to 
provide input. And each command entry should also be able to specify 
something like "/usr/bin/mythtv <options>" or "/usr/sbin/shutdown" to 
call on a system binary directly and perform an action other than 
sending some data to an entrypoint.

I'll see what I can do to finalize these features. If you want to 
develop a new backend for the RainshadowTech device, I'll be happy to 
add it to the project, or answer any question you might have.

Time permitting, I also have some plans to port the library to Windows, 
where I guess, considering the current reluctance of nVidia and ATI to 
implement HDMI-CEC support on their GPUs, the RainshadowTech would 
probably be the only device we'd support there...

Regards,

/Pete

[1] 
http://cecd.git.sourceforge.net/git/gitweb.cgi?p=cecd/cecd;a=blob;f=cecd/sample_config/cecd.conf