[RFC] HDMI-CEC proposal

[RFC] HDMI-CEC proposal

[Martin Bugge (marbugge)]

Author: Martin Bugge <marbugge@cisco.com>
Date:  Tue, 1 March 2010
======================

This is a proposal for adding a Consumer Electronic Control (CEC) API to 
V4L2.
This document describes the changes and new ioctls needed.

Version 1.0 (This is first version)

Background
==========
CEC is a protocol that provides high-level control functions between 
various audiovisual products.
It is an optional supplement to the High-Definition Multimedia Interface 
Specification (HDMI).
Physical layer is a one-wire bidirectional serial bus that uses the 
industry-standard AV.link protocol.

In short: CEC uses pin 13 on the HDMI connector to transmit and receive 
small data-packets
           (maximum 16 bytes including a 1 byte header) at low data 
rates (~400 bits/s).

A CEC device may have any of 15 logical addresses (0 - 14).
(address 15 is broadcast and some addresses are reserved)


References
==========
[1] High-Definition Multimedia Interface Specification version 1.3a,
     Supplement 1 Consumer Electronic Control (CEC).
     http://www.hdmi.org/manufacturer/specification.aspx

[2] 
http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf


Proposed solution
=================

Two new ioctls:
     VIDIOC_CEC_CAP (read)
     VIDIOC_CEC_CMD (read/write)

VIDIOC_CEC_CAP:
---------------

struct vl2_cec_cap {
        __u32 logicaldevices;
        __u32 reserved[7];
};

The capability ioctl will return the number of logical devices/addresses 
which can be
simultaneously supported on this HW.
     0:       This HW don't support CEC.
     1 -> 14: This HW supports n logical devices simultaneously.

VIDIOC_CEC_CMD:
---------------

struct v4l2_cec_cmd {
     __u32 cmd;
     __u32 reserved[7];
     union {
         struct {
             __u32 index;
             __u32 enable;
             __u32 addr;
         } conf;
         struct {
             __u32 len;
             __u8  msg[16];
             __u32 status;
         } data;
         __u32 raw[8];
     };
};

Alternatively the data struct could be:
         struct {
             __u8  initiator;
             __u8  destination;
             __u8  len;
             __u8  msg[15];
             __u32 status;
         } data;

Commands:

#define V4L2_CEC_CMD_CONF  (1)
#define V4L2_CEC_CMD_TX    (2)
#define V4L2_CEC_CMD_RX    (3)

Tx status field:

#define V4L2_CEC_STAT_TX_OK            (0)
#define V4L2_CEC_STAT_TX_ARB_LOST      (1)
#define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)

The command ioctl is used both for configuration and to receive/transmit 
data.

* The configuration command must be done for each logical device address
   which is to be enabled on this HW. Maximum number of logical devices
   is found with the capability ioctl.
     conf:
          index:  0 -> number_of_logical_devices-1
          enable: true/false
          addr:   logical address

   By default all logical devices are disabled.

* Tx/Rx command
     data:
          len:    length of message (data + header)
          msg:    the raw CEC message received/transmitted
          status: when the driver is in blocking mode it gives the 
result for transmit.

Events
------

In the case of non-blocking mode the driver will issue the following events:

V4L2_EVENT_CEC_TX
V4L2_EVENT_CEC_RX

V4L2_EVENT_CEC_TX
-----------------
  * transmit is complete with the following status:
Add an additional struct to the struct v4l2_event

struct v4l2_event_cec_tx {
        __u32 status;
}

V4L2_EVENT_CEC_RX
-----------------
  * received a complete message


Comments ?

            Martin Bugge

--
Martin Bugge - Tandberg (now a part of Cisco)
--

Re: [RFC] HDMI-CEC proposal

[Mauro Carvalho Chehab]

Hi Martin,

Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu:
> Author: Martin Bugge <marbugge@cisco.com>
> Date:  Tue, 1 March 2010
> ======================
> 
> This is a proposal for adding a Consumer Electronic Control (CEC) API to V4L2.
> This document describes the changes and new ioctls needed.
> 
> Version 1.0 (This is first version)
> 
> Background
> ==========
> CEC is a protocol that provides high-level control functions between various audiovisual products.
> It is an optional supplement to the High-Definition Multimedia Interface Specification (HDMI).
> Physical layer is a one-wire bidirectional serial bus that uses the industry-standard AV.link protocol.
> 
> In short: CEC uses pin 13 on the HDMI connector to transmit and receive small data-packets
>           (maximum 16 bytes including a 1 byte header) at low data rates (~400 bits/s).
> 
> A CEC device may have any of 15 logical addresses (0 - 14).
> (address 15 is broadcast and some addresses are reserved)
> 
> 
> References
> ==========
> [1] High-Definition Multimedia Interface Specification version 1.3a,
>     Supplement 1 Consumer Electronic Control (CEC).
>     http://www.hdmi.org/manufacturer/specification.aspx
> 
> [2] http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
> 
> 
> Proposed solution
> =================
> 
> Two new ioctls:
>     VIDIOC_CEC_CAP (read)
>     VIDIOC_CEC_CMD (read/write)

How this proposal will interact with RC core? The way I see it, HDMI-CEC is just a way to get/send
Remote Controller data, and should be interacting with the proper Kernel subsystems, e. g.,
with Remote Controller and input/event subsystems.

I don't think we need two ioctls for that, as RC capabilities are already exported via
sysfs, and we have two interfaces already for receiving events (input/event and lirc).
For sending, lirc interface might be used, but it is currently focused only on sending
raw pulse/space sequences. So, we'll need to add some capability there for IR/CEC TX.
I had a few discussions about that with Jarod, but we didn't write yet an interface for it.


> 
> VIDIOC_CEC_CAP:
> ---------------
> 
> struct vl2_cec_cap {
>        __u32 logicaldevices;
>        __u32 reserved[7];
> };
> 
> The capability ioctl will return the number of logical devices/addresses which can be
> simultaneously supported on this HW.
>     0:       This HW don't support CEC.
>     1 -> 14: This HW supports n logical devices simultaneously.
> 
> VIDIOC_CEC_CMD:
> ---------------
> 
> struct v4l2_cec_cmd {
>     __u32 cmd;
>     __u32 reserved[7];
>     union {
>         struct {
>             __u32 index;
>             __u32 enable;
>             __u32 addr;
>         } conf;
>         struct {
>             __u32 len;
>             __u8  msg[16];
>             __u32 status;
>         } data;
>         __u32 raw[8];
>     };
> };
> 
> Alternatively the data struct could be:
>         struct {
>             __u8  initiator;
>             __u8  destination;
>             __u8  len;
>             __u8  msg[15];
>             __u32 status;
>         } data;
> 
> Commands:
> 
> #define V4L2_CEC_CMD_CONF  (1)
> #define V4L2_CEC_CMD_TX    (2)
> #define V4L2_CEC_CMD_RX    (3)
> 
> Tx status field:
> 
> #define V4L2_CEC_STAT_TX_OK            (0)
> #define V4L2_CEC_STAT_TX_ARB_LOST      (1)
> #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
> 
> The command ioctl is used both for configuration and to receive/transmit data.
> 
> * The configuration command must be done for each logical device address
>   which is to be enabled on this HW. Maximum number of logical devices
>   is found with the capability ioctl.
>     conf:
>          index:  0 -> number_of_logical_devices-1
>          enable: true/false
>          addr:   logical address
> 
>   By default all logical devices are disabled.
> 
> * Tx/Rx command
>     data:
>          len:    length of message (data + header)
>          msg:    the raw CEC message received/transmitted
>          status: when the driver is in blocking mode it gives the result for transmit.
> 
> Events
> ------
> 
> In the case of non-blocking mode the driver will issue the following events:
> 
> V4L2_EVENT_CEC_TX
> V4L2_EVENT_CEC_RX
> 
> V4L2_EVENT_CEC_TX
> -----------------
>  * transmit is complete with the following status:
> Add an additional struct to the struct v4l2_event
> 
> struct v4l2_event_cec_tx {
>        __u32 status;
> }
> 
> V4L2_EVENT_CEC_RX
> -----------------
>  * received a complete message
> 
> 
> Comments ?
> 
>            Martin Bugge
> 
> -- 
> Martin Bugge - Tandberg (now a part of Cisco)
> -- 
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] HDMI-CEC proposal

[Hans Verkuil]

Hi Mauro,

On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote:
> Hi Martin,
> 
> Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu:
> > Author: Martin Bugge <marbugge@cisco.com>
> > Date:  Tue, 1 March 2010
> > ======================
> > 
> > This is a proposal for adding a Consumer Electronic Control (CEC) API to 
V4L2.
> > This document describes the changes and new ioctls needed.
> > 
> > Version 1.0 (This is first version)
> > 
> > Background
> > ==========
> > CEC is a protocol that provides high-level control functions between 
various audiovisual products.
> > It is an optional supplement to the High-Definition Multimedia Interface 
Specification (HDMI).
> > Physical layer is a one-wire bidirectional serial bus that uses the 
industry-standard AV.link protocol.
> > 
> > In short: CEC uses pin 13 on the HDMI connector to transmit and receive 
small data-packets
> >           (maximum 16 bytes including a 1 byte header) at low data rates 
(~400 bits/s).
> > 
> > A CEC device may have any of 15 logical addresses (0 - 14).
> > (address 15 is broadcast and some addresses are reserved)
> > 
> > 
> > References
> > ==========
> > [1] High-Definition Multimedia Interface Specification version 1.3a,
> >     Supplement 1 Consumer Electronic Control (CEC).
> >     http://www.hdmi.org/manufacturer/specification.aspx
> > 
> > [2] 
http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
> > 
> > 
> > Proposed solution
> > =================
> > 
> > Two new ioctls:
> >     VIDIOC_CEC_CAP (read)
> >     VIDIOC_CEC_CMD (read/write)
> 
> How this proposal will interact with RC core? The way I see it, HDMI-CEC is 
just a way to get/send
> Remote Controller data, and should be interacting with the proper Kernel 
subsystems, e. g.,
> with Remote Controller and input/event subsystems.

I knew you were going to mention this :-)

Actually, while CEC does support IR commands, this is only a very small part 
of the standard. Routing IR commands to the IR core is possible to do, 
although it is not in this initial version. Should this be needed, then a flag 
can be created that tells V4L to route IR commands to the IR core.

This should be optional, though, because if you are a repeater you do not want 
to pass such IR commands to the IR core, instead you want to retransmit them 
to a CEC output.

> 
> I don't think we need two ioctls for that, as RC capabilities are already 
exported via
> sysfs, and we have two interfaces already for receiving events (input/event 
and lirc).
> For sending, lirc interface might be used, but it is currently focused only 
on sending
> raw pulse/space sequences. So, we'll need to add some capability there for 
IR/CEC TX.
> I had a few discussions about that with Jarod, but we didn't write yet an 
interface for it.

Again, CEC != IR. All you need is a simple API to be able to send and receive 
CEC packets and a libcec that you can use to do the topology discovery and 
send/receive the commands. You don't want nor need that in the kernel.

The only place where routing things to the IR core is useful is when someone 
points a remote at a TV (for example), which then passes it over CEC to your 
device which is not a repeater but can actually handle the remote command.

This is a future extension, though.

Regards,

	Hans

