Re: Update on the CEC API

Re: Update on the CEC API

[Florian Fainelli]

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.

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

- allow for a CEC adapter to define several receive modes: unicast and 
"promiscuous", which is useful for dumping the CEC bus messages

- 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

Thank you!
--
Florian

Re: Update on the CEC API

[Hans Verkuil]

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.

> 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.

> - 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.

Regards,

	Hans

Re: 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

Re: Update on the CEC API

[Mauro Carvalho Chehab]

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