Since a lot of video cards dont' support CEC at all (not even
connected), don't have hdmi, but work perfectly fine with dvi->hdmi
adapters, CEC can be implemented in many other ways (think media centers)
One such exammple is using USB/Arduino
http://code.google.com/p/cec-arduino/wiki/ElectricalInterface
Having an AVR with v-usb code and cec code doesn't look all that hard
nor impossible, so one could simply have a USB plug on one end, and an
HDMI plug on the other end, utilizing only the CEC pins.
This would make it more something like LIRC if anything.
On 04/12/12 17:24, Florian Fainelli wrote:
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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