> 
> 
> > 
> > VIDIOC_CEC_CAP:
> > ---------------
> > 
> > struct vl2_cec_cap {
> >        __u32 logicaldevices;
> >        __u32 reserved[7];
> > };
> > 
> > The capability ioctl will return the number of logical devices/addresses 
which can be
> > simultaneously supported on this HW.
> >     0:       This HW don't support CEC.
> >     1 -> 14: This HW supports n logical devices simultaneously.
> > 
> > VIDIOC_CEC_CMD:
> > ---------------
> > 
> > struct v4l2_cec_cmd {
> >     __u32 cmd;
> >     __u32 reserved[7];
> >     union {
> >         struct {
> >             __u32 index;
> >             __u32 enable;
> >             __u32 addr;
> >         } conf;
> >         struct {
> >             __u32 len;
> >             __u8  msg[16];
> >             __u32 status;
> >         } data;
> >         __u32 raw[8];
> >     };
> > };
> > 
> > Alternatively the data struct could be:
> >         struct {
> >             __u8  initiator;
> >             __u8  destination;
> >             __u8  len;
> >             __u8  msg[15];
> >             __u32 status;
> >         } data;
> > 
> > Commands:
> > 
> > #define V4L2_CEC_CMD_CONF  (1)
> > #define V4L2_CEC_CMD_TX    (2)
> > #define V4L2_CEC_CMD_RX    (3)
> > 
> > Tx status field:
> > 
> > #define V4L2_CEC_STAT_TX_OK            (0)
> > #define V4L2_CEC_STAT_TX_ARB_LOST      (1)
> > #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
> > 
> > The command ioctl is used both for configuration and to receive/transmit 
data.
> > 
> > * The configuration command must be done for each logical device address
> >   which is to be enabled on this HW. Maximum number of logical devices
> >   is found with the capability ioctl.
> >     conf:
> >          index:  0 -> number_of_logical_devices-1
> >          enable: true/false
> >          addr:   logical address
> > 
> >   By default all logical devices are disabled.
> > 
> > * Tx/Rx command
> >     data:
> >          len:    length of message (data + header)
> >          msg:    the raw CEC message received/transmitted
> >          status: when the driver is in blocking mode it gives the result 
for transmit.
> > 
> > Events
> > ------
> > 
> > In the case of non-blocking mode the driver will issue the following 
events:
> > 
> > V4L2_EVENT_CEC_TX
> > V4L2_EVENT_CEC_RX
> > 
> > V4L2_EVENT_CEC_TX
> > -----------------
> >  * transmit is complete with the following status:
> > Add an additional struct to the struct v4l2_event
> > 
> > struct v4l2_event_cec_tx {
> >        __u32 status;
> > }
> > 
> > V4L2_EVENT_CEC_RX
> > -----------------
> >  * received a complete message
> > 
> > 
> > Comments ?
> > 
> >            Martin Bugge
> > 
> > -- 
> > Martin Bugge - Tandberg (now a part of Cisco)
> > -- 
> > 
> > -- 
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: [RFC] HDMI-CEC proposal

[Mauro Carvalho Chehab]

Em 01-03-2011 11:38, Hans Verkuil escreveu:
> Hi Mauro,
> 
> On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote:
>> Hi Martin,
>>
>> Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu:
>>> Author: Martin Bugge <marbugge@cisco.com>
>>> Date:  Tue, 1 March 2010
>>> ======================
>>>
>>> This is a proposal for adding a Consumer Electronic Control (CEC) API to 
> V4L2.
>>> This document describes the changes and new ioctls needed.
>>>
>>> Version 1.0 (This is first version)
>>>
>>> Background
>>> ==========
>>> CEC is a protocol that provides high-level control functions between 
> various audiovisual products.
>>> It is an optional supplement to the High-Definition Multimedia Interface 
> Specification (HDMI).
>>> Physical layer is a one-wire bidirectional serial bus that uses the 
> industry-standard AV.link protocol.
>>>
>>> In short: CEC uses pin 13 on the HDMI connector to transmit and receive 
> small data-packets
>>>           (maximum 16 bytes including a 1 byte header) at low data rates 
> (~400 bits/s).
>>>
>>> A CEC device may have any of 15 logical addresses (0 - 14).
>>> (address 15 is broadcast and some addresses are reserved)
>>>
>>>
>>> References
>>> ==========
>>> [1] High-Definition Multimedia Interface Specification version 1.3a,
>>>     Supplement 1 Consumer Electronic Control (CEC).
>>>     http://www.hdmi.org/manufacturer/specification.aspx
>>>
>>> [2] 
> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
>>>
>>>
>>> Proposed solution
>>> =================
>>>
>>> Two new ioctls:
>>>     VIDIOC_CEC_CAP (read)
>>>     VIDIOC_CEC_CMD (read/write)
>>
>> How this proposal will interact with RC core? The way I see it, HDMI-CEC is 
> just a way to get/send
>> Remote Controller data, and should be interacting with the proper Kernel 
> subsystems, e. g.,
>> with Remote Controller and input/event subsystems.
> 
> I knew you were going to mention this :-)
> 
> Actually, while CEC does support IR commands, this is only a very small part 
> of the standard. Routing IR commands to the IR core is possible to do, 
> although it is not in this initial version. Should this be needed, then a flag 
> can be created that tells V4L to route IR commands to the IR core.
> 
> This should be optional, though, because if you are a repeater you do not want 
> to pass such IR commands to the IR core, instead you want to retransmit them 
> to a CEC output.
> 
>>
>> I don't think we need two ioctls for that, as RC capabilities are already 
> exported via
>> sysfs, and we have two interfaces already for receiving events (input/event 
> and lirc).
>> For sending, lirc interface might be used, but it is currently focused only 
> on sending
>> raw pulse/space sequences. So, we'll need to add some capability there for 
> IR/CEC TX.
>> I had a few discussions about that with Jarod, but we didn't write yet an 
> interface for it.
> 
> Again, CEC != IR. All you need is a simple API to be able to send and receive 
> CEC packets and a libcec that you can use to do the topology discovery and 
> send/receive the commands. You don't want nor need that in the kernel.
> 
> The only place where routing things to the IR core is useful is when someone 
> points a remote at a TV (for example), which then passes it over CEC to your 
> device which is not a repeater but can actually handle the remote command.
> 
> This is a future extension, though.

There are two separate things when dealing with CEC: the low-level kernel
implementation of a bus for connecting with CEC devices, and userspace APIs
for using its features.

If you were needing it only internally inside the kernel, there's no need for 
new ioctl's. So, your proposal seems to add a raw interface for it, and do 
all the work in userspace.

An alternative approach, that it is the way most Kernel API's do is to write/use
higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC, input/event,
vfs, tty, etc are good examples of how we do APIs in Linux. We should only go 
to a raw API if the high-level ones won't work. 

Also, a raw-level implementation of CEC may/will interfere on higher level
interfaces. For example, assuming that we have both raw and RC interfaces using 
HDMI-CIC, a raw access on one process during a RC reception or transmit could 
interfere on another process using the high-level interface for RC (as a raw
access to a block device may actually corrupt data). So, raw interfaces are
evil, and generally require CAP_SYS_ADMIN.

So, I think we should first discuss what are the needs, and then discuss how
to implement them.

Cheers,
Mauro.

Re: [RFC] HDMI-CEC proposal

[Hans Verkuil]

On Tuesday, March 01, 2011 16:20:25 Mauro Carvalho Chehab wrote:
> Em 01-03-2011 11:38, Hans Verkuil escreveu:
> > Hi Mauro,
> > 
> > On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote:
> >> Hi Martin,
> >>
> >> Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu:
> >>> Author: Martin Bugge <marbugge@cisco.com>
> >>> Date:  Tue, 1 March 2010
> >>> ======================
> >>>
> >>> This is a proposal for adding a Consumer Electronic Control (CEC) API to 
> > V4L2.
> >>> This document describes the changes and new ioctls needed.
> >>>
> >>> Version 1.0 (This is first version)
> >>>
> >>> Background
> >>> ==========
> >>> CEC is a protocol that provides high-level control functions between 
> > various audiovisual products.
> >>> It is an optional supplement to the High-Definition Multimedia Interface 
> > Specification (HDMI).
> >>> Physical layer is a one-wire bidirectional serial bus that uses the 
> > industry-standard AV.link protocol.
> >>>
> >>> In short: CEC uses pin 13 on the HDMI connector to transmit and receive 
> > small data-packets
> >>>           (maximum 16 bytes including a 1 byte header) at low data rates 
> > (~400 bits/s).
> >>>
> >>> A CEC device may have any of 15 logical addresses (0 - 14).
> >>> (address 15 is broadcast and some addresses are reserved)
> >>>
> >>>
> >>> References
> >>> ==========
> >>> [1] High-Definition Multimedia Interface Specification version 1.3a,
> >>>     Supplement 1 Consumer Electronic Control (CEC).
> >>>     http://www.hdmi.org/manufacturer/specification.aspx
> >>>
> >>> [2] 
> > http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
> >>>
> >>>
> >>> Proposed solution
> >>> =================
> >>>
> >>> Two new ioctls:
> >>>     VIDIOC_CEC_CAP (read)
> >>>     VIDIOC_CEC_CMD (read/write)
> >>
> >> How this proposal will interact with RC core? The way I see it, HDMI-CEC 
is 
> > just a way to get/send
> >> Remote Controller data, and should be interacting with the proper Kernel 
> > subsystems, e. g.,
> >> with Remote Controller and input/event subsystems.
> > 
> > I knew you were going to mention this :-)
> > 
> > Actually, while CEC does support IR commands, this is only a very small 
part 
> > of the standard. Routing IR commands to the IR core is possible to do, 
> > although it is not in this initial version. Should this be needed, then a 
flag 
> > can be created that tells V4L to route IR commands to the IR core.
> > 
> > This should be optional, though, because if you are a repeater you do not 
want 
> > to pass such IR commands to the IR core, instead you want to retransmit 
them 
> > to a CEC output.
> > 
> >>
> >> I don't think we need two ioctls for that, as RC capabilities are already 
> > exported via
> >> sysfs, and we have two interfaces already for receiving events 
(input/event 
> > and lirc).
> >> For sending, lirc interface might be used, but it is currently focused 
only 
> > on sending
> >> raw pulse/space sequences. So, we'll need to add some capability there 
for 
> > IR/CEC TX.
> >> I had a few discussions about that with Jarod, but we didn't write yet an 
> > interface for it.
> > 
> > Again, CEC != IR. All you need is a simple API to be able to send and 
receive 
> > CEC packets and a libcec that you can use to do the topology discovery and 
> > send/receive the commands. You don't want nor need that in the kernel.
> > 
> > The only place where routing things to the IR core is useful is when 
someone 
> > points a remote at a TV (for example), which then passes it over CEC to 
your 
> > device which is not a repeater but can actually handle the remote command.
> > 
> > This is a future extension, though.
> 
> There are two separate things when dealing with CEC: the low-level kernel
> implementation of a bus for connecting with CEC devices, and userspace APIs
> for using its features.
> 
> If you were needing it only internally inside the kernel, there's no need 
for 
> new ioctl's. So, your proposal seems to add a raw interface for it, and do 
> all the work in userspace.
> 
> An alternative approach, that it is the way most Kernel API's do is to 
write/use
> higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC, 
input/event,
> vfs, tty, etc are good examples of how we do APIs in Linux. We should only 
go 
> to a raw API if the high-level ones won't work. 

What high-level API? There isn't much high-level about CEC. It's a very 
simplistic standard. Each packet has a source and destination address (0-14 
which you can choose yourself), an optional command with an optional payload. 
You can put in pretty much what you want since you can make custom commands as 
well.

You also assume that you can handle packets at a high level. But you can't, 
because what you want to do with packets depends very much on what device you 
are: TV, recorder, set-top, CEC switch, etc.

> Also, a raw-level implementation of CEC may/will interfere on higher level
> interfaces. For example, assuming that we have both raw and RC interfaces 
using 
> HDMI-CIC, a raw access on one process during a RC reception or transmit 
could 
> interfere on another process using the high-level interface for RC (as a raw
> access to a block device may actually corrupt data). So, raw interfaces are
> evil, and generally require CAP_SYS_ADMIN.

??? If we add a flag that causes the IR commands to go to the IR core, then 
they will obviously not appear on the normal CEC interface.

> So, I think we should first discuss what are the needs, and then discuss how
> to implement them.

