Re: Preliminary proposal, new APIs for HDMI and DVI control in v4l2
Hi Soby On 05/27/2012 07:30 PM, Soby Mathew wrote: Martin Bugge (marbugge cisco.com> writes: This is a preliminary proposal for an extension to the v4l2 api. To be discussed at the V4L2 'brainstorming' meeting in Warsaw, March 2011 Purpose: Provide basic controls for HDMI and DVI devices. reposting the query since the earlier post did not appear in mailing list. Hi Martin, We are also in requirement of these controls as described by you. I did a search in the archives but could not find a suitable conclusion to the RFC. I could find that the dv_timings structure has been modified as a result of further discussions. But for many items like S_EDID, DV_CABLE_DETECT, Info frames etc , I could not find the logical conclusion to this RFC. Could please let me know the further updates on these requirements? It has been on hold for a very long time, but just last week Hans Verkuil posted a RFC which is a follow up on this subject. http://www.spinics.net/lists/linux-media/msg47671.html So that thread has taken over. Thanks in Advance Best Regards Soby Mathew Best regards Martin Bugge -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] HDMI-CEC proposal
Author: Martin Bugge 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) -- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
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 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
Re: [RFC] HDMI-CEC proposal
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] HDMI-CEC proposal, ver 2
Hi This is an updated version of the proposal for adding an api for HDMI-CEC to V4L2. Main difference is the support of AV.link EN 50157-2-[123]. (thanks to Daniel Glöckner) Author: Martin Bugge Date: Fri, 11th of 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. Initial version Version 2. Added support for AV.link EN 50157-2-[123]. 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). 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) Physical layer is a one-wire bidirectional serial bus that uses the industry-standard AV.link, see [3]. Due to this the proposed ioctls and events are meant to cover expansion for the protocols in [3]. 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 [3] Domestic and similar electronic equipment interconnection requirements AV.link. EN 50157-2-[123] Proposed solution = Two new ioctls: VIDIOC_AV_LINK_CAP (read) VIDIOC_AV_LINK_CMD (read/write) VIDIOC_AV_LINK_CAP: --- #define AV_LINK_CAP_MODE_CEC (1 << 0) #define AV_LINK_CAP_MODE_1 (1 << 1) #define AV_LINK_CAP_MODE_2 (1 << 2) #define AV_LINK_CAP_MODE_3 (1 << 3) struct vl2_av_link_cap { __u32 capabilities; __u32 logicaldevices; __u32 reserved[14]; }; The capabilities field will indicate which protocols/formats this HW supports. * AV link mode CEC: logicaldevices: 1 -> 14, this HW supports n logical devices simultaneously. * AV link mode 1: logicaldevices: not used. * AV link mode 2: Same as AV link mode CEC. * AV link mode 3: logicaldevices: not used. reserved: for future use. VIDIOC_AV_LINK_CMD: --- The command ioctl is used both for configuration and to receive/transmit data. /* mode 1 */ struct avl_mode1_conf { __u32 enable; __u32 upstream_Qty; __u32 downstream_Qty; }; struct avl_mode1 { __u32 head; __u32 Qty; __u32 tx_status; __u32 tx_status_Qty; }; /* mode 2, 3 and CEC */ struct avl_conf { __u32 enable; __u32 index; __u32 addr; }; struct avl { __u32 len; __u8 msg[16]; __u32 tx_status; }; struct v4l2_av_link_cmd { __u32 command; __u32 mode; __u32 reserved[2]; union { struct avl_mode1_conf avlm1_conf; struct avl_mode1 avlm1; struct avl_conf conf; struct avl avl; __u32 raw[12]; }; }; /* command */ #define V4L2_AV_LINK_CMD_CONF (1) #define V4L2_AV_LINK_CMD_TX (2) #define V4L2_AV_LINK_CMD_RX (3) /* mode */ #define AV_LINK_CMD_MODE_CEC (1) #define AV_LINK_CMD_MODE_1 (2) #define AV_LINK_CMD_MODE_2 (3) #define AV_LINK_CMD_MODE_3 (4) /* Tx status */ #define V4L2_AV_LINK_STAT_TX_OK (0) #define V4L2_AV_LINK_STAT_TX_ARB_LOST (1) #define V4L2_AV_LINK_STAT_TX_RETRY_TIMEOUT (2) #define V4L2_AV_LINK_STAT_TX_BROADCAST_REJECT (3) Not every tx status is applicable for all modes, see table 1. |-| |Av link Mode | CEC | 1 | 2 | 3 | |-| | Status | | | | | |-| | TX_OK | a | n/a | a | n/a | |-| | TX_ARB_LOST| a | n/a | a | a | |-| | TX_RETRY_TIMEOUT| a | n/a | a | a | |-| | TX_BROADCAST_REJECT | a | n/a | a | n/a | |-| Table 1: tx status versus mode. a: applicable n/a: not applicable Configuration command: -- * AV link mode CEC: 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 * AV link mode 1: In mode 1 the frame l
Re: [RFC] HDMI-CEC proposal, ver 2
Hi Daniel and thank you, On 03/12/2011 01:42 AM, Daniel Glöckner wrote: Hi Martin, On Fri, Mar 11, 2011 at 12:36:09PM +0100, Martin Bugge (marbugge) wrote: Not every tx status is applicable for all modes, see table 1. |-| |Av link Mode | CEC | 1 | 2 | 3 | |-| | Status | | | | | |-| | TX_OK | a | n/a | a | n/a | |-| | TX_ARB_LOST| a | n/a | a | a | |-| | TX_RETRY_TIMEOUT| a | n/a | a | a | |-| | TX_BROADCAST_REJECT | a | n/a | a | n/a | |-| TX_ARB_LOST is applicable to mode 1. Arbitration loss will also be caused by receivers detecting a bad pulse. You are correct, a typo. However, it looks like also TX_OK will be used for Mode 3. And maybe also TX_BROADCAST_REJECT. In particular with reference to your link in below. * AV link mode 1: In mode 1 the frame length is fixed to 21 bits (including the start sequence). Some of these bits (Qty 1 - 6) can be arbitrated by the receiver to signal supported formats/standards. conf: enable: true/false upstream_Qty: QTY bits 1-6 downstream_Qty: QTY bits 1-6 || | Bits: | 31 - 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | || | Qty bits | x| x | 6 | 5 | 4 | 3 | 2 | 1 | || Qty bits 1-6 mapping (x: not used) If the Linux system is a video source, it must stop arbitrating those Qty bits as soon as another video source wants to become active. As this includes the message where the new source announces itself, this can't be handled by reconfiguration after reception of the message. If the Linux system is a video sink, the announcement of a new source should not affect the Qty bits to arbitrate. And don't get me startet about systems capable of being a video source and sink at the same time, capturing their own signal until a new source becomes active... I assume this must be handled by logic in the driver if it supports this mode. * AV link mode 1: Frame received/transmitted: head: |-| | Bits: | 31 - 4 | 3 | 2 | 1 | 0 | |-| | head bits: |x | DIR | /PAS | /NAS | /DES | |-| Qty: Quality bits 1 - 16; |---| | Bits: | 31 - 16 | 15 | 14 - 1 | 0 | |---| | Qty bits |x| 16 | 15 - 2 | 1 | |---| x: not used Is Qty-1 or Qty-16 the bit sent after /DES? Even though I find it a bit confusing in the standard, the plan was to send Qty-1 just after the /DES bit. It was an attempt to make the configuration and status the same. Such that we could use the same bit masks. In blocking mode only: tx_status: tx status. tx_status_Qty: which Qty bits 1 - 6 bits was arbitrated during transmit. It may be interesting to know what other devices did to the /PAS and /DES bits when they were sent as 1. Maybe I should change this such that we actually send up the whole frame as tx_status. In that way we will avoid the confusion of the Qty bit orders also. But then this should apply to the configuration as well. * AV link mode 3: TBD. Chances are that nobody ever used this len: length of message in bits, maximum 96 bits. msg: the raw message received/transmitted. (without the start sequence). tx_status: tx status in blocking mode. Google turned up this: http://fmt.cs.utwente.nl/publications/files/111_heerink.pdf It suggests that at least Philips' variant of AV.link mode 3 - EasyLink - is even closer to CEC than mode 2. Yes I see that. However CEC don't have the start sequence (to differenciate between mode 1 - 3), and the application id. In addition can't I see that mode 3 describe the ACK and EOM bits. It might be difficult to "force" easylink into the mode 3 as it is. If we could use the application id it might be possible for the driver to change behaviour. Or we will end up with #define AV_LINK_CAP_MODE_EASY_LINK (1 << 4) And so on,
Preliminary proposal, new APIs for HDMI and DVI control in v4l2
This is a preliminary proposal for an extension to the v4l2 api. To be discussed at the V4L2 'brainstorming' meeting in Warsaw, March 2011 Purpose: Provide basic controls for HDMI and DVI devices. sink : HDMI/DVI/VGA receiver source: HDMI/DVI/VGA transmitter New Controls: = These controls rely on control events to be able to notify the application of any change. The idea is to create an event that will be triggered by the control framework whenever a control changes value. TX source: -- Control: V4L2_CID_DV_TX_HOTPLUG type: bitmask (output), read only name: Hotplug Hotplug is present on each output. The hotplug is issued by the sink to indicate that an edid exists and should be read by the source. Not applicable for VGA connectors. Control: V4L2_CID_DV_TX_RXSENSE type: bitmask (output), read only name: Rx Sense Rx sense is present on each output. Rx Sense is detection of pull-ups on the TMDS clock lines. Normally means that the sink has left/entered standby. Not applicable for VGA connectors. Control: V4L2_CID_DV_TX_EDID_SEGMENT0_PRESENT type: bitmask (output), read only name: Edid segment 0 The source driver has read edid segment 0 from the sink. Control: V4L2_CID_DV_TX_DVI_HDMI_MODE type: menu, read and write name: Hdmi/Dvi mode Settings: "HDMI" "DVI-D" RX sink: Control: V4L2_CID_DV_RX_5V type: bitmask (input), read only name: Rx 5V The source must supply the sink with a +5v via the HDMI/DVI cable. This is often used to power an eeprom which contains edid information, such that the source can read the edid even if the sink is in standby/power off. Control: V4L2_CID_DV_CABLE_DETECT type: bitmask (input), read only name: Cable detect This is not a part of the HDMI/DVI standards. But many sinks (read monitors) uses a + 5v pull-up on a ground pin (typically pin 15 on dvi) to detect if a cable is is connected and terminated at the source end. Control: V4L2_CID_DV_FORMAT_STATUS type: menu, read only name: Format status Format status for the current selected input. Statuses: "No signal" "Unknown" "Unsupported" "Encrypted" "Valid/supported" The input signal has changed format or status. In the case of a valid signal use the vidioc_query_dv_preset to read the new format. Alternatively this could also be implemented as a bitmask with bits for: 'signal present', 'encrypted', 'supported format'. Or as three separate boolean controls. New Events: === V4L2_EVENT_TX_EDID struct v4l2_event_tx_edid { __u32 output; __u32 present; __u32 segment; } The source driver has read an edid segment from the sink. One segment is 256 bytes and will contain one or two 128 bytes blocks. Most HDMI and DVI sinks will have only segment 0. The driver should read segment 0 when hotplug is detected and report this to userspace. The application can then use the V4L2_G_EDID ioctl to get the actual edid data. If the EDID data indicates the presence of further extension blocks the userspace application can use the V4L2_REQ_EDID ioctl to trigger a read. When the driver has read that extended segment it will generate a V4L2_EVENT_TX_EDID event. New Ioctls: === TX source: -- V4L2_REQ_EDID struct v4l2_req_edid { __u32 output; __u32 segment; } Trigger a read of a 256 bytes segment. Normally the driver will read segment 0 by itself when hotplug is detected, But this ioctl may also be used to trigger a re-read of segment 0. V4L2_G_EDID struct v4l2_g_edid { __u32 output; __u32 segment; __u8 edid[256]; } Get the edid segment indicated in the V4L2_EVENT_TX_EDID RX sink: V4L2_S_EDID struct v4l2_s_edid { __u32 input; __u32 segment; __u8 _edid[256]; } Set the edid information in the source. Additional Controls and Status: === Controls and statuses we want to add. Currently based on HDMI version 1.3a, must be updated From Info frames * Y0, Y1 RGB or YCBCR indicator. * A0Active Information Present. Indicates whether field R0...R3 is valid. See CEA-861-D table 8 for details. * B0, B1Bar Info data valid. See CEA-861-D table 8 for details. HDMI Licensing, LLC Page 113 of 156 High-Definition Multimedia Interface Specification Version 1.3a * S0, S1Scan Information (i.e. overscan, underscan). See CEA-861-D table 8 for details. * C0, C1Colorimetry (ITU BT.601, BT.709 etc.). See CEA-861-D table 9 for details. * EC0, EC1, EC2 Extended Colorimetry (IEC 61966-2
Re: [PATCH 2/3] [media] adv7842: Source Product Description (SPD) InfoFrame
Thank you Hans On 19/03/14 11:13, Hans Verkuil wrote: Hi Martin, On 03/19/14 10:43, Martin Bugge wrote: Decode and display any received SPD InfoFrame in log-status. This is really quite standardized data. I looked around in the kernel and I found this very nice header: include/linux/hdmi.h and source drivers/video/hdmi.c. I would suggest that the adv7842 driver fills the hdmi_spd_infoframe struct and calls a function in v4l2_dv_timings.c to log the contents. That way it can also be used by e.g. adv7604. We really should be using this header for other frame types as well. Actually, I think you should ask on the dri-devel mailinglist (with a CC to the active maintainers of the hdmi.c source, see 'git log') whether creating an hdmi_spd_infoframe_log function would be useful to add to hdmi.c. If they don't like it, then we stick it in v4l2_dv_timings.c. If they do like it, we can just add it to hdmi.c. It's something that is primarily useful for receivers, and not so much for transmitters, so they might not want it in the hdmi.c source. Yes you are right, it could be nice to have decoding of these Packets in a common place. I have added the same code to adv7604 as well so its already duplicated. I will look into it. I think the two other patches should apply ok. They are bug fixes. Regards, Martin Signed-off-by: Martin Bugge --- drivers/media/i2c/adv7842.c | 76 + 1 file changed, 76 insertions(+) diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c index 5d79c57..805a117 100644 --- a/drivers/media/i2c/adv7842.c +++ b/drivers/media/i2c/adv7842.c @@ -2243,6 +2243,81 @@ static void print_avi_infoframe(struct v4l2_subdev *sd) v4l2_info(sd, "\t%s %s\n", y10_txt[avi.y10], q10_txt[avi.q10]); } +static const char *sdi_txt(u8 code) +{ + switch (code) { + case 0x00: return "unknown"; "unknown" -> "Unknown" to be consistent with the others. Regards, Hans + case 0x01: return "Digital STB"; + case 0x02: return "DVD player"; + case 0x03: return "D-VHS"; + case 0x04: return "HDD Videorecorder"; + case 0x05: return "DVC"; + case 0x06: return "DSC"; + case 0x07: return "Video CD"; + case 0x08: return "Game"; + case 0x09: return "PC general"; + case 0x0a: return "Blu-Ray Disc (BD)"; + case 0x0b: return "Super Audio CD"; + } + return "Reserved"; +} + +static void print_spd_info_frame(struct v4l2_subdev *sd) +{ + int i; + u8 spd_type; + u8 spd_ver; + u8 spd_len; + u8 spd_crc; + u8 buf[32]; + u8 vn[8]; + u8 pd[16]; + u8 sdi; + + if (!(hdmi_read(sd, 0x05) & 0x80)) { + v4l2_info(sd, "receive DVI-D signal (SDP infoframe not supported)\n"); + return; + } + if (!(io_read(sd, 0x60) & 0x04)) { + v4l2_info(sd, "SDP infoframe not received\n"); + return; + } + + if (io_read(sd, 0x88) & 0x40) { + v4l2_info(sd, "SPD infoframe checksum error has occurred earlier\n"); + io_write(sd, 0x8a, 0x40); /* clear SPD_INF_CKS_ERR_RAW */ + if (io_read(sd, 0x88) & 0x40) { + v4l2_info(sd, "SPD infoframe checksum error still present\n"); + io_write(sd, 0x8a, 0x40); /* clear SPD_INF_CKS_ERR_RAW */ + } + } + + spd_type = infoframe_read(sd, 0xe6) & 0x7f; + spd_ver = infoframe_read(sd, 0xe7); + spd_len = infoframe_read(sd, 0xe8); + spd_crc = infoframe_read(sd, 0x2a); + + v4l2_info(sd, "SPD infoframe type %d, version %d, crc 0x%x, len %d\n", + spd_type, spd_ver, spd_crc, spd_len); + + if (spd_type != 0x03) + return; + if (spd_ver != 0x01) + return; + + memset(buf, 0, sizeof(buf)); + for (i = 0; i < 25 && i < spd_len; i++) + buf[i] = infoframe_read(sd, i + 0x2b); + + snprintf(vn, 8, buf); + snprintf(pd, 16, buf + 8); + sdi = buf[24]; + + v4l2_info(sd, "\tVendor Name: %s\n", vn); + v4l2_info(sd, "\tProduct Description: %s\n", pd); + v4l2_info(sd, "\tSource Device Information: %s (%d)\n", sdi_txt(sdi), sdi); +} + static const char * const prim_mode_txt[] = { "SDP", "Component", @@ -2455,6 +2530,7 @@ static int adv7842_cp_log_status(struct v4l2_subdev *sd) deep_color_mode_txt[hdmi_read(sd, 0x0b) >> 6]); print_avi_infoframe(sd); + print_spd_info_frame(sd); return 0; } -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html