According to wikipedia definition : “Consumer Electronics Control (CEC) is an HDMI feature designed to allow the user to command and control up-to 15 CEC-enabled devices, that are connected through HDMI by using only one of their remote controls (for example by controlling a television set, set-top box, and DVD player using only the remote control of the TV). CEC also allows for individual CEC-enabled devices to command and control each other without user intervention.
It is a one-wire bidirectional serial bus that is based on the CENELEC standard AV.link protocol to perform remote control functions.”
Since the Eden release XBMC has support for CEC thanks to libCEC. Besides the freescale i.MX6 SOC is able to handle this bus by itself : There is no need to buy an additional USB device such as this one.
Unfortunately, so far, nobody publicly added i.MX6 CEC support in libCEC. It was a shame and I decided to address this issue.
While developing this missing part, I had to tackle 3 tasks :
- Finding a hardware platform to develop and test this feature
- Adding support in libCEC
- Solving issues with the CEC driver itself
The first item may seem trivial but it is not. Indeed, many iMX6 products/boards do not properly wire the CEC signal.
Here are the info I gathered :
- Wandboard was reported by a user to have CEC signal unconnected in this comment which refers to wandboard forums
Edit (october, 12): After lots of comments, I confirm that no wandboard version is properly wired to use CEC (At this time at least). But if you have a wandboard quad and are able to use a soldering iron, then have a look at this thread
- GK802 is no longer of interest to me : It is a device with no engineering support nor official technical data. It is not properly cooled. It has a very attractive price but, as a developer, I lost enough time with it. CEC signal may be connected or not, I don’t care as I know I will have no resource to understand what happens if it does not work…
- I also know that nitrogen6x (I don’t own that board by myself) from boundary devices does not expose the CEC signal (thanks to this comment)
- My utilite pro would have been a perfect device to test CEC. Unfortunately, my device comes from an early batch which was not properly wired (while currently produced devices are all good).
So, at the end, finding the right device for this development was not so easy. Fortunately compulab was kind enough to send me a new utilite from their new batch (and a properly wired CEC signal). I am about to publish a XBMC image with CEC support for utilite as a way to thank them for their support.
Then adding support for a new adapter in libCEC was not so hard : The code is well structured and there is obviously a provision to add new devices.
At some stage, I found that support for existing devices was a little cumbersome but I finally understood that the real culprit was not libCEC but the interface with underlying hardware and that I was able to have a simpler implementation as long as the driver allows for it. Note that, for now, I have not added support to handle several logical addresses at the same time (The hardware allows for it but there is not yet support in the driver for this)
And so we come to the third item : The CEC kernel driver. Freescale provides this driver but I was a little surprised of the current state of this driver (in the their BSP V4.0.0 or V4.1.0). It is supposed to be a simple character device (which is just fine) but I found quite a few shortcomings.
- First they don’t care about being compliant with the well known POSIX interface :
The read syscall will immediately return if no data is available even if the device is not opened with the O_NONBLOCK flag.
This same read syscall will return a false value (ie not the effective number of bytes seen by userspace)
The write syscall will return 0 if successful while it should return the number of written bytes
The poll syscall will never state that the device is writable
- Then they do not properly release the IRQ when the kernel module is unloaded (because of this, you will not be able to reload the module a second time)
- At last, they use locking in a sometime hazardous way and even copy/paste comments from “vpu” in this driver…
As a conclusion, this driver has not been very carefully developed and is misleading when you try to use it at first time.
But I don’t blame freescale for this : At least they release this driver and, that way, they allow to enhance it. All the more as they also provide an excellent reference manual which describes very well the hardware interface.
So I had to solve the afforded mentioned items in order to use it smoothly from libCEC.
At the end, I rebuilt XBMC with CEC support and was able to give it a try faced to my panasonic PZ81 TV.
And… it works just fine !
I am able to browse XBMC GUI with my TV remote.
I have already published my changes for libCEC here and will try to mainline them.
Changes for the kernel driver should be released next week.
[Edit : A first (still wip) patch is now public]
Last but not least, all this work is useful only if a product can take advantage of it. So here is a XBMC image which provides XBMC with CEC support targeted at utilite here.