Well, the need is to receive and transmit CEC packets. And this is a possible 
implementation.

Don't give CEC too much status: CEC is a very simplistic, stupid and very low 
bandwidth protocol. It is even simpler than RDS.

Regards,

	Hans

Re: [RFC] HDMI-CEC proposal

[Mauro Carvalho Chehab]

Em 01-03-2011 12:49, Hans Verkuil escreveu:
> On Tuesday, March 01, 2011 16:20:25 Mauro Carvalho Chehab wrote:
>> Em 01-03-2011 11:38, Hans Verkuil escreveu:
>>> Hi Mauro,
>>>
>>> On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote:
>>>> Hi Martin,
>>>>
>>>> Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu:
>>>>> Author: Martin Bugge <marbugge@cisco.com>
>>>>> Date:  Tue, 1 March 2010
>>>>> ======================
>>>>>
>>>>> This is a proposal for adding a Consumer Electronic Control (CEC) API to 
>>> V4L2.
>>>>> This document describes the changes and new ioctls needed.
>>>>>
>>>>> Version 1.0 (This is first version)
>>>>>
>>>>> Background
>>>>> ==========
>>>>> CEC is a protocol that provides high-level control functions between 
>>> various audiovisual products.
>>>>> It is an optional supplement to the High-Definition Multimedia Interface 
>>> Specification (HDMI).
>>>>> Physical layer is a one-wire bidirectional serial bus that uses the 
>>> industry-standard AV.link protocol.
>>>>>
>>>>> In short: CEC uses pin 13 on the HDMI connector to transmit and receive 
>>> small data-packets
>>>>>           (maximum 16 bytes including a 1 byte header) at low data rates 
>>> (~400 bits/s).
>>>>>
>>>>> A CEC device may have any of 15 logical addresses (0 - 14).
>>>>> (address 15 is broadcast and some addresses are reserved)
>>>>>
>>>>>
>>>>> References
>>>>> ==========
>>>>> [1] High-Definition Multimedia Interface Specification version 1.3a,
>>>>>     Supplement 1 Consumer Electronic Control (CEC).
>>>>>     http://www.hdmi.org/manufacturer/specification.aspx
>>>>>
>>>>> [2] 
>>> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
>>>>>
>>>>>
>>>>> Proposed solution
>>>>> =================
>>>>>
>>>>> Two new ioctls:
>>>>>     VIDIOC_CEC_CAP (read)
>>>>>     VIDIOC_CEC_CMD (read/write)
>>>>
>>>> How this proposal will interact with RC core? The way I see it, HDMI-CEC 
> is 
>>> just a way to get/send
>>>> Remote Controller data, and should be interacting with the proper Kernel 
>>> subsystems, e. g.,
>>>> with Remote Controller and input/event subsystems.
>>>
>>> I knew you were going to mention this :-)
>>>
>>> Actually, while CEC does support IR commands, this is only a very small 
> part 
>>> of the standard. Routing IR commands to the IR core is possible to do, 
>>> although it is not in this initial version. Should this be needed, then a 
> flag 
>>> can be created that tells V4L to route IR commands to the IR core.
>>>
>>> This should be optional, though, because if you are a repeater you do not 
> want 
>>> to pass such IR commands to the IR core, instead you want to retransmit 
> them 
>>> to a CEC output.
>>>
>>>>
>>>> I don't think we need two ioctls for that, as RC capabilities are already 
>>> exported via
>>>> sysfs, and we have two interfaces already for receiving events 
> (input/event 
>>> and lirc).
>>>> For sending, lirc interface might be used, but it is currently focused 
> only 
>>> on sending
>>>> raw pulse/space sequences. So, we'll need to add some capability there 
> for 
>>> IR/CEC TX.
>>>> I had a few discussions about that with Jarod, but we didn't write yet an 
>>> interface for it.
>>>
>>> Again, CEC != IR. All you need is a simple API to be able to send and 
> receive 
>>> CEC packets and a libcec that you can use to do the topology discovery and 
>>> send/receive the commands. You don't want nor need that in the kernel.
>>>
>>> The only place where routing things to the IR core is useful is when 
> someone 
>>> points a remote at a TV (for example), which then passes it over CEC to 
> your 
>>> device which is not a repeater but can actually handle the remote command.
>>>
>>> This is a future extension, though.
>>
>> There are two separate things when dealing with CEC: the low-level kernel
>> implementation of a bus for connecting with CEC devices, and userspace APIs
>> for using its features.
>>
>> If you were needing it only internally inside the kernel, there's no need 
> for 
>> new ioctl's. So, your proposal seems to add a raw interface for it, and do 
>> all the work in userspace.
>>
>> An alternative approach, that it is the way most Kernel API's do is to 
> write/use
>> higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC, 
> input/event,
>> vfs, tty, etc are good examples of how we do APIs in Linux. We should only 
> go 
>> to a raw API if the high-level ones won't work. 
> 
> What high-level API? There isn't much high-level about CEC. It's a very 
> simplistic standard. Each packet has a source and destination address (0-14 
> which you can choose yourself), an optional command with an optional payload. 
> You can put in pretty much what you want since you can make custom commands as 
> well.

I2C is even simpler in theory (1 TX wire, 1 RX wire, low speed, 7 bits for address), 
but a hole subsystem and several API's are needed in order to handle with I2C 
device complexity.
 
> You also assume that you can handle packets at a high level. But you can't, 
> because what you want to do with packets depends very much on what device you 
> are: TV, recorder, set-top, CEC switch, etc.

Again, it sounds similar to I2C.

>> Also, a raw-level implementation of CEC may/will interfere on higher level
>> interfaces. For example, assuming that we have both raw and RC interfaces 
> using 
>> HDMI-CIC, a raw access on one process during a RC reception or transmit 
> could 
>> interfere on another process using the high-level interface for RC (as a raw
>> access to a block device may actually corrupt data). So, raw interfaces are
>> evil, and generally require CAP_SYS_ADMIN.
> 
> ??? If we add a flag that causes the IR commands to go to the IR core, then 
> they will obviously not appear on the normal CEC interface.
> 
>> So, I think we should first discuss what are the needs, and then discuss how
>> to implement them.
> 
> Well, the need is to receive and transmit CEC packets. And this is a possible 
> implementation.
> 
> Don't give CEC too much status: CEC is a very simplistic, stupid and very low 
> bandwidth protocol. It is even simpler than RDS.

We should look what usage you have in mind for CEC, and then write an API for it,
not the opposite.

Usage of CEC for remote-controlling devices is one application whose usage is clear
to me, and that we have already Kernel APIs for them. As usual, the current API's may 
need additions in order to support some features.

What are the other use-cases?

Cheers,
Mauro.

Re: [RFC] HDMI-CEC proposal

[Hans Verkuil]

On Tuesday, March 01, 2011 17:19:21 Mauro Carvalho Chehab wrote:
> Em 01-03-2011 12:49, Hans Verkuil escreveu:
> > On Tuesday, March 01, 2011 16:20:25 Mauro Carvalho Chehab wrote:
> >> Em 01-03-2011 11:38, Hans Verkuil escreveu:

<snip>

> >>> Again, CEC != IR. All you need is a simple API to be able to send and 
> > receive 
> >>> CEC packets and a libcec that you can use to do the topology discovery and 
> >>> send/receive the commands. You don't want nor need that in the kernel.
> >>>
> >>> The only place where routing things to the IR core is useful is when 
> > someone 
> >>> points a remote at a TV (for example), which then passes it over CEC to 
> > your 
> >>> device which is not a repeater but can actually handle the remote command.
> >>>
> >>> This is a future extension, though.
> >>
> >> There are two separate things when dealing with CEC: the low-level kernel
> >> implementation of a bus for connecting with CEC devices, and userspace APIs
> >> for using its features.
> >>
> >> If you were needing it only internally inside the kernel, there's no need 
> > for 
> >> new ioctl's. So, your proposal seems to add a raw interface for it, and do 
> >> all the work in userspace.
> >>
> >> An alternative approach, that it is the way most Kernel API's do is to 
> > write/use
> >> higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC, 
> > input/event,
> >> vfs, tty, etc are good examples of how we do APIs in Linux. We should only 
> > go 
> >> to a raw API if the high-level ones won't work. 
> > 
> > What high-level API? There isn't much high-level about CEC. It's a very 
> > simplistic standard. Each packet has a source and destination address (0-14 
> > which you can choose yourself), an optional command with an optional payload. 
> > You can put in pretty much what you want since you can make custom commands as 
> > well.
> 
> I2C is even simpler in theory (1 TX wire, 1 RX wire, low speed, 7 bits for address), 
> but a hole subsystem and several API's are needed in order to handle with I2C 
> device complexity.

Nope, CEC is simpler: just one line and 400 bits per second. I win :-)

More to the point: i2c is a generic protocol to communicate with hardware devices.
Emphasis on 'generic'. CEC is far from generic: it is full of assumptions and
specific use-cases. In that respect it closely resembles RDS: this too is a low
bandwidth, application-specific protocol. For RDS the API is also at the packet
level, requiring a library to make use of it.

>  
> > You also assume that you can handle packets at a high level. But you can't, 
> > because what you want to do with packets depends very much on what device you 
> > are: TV, recorder, set-top, CEC switch, etc.
> 
> Again, it sounds similar to I2C.

No. The difference is that I2C is a generic protocol. For CEC these roles are
hardwired in the protocol.

> 
> >> Also, a raw-level implementation of CEC may/will interfere on higher level
> >> interfaces. For example, assuming that we have both raw and RC interfaces 
> > using 
> >> HDMI-CIC, a raw access on one process during a RC reception or transmit 
> > could 
> >> interfere on another process using the high-level interface for RC (as a raw
> >> access to a block device may actually corrupt data). So, raw interfaces are
> >> evil, and generally require CAP_SYS_ADMIN.
> > 
> > ??? If we add a flag that causes the IR commands to go to the IR core, then 
> > they will obviously not appear on the normal CEC interface.
> > 
> >> So, I think we should first discuss what are the needs, and then discuss how
> >> to implement them.
> > 
> > Well, the need is to receive and transmit CEC packets. And this is a possible 
> > implementation.
> > 
> > Don't give CEC too much status: CEC is a very simplistic, stupid and very low 
> > bandwidth protocol. It is even simpler than RDS.
> 
> We should look what usage you have in mind for CEC, and then write an API for it,
> not the opposite.
> 
> Usage of CEC for remote-controlling devices is one application whose usage is clear
> to me, and that we have already Kernel APIs for them. As usual, the current API's may 
> need additions in order to support some features.
> 
> What are the other use-cases?

Please read the CEC standard. In particular look at the CEC 13 chapter, which is
basically a list of the common use-cases. This proposed API basically handles the
protocol up to section CEC 9. CEC 15 is also useful to look at.

All this is highly specific to consumer electronics (and very restrictive as well:
something like video conferencing equipment doesn't really fit well in this
protocol).

All this screams 'userspace CEC protocol library' to me, with just the hardware
part of the protocol in the kernel. For exactly the same reason why RDS parsing
is done in userspace.

The only exception I see is the "Remote Control Pass Through" (CEC 13.13). This
can optionally be routed via the IR core.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco

Re: [RFC] HDMI-CEC proposal

[Andy Walls]

On Tue, 2011-03-01 at 10:59 +0100, Martin Bugge (marbugge) wrote:
> Author: Martin Bugge <marbugge@cisco.com>
> Date:  Tue, 1 March 2010
> ======================
> 
> This is a proposal for adding a Consumer Electronic Control (CEC) API to 
> V4L2.
> This document describes the changes and new ioctls needed.
> 
> Version 1.0 (This is first version)
> 
> Background
> ==========
> CEC is a protocol that provides high-level control functions between 
> various audiovisual products.
> It is an optional supplement to the High-Definition Multimedia Interface 
> Specification (HDMI).
> Physical layer is a one-wire bidirectional serial bus that uses the 
> industry-standard AV.link protocol.
> 
> In short: CEC uses pin 13 on the HDMI connector to transmit and receive 
> small data-packets
>            (maximum 16 bytes including a 1 byte header) at low data 
> rates (~400 bits/s).
> 
> A CEC device may have any of 15 logical addresses (0 - 14).
> (address 15 is broadcast and some addresses are reserved)
> 
> 
> References
> ==========
> [1] High-Definition Multimedia Interface Specification version 1.3a,
>      Supplement 1 Consumer Electronic Control (CEC).
>      http://www.hdmi.org/manufacturer/specification.aspx
> 
> [2] 
> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf


