From: Florian Fainelli <f.fainelli@gmail.com>
To: linux-media@vger.kernel.org, marbugge@cisco.com, hverkuil@cisco.com
Subject: Re: [RFC] HDMI-CEC proposal
Date: Thu, 12 Apr 2012 17:24:22 +0200 [thread overview]
Message-ID: <4F86F3A6.9040305@gmail.com> (raw)
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
next reply other threads:[~2012-04-12 15:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-12 15:24 Florian Fainelli [this message]
2012-04-12 20:36 ` [RFC] HDMI-CEC proposal Oliver Schinagl
2012-04-13 5:03 ` Hans Verkuil
2012-04-13 9:27 ` Florian Fainelli
2012-04-17 13:31 ` Anssi Hannula
2012-04-17 13:44 ` Oliver Schinagl
[not found] <CAH-Z1=WtUrS0HYMsOb9CarAcXhR72cO8QWAnUJdP+zDuj92Rxg@mail.gmail.com>
2012-05-10 11:43 ` Florian Fainelli
2012-05-10 12:11 ` Hans Verkuil
-- strict thread matches above, loose matches on Subject: below --
2011-03-01 9:59 Martin Bugge (marbugge)
2011-03-01 12:28 ` Mauro Carvalho Chehab
2011-03-01 14:38 ` Hans Verkuil
2011-03-01 15:20 ` Mauro Carvalho Chehab
2011-03-01 15:49 ` Hans Verkuil
2011-03-01 16:19 ` Mauro Carvalho Chehab
2011-03-01 17:09 ` Hans Verkuil
2011-03-01 13:47 ` Andy Walls
2011-03-01 14:59 ` Martin Bugge (marbugge)
2011-03-01 17:31 ` Hans Verkuil
2011-03-01 17:52 ` Alex Deucher
2011-03-02 9:13 ` Hans Verkuil
2011-03-02 15:49 ` Alex Deucher
2011-03-01 23:38 ` Daniel Glöckner
2011-03-02 9:34 ` Martin Bugge (marbugge)
2011-03-03 10:37 ` Laurent Pinchart
2011-03-03 12:11 ` Martin Bugge (marbugge)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F86F3A6.9040305@gmail.com \
--to=f.fainelli@gmail.com \
--cc=hverkuil@cisco.com \
--cc=linux-media@vger.kernel.org \
--cc=marbugge@cisco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.