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