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@xxxxxxxxx> > > 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@xxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
