From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
linux-media <linux-media@vger.kernel.org>,
dri-devel@lists.freedesktop.org
Subject: Re: Update on the CEC API
Date: Tue, 9 Oct 2012 18:27:25 -0300 [thread overview]
Message-ID: <20121009182725.4275d8cc@redhat.com> (raw)
In-Reply-To: <2023416.fd8kVxWoQJ@flexo>
Em Mon, 08 Oct 2012 19:45:14 +0200
Florian Fainelli <f.fainelli@gmail.com> escreveu:
> On Monday 08 October 2012 17:49:00 Hans Verkuil wrote:
> > On Mon October 8 2012 17:06:20 Florian Fainelli wrote:
> > > Hi Hans,
> > >
> > > On Thursday 27 September 2012 16:33:30 Hans Verkuil wrote:
> > > > Hi all,
> > > >
> > > > During the Linux Plumbers Conference we (i.e. V4L2 and DRM developers) had a
> > > > discussion on how to handle the CEC protocol that's part of the HDMI
> > > standard.
> > > >
> > > > The decision was made to create a CEC bus with CEC clients, each represented
> > > > by a /dev/cecX device. So this is independent of the V4L or DRM APIs.
> > > >
> > > > In addition interested subsystems (alsa for the Audio Return Channel, and
> > > > possibly networking as well for ethernet over HDMI) can intercept/send CEC
> > > > messages as well if needed. Particularly for the CEC additions made in
> > > > HDMI 1.4a it is no longer possible to handle the CEC protocol completely in
> > > > userspace, but part of the intelligence has to be moved to kernelspace.
...
> > Also remote control messages might optionally be handled through an input driver.
>
> Ok, then maybe just stick to the standard CEC_UI_* key codes, and let people
> having proprietary UI functions do the rest in user-space, or write their own
> input driver.
No. The RC core already provides standard ways for userspace to read/add/replace
the scancode -> Linux keycode using the standard Kernel mechanisms for that.
All it is needed is to use an userspace program for that (with already exists).
So, there's absolutely no need for per-vendor kernelspace/userspace drivers.
The RC core also allows sending remote controller keystrokes. The userspace API
currently works only with IR raw codes. There are, however, discussions and some
RFC patches proposing some changes there to also accept scancodes (and/or
Linux keycodes) to be passed for the Remote Controller TX drivers.
So, from remote controller standpoint, just one driver will be enough to handle
HDMI CEC.
Regards,
Mauro
prev parent reply other threads:[~2012-10-09 21:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201209271633.30812.hverkuil@xs4all.nl>
2012-10-08 15:06 ` Update on the CEC API Florian Fainelli
2012-10-08 15:49 ` Hans Verkuil
2012-10-08 17:45 ` Florian Fainelli
2012-10-09 21:27 ` Mauro Carvalho Chehab [this message]
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=20121009182725.4275d8cc@redhat.com \
--to=mchehab@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=f.fainelli@gmail.com \
--cc=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).