Hi Martin,

After reading the whitepaper, and the the general purpose nature of your
proposed API calls, I'm wondering if a socket interface wouldn't be
appropriate.

The CEC bus seems to be designed as a network.  A broadcast medium, with
multiport devices (switches), physical (MAC) addresses in dotted decimal
notation (1.0.0.0), dynamic logical address assignment, arbitration
(Media Access Control), etc.  The whitepaper even suggests OSI layers,
using the term PHY in a few places.


A network interface could be implemented something like what is done for
SLIP in figure 2 here (compare with figure 1):

	http://www.linux.it/~rubini/docs/serial/serial.html


Using that diagram as a guide, a socket interface would need a CEC tty
line discipline, CEC network device, and code to hook the CEC serial
device to the tty layer.  Multiple CEC serial devices would show up as
multiple network interfaces.

Once a network device is available, user-space could then use AF_PACKET
sockets.  If CEC's layers are standardized enough, a new address family
could be added to the kernel, I guess.

Of course, all that is a lot of work.  Since Cisco should have some
networking experts hanging around, maybe it wouldn't be too hard. ;)


Regards,
Andy

> Proposed solution
> =================
> 
> Two new ioctls:
>      VIDIOC_CEC_CAP (read)
>      VIDIOC_CEC_CMD (read/write)
> 
> VIDIOC_CEC_CAP:
> ---------------
> 
> struct vl2_cec_cap {
>         __u32 logicaldevices;
>         __u32 reserved[7];
> };
> 
> The capability ioctl will return the number of logical devices/addresses 
> which can be
> simultaneously supported on this HW.
>      0:       This HW don't support CEC.
>      1 -> 14: This HW supports n logical devices simultaneously.
> 
> VIDIOC_CEC_CMD:
> ---------------
> 
> struct v4l2_cec_cmd {
>      __u32 cmd;
>      __u32 reserved[7];
>      union {
>          struct {
>              __u32 index;
>              __u32 enable;
>              __u32 addr;
>          } conf;
>          struct {
>              __u32 len;
>              __u8  msg[16];
>              __u32 status;
>          } data;
>          __u32 raw[8];
>      };
> };
> 
> Alternatively the data struct could be:
>          struct {
>              __u8  initiator;
>              __u8  destination;
>              __u8  len;
>              __u8  msg[15];
>              __u32 status;
>          } data;
> 
> Commands:
> 
> #define V4L2_CEC_CMD_CONF  (1)
> #define V4L2_CEC_CMD_TX    (2)
> #define V4L2_CEC_CMD_RX    (3)
> 
> Tx status field:
> 
> #define V4L2_CEC_STAT_TX_OK            (0)
> #define V4L2_CEC_STAT_TX_ARB_LOST      (1)
> #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
> 
> The command ioctl is used both for configuration and to receive/transmit 
> data.
> 
> * The configuration command must be done for each logical device address
>    which is to be enabled on this HW. Maximum number of logical devices
>    is found with the capability ioctl.
>      conf:
>           index:  0 -> number_of_logical_devices-1
>           enable: true/false
>           addr:   logical address
> 
>    By default all logical devices are disabled.
> 
> * Tx/Rx command
>      data:
>           len:    length of message (data + header)
>           msg:    the raw CEC message received/transmitted
>           status: when the driver is in blocking mode it gives the 
> result for transmit.
> 
> Events
> ------
> 
> In the case of non-blocking mode the driver will issue the following events:
> 
> V4L2_EVENT_CEC_TX
> V4L2_EVENT_CEC_RX
> 
> V4L2_EVENT_CEC_TX
> -----------------
>   * transmit is complete with the following status:
> Add an additional struct to the struct v4l2_event
> 
> struct v4l2_event_cec_tx {
>         __u32 status;
> }
> 
> V4L2_EVENT_CEC_RX
> -----------------
>   * received a complete message
> 
> 
> Comments ?
> 
>             Martin Bugge
> 
> --
> Martin Bugge - Tandberg (now a part of Cisco)
> --
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] HDMI-CEC proposal

[Martin Bugge (marbugge)]

On 03/01/2011 02:47 PM, Andy Walls wrote:
> On Tue, 2011-03-01 at 10:59 +0100, Martin Bugge (marbugge) wrote:
>    
>> Author: Martin Bugge<marbugge@cisco.com>
>> Date:  Tue, 1 March 2010
>> ======================
>>
>> This is a proposal for adding a Consumer Electronic Control (CEC) API to
>> V4L2.
>> This document describes the changes and new ioctls needed.
>>
>> Version 1.0 (This is first version)
>>
>> Background
>> ==========
>> CEC is a protocol that provides high-level control functions between
>> various audiovisual products.
>> It is an optional supplement to the High-Definition Multimedia Interface
>> Specification (HDMI).
>> Physical layer is a one-wire bidirectional serial bus that uses the
>> industry-standard AV.link protocol.
>>
>> In short: CEC uses pin 13 on the HDMI connector to transmit and receive
>> small data-packets
>>             (maximum 16 bytes including a 1 byte header) at low data
>> rates (~400 bits/s).
>>
>> A CEC device may have any of 15 logical addresses (0 - 14).
>> (address 15 is broadcast and some addresses are reserved)
>>
>>
>> References
>> ==========
>> [1] High-Definition Multimedia Interface Specification version 1.3a,
>>       Supplement 1 Consumer Electronic Control (CEC).
>>       http://www.hdmi.org/manufacturer/specification.aspx
>>
>> [2]
>> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
>>      
>
> Hi Martin,
>
> After reading the whitepaper, and the the general purpose nature of your
> proposed API calls, I'm wondering if a socket interface wouldn't be
> appropriate.
>
> The CEC bus seems to be designed as a network.  A broadcast medium, with
> multiport devices (switches), physical (MAC) addresses in dotted decimal
> notation (1.0.0.0), dynamic logical address assignment, arbitration
> (Media Access Control), etc.  The whitepaper even suggests OSI layers,
> using the term PHY in a few places.
>
>
> A network interface could be implemented something like what is done for
> SLIP in figure 2 here (compare with figure 1):
>
> 	http://www.linux.it/~rubini/docs/serial/serial.html
>
>
> Using that diagram as a guide, a socket interface would need a CEC tty
> line discipline, CEC network device, and code to hook the CEC serial
> device to the tty layer.  Multiple CEC serial devices would show up as
> multiple network interfaces.
>
> Once a network device is available, user-space could then use AF_PACKET
> sockets.  If CEC's layers are standardized enough, a new address family
> could be added to the kernel, I guess.
>
> Of course, all that is a lot of work.  Since Cisco should have some
> networking experts hanging around, maybe it wouldn't be too hard. ;)
>
>
> Regards,
> Andy
>    

Hi Andy and thank you.

I agree its always nice to strive for a generic solution, but I don't 
think I'm able to
get hold of the resources required.

In CEC the physical address is determined by the edid information from 
the HDMI sink,
or for the HDMI sink its HDMI port number.

While the logical address describes the type of device, TV, Recorder, 
Tuner, etc.

 From that point of view I do think that the CEC protocol is closly 
connected to the HDMI connector,
such that it belongs together with a video device.

But I will ask my "mentor" for advice.

Regards,
Martin

>    
>> Proposed solution
>> =================
>>
>> Two new ioctls:
>>       VIDIOC_CEC_CAP (read)
>>       VIDIOC_CEC_CMD (read/write)
>>
>> VIDIOC_CEC_CAP:
>> ---------------
>>
>> struct vl2_cec_cap {
>>          __u32 logicaldevices;
>>          __u32 reserved[7];
>> };
>>
>> The capability ioctl will return the number of logical devices/addresses
>> which can be
>> simultaneously supported on this HW.
>>       0:       This HW don't support CEC.
>>       1 ->  14: This HW supports n logical devices simultaneously.
>>
>> VIDIOC_CEC_CMD:
>> ---------------
>>
>> struct v4l2_cec_cmd {
>>       __u32 cmd;
>>       __u32 reserved[7];
>>       union {
>>           struct {
>>               __u32 index;
>>               __u32 enable;
>>               __u32 addr;
>>           } conf;
>>           struct {
>>               __u32 len;
>>               __u8  msg[16];
>>               __u32 status;
>>           } data;
>>           __u32 raw[8];
>>       };
>> };
>>
>> Alternatively the data struct could be:
>>           struct {
>>               __u8  initiator;
>>               __u8  destination;
>>               __u8  len;
>>               __u8  msg[15];
>>               __u32 status;
>>           } data;
>>
>> Commands:
>>
>> #define V4L2_CEC_CMD_CONF  (1)
>> #define V4L2_CEC_CMD_TX    (2)
>> #define V4L2_CEC_CMD_RX    (3)
>>
>> Tx status field:
>>
>> #define V4L2_CEC_STAT_TX_OK            (0)
>> #define V4L2_CEC_STAT_TX_ARB_LOST      (1)
>> #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
>>
>> The command ioctl is used both for configuration and to receive/transmit
>> data.
>>
>> * The configuration command must be done for each logical device address
>>     which is to be enabled on this HW. Maximum number of logical devices
>>     is found with the capability ioctl.
>>       conf:
>>            index:  0 ->  number_of_logical_devices-1
>>            enable: true/false
>>            addr:   logical address
>>
>>     By default all logical devices are disabled.
>>
>> * Tx/Rx command
>>       data:
>>            len:    length of message (data + header)
>>            msg:    the raw CEC message received/transmitted
>>            status: when the driver is in blocking mode it gives the
>> result for transmit.
>>
>> Events
>> ------
>>
>> In the case of non-blocking mode the driver will issue the following events:
>>
>> V4L2_EVENT_CEC_TX
>> V4L2_EVENT_CEC_RX
>>
>> V4L2_EVENT_CEC_TX
>> -----------------
>>    * transmit is complete with the following status:
>> Add an additional struct to the struct v4l2_event
>>
>> struct v4l2_event_cec_tx {
>>          __u32 status;
>> }
>>
>> V4L2_EVENT_CEC_RX
>> -----------------
>>    * received a complete message
>>
>>
>> Comments ?
>>
>>              Martin Bugge
>>
>> --
>> Martin Bugge - Tandberg (now a part of Cisco)
>> --
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>      
>
>    

Re: [RFC] HDMI-CEC proposal

[Hans Verkuil]

On Tuesday, March 01, 2011 15:59:21 Martin Bugge (marbugge) wrote:
> On 03/01/2011 02:47 PM, Andy Walls wrote:
> > On Tue, 2011-03-01 at 10:59 +0100, Martin Bugge (marbugge) wrote:
> >    
> >> Author: Martin Bugge<marbugge@cisco.com>
> >> Date:  Tue, 1 March 2010
> >> ======================
> >>
> >> This is a proposal for adding a Consumer Electronic Control (CEC) API to
> >> V4L2.
> >> This document describes the changes and new ioctls needed.
> >>
> >> Version 1.0 (This is first version)
> >>
> >> Background
> >> ==========
> >> CEC is a protocol that provides high-level control functions between
> >> various audiovisual products.
> >> It is an optional supplement to the High-Definition Multimedia Interface
> >> Specification (HDMI).
> >> Physical layer is a one-wire bidirectional serial bus that uses the
> >> industry-standard AV.link protocol.
> >>
> >> In short: CEC uses pin 13 on the HDMI connector to transmit and receive
> >> small data-packets
> >>             (maximum 16 bytes including a 1 byte header) at low data
> >> rates (~400 bits/s).
> >>
> >> A CEC device may have any of 15 logical addresses (0 - 14).
> >> (address 15 is broadcast and some addresses are reserved)
> >>
> >>
> >> References
> >> ==========
> >> [1] High-Definition Multimedia Interface Specification version 1.3a,
> >>       Supplement 1 Consumer Electronic Control (CEC).
> >>       http://www.hdmi.org/manufacturer/specification.aspx
> >>
> >> [2]
> >> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
> >>      
> >
> > Hi Martin,
> >
> > After reading the whitepaper, and the the general purpose nature of your
> > proposed API calls, I'm wondering if a socket interface wouldn't be
> > appropriate.
> >
> > The CEC bus seems to be designed as a network.  A broadcast medium, with
> > multiport devices (switches), physical (MAC) addresses in dotted decimal
> > notation (1.0.0.0), dynamic logical address assignment, arbitration
> > (Media Access Control), etc.  The whitepaper even suggests OSI layers,
> > using the term PHY in a few places.
> >
> >
> > A network interface could be implemented something like what is done for
> > SLIP in figure 2 here (compare with figure 1):
> >
> > 	http://www.linux.it/~rubini/docs/serial/serial.html
> >
> >
> > Using that diagram as a guide, a socket interface would need a CEC tty
> > line discipline, CEC network device, and code to hook the CEC serial
> > device to the tty layer.  Multiple CEC serial devices would show up as
> > multiple network interfaces.
> >
> > Once a network device is available, user-space could then use AF_PACKET
> > sockets.  If CEC's layers are standardized enough, a new address family
> > could be added to the kernel, I guess.
> >
> > Of course, all that is a lot of work.  Since Cisco should have some
> > networking experts hanging around, maybe it wouldn't be too hard. ;)
> >
> >
> > Regards,
> > Andy
> >    
> 
> Hi Andy and thank you.
> 
> I agree its always nice to strive for a generic solution, but I don't 
> think I'm able to
> get hold of the resources required.
> 
> In CEC the physical address is determined by the edid information from 
> the HDMI sink,
> or for the HDMI sink its HDMI port number.
> 
> While the logical address describes the type of device, TV, Recorder, 
> Tuner, etc.
> 
>  From that point of view I do think that the CEC protocol is closly 
> connected to the HDMI connector,
> such that it belongs together with a video device.
> 
> But I will ask my "mentor" for advice.

Yes, CEC has a physical address which obtained from the EDID. It is generated
via the EDID. It has nothing to do with network addresses. Instead it is a
generated unique identifier. CEC also has logical addresses which is a really
a 'Device Type Identifier' for want of a better name. See CEC Table 5 in the
1.3a HDMI spec.

When I read through it I couldn't help wondering what to do if I have more than
three playback devices or recording devices. Or more than one TV, for that matter.

It also seems that the tree of connected devices can't be more than 4 or 5 levels,
if I understand section 8.7.2 (Physical Address Discovery) correctly.

As I mentioned in my reply to Mauro, CEC most closely resembles RDS in that the
hardware/kernel part is trivial, but parsing and correctly handling it is a lot
more complicated and ideal for a userspace library.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco

Re: [RFC] HDMI-CEC proposal

[Alex Deucher]

On Tue, Mar 1, 2011 at 4:59 AM, Martin Bugge (marbugge)
<marbugge@cisco.com> wrote:
> Author: Martin Bugge <marbugge@cisco.com>
> Date:  Tue, 1 March 2010
> ======================
>
> This is a proposal for adding a Consumer Electronic Control (CEC) API to
> V4L2.
> This document describes the changes and new ioctls needed.
>
> Version 1.0 (This is first version)
>
> Background
> ==========
> CEC is a protocol that provides high-level control functions between various
> audiovisual products.
> It is an optional supplement to the High-Definition Multimedia Interface
> Specification (HDMI).
> Physical layer is a one-wire bidirectional serial bus that uses the
> industry-standard AV.link protocol.
>
> In short: CEC uses pin 13 on the HDMI connector to transmit and receive
> small data-packets
>          (maximum 16 bytes including a 1 byte header) at low data rates
> (~400 bits/s).
>
> A CEC device may have any of 15 logical addresses (0 - 14).
> (address 15 is broadcast and some addresses are reserved)
>

It would be nice if this was not tied to v4l as we'll start seeing CEC
support show in GPUs soon as well.

Alex

>
> References
> ==========
> [1] High-Definition Multimedia Interface Specification version 1.3a,
>    Supplement 1 Consumer Electronic Control (CEC).
>    http://www.hdmi.org/manufacturer/specification.aspx
>
> [2]
> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
>
>
> Proposed solution
> =================
>
> Two new ioctls:
>    VIDIOC_CEC_CAP (read)
>    VIDIOC_CEC_CMD (read/write)
>
> VIDIOC_CEC_CAP:
> ---------------
>
> struct vl2_cec_cap {
>       __u32 logicaldevices;
>       __u32 reserved[7];
> };
>
> The capability ioctl will return the number of logical devices/addresses
> which can be
> simultaneously supported on this HW.
>    0:       This HW don't support CEC.
>    1 -> 14: This HW supports n logical devices simultaneously.
>
> VIDIOC_CEC_CMD:
> ---------------
>
> struct v4l2_cec_cmd {
>    __u32 cmd;
>    __u32 reserved[7];
>    union {
>        struct {
>            __u32 index;
>            __u32 enable;
>            __u32 addr;
>        } conf;
>        struct {
>            __u32 len;
>            __u8  msg[16];
>            __u32 status;
>        } data;
>        __u32 raw[8];
>    };
> };
>
> Alternatively the data struct could be:
>        struct {
>            __u8  initiator;
>            __u8  destination;
>            __u8  len;
>            __u8  msg[15];
>            __u32 status;
>        } data;
>
> Commands:
>
> #define V4L2_CEC_CMD_CONF  (1)
> #define V4L2_CEC_CMD_TX    (2)
> #define V4L2_CEC_CMD_RX    (3)
>
> Tx status field:
>
> #define V4L2_CEC_STAT_TX_OK            (0)
> #define V4L2_CEC_STAT_TX_ARB_LOST      (1)
> #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
>
> The command ioctl is used both for configuration and to receive/transmit
> data.
>
> * The configuration command must be done for each logical device address
>  which is to be enabled on this HW. Maximum number of logical devices
>  is found with the capability ioctl.
>    conf:
>         index:  0 -> number_of_logical_devices-1
>         enable: true/false
>         addr:   logical address
>
>  By default all logical devices are disabled.
>
> * Tx/Rx command
>    data:
>         len:    length of message (data + header)
>         msg:    the raw CEC message received/transmitted
>         status: when the driver is in blocking mode it gives the result for
> transmit.
>
> Events
> ------
>
> In the case of non-blocking mode the driver will issue the following events:
>
> V4L2_EVENT_CEC_TX
> V4L2_EVENT_CEC_RX
>
> V4L2_EVENT_CEC_TX
> -----------------
>  * transmit is complete with the following status:
> Add an additional struct to the struct v4l2_event
>
> struct v4l2_event_cec_tx {
>       __u32 status;
> }
>
> V4L2_EVENT_CEC_RX
> -----------------
>  * received a complete message
>
>
> Comments ?
>
>           Martin Bugge
>
> --
> Martin Bugge - Tandberg (now a part of Cisco)
> --
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [RFC] HDMI-CEC proposal

[Hans Verkuil]

Hi Alex,

On Tuesday, March 01, 2011 18:52:28 Alex Deucher wrote:
> On Tue, Mar 1, 2011 at 4:59 AM, Martin Bugge (marbugge)
> <marbugge@cisco.com> wrote:
> > Author: Martin Bugge <marbugge@cisco.com>
> > Date:  Tue, 1 March 2010
> > ======================
> >
> > This is a proposal for adding a Consumer Electronic Control (CEC) API to
> > V4L2.
> > This document describes the changes and new ioctls needed.
> >
> > Version 1.0 (This is first version)
> >
> > Background
> > ==========
> > CEC is a protocol that provides high-level control functions between 
various
> > audiovisual products.
> > It is an optional supplement to the High-Definition Multimedia Interface
> > Specification (HDMI).
> > Physical layer is a one-wire bidirectional serial bus that uses the
> > industry-standard AV.link protocol.
> >
> > In short: CEC uses pin 13 on the HDMI connector to transmit and receive
> > small data-packets
> >          (maximum 16 bytes including a 1 byte header) at low data rates
> > (~400 bits/s).
> >
> > A CEC device may have any of 15 logical addresses (0 - 14).
> > (address 15 is broadcast and some addresses are reserved)
> >
> 
> It would be nice if this was not tied to v4l as we'll start seeing CEC
> support show in GPUs soon as well.

As mentioned in other emails it is my firm believe that mixing APIs is a bad 
idea. I've never seen that work in practice. That said, I do think that any 
userspace CEC library shouldn't be tied to V4L allowing it to be used by GPUs. 

It would also be interesting to see if i2c HDMI receiver/transmitter drivers 
can be used by both subsystems. This would make a lot of sense.

Apologies if I asked this before, but are you planning to attend the ELC in 
San Francisco? If so, then we should sit together and compare the subsystems 
and see if we can work something out.

Regards,

	Hans

> 
> Alex
> 
> >
> > References
> > ==========
> > [1] High-Definition Multimedia Interface Specification version 1.3a,
> >    Supplement 1 Consumer Electronic Control (CEC).
> >    http://www.hdmi.org/manufacturer/specification.aspx
> >
> > [2]
> > http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
> >
> >
> > Proposed solution
> > =================
> >
> > Two new ioctls:
> >    VIDIOC_CEC_CAP (read)
> >    VIDIOC_CEC_CMD (read/write)
> >
> > VIDIOC_CEC_CAP:
> > ---------------
> >
> > struct vl2_cec_cap {
> >       __u32 logicaldevices;
> >       __u32 reserved[7];
> > };
> >
> > The capability ioctl will return the number of logical devices/addresses
> > which can be
> > simultaneously supported on this HW.
> >    0:       This HW don't support CEC.
> >    1 -> 14: This HW supports n logical devices simultaneously.
> >
> > VIDIOC_CEC_CMD:
> > ---------------
> >
> > struct v4l2_cec_cmd {
> >    __u32 cmd;
> >    __u32 reserved[7];
> >    union {
> >        struct {
> >            __u32 index;
> >            __u32 enable;
> >            __u32 addr;
> >        } conf;
> >        struct {
> >            __u32 len;
> >            __u8  msg[16];
> >            __u32 status;
> >        } data;
> >        __u32 raw[8];
> >    };
> > };
> >
> > Alternatively the data struct could be:
> >        struct {
> >            __u8  initiator;
> >            __u8  destination;
> >            __u8  len;
> >            __u8  msg[15];
> >            __u32 status;
> >        } data;
> >
> > Commands:
> >
> > #define V4L2_CEC_CMD_CONF  (1)
> > #define V4L2_CEC_CMD_TX    (2)
> > #define V4L2_CEC_CMD_RX    (3)
> >
> > Tx status field:
> >
> > #define V4L2_CEC_STAT_TX_OK            (0)
> > #define V4L2_CEC_STAT_TX_ARB_LOST      (1)
> > #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
> >
> > The command ioctl is used both for configuration and to receive/transmit
> > data.
> >
> > * The configuration command must be done for each logical device address
> >  which is to be enabled on this HW. Maximum number of logical devices
> >  is found with the capability ioctl.
> >    conf:
> >         index:  0 -> number_of_logical_devices-1
> >         enable: true/false
> >         addr:   logical address
> >
> >  By default all logical devices are disabled.
> >
> > * Tx/Rx command
> >    data:
> >         len:    length of message (data + header)
> >         msg:    the raw CEC message received/transmitted
> >         status: when the driver is in blocking mode it gives the result 
for
> > transmit.
> >
> > Events
> > ------
> >
> > In the case of non-blocking mode the driver will issue the following 
events:
> >
> > V4L2_EVENT_CEC_TX
> > V4L2_EVENT_CEC_RX
> >
> > V4L2_EVENT_CEC_TX
> > -----------------
> >  * transmit is complete with the following status:
> > Add an additional struct to the struct v4l2_event
> >
> > struct v4l2_event_cec_tx {
> >       __u32 status;
> > }
> >
> > V4L2_EVENT_CEC_RX
> > -----------------
> >  * received a complete message
> >
> >
> > Comments ?
> >
> >           Martin Bugge
> >
> > --
> > Martin Bugge - Tandberg (now a part of Cisco)
> > --
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> 

Re: [RFC] HDMI-CEC proposal

[Alex Deucher]

On Wed, Mar 2, 2011 at 4:13 AM, Hans Verkuil <hansverk@cisco.com> wrote:
> Hi Alex,
>
> On Tuesday, March 01, 2011 18:52:28 Alex Deucher wrote:
>> On Tue, Mar 1, 2011 at 4:59 AM, Martin Bugge (marbugge)
>> <marbugge@cisco.com> wrote:
>> > Author: Martin Bugge <marbugge@cisco.com>
>> > Date:  Tue, 1 March 2010
>> > ======================
>> >
>> > This is a proposal for adding a Consumer Electronic Control (CEC) API to
>> > V4L2.
>> > This document describes the changes and new ioctls needed.
>> >
>> > Version 1.0 (This is first version)
>> >
>> > Background
>> > ==========
>> > CEC is a protocol that provides high-level control functions between
> various
>> > audiovisual products.
>> > It is an optional supplement to the High-Definition Multimedia Interface
>> > Specification (HDMI).
>> > Physical layer is a one-wire bidirectional serial bus that uses the
>> > industry-standard AV.link protocol.
>> >
>> > In short: CEC uses pin 13 on the HDMI connector to transmit and receive
>> > small data-packets
>> >          (maximum 16 bytes including a 1 byte header) at low data rates
>> > (~400 bits/s).
>> >
>> > A CEC device may have any of 15 logical addresses (0 - 14).
>> > (address 15 is broadcast and some addresses are reserved)
>> >
>>
>> It would be nice if this was not tied to v4l as we'll start seeing CEC
>> support show in GPUs soon as well.
>
> As mentioned in other emails it is my firm believe that mixing APIs is a bad
> idea. I've never seen that work in practice. That said, I do think that any
> userspace CEC library shouldn't be tied to V4L allowing it to be used by GPUs.
>

Right.  That was my concern.  You are probably more of an expert on
CEC so I'll leave the API to you, but as it's going to show up in
GPUs, I'd rather not re-invent the wheel to support it on the GPU side
in some incompatible manner if it can be avoided.

> It would also be interesting to see if i2c HDMI receiver/transmitter drivers
> can be used by both subsystems. This would make a lot of sense.

There are already several i2c tmds drivers in the drm tree:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/gpu/drm/i2c;h=9eb6dad3ffa6cac6dfc07afb0b8526049416398b;hb=HEAD
And a few in the intel kms driver that could be broken out as
independent drivers.  See the dvo_*.c files in:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/gpu/drm/i915;h=19e4b8fe8f5413f0c5d5059d8b2561eafab9e5dd;hb=HEAD
Still they are tied to the drm as they are used as kms encoders.


>
> Apologies if I asked this before, but are you planning to attend the ELC in
> San Francisco? If so, then we should sit together and compare the subsystems
> and see if we can work something out.

Probably not, but I'll know more soon.

Alex

>
> Regards,
>
>        Hans
>
>>
>> Alex
>>
>> >
>> > References
>> > ==========
>> > [1] High-Definition Multimedia Interface Specification version 1.3a,
>> >    Supplement 1 Consumer Electronic Control (CEC).
>> >    http://www.hdmi.org/manufacturer/specification.aspx
>> >
>> > [2]
>> > http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
>> >
>> >
>> > Proposed solution
>> > =================
>> >
>> > Two new ioctls:
>> >    VIDIOC_CEC_CAP (read)
>> >    VIDIOC_CEC_CMD (read/write)
>> >
>> > VIDIOC_CEC_CAP:
>> > ---------------
>> >
>> > struct vl2_cec_cap {
>> >       __u32 logicaldevices;
>> >       __u32 reserved[7];
>> > };
>> >
>> > The capability ioctl will return the number of logical devices/addresses
>> > which can be
>> > simultaneously supported on this HW.
>> >    0:       This HW don't support CEC.
>> >    1 -> 14: This HW supports n logical devices simultaneously.
>> >
>> > VIDIOC_CEC_CMD:
>> > ---------------
>> >
>> > struct v4l2_cec_cmd {
>> >    __u32 cmd;
>> >    __u32 reserved[7];
>> >    union {
>> >        struct {
>> >            __u32 index;
>> >            __u32 enable;
>> >            __u32 addr;
>> >        } conf;
>> >        struct {
>> >            __u32 len;
>> >            __u8  msg[16];
>> >            __u32 status;
>> >        } data;
>> >        __u32 raw[8];
>> >    };
>> > };
>> >
>> > Alternatively the data struct could be:
>> >        struct {
>> >            __u8  initiator;
>> >            __u8  destination;
>> >            __u8  len;
>> >            __u8  msg[15];
>> >            __u32 status;
>> >        } data;
>> >
>> > Commands:
>> >
>> > #define V4L2_CEC_CMD_CONF  (1)
>> > #define V4L2_CEC_CMD_TX    (2)
>> > #define V4L2_CEC_CMD_RX    (3)
>> >
>> > Tx status field:
>> >
>> > #define V4L2_CEC_STAT_TX_OK            (0)
>> > #define V4L2_CEC_STAT_TX_ARB_LOST      (1)
>> > #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
>> >
>> > The command ioctl is used both for configuration and to receive/transmit
>> > data.
>> >
>> > * The configuration command must be done for each logical device address
>> >  which is to be enabled on this HW. Maximum number of logical devices
>> >  is found with the capability ioctl.
>> >    conf:
>> >         index:  0 -> number_of_logical_devices-1
>> >         enable: true/false
>> >         addr:   logical address
>> >
>> >  By default all logical devices are disabled.
>> >
>> > * Tx/Rx command
>> >    data:
>> >         len:    length of message (data + header)
>> >         msg:    the raw CEC message received/transmitted
>> >         status: when the driver is in blocking mode it gives the result
> for
>> > transmit.
>> >
>> > Events
>> > ------
>> >
>> > In the case of non-blocking mode the driver will issue the following
> events:
>> >
>> > V4L2_EVENT_CEC_TX
>> > V4L2_EVENT_CEC_RX
>> >
>> > V4L2_EVENT_CEC_TX
>> > -----------------
>> >  * transmit is complete with the following status:
>> > Add an additional struct to the struct v4l2_event
>> >
>> > struct v4l2_event_cec_tx {
>> >       __u32 status;
>> > }
>> >
>> > V4L2_EVENT_CEC_RX
>> > -----------------
>> >  * received a complete message
>> >
>> >
>> > Comments ?
>> >
>> >           Martin Bugge
>> >
>> > --
>> > Martin Bugge - Tandberg (now a part of Cisco)
>> > --
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>>
>>
>

Re: [RFC] HDMI-CEC proposal

[Daniel Glöckner]

On Tue, Mar 01, 2011 at 10:59:07AM +0100, Martin Bugge (marbugge) wrote:
> CEC is a protocol that provides high-level control functions between
> various audiovisual products.
> It is an optional supplement to the High-Definition Multimedia
> Interface Specification (HDMI).
> Physical layer is a one-wire bidirectional serial bus that uses the
> industry-standard AV.link protocol.

Apart from CEC being twice as fast as AV.link and using 3.6V
instead of 5V, CEC does look like an extension to the frame format
defined in EN 50157-2-2 for multiple data bytes.

So, how about adding support for EN 50157-2-* messages as well?
SCART isn't dead yet.

EN 50157-2-1 is tricky in that it requires devices to override
data bits like it is done for ack bits to announce their status.
There is a single message type with 21 bits.

For EN 50157-2-2 the only change necessary would be to tell the
application that it has to use AV.link commands instead of CEC
commands. In theory one could mix AV.link and CEC on a single
wire as they can be distinguished by their start bits.

EN 50157-2-3 allows 7 vendors to register their own applications
with up to 100 data bits per message. I doubt we can support
these if they require bits on the wire to be modified.
As they still didn't make use of the reserved value to extend the
application number space beyond 7, chances are no vendor ever
applied for a number.

Just my 2 cents.

  Daniel

Re: [RFC] HDMI-CEC proposal

[Martin Bugge (marbugge)]

On 03/02/2011 12:38 AM, Daniel Glöckner wrote:
> On Tue, Mar 01, 2011 at 10:59:07AM +0100, Martin Bugge (marbugge) wrote:
>    
>> CEC is a protocol that provides high-level control functions between
>> various audiovisual products.
>> It is an optional supplement to the High-Definition Multimedia
>> Interface Specification (HDMI).
>> Physical layer is a one-wire bidirectional serial bus that uses the
>> industry-standard AV.link protocol.
>>      
> Apart from CEC being twice as fast as AV.link and using 3.6V
> instead of 5V, CEC does look like an extension to the frame format
> defined in EN 50157-2-2 for multiple data bytes.
>
> So, how about adding support for EN 50157-2-* messages as well?
> SCART isn't dead yet.
>
> EN 50157-2-1 is tricky in that it requires devices to override
> data bits like it is done for ack bits to announce their status.
> There is a single message type with 21 bits.
>
> For EN 50157-2-2 the only change necessary would be to tell the
> application that it has to use AV.link commands instead of CEC
> commands. In theory one could mix AV.link and CEC on a single
> wire as they can be distinguished by their start bits.
>
> EN 50157-2-3 allows 7 vendors to register their own applications
> with up to 100 data bits per message. I doubt we can support
> these if they require bits on the wire to be modified.
> As they still didn't make use of the reserved value to extend the
> application number space beyond 7, chances are no vendor ever
> applied for a number.
>
> Just my 2 cents.
>
>    Daniel
>    

Hi Daniel and thank you.

I haven't read these standards myself but will do so as soon as I get 
hold of them.
But this sounds like a good idea since cec is based on these protocols.

I will look into it.

Regards,
Martin

Re: [RFC] HDMI-CEC proposal

[Laurent Pinchart]

Hi Martin,

