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