Update on the CEC API

[Florian Fainelli]

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.
> > 
> > What kind of "intelligence" are you talking about? I see nothing in HDMI 1.4a 
> > or earlier that requires doing stuff in kernelspace besides managing control to 
> > the hardware, but I might be missing something.
> 
> Most notably: handling the new hotplug message. That's something that kernel
> drivers need to know. Some ARC messages might be relevant for ALSA drivers as
> well, but I need to look into those more carefully.
> 
> 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.

> 
> > In my opinion ARC is just a control mechanism, and can be dealt with in user-
> > space, since you really want to just have hints about when ARC is 
> > enabled/disabled to take appropriate actions on the audio outputs or your 
> > system.
> > 
> > > 
> > > I've started working on this API but I am still at the stage of playing
> > > around with it and thinking about the best way this functionality should
> > > be exposed. At least I managed to get the first CEC packets transferred
> > > today :-)
> > > 
> > > It will probably be a few weeks before I post something, but in the meantime
> > > if you want to use CEC and have certain requirements that need to be met,
> > > please let me know. If only so that I can be certain I haven't forgotten
> > > anything.
> > 
> > Here is my wish-list, if I may:
> > - allow for a CEC adapter to be in "detached" / "attached" mode, particularly 
> > useful if the hardware doing CEC can process a basic set of messages to act a 
> > a global wake-up source for the system
> 
> I have hardware that can do that, so I want to look into supporting this.
> 
> > - allow for a CEC adapter to define several receive modes: unicast and 
> > "promiscuous", which is useful for dumping the CEC bus messages
> 
> I don't think I have hardware for that, but it shouldn't be difficult to add.

Definitively not, just let a driver writer specify a flag to advertise this
capability and have a getter/setter to specify the receive mode.

> 
> > - make the CEC adapter API asynchronous for the data path, so it is easy for a 
> > driver to report completion of a successfully transmitted/received CEC frame
> 
> Already done.

Great, thanks!
--
Florian