On Tuesday 01 March 2011 10:59:07 Martin Bugge (marbugge) wrote:
> Author: Martin Bugge <marbugge@cisco.com>
> Date:  Tue, 1 March 2010
> ======================
> 
> This is a proposal for adding a Consumer Electronic Control (CEC) API to
> V4L2.
> This document describes the changes and new ioctls needed.
> 
> Version 1.0 (This is first version)
> 
> Background
> ==========
> CEC is a protocol that provides high-level control functions between
> various audiovisual products.
> It is an optional supplement to the High-Definition Multimedia Interface
> Specification (HDMI).
> Physical layer is a one-wire bidirectional serial bus that uses the
> industry-standard AV.link protocol.
> 
> In short: CEC uses pin 13 on the HDMI connector to transmit and receive
> small data-packets
>            (maximum 16 bytes including a 1 byte header) at low data
> rates (~400 bits/s).
> 
> A CEC device may have any of 15 logical addresses (0 - 14).
> (address 15 is broadcast and some addresses are reserved)
> 
> 
> References
> ==========
> [1] High-Definition Multimedia Interface Specification version 1.3a,
>      Supplement 1 Consumer Electronic Control (CEC).
>      http://www.hdmi.org/manufacturer/specification.aspx
> 
> [2]
> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
> 
> 
> Proposed solution
> =================
> 
> Two new ioctls:
>      VIDIOC_CEC_CAP (read)
>      VIDIOC_CEC_CMD (read/write)
> 
> VIDIOC_CEC_CAP:
> ---------------
> 
> struct vl2_cec_cap {
>         __u32 logicaldevices;
>         __u32 reserved[7];
> };
> 
> The capability ioctl will return the number of logical devices/addresses
> which can be
> simultaneously supported on this HW.
>      0:       This HW don't support CEC.
>      1 -> 14: This HW supports n logical devices simultaneously.
> 
> VIDIOC_CEC_CMD:
> ---------------
> 
> struct v4l2_cec_cmd {
>      __u32 cmd;
>      __u32 reserved[7];
>      union {
>          struct {
>              __u32 index;
>              __u32 enable;
>              __u32 addr;
>          } conf;
>          struct {
>              __u32 len;
>              __u8  msg[16];
>              __u32 status;
>          } data;
>          __u32 raw[8];
>      };
> };
> 
> Alternatively the data struct could be:
>          struct {
>              __u8  initiator;
>              __u8  destination;
>              __u8  len;
>              __u8  msg[15];
>              __u32 status;
>          } data;
> 
> Commands:
> 
> #define V4L2_CEC_CMD_CONF  (1)
> #define V4L2_CEC_CMD_TX    (2)
> #define V4L2_CEC_CMD_RX    (3)
> 
> Tx status field:
> 
> #define V4L2_CEC_STAT_TX_OK            (0)
> #define V4L2_CEC_STAT_TX_ARB_LOST      (1)
> #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
> 
> The command ioctl is used both for configuration and to receive/transmit
> data.
> 
> * The configuration command must be done for each logical device address
>    which is to be enabled on this HW. Maximum number of logical devices
>    is found with the capability ioctl.
>      conf:
>           index:  0 -> number_of_logical_devices-1
>           enable: true/false
>           addr:   logical address
> 
>    By default all logical devices are disabled.
> 
> * Tx/Rx command
>      data:
>           len:    length of message (data + header)
>           msg:    the raw CEC message received/transmitted
>           status: when the driver is in blocking mode it gives the
> result for transmit.
> 
> Events
> ------
> 
> In the case of non-blocking mode the driver will issue the following
> events:
> 
> V4L2_EVENT_CEC_TX
> V4L2_EVENT_CEC_RX
> 
> V4L2_EVENT_CEC_TX
> -----------------
>   * transmit is complete with the following status:
> Add an additional struct to the struct v4l2_event
> 
> struct v4l2_event_cec_tx {
>         __u32 status;
> }

In non-blocking mode, will applications be able to send several messages 
without waiting for a transmission done event between each of them ? If so, 
maybe some kind of ID to correlate TX events with TX commands would be useful.

> V4L2_EVENT_CEC_RX
> -----------------
>   * received a complete message

-- 
Regards,

Laurent Pinchart

Re: [RFC] HDMI-CEC proposal

[Martin Bugge (marbugge)]

On 03/03/2011 11:37 AM, Laurent Pinchart wrote:
> Hi Martin,
>
> On Tuesday 01 March 2011 10:59:07 Martin Bugge (marbugge) wrote:
>    
>> Author: Martin Bugge<marbugge@cisco.com>
>> Date:  Tue, 1 March 2010
>> ======================
>>
>> This is a proposal for adding a Consumer Electronic Control (CEC) API to
>> V4L2.
>> This document describes the changes and new ioctls needed.
>>
>> Version 1.0 (This is first version)
>>
>> Background
>> ==========
>> CEC is a protocol that provides high-level control functions between
>> various audiovisual products.
>> It is an optional supplement to the High-Definition Multimedia Interface
>> Specification (HDMI).
>> Physical layer is a one-wire bidirectional serial bus that uses the
>> industry-standard AV.link protocol.
>>
>> In short: CEC uses pin 13 on the HDMI connector to transmit and receive
>> small data-packets
>>             (maximum 16 bytes including a 1 byte header) at low data
>> rates (~400 bits/s).
>>
>> A CEC device may have any of 15 logical addresses (0 - 14).
>> (address 15 is broadcast and some addresses are reserved)
>>
>>
>> References
>> ==========
>> [1] High-Definition Multimedia Interface Specification version 1.3a,
>>       Supplement 1 Consumer Electronic Control (CEC).
>>       http://www.hdmi.org/manufacturer/specification.aspx
>>
>> [2]
>> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
>>
>>
>> Proposed solution
>> =================
>>
>> Two new ioctls:
>>       VIDIOC_CEC_CAP (read)
>>       VIDIOC_CEC_CMD (read/write)
>>
>> VIDIOC_CEC_CAP:
>> ---------------
>>
>> struct vl2_cec_cap {
>>          __u32 logicaldevices;
>>          __u32 reserved[7];
>> };
>>
>> The capability ioctl will return the number of logical devices/addresses
>> which can be
>> simultaneously supported on this HW.
>>       0:       This HW don't support CEC.
>>       1 ->  14: This HW supports n logical devices simultaneously.
>>
>> VIDIOC_CEC_CMD:
>> ---------------
>>
>> struct v4l2_cec_cmd {
>>       __u32 cmd;
>>       __u32 reserved[7];
>>       union {
>>           struct {
>>               __u32 index;
>>               __u32 enable;
>>               __u32 addr;
>>           } conf;
>>           struct {
>>               __u32 len;
>>               __u8  msg[16];
>>               __u32 status;
>>           } data;
>>           __u32 raw[8];
>>       };
>> };
>>
>> Alternatively the data struct could be:
>>           struct {
>>               __u8  initiator;
>>               __u8  destination;
>>               __u8  len;
>>               __u8  msg[15];
>>               __u32 status;
>>           } data;
>>
>> Commands:
>>
>> #define V4L2_CEC_CMD_CONF  (1)
>> #define V4L2_CEC_CMD_TX    (2)
>> #define V4L2_CEC_CMD_RX    (3)
>>
>> Tx status field:
>>
>> #define V4L2_CEC_STAT_TX_OK            (0)
>> #define V4L2_CEC_STAT_TX_ARB_LOST      (1)
>> #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
>>
>> The command ioctl is used both for configuration and to receive/transmit
>> data.
>>
>> * The configuration command must be done for each logical device address
>>     which is to be enabled on this HW. Maximum number of logical devices
>>     is found with the capability ioctl.
>>       conf:
>>            index:  0 ->  number_of_logical_devices-1
>>            enable: true/false
>>            addr:   logical address
>>
>>     By default all logical devices are disabled.
>>
>> * Tx/Rx command
>>       data:
>>            len:    length of message (data + header)
>>            msg:    the raw CEC message received/transmitted
>>            status: when the driver is in blocking mode it gives the
>> result for transmit.
>>
>> Events
>> ------
>>
>> In the case of non-blocking mode the driver will issue the following
>> events:
>>
>> V4L2_EVENT_CEC_TX
>> V4L2_EVENT_CEC_RX
>>
>> V4L2_EVENT_CEC_TX
>> -----------------
>>    * transmit is complete with the following status:
>> Add an additional struct to the struct v4l2_event
>>
>> struct v4l2_event_cec_tx {
>>          __u32 status;
>> }
>>      
> In non-blocking mode, will applications be able to send several messages
> without waiting for a transmission done event between each of them ? If so,
> maybe some kind of ID to correlate TX events with TX commands would be useful.
>    
Hi Laurent and thank you,

No it wasn't the plan to be able to send several messages without 
waiting for
the previous to complete.

In the first test driver we have written for this, a new send while
previous transmission is not complete in non-blocking mode will return 
-EAGAIN;

Regards
Martin
>> V4L2_EVENT_CEC_RX
>> -----------------
>>    * received a complete message
>>      
>    

Re: [RFC] HDMI-CEC proposal

[Florian Fainelli]

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

Re: [RFC] HDMI-CEC proposal

[Oliver Schinagl]

Since a lot of video cards dont' support CEC at all (not even 
connected), don't have hdmi, but work perfectly fine with dvi->hdmi 
adapters, CEC can be implemented in many other ways (think media centers)

One such exammple is using USB/Arduino

http://code.google.com/p/cec-arduino/wiki/ElectricalInterface

Having an AVR with v-usb code and cec code doesn't look all that hard 
nor impossible, so one could simply have a USB plug on one end, and an 
HDMI plug on the other end, utilizing only the CEC pins.

This would make it more something like LIRC if anything.

On 04/12/12 17:24, Florian Fainelli wrote:
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [RFC] HDMI-CEC proposal

[Hans Verkuil]

You both hit the main problem of the CEC support: how to implement the API.

Cisco's work on CEC has been stalled as we first want to get HDMI support in
V4L. Hopefully that will happen in the next few months. After that we will
resume working on the CEC API.

Regards,

	Hans

On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote:
> Since a lot of video cards dont' support CEC at all (not even 
> connected), don't have hdmi, but work perfectly fine with dvi->hdmi 
> adapters, CEC can be implemented in many other ways (think media centers)
> 
> One such exammple is using USB/Arduino
> 
> http://code.google.com/p/cec-arduino/wiki/ElectricalInterface
> 
> Having an AVR with v-usb code and cec code doesn't look all that hard 
> nor impossible, so one could simply have a USB plug on one end, and an 
> HDMI plug on the other end, utilizing only the CEC pins.
> 
> This would make it more something like LIRC if anything.
> 
> On 04/12/12 17:24, Florian Fainelli wrote:
> > 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
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC] HDMI-CEC proposal

[Florian Fainelli]

Hi Hans,

Le 04/13/12 07:03, Hans Verkuil a écrit :
> You both hit the main problem of the CEC support: how to implement the API.

Well, the API that I propose here [1] is quite simple:

- a kernel-side API for defining CEC adapters drivers
- a character device with an ioctl() control path and read/write/poll 
data-path

[1]: https://github.com/ffainelli/linux-hdmi-cec

>
> Cisco's work on CEC has been stalled as we first want to get HDMI support in
> V4L. Hopefully that will happen in the next few months. After that we will
> resume working on the CEC API.

Well, I don't think that tighting HDMI into V4L is such a good idea 
either. HDMI is also a separate bus and deserves its own subsystem and 
even subsystems (audio, video, HDCP, CEC). For instance, the STB I am 
working with does not use the V4L API at all, however, I would like to 
be able to integrate within the Linux HDMI stack once there, think about 
nvidia's driver too.

I can understand that you want to hold on your efforts on CEC while you 
want to get HDMI in, but don't make it entirely driven by Cisco and 
accept the community feedback.

>
> Regards,
>
> 	Hans
>
> On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote:
>> Since a lot of video cards dont' support CEC at all (not even
>> connected), don't have hdmi, but work perfectly fine with dvi->hdmi
>> adapters, CEC can be implemented in many other ways (think media centers)
>>
>> One such exammple is using USB/Arduino
>>
>> http://code.google.com/p/cec-arduino/wiki/ElectricalInterface
>>
>> Having an AVR with v-usb code and cec code doesn't look all that hard
>> nor impossible, so one could simply have a USB plug on one end, and an
>> HDMI plug on the other end, utilizing only the CEC pins.
>>
>> This would make it more something like LIRC if anything.
>>
>> On 04/12/12 17:24, Florian Fainelli wrote:
>>> 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
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Re: [RFC] HDMI-CEC proposal

[Anssi Hannula]

12.04.2012 23:36, Oliver Schinagl kirjoitti:
> Since a lot of video cards dont' support CEC at all (not even
> connected), don't have hdmi, but work perfectly fine with dvi->hdmi
> adapters, CEC can be implemented in many other ways (think media centers)
> 
> One such exammple is using USB/Arduino
> 
> http://code.google.com/p/cec-arduino/wiki/ElectricalInterface
> 
> Having an AVR with v-usb code and cec code doesn't look all that hard
> nor impossible, so one could simply have a USB plug on one end, and an
> HDMI plug on the other end, utilizing only the CEC pins.
> 
> This would make it more something like LIRC if anything.

