Re: [RFC] HDMI-CEC proposal

[Hans Verkuil <hansverk@cisco.com>]

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