Re: [RFC] HDMI-CEC proposal

[Florian Fainelli <f.fainelli@gmail.com>]

Hi Hans, Martin,

Sorry to jump in so late in the HDMI-CEC discussion, here are some 
comments from my perspective on your proposal:

- the HDMI-CEC implementation deserves its own bus and class of devices 
because by definition it is a physical bus, which is even electrically 
independant from the rest of the HDMI bus (A/V path)

- I don't think it is a good idea to tight it so closely to v4l, because 
one can perfectly have CEC-capable hardware without video, or at least 
not use v4l and have HDMI-CEC hardware

- it was suggested to use sockets at some point, I think it is 
over-engineered and should only lead

- processing messages in user-space is definitively the way to go, even 
input can be either re-injected using an uinput driver, or be handled in 
user-space entirely, eventually we might want to install "filters" based 
on opcodes to divert some opcodes to a kernel consumer, and the others 
to an user-space one

Right now, I have a very simple implementation that I developed for the 
company I work for which can be found here: 
https://github.com/ffainelli/linux-hdmi-cec

It is designed like this:

1) A core module, which registers a cec bus, and provides an abstraction 
for a CEC adapter (both device & driver):
- basic CEC adapter operations: logical address setting, queueing management
- counters, rx filtering
- host attaching/detaching in case the hardware is capable of 
self-processing CEC messages (for wakeup in particular)

2) A character device module, which exposes a character device per CEC 
adapter and only allows one consumer at a time and exposes the following 
ioctl's:

- SET_LOGICAL_ADDRESS
- RESET_DEVICE
- GET_COUNTERS
- SET_RX_MODE (my adapter can be set in a promiscuous mode)

the character device supports read/write/poll, which are the prefered 
ways for transfering/receiving data

3) A CEC adapter implementation which registers and calls into the core 
module when receiving a CEC message, and which the core module calls in 
response to the IOCTLs described below.

At first I thought about defining a generic netlink family in order to 
allow multiple user-space listeners receive CEC messages, but in the end 
having only one consumer per adapter device is fine by me and a more 
traditionnal approach for programmers.

I am relying on external components for knowing my HDMI physical address.

Hope this is not too late to (re)start the discussion on HDMI-CEC.

Thank you very much.
--
Florian