There already exists a device like this (USB CEC adapter with hdmi
in/out) with open source userspace driver, developed for the XBMC Media
Center (apparently MythTV is also supported):

http://www.pulse-eight.com/store/products/104-usb-hdmi-cec-adapter.aspx
http://libcec.pulse-eight.com/
https://github.com/Pulse-Eight/libcec

-- 
Anssi Hannula

Re: [RFC] HDMI-CEC proposal

[Oliver Schinagl]

Yes, the library to talk to the device is opensource, the hardware, not 
so much. :)

On 17-04-12 15:31, Anssi Hannula wrote:
> 12.04.2012 23:36, Oliver Schinagl kirjoitti:
>> Since a lot of video cards dont' support CEC at all (not even
>> connected), don't have hdmi, but work perfectly fine with dvi->hdmi
>> adapters, CEC can be implemented in many other ways (think media centers)
>>
>> One such exammple is using USB/Arduino
>>
>> http://code.google.com/p/cec-arduino/wiki/ElectricalInterface
>>
>> Having an AVR with v-usb code and cec code doesn't look all that hard
>> nor impossible, so one could simply have a USB plug on one end, and an
>> HDMI plug on the other end, utilizing only the CEC pins.
>>
>> This would make it more something like LIRC if anything.
> There already exists a device like this (USB CEC adapter with hdmi
> in/out) with open source userspace driver, developed for the XBMC Media
> Center (apparently MythTV is also supported):
>
> http://www.pulse-eight.com/store/products/104-usb-hdmi-cec-adapter.aspx
> http://libcec.pulse-eight.com/
> https://github.com/Pulse-Eight/libcec
>

Re: [RFC] HDMI-CEC proposal

[Florian Fainelli]

Hello Murali,

On Thursday 10 May 2012 12:40:05 muralidhar dixit wrote:
> Hello Florian,
> 
> I do have similar implementation for my CEC driver.
> And I prefer most of the CEC messaged to be handled in the user space and
> have the kernel driver bare minimum with interfaces to
> 1) REGISTER CEC device( I have support for multiple logical devices)
> 2) SEND CEC MESSAGE
> 3) RECV CEC MESSAGE
> 
> But one issue with this was the response time to the TV remote actions.

Well, I think this is specific to your platform, because I don't have any such 
issue here with my implementation. The specification says that the desired 
response time is of 200 ms and the maximum 1s, even with multiple context 
switches you should be able to achieve that. Not knowing exactly how your 
hardware works, maybe there is a bottleneck somewhere.

> Initially I was sending the UI control messages also to user space but
> response time was too bad. Hence I wrote a CEC Keyboard driver which will
> process the CEC UI control messages. From the CEC driver if I recv any CEC
> UI control messages I will route it to CEC Keyboard driver in the kernel
> and all other messages have to be handled by user space application.

This is the kind of thing that I want to avoid, on my platform, all the input 
is processed in user-land and exposed as a HID device (thus self-describing), 
forwarding CEC UI key codes to the kernel does not seem like a good solution 
to me because it means we have to know about the CEC protocol itself.

I fear that if we start doing this with the CEC UI codes, we end-up doing the 
same for the system-related messages (Power, standby etc ...) and this is also 
to be avoided.

> 
> Best Regards,
> Murali
> From: Florian Fainelli <f.fainelli <at> gmail.com>
> Subject: Re: [RFC] HDMI-CEC
> proposal<http://news.gmane.org/find-
root.php?message_id=%3c4F87F195.5080504%40gmail.com%3e>
> Newsgroups: gmane.linux.drivers.video-input-
infrastructure<http://news.gmane.org/gmane.linux.drivers.video-input-
infrastructure>
> Date: 2012-04-13 09:27:49 GMT (3 weeks, 5 days, 21 hours and 33 minutes ago)
> 
> Hi Hans,
> 
> Le 04/13/12 07:03, Hans Verkuil a écrit :
> > You both hit the main problem of the *CEC* support: how to implement the 
API.
> 
> Well, the API that I propose here [1] is quite simple:
> 
> - a kernel-side API for defining *CEC* adapters drivers
> - a character device with an ioctl() control path and read/write/poll
> data-path
> 
> [1]: https://github.com/ffainelli/linux-*hdmi*-*cec*
> <https://github.com/ffainelli/linux-hdmi-cec>
> 
> >
> > Cisco's work on *CEC* has been stalled as we first want to get *HDMI* 
support in
> > V4L. Hopefully that will happen in the next few months. After that we will
> > resume working on the *CEC* API.
> 
> Well, I don't think that tighting *HDMI* into V4L is such a good idea
> either. *HDMI* is also a separate bus and deserves its own subsystem and
> even subsystems (audio, video, HDCP, *CEC*). For instance, the STB I am
> working with does not use the V4L API at all, however, I would like to
> be able to integrate within the Linux *HDMI* stack once there, think about
> nvidia's driver too.
> 
> I can understand that you want to hold on your efforts on *CEC* while you
> want to get *HDMI* in, but don't make it entirely driven by Cisco and
> accept the community feedback.
> 
> >
> > Regards,
> >
> > 	Hans
> >
> > On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote:
> >> Since a lot of video cards dont' support *CEC* at all (not even
> >> connected), don't have *hdmi*, but work perfectly fine with dvi->*hdmi*
> >> adapters, *CEC* can be implemented in many other ways (think media 
centers)
> >>
> >> One such exammple is using USB/Arduino
> >>
> >> http://code.google.com/p/*cec*-arduino/wiki/ElectricalInterface 
<http://code.google.com/p/cec-arduino/wiki/ElectricalInterface>
> >>
> >> Having an AVR with v-usb code and *cec* code doesn't look all that hard
> >> nor impossible, so one could simply have a USB plug on one end, and an
> >> *HDMI* plug on the other end, utilizing only the *CEC* pins.
> >>
> >> This would make it more something like LIRC if anything.
> >>
> >> On 04/12/12 17:24, Florian Fainelli wrote:
> >>> 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* 
<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
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-media" 
in
> >>> the body of a message to majordomo <at> vger.kernel.org
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> >> the body of a message to majordomo <at> vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>

Re: [RFC] HDMI-CEC proposal

[Hans Verkuil]

On Thu 10 May 2012 13:43:16 Florian Fainelli wrote:
> Hello Murali,
> 
> On Thursday 10 May 2012 12:40:05 muralidhar dixit wrote:
> > Hello Florian,
> > 
> > I do have similar implementation for my CEC driver.
> > And I prefer most of the CEC messaged to be handled in the user space and
> > have the kernel driver bare minimum with interfaces to
> > 1) REGISTER CEC device( I have support for multiple logical devices)
> > 2) SEND CEC MESSAGE
> > 3) RECV CEC MESSAGE
> > 
> > But one issue with this was the response time to the TV remote actions.
> 
> Well, I think this is specific to your platform, because I don't have any such 
> issue here with my implementation. The specification says that the desired 
> response time is of 200 ms and the maximum 1s, even with multiple context 
> switches you should be able to achieve that. Not knowing exactly how your 
> hardware works, maybe there is a bottleneck somewhere.
> 
> > Initially I was sending the UI control messages also to user space but
> > response time was too bad. Hence I wrote a CEC Keyboard driver which will
> > process the CEC UI control messages. From the CEC driver if I recv any CEC
> > UI control messages I will route it to CEC Keyboard driver in the kernel
> > and all other messages have to be handled by user space application.
> 
> This is the kind of thing that I want to avoid, on my platform, all the input 
> is processed in user-land and exposed as a HID device (thus self-describing), 
> forwarding CEC UI key codes to the kernel does not seem like a good solution 
> to me because it means we have to know about the CEC protocol itself.
> 
> I fear that if we start doing this with the CEC UI codes, we end-up doing the 
> same for the system-related messages (Power, standby etc ...) and this is also 
> to be avoided.

We are also doing parsing in userspace. The CEC API just gets the hardware up
and running so that we can send and receive CEC packets, but the kernel doesn't
parse. The only exception to that *might* be the remote control part of the
CEC specification (that's where button presses of a remote control are passed
over CEC). It might make sense to pass them on to the V4L2 framework for remote
controls.

Then again, it might not. Or only if you set a flag or something.

My personal view (but not everyone agreed at the time) is that we just need a
simple API to send/receive CEC packets and do everything else in userspace.
It would be nice if we have a standard library for that that everyone can use,
though.

Regards,

	Hans

> 
> > 
> > Best Regards,
> > Murali
> > From: Florian Fainelli <f.fainelli <at> gmail.com>
> > Subject: Re: [RFC] HDMI-CEC
> > proposal<http://news.gmane.org/find-
> root.php?message_id=%3c4F87F195.5080504%40gmail.com%3e>
> > Newsgroups: gmane.linux.drivers.video-input-
> infrastructure<http://news.gmane.org/gmane.linux.drivers.video-input-
> infrastructure>
> > Date: 2012-04-13 09:27:49 GMT (3 weeks, 5 days, 21 hours and 33 minutes ago)
> > 
> > Hi Hans,
> > 
> > Le 04/13/12 07:03, Hans Verkuil a écrit :
> > > You both hit the main problem of the *CEC* support: how to implement the 
> API.
> > 
> > Well, the API that I propose here [1] is quite simple:
> > 
> > - a kernel-side API for defining *CEC* adapters drivers
> > - a character device with an ioctl() control path and read/write/poll
> > data-path
> > 
> > [1]: https://github.com/ffainelli/linux-*hdmi*-*cec*
> > <https://github.com/ffainelli/linux-hdmi-cec>
> > 
> > >
> > > Cisco's work on *CEC* has been stalled as we first want to get *HDMI* 
> support in
> > > V4L. Hopefully that will happen in the next few months. After that we will
> > > resume working on the *CEC* API.
> > 
> > Well, I don't think that tighting *HDMI* into V4L is such a good idea
> > either. *HDMI* is also a separate bus and deserves its own subsystem and
> > even subsystems (audio, video, HDCP, *CEC*). For instance, the STB I am
> > working with does not use the V4L API at all, however, I would like to
> > be able to integrate within the Linux *HDMI* stack once there, think about
> > nvidia's driver too.
> > 
> > I can understand that you want to hold on your efforts on *CEC* while you
> > want to get *HDMI* in, but don't make it entirely driven by Cisco and
> > accept the community feedback.
> > 
> > >
> > > Regards,
> > >
> > > 	Hans
> > >
> > > On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote:
> > >> Since a lot of video cards dont' support *CEC* at all (not even
> > >> connected), don't have *hdmi*, but work perfectly fine with dvi->*hdmi*
> > >> adapters, *CEC* can be implemented in many other ways (think media 
> centers)
> > >>
> > >> One such exammple is using USB/Arduino
> > >>
> > >> http://code.google.com/p/*cec*-arduino/wiki/ElectricalInterface 
> <http://code.google.com/p/cec-arduino/wiki/ElectricalInterface>
> > >>
> > >> Having an AVR with v-usb code and *cec* code doesn't look all that hard
> > >> nor impossible, so one could simply have a USB plug on one end, and an
> > >> *HDMI* plug on the other end, utilizing only the *CEC* pins.
> > >>
> > >> This would make it more something like LIRC if anything.
> > >>
> > >> On 04/12/12 17:24, Florian Fainelli wrote:
> > >>> 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* 
> <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
> > >>> --
> > >>> To unsubscribe from this list: send the line "unsubscribe linux-media" 
> in
> > >>> the body of a message to majordomo <at> vger.kernel.org
> > >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> > >>
> > >> --
> > >> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > >> the body of a message to majordomo <at> vger.kernel.org
> > >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > >>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>