Re: [RFC] HDMI-CEC proposal

[Mauro Carvalho Chehab <mchehab@redhat.com>]

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