* [RFC] HDMI-CEC proposal @ 2011-03-01 9:59 Martin Bugge (marbugge) 2011-03-01 12:28 ` Mauro Carvalho Chehab ` (4 more replies) 0 siblings, 5 replies; 25+ messages in thread From: Martin Bugge (marbugge) @ 2011-03-01 9:59 UTC (permalink / raw) To: linux-media; +Cc: Hans Verkuil 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) 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) -- ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-01 9:59 [RFC] HDMI-CEC proposal Martin Bugge (marbugge) @ 2011-03-01 12:28 ` Mauro Carvalho Chehab 2011-03-01 14:38 ` Hans Verkuil 2011-03-01 13:47 ` Andy Walls ` (3 subsequent siblings) 4 siblings, 1 reply; 25+ messages in thread From: Mauro Carvalho Chehab @ 2011-03-01 12:28 UTC (permalink / raw) To: Martin Bugge (marbugge); +Cc: linux-media, Hans Verkuil, Jarod Wilson 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-01 12:28 ` Mauro Carvalho Chehab @ 2011-03-01 14:38 ` Hans Verkuil 2011-03-01 15:20 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 25+ messages in thread From: Hans Verkuil @ 2011-03-01 14:38 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Martin Bugge (marbugge), linux-media, Hans Verkuil, Jarod Wilson 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 > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-01 14:38 ` Hans Verkuil @ 2011-03-01 15:20 ` Mauro Carvalho Chehab 2011-03-01 15:49 ` Hans Verkuil 0 siblings, 1 reply; 25+ messages in thread From: Mauro Carvalho Chehab @ 2011-03-01 15:20 UTC (permalink / raw) To: Hans Verkuil Cc: Martin Bugge (marbugge), linux-media, Hans Verkuil, Jarod Wilson Em 01-03-2011 11:38, Hans Verkuil escreveu: > 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. There are two separate things when dealing with CEC: the low-level kernel implementation of a bus for connecting with CEC devices, and userspace APIs for using its features. If you were needing it only internally inside the kernel, there's no need for new ioctl's. So, your proposal seems to add a raw interface for it, and do all the work in userspace. An alternative approach, that it is the way most Kernel API's do is to write/use higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC, input/event, vfs, tty, etc are good examples of how we do APIs in Linux. We should only go to a raw API if the high-level ones won't work. Also, a raw-level implementation of CEC may/will interfere on higher level interfaces. For example, assuming that we have both raw and RC interfaces using HDMI-CIC, a raw access on one process during a RC reception or transmit could interfere on another process using the high-level interface for RC (as a raw access to a block device may actually corrupt data). So, raw interfaces are evil, and generally require CAP_SYS_ADMIN. So, I think we should first discuss what are the needs, and then discuss how to implement them. Cheers, Mauro. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-01 15:20 ` Mauro Carvalho Chehab @ 2011-03-01 15:49 ` Hans Verkuil 2011-03-01 16:19 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 25+ messages in thread From: Hans Verkuil @ 2011-03-01 15:49 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Martin Bugge (marbugge), linux-media, Hans Verkuil, Jarod Wilson On Tuesday, March 01, 2011 16:20:25 Mauro Carvalho Chehab wrote: > Em 01-03-2011 11:38, Hans Verkuil escreveu: > > 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. > > There are two separate things when dealing with CEC: the low-level kernel > implementation of a bus for connecting with CEC devices, and userspace APIs > for using its features. > > If you were needing it only internally inside the kernel, there's no need for > new ioctl's. So, your proposal seems to add a raw interface for it, and do > all the work in userspace. > > An alternative approach, that it is the way most Kernel API's do is to write/use > higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC, input/event, > vfs, tty, etc are good examples of how we do APIs in Linux. We should only go > to a raw API if the high-level ones won't work. What high-level API? There isn't much high-level about CEC. It's a very simplistic standard. Each packet has a source and destination address (0-14 which you can choose yourself), an optional command with an optional payload. You can put in pretty much what you want since you can make custom commands as well. You also assume that you can handle packets at a high level. But you can't, because what you want to do with packets depends very much on what device you are: TV, recorder, set-top, CEC switch, etc. > Also, a raw-level implementation of CEC may/will interfere on higher level > interfaces. For example, assuming that we have both raw and RC interfaces using > HDMI-CIC, a raw access on one process during a RC reception or transmit could > interfere on another process using the high-level interface for RC (as a raw > access to a block device may actually corrupt data). So, raw interfaces are > evil, and generally require CAP_SYS_ADMIN. ??? If we add a flag that causes the IR commands to go to the IR core, then they will obviously not appear on the normal CEC interface. > So, I think we should first discuss what are the needs, and then discuss how > to implement them. Well, the need is to receive and transmit CEC packets. And this is a possible implementation. Don't give CEC too much status: CEC is a very simplistic, stupid and very low bandwidth protocol. It is even simpler than RDS. Regards, Hans ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-01 15:49 ` Hans Verkuil @ 2011-03-01 16:19 ` Mauro Carvalho Chehab 2011-03-01 17:09 ` Hans Verkuil 0 siblings, 1 reply; 25+ messages in thread From: Mauro Carvalho Chehab @ 2011-03-01 16:19 UTC (permalink / raw) To: Hans Verkuil Cc: Martin Bugge (marbugge), linux-media, Hans Verkuil, Jarod Wilson Em 01-03-2011 12:49, Hans Verkuil escreveu: > On Tuesday, March 01, 2011 16:20:25 Mauro Carvalho Chehab wrote: >> Em 01-03-2011 11:38, Hans Verkuil escreveu: >>> 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. >> >> There are two separate things when dealing with CEC: the low-level kernel >> implementation of a bus for connecting with CEC devices, and userspace APIs >> for using its features. >> >> If you were needing it only internally inside the kernel, there's no need > for >> new ioctl's. So, your proposal seems to add a raw interface for it, and do >> all the work in userspace. >> >> An alternative approach, that it is the way most Kernel API's do is to > write/use >> higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC, > input/event, >> vfs, tty, etc are good examples of how we do APIs in Linux. We should only > go >> to a raw API if the high-level ones won't work. > > What high-level API? There isn't much high-level about CEC. It's a very > simplistic standard. Each packet has a source and destination address (0-14 > which you can choose yourself), an optional command with an optional payload. > You can put in pretty much what you want since you can make custom commands as > well. I2C is even simpler in theory (1 TX wire, 1 RX wire, low speed, 7 bits for address), but a hole subsystem and several API's are needed in order to handle with I2C device complexity. > You also assume that you can handle packets at a high level. But you can't, > because what you want to do with packets depends very much on what device you > are: TV, recorder, set-top, CEC switch, etc. Again, it sounds similar to I2C. >> Also, a raw-level implementation of CEC may/will interfere on higher level >> interfaces. For example, assuming that we have both raw and RC interfaces > using >> HDMI-CIC, a raw access on one process during a RC reception or transmit > could >> interfere on another process using the high-level interface for RC (as a raw >> access to a block device may actually corrupt data). So, raw interfaces are >> evil, and generally require CAP_SYS_ADMIN. > > ??? If we add a flag that causes the IR commands to go to the IR core, then > they will obviously not appear on the normal CEC interface. > >> So, I think we should first discuss what are the needs, and then discuss how >> to implement them. > > Well, the need is to receive and transmit CEC packets. And this is a possible > implementation. > > Don't give CEC too much status: CEC is a very simplistic, stupid and very low > bandwidth protocol. It is even simpler than RDS. We should look what usage you have in mind for CEC, and then write an API for it, not the opposite. Usage of CEC for remote-controlling devices is one application whose usage is clear to me, and that we have already Kernel APIs for them. As usual, the current API's may need additions in order to support some features. What are the other use-cases? Cheers, Mauro. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-01 16:19 ` Mauro Carvalho Chehab @ 2011-03-01 17:09 ` Hans Verkuil 0 siblings, 0 replies; 25+ messages in thread From: Hans Verkuil @ 2011-03-01 17:09 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Hans Verkuil, Martin Bugge (marbugge), linux-media, Hans Verkuil, Jarod Wilson On Tuesday, March 01, 2011 17:19:21 Mauro Carvalho Chehab wrote: > Em 01-03-2011 12:49, Hans Verkuil escreveu: > > On Tuesday, March 01, 2011 16:20:25 Mauro Carvalho Chehab wrote: > >> Em 01-03-2011 11:38, Hans Verkuil escreveu: <snip> > >>> 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. > >> > >> There are two separate things when dealing with CEC: the low-level kernel > >> implementation of a bus for connecting with CEC devices, and userspace APIs > >> for using its features. > >> > >> If you were needing it only internally inside the kernel, there's no need > > for > >> new ioctl's. So, your proposal seems to add a raw interface for it, and do > >> all the work in userspace. > >> > >> An alternative approach, that it is the way most Kernel API's do is to > > write/use > >> higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC, > > input/event, > >> vfs, tty, etc are good examples of how we do APIs in Linux. We should only > > go > >> to a raw API if the high-level ones won't work. > > > > What high-level API? There isn't much high-level about CEC. It's a very > > simplistic standard. Each packet has a source and destination address (0-14 > > which you can choose yourself), an optional command with an optional payload. > > You can put in pretty much what you want since you can make custom commands as > > well. > > I2C is even simpler in theory (1 TX wire, 1 RX wire, low speed, 7 bits for address), > but a hole subsystem and several API's are needed in order to handle with I2C > device complexity. Nope, CEC is simpler: just one line and 400 bits per second. I win :-) More to the point: i2c is a generic protocol to communicate with hardware devices. Emphasis on 'generic'. CEC is far from generic: it is full of assumptions and specific use-cases. In that respect it closely resembles RDS: this too is a low bandwidth, application-specific protocol. For RDS the API is also at the packet level, requiring a library to make use of it. > > > You also assume that you can handle packets at a high level. But you can't, > > because what you want to do with packets depends very much on what device you > > are: TV, recorder, set-top, CEC switch, etc. > > Again, it sounds similar to I2C. No. The difference is that I2C is a generic protocol. For CEC these roles are hardwired in the protocol. > > >> Also, a raw-level implementation of CEC may/will interfere on higher level > >> interfaces. For example, assuming that we have both raw and RC interfaces > > using > >> HDMI-CIC, a raw access on one process during a RC reception or transmit > > could > >> interfere on another process using the high-level interface for RC (as a raw > >> access to a block device may actually corrupt data). So, raw interfaces are > >> evil, and generally require CAP_SYS_ADMIN. > > > > ??? If we add a flag that causes the IR commands to go to the IR core, then > > they will obviously not appear on the normal CEC interface. > > > >> So, I think we should first discuss what are the needs, and then discuss how > >> to implement them. > > > > Well, the need is to receive and transmit CEC packets. And this is a possible > > implementation. > > > > Don't give CEC too much status: CEC is a very simplistic, stupid and very low > > bandwidth protocol. It is even simpler than RDS. > > We should look what usage you have in mind for CEC, and then write an API for it, > not the opposite. > > Usage of CEC for remote-controlling devices is one application whose usage is clear > to me, and that we have already Kernel APIs for them. As usual, the current API's may > need additions in order to support some features. > > What are the other use-cases? Please read the CEC standard. In particular look at the CEC 13 chapter, which is basically a list of the common use-cases. This proposed API basically handles the protocol up to section CEC 9. CEC 15 is also useful to look at. All this is highly specific to consumer electronics (and very restrictive as well: something like video conferencing equipment doesn't really fit well in this protocol). All this screams 'userspace CEC protocol library' to me, with just the hardware part of the protocol in the kernel. For exactly the same reason why RDS parsing is done in userspace. The only exception I see is the "Remote Control Pass Through" (CEC 13.13). This can optionally be routed via the IR core. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-01 9:59 [RFC] HDMI-CEC proposal Martin Bugge (marbugge) 2011-03-01 12:28 ` Mauro Carvalho Chehab @ 2011-03-01 13:47 ` Andy Walls 2011-03-01 14:59 ` Martin Bugge (marbugge) 2011-03-01 17:52 ` Alex Deucher ` (2 subsequent siblings) 4 siblings, 1 reply; 25+ messages in thread From: Andy Walls @ 2011-03-01 13:47 UTC (permalink / raw) To: Martin Bugge (marbugge); +Cc: linux-media, Hans Verkuil On Tue, 2011-03-01 at 10:59 +0100, Martin Bugge (marbugge) wrote: > 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 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 > 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-01 13:47 ` Andy Walls @ 2011-03-01 14:59 ` Martin Bugge (marbugge) 2011-03-01 17:31 ` Hans Verkuil 0 siblings, 1 reply; 25+ messages in thread From: Martin Bugge (marbugge) @ 2011-03-01 14:59 UTC (permalink / raw) To: Andy Walls, linux-media 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<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 >> > > 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 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 >> > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-01 14:59 ` Martin Bugge (marbugge) @ 2011-03-01 17:31 ` Hans Verkuil 0 siblings, 0 replies; 25+ messages in thread From: Hans Verkuil @ 2011-03-01 17:31 UTC (permalink / raw) To: Martin Bugge (marbugge); +Cc: Andy Walls, linux-media On Tuesday, March 01, 2011 15:59:21 Martin Bugge (marbugge) wrote: > 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<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 > >> > > > > 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. Yes, CEC has a physical address which obtained from the EDID. It is generated via the EDID. It has nothing to do with network addresses. Instead it is a generated unique identifier. CEC also has logical addresses which is a really a 'Device Type Identifier' for want of a better name. See CEC Table 5 in the 1.3a HDMI spec. When I read through it I couldn't help wondering what to do if I have more than three playback devices or recording devices. Or more than one TV, for that matter. It also seems that the tree of connected devices can't be more than 4 or 5 levels, if I understand section 8.7.2 (Physical Address Discovery) correctly. As I mentioned in my reply to Mauro, CEC most closely resembles RDS in that the hardware/kernel part is trivial, but parsing and correctly handling it is a lot more complicated and ideal for a userspace library. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-01 9:59 [RFC] HDMI-CEC proposal Martin Bugge (marbugge) 2011-03-01 12:28 ` Mauro Carvalho Chehab 2011-03-01 13:47 ` Andy Walls @ 2011-03-01 17:52 ` Alex Deucher 2011-03-02 9:13 ` Hans Verkuil 2011-03-01 23:38 ` Daniel Glöckner 2011-03-03 10:37 ` Laurent Pinchart 4 siblings, 1 reply; 25+ messages in thread From: Alex Deucher @ 2011-03-01 17:52 UTC (permalink / raw) To: Martin Bugge (marbugge); +Cc: linux-media, Hans Verkuil On Tue, Mar 1, 2011 at 4:59 AM, Martin Bugge (marbugge) <marbugge@cisco.com> wrote: > 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) > It would be nice if this was not tied to v4l as we'll start seeing CEC support show in GPUs soon as well. Alex > > 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-01 17:52 ` Alex Deucher @ 2011-03-02 9:13 ` Hans Verkuil 2011-03-02 15:49 ` Alex Deucher 0 siblings, 1 reply; 25+ messages in thread From: Hans Verkuil @ 2011-03-02 9:13 UTC (permalink / raw) To: Alex Deucher; +Cc: Martin Bugge (marbugge), linux-media Hi Alex, On Tuesday, March 01, 2011 18:52:28 Alex Deucher wrote: > On Tue, Mar 1, 2011 at 4:59 AM, Martin Bugge (marbugge) > <marbugge@cisco.com> wrote: > > 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) > > > > It would be nice if this was not tied to v4l as we'll start seeing CEC > support show in GPUs soon as well. As mentioned in other emails it is my firm believe that mixing APIs is a bad idea. I've never seen that work in practice. That said, I do think that any userspace CEC library shouldn't be tied to V4L allowing it to be used by GPUs. It would also be interesting to see if i2c HDMI receiver/transmitter drivers can be used by both subsystems. This would make a lot of sense. Apologies if I asked this before, but are you planning to attend the ELC in San Francisco? If so, then we should sit together and compare the subsystems and see if we can work something out. Regards, Hans > > Alex > > > > > 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 majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-02 9:13 ` Hans Verkuil @ 2011-03-02 15:49 ` Alex Deucher 0 siblings, 0 replies; 25+ messages in thread From: Alex Deucher @ 2011-03-02 15:49 UTC (permalink / raw) To: Hans Verkuil; +Cc: Martin Bugge (marbugge), linux-media On Wed, Mar 2, 2011 at 4:13 AM, Hans Verkuil <hansverk@cisco.com> wrote: > Hi Alex, > > On Tuesday, March 01, 2011 18:52:28 Alex Deucher wrote: >> On Tue, Mar 1, 2011 at 4:59 AM, Martin Bugge (marbugge) >> <marbugge@cisco.com> wrote: >> > 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) >> > >> >> It would be nice if this was not tied to v4l as we'll start seeing CEC >> support show in GPUs soon as well. > > As mentioned in other emails it is my firm believe that mixing APIs is a bad > idea. I've never seen that work in practice. That said, I do think that any > userspace CEC library shouldn't be tied to V4L allowing it to be used by GPUs. > Right. That was my concern. You are probably more of an expert on CEC so I'll leave the API to you, but as it's going to show up in GPUs, I'd rather not re-invent the wheel to support it on the GPU side in some incompatible manner if it can be avoided. > It would also be interesting to see if i2c HDMI receiver/transmitter drivers > can be used by both subsystems. This would make a lot of sense. There are already several i2c tmds drivers in the drm tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/gpu/drm/i2c;h=9eb6dad3ffa6cac6dfc07afb0b8526049416398b;hb=HEAD And a few in the intel kms driver that could be broken out as independent drivers. See the dvo_*.c files in: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/gpu/drm/i915;h=19e4b8fe8f5413f0c5d5059d8b2561eafab9e5dd;hb=HEAD Still they are tied to the drm as they are used as kms encoders. > > Apologies if I asked this before, but are you planning to attend the ELC in > San Francisco? If so, then we should sit together and compare the subsystems > and see if we can work something out. Probably not, but I'll know more soon. Alex > > Regards, > > Hans > >> >> Alex >> >> > >> > 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 majordomo@vger.kernel.org >> > More majordomo info at http://vger.kernel.org/majordomo-info.html >> > >> >> > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-01 9:59 [RFC] HDMI-CEC proposal Martin Bugge (marbugge) ` (2 preceding siblings ...) 2011-03-01 17:52 ` Alex Deucher @ 2011-03-01 23:38 ` Daniel Glöckner 2011-03-02 9:34 ` Martin Bugge (marbugge) 2011-03-03 10:37 ` Laurent Pinchart 4 siblings, 1 reply; 25+ messages in thread From: Daniel Glöckner @ 2011-03-01 23:38 UTC (permalink / raw) To: Martin Bugge (marbugge); +Cc: linux-media, Hans Verkuil 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-01 23:38 ` Daniel Glöckner @ 2011-03-02 9:34 ` Martin Bugge (marbugge) 0 siblings, 0 replies; 25+ messages in thread From: Martin Bugge (marbugge) @ 2011-03-02 9:34 UTC (permalink / raw) To: Daniel Glöckner; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-01 9:59 [RFC] HDMI-CEC proposal Martin Bugge (marbugge) ` (3 preceding siblings ...) 2011-03-01 23:38 ` Daniel Glöckner @ 2011-03-03 10:37 ` Laurent Pinchart 2011-03-03 12:11 ` Martin Bugge (marbugge) 4 siblings, 1 reply; 25+ messages in thread From: Laurent Pinchart @ 2011-03-03 10:37 UTC (permalink / raw) To: Martin Bugge (marbugge); +Cc: linux-media, Hans Verkuil Hi Martin, On Tuesday 01 March 2011 10:59:07 Martin Bugge (marbugge) wrote: > 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) > > 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. > V4L2_EVENT_CEC_RX > ----------------- > * received a complete message -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2011-03-03 10:37 ` Laurent Pinchart @ 2011-03-03 12:11 ` Martin Bugge (marbugge) 0 siblings, 0 replies; 25+ messages in thread From: Martin Bugge (marbugge) @ 2011-03-03 12:11 UTC (permalink / raw) To: Laurent Pinchart, linux-media 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<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) >> >> 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 >> > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal @ 2012-04-12 15:24 Florian Fainelli 2012-04-12 20:36 ` Oliver Schinagl 0 siblings, 1 reply; 25+ messages in thread From: Florian Fainelli @ 2012-04-12 15:24 UTC (permalink / raw) To: linux-media, marbugge, hverkuil Hi Hans, Martin, Sorry to jump in so late in the HDMI-CEC discussion, here are some comments from my perspective on your proposal: - the HDMI-CEC implementation deserves its own bus and class of devices because by definition it is a physical bus, which is even electrically independant from the rest of the HDMI bus (A/V path) - I don't think it is a good idea to tight it so closely to v4l, because one can perfectly have CEC-capable hardware without video, or at least not use v4l and have HDMI-CEC hardware - it was suggested to use sockets at some point, I think it is over-engineered and should only lead - processing messages in user-space is definitively the way to go, even input can be either re-injected using an uinput driver, or be handled in user-space entirely, eventually we might want to install "filters" based on opcodes to divert some opcodes to a kernel consumer, and the others to an user-space one Right now, I have a very simple implementation that I developed for the company I work for which can be found here: https://github.com/ffainelli/linux-hdmi-cec It is designed like this: 1) A core module, which registers a cec bus, and provides an abstraction for a CEC adapter (both device & driver): - basic CEC adapter operations: logical address setting, queueing management - counters, rx filtering - host attaching/detaching in case the hardware is capable of self-processing CEC messages (for wakeup in particular) 2) A character device module, which exposes a character device per CEC adapter and only allows one consumer at a time and exposes the following ioctl's: - SET_LOGICAL_ADDRESS - RESET_DEVICE - GET_COUNTERS - SET_RX_MODE (my adapter can be set in a promiscuous mode) the character device supports read/write/poll, which are the prefered ways for transfering/receiving data 3) A CEC adapter implementation which registers and calls into the core module when receiving a CEC message, and which the core module calls in response to the IOCTLs described below. At first I thought about defining a generic netlink family in order to allow multiple user-space listeners receive CEC messages, but in the end having only one consumer per adapter device is fine by me and a more traditionnal approach for programmers. I am relying on external components for knowing my HDMI physical address. Hope this is not too late to (re)start the discussion on HDMI-CEC. Thank you very much. -- Florian ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2012-04-12 15:24 Florian Fainelli @ 2012-04-12 20:36 ` Oliver Schinagl 2012-04-13 5:03 ` Hans Verkuil 2012-04-17 13:31 ` Anssi Hannula 0 siblings, 2 replies; 25+ messages in thread From: Oliver Schinagl @ 2012-04-12 20:36 UTC (permalink / raw) To: Florian Fainelli; +Cc: linux-media, marbugge, hverkuil Since a lot of video cards dont' support CEC at all (not even connected), don't have hdmi, but work perfectly fine with dvi->hdmi adapters, CEC can be implemented in many other ways (think media centers) One such exammple is using USB/Arduino http://code.google.com/p/cec-arduino/wiki/ElectricalInterface Having an AVR with v-usb code and cec code doesn't look all that hard nor impossible, so one could simply have a USB plug on one end, and an HDMI plug on the other end, utilizing only the CEC pins. This would make it more something like LIRC if anything. On 04/12/12 17:24, Florian Fainelli wrote: > Hi Hans, Martin, > > Sorry to jump in so late in the HDMI-CEC discussion, here are some > comments from my perspective on your proposal: > > - the HDMI-CEC implementation deserves its own bus and class of devices > because by definition it is a physical bus, which is even electrically > independant from the rest of the HDMI bus (A/V path) > > - I don't think it is a good idea to tight it so closely to v4l, because > one can perfectly have CEC-capable hardware without video, or at least > not use v4l and have HDMI-CEC hardware > > - it was suggested to use sockets at some point, I think it is > over-engineered and should only lead > > - processing messages in user-space is definitively the way to go, even > input can be either re-injected using an uinput driver, or be handled in > user-space entirely, eventually we might want to install "filters" based > on opcodes to divert some opcodes to a kernel consumer, and the others > to an user-space one > > Right now, I have a very simple implementation that I developed for the > company I work for which can be found here: > https://github.com/ffainelli/linux-hdmi-cec > > It is designed like this: > > 1) A core module, which registers a cec bus, and provides an abstraction > for a CEC adapter (both device & driver): > - basic CEC adapter operations: logical address setting, queueing > management > - counters, rx filtering > - host attaching/detaching in case the hardware is capable of > self-processing CEC messages (for wakeup in particular) > > 2) A character device module, which exposes a character device per CEC > adapter and only allows one consumer at a time and exposes the following > ioctl's: > > - SET_LOGICAL_ADDRESS > - RESET_DEVICE > - GET_COUNTERS > - SET_RX_MODE (my adapter can be set in a promiscuous mode) > > the character device supports read/write/poll, which are the prefered > ways for transfering/receiving data > > 3) A CEC adapter implementation which registers and calls into the core > module when receiving a CEC message, and which the core module calls in > response to the IOCTLs described below. > > At first I thought about defining a generic netlink family in order to > allow multiple user-space listeners receive CEC messages, but in the end > having only one consumer per adapter device is fine by me and a more > traditionnal approach for programmers. > > I am relying on external components for knowing my HDMI physical address. > > Hope this is not too late to (re)start the discussion on HDMI-CEC. > > Thank you very much. > -- > Florian > -- > 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2012-04-12 20:36 ` Oliver Schinagl @ 2012-04-13 5:03 ` Hans Verkuil 2012-04-13 9:27 ` Florian Fainelli 2012-04-17 13:31 ` Anssi Hannula 1 sibling, 1 reply; 25+ messages in thread From: Hans Verkuil @ 2012-04-13 5:03 UTC (permalink / raw) To: Oliver Schinagl; +Cc: Florian Fainelli, linux-media, marbugge You both hit the main problem of the CEC support: how to implement the API. Cisco's work on CEC has been stalled as we first want to get HDMI support in V4L. Hopefully that will happen in the next few months. After that we will resume working on the CEC API. Regards, Hans On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote: > Since a lot of video cards dont' support CEC at all (not even > connected), don't have hdmi, but work perfectly fine with dvi->hdmi > adapters, CEC can be implemented in many other ways (think media centers) > > One such exammple is using USB/Arduino > > http://code.google.com/p/cec-arduino/wiki/ElectricalInterface > > Having an AVR with v-usb code and cec code doesn't look all that hard > nor impossible, so one could simply have a USB plug on one end, and an > HDMI plug on the other end, utilizing only the CEC pins. > > This would make it more something like LIRC if anything. > > On 04/12/12 17:24, Florian Fainelli wrote: > > Hi Hans, Martin, > > > > Sorry to jump in so late in the HDMI-CEC discussion, here are some > > comments from my perspective on your proposal: > > > > - the HDMI-CEC implementation deserves its own bus and class of devices > > because by definition it is a physical bus, which is even electrically > > independant from the rest of the HDMI bus (A/V path) > > > > - I don't think it is a good idea to tight it so closely to v4l, because > > one can perfectly have CEC-capable hardware without video, or at least > > not use v4l and have HDMI-CEC hardware > > > > - it was suggested to use sockets at some point, I think it is > > over-engineered and should only lead > > > > - processing messages in user-space is definitively the way to go, even > > input can be either re-injected using an uinput driver, or be handled in > > user-space entirely, eventually we might want to install "filters" based > > on opcodes to divert some opcodes to a kernel consumer, and the others > > to an user-space one > > > > Right now, I have a very simple implementation that I developed for the > > company I work for which can be found here: > > https://github.com/ffainelli/linux-hdmi-cec > > > > It is designed like this: > > > > 1) A core module, which registers a cec bus, and provides an abstraction > > for a CEC adapter (both device & driver): > > - basic CEC adapter operations: logical address setting, queueing > > management > > - counters, rx filtering > > - host attaching/detaching in case the hardware is capable of > > self-processing CEC messages (for wakeup in particular) > > > > 2) A character device module, which exposes a character device per CEC > > adapter and only allows one consumer at a time and exposes the following > > ioctl's: > > > > - SET_LOGICAL_ADDRESS > > - RESET_DEVICE > > - GET_COUNTERS > > - SET_RX_MODE (my adapter can be set in a promiscuous mode) > > > > the character device supports read/write/poll, which are the prefered > > ways for transfering/receiving data > > > > 3) A CEC adapter implementation which registers and calls into the core > > module when receiving a CEC message, and which the core module calls in > > response to the IOCTLs described below. > > > > At first I thought about defining a generic netlink family in order to > > allow multiple user-space listeners receive CEC messages, but in the end > > having only one consumer per adapter device is fine by me and a more > > traditionnal approach for programmers. > > > > I am relying on external components for knowing my HDMI physical address. > > > > Hope this is not too late to (re)start the discussion on HDMI-CEC. > > > > Thank you very much. > > -- > > Florian > > -- > > 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 > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2012-04-13 5:03 ` Hans Verkuil @ 2012-04-13 9:27 ` Florian Fainelli 0 siblings, 0 replies; 25+ messages in thread From: Florian Fainelli @ 2012-04-13 9:27 UTC (permalink / raw) To: Hans Verkuil; +Cc: Oliver Schinagl, linux-media, marbugge Hi Hans, Le 04/13/12 07:03, Hans Verkuil a écrit : > You both hit the main problem of the CEC support: how to implement the API. Well, the API that I propose here [1] is quite simple: - a kernel-side API for defining CEC adapters drivers - a character device with an ioctl() control path and read/write/poll data-path [1]: https://github.com/ffainelli/linux-hdmi-cec > > Cisco's work on CEC has been stalled as we first want to get HDMI support in > V4L. Hopefully that will happen in the next few months. After that we will > resume working on the CEC API. Well, I don't think that tighting HDMI into V4L is such a good idea either. HDMI is also a separate bus and deserves its own subsystem and even subsystems (audio, video, HDCP, CEC). For instance, the STB I am working with does not use the V4L API at all, however, I would like to be able to integrate within the Linux HDMI stack once there, think about nvidia's driver too. I can understand that you want to hold on your efforts on CEC while you want to get HDMI in, but don't make it entirely driven by Cisco and accept the community feedback. > > Regards, > > Hans > > On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote: >> Since a lot of video cards dont' support CEC at all (not even >> connected), don't have hdmi, but work perfectly fine with dvi->hdmi >> adapters, CEC can be implemented in many other ways (think media centers) >> >> One such exammple is using USB/Arduino >> >> http://code.google.com/p/cec-arduino/wiki/ElectricalInterface >> >> Having an AVR with v-usb code and cec code doesn't look all that hard >> nor impossible, so one could simply have a USB plug on one end, and an >> HDMI plug on the other end, utilizing only the CEC pins. >> >> This would make it more something like LIRC if anything. >> >> On 04/12/12 17:24, Florian Fainelli wrote: >>> Hi Hans, Martin, >>> >>> Sorry to jump in so late in the HDMI-CEC discussion, here are some >>> comments from my perspective on your proposal: >>> >>> - the HDMI-CEC implementation deserves its own bus and class of devices >>> because by definition it is a physical bus, which is even electrically >>> independant from the rest of the HDMI bus (A/V path) >>> >>> - I don't think it is a good idea to tight it so closely to v4l, because >>> one can perfectly have CEC-capable hardware without video, or at least >>> not use v4l and have HDMI-CEC hardware >>> >>> - it was suggested to use sockets at some point, I think it is >>> over-engineered and should only lead >>> >>> - processing messages in user-space is definitively the way to go, even >>> input can be either re-injected using an uinput driver, or be handled in >>> user-space entirely, eventually we might want to install "filters" based >>> on opcodes to divert some opcodes to a kernel consumer, and the others >>> to an user-space one >>> >>> Right now, I have a very simple implementation that I developed for the >>> company I work for which can be found here: >>> https://github.com/ffainelli/linux-hdmi-cec >>> >>> It is designed like this: >>> >>> 1) A core module, which registers a cec bus, and provides an abstraction >>> for a CEC adapter (both device& driver): >>> - basic CEC adapter operations: logical address setting, queueing >>> management >>> - counters, rx filtering >>> - host attaching/detaching in case the hardware is capable of >>> self-processing CEC messages (for wakeup in particular) >>> >>> 2) A character device module, which exposes a character device per CEC >>> adapter and only allows one consumer at a time and exposes the following >>> ioctl's: >>> >>> - SET_LOGICAL_ADDRESS >>> - RESET_DEVICE >>> - GET_COUNTERS >>> - SET_RX_MODE (my adapter can be set in a promiscuous mode) >>> >>> the character device supports read/write/poll, which are the prefered >>> ways for transfering/receiving data >>> >>> 3) A CEC adapter implementation which registers and calls into the core >>> module when receiving a CEC message, and which the core module calls in >>> response to the IOCTLs described below. >>> >>> At first I thought about defining a generic netlink family in order to >>> allow multiple user-space listeners receive CEC messages, but in the end >>> having only one consumer per adapter device is fine by me and a more >>> traditionnal approach for programmers. >>> >>> I am relying on external components for knowing my HDMI physical address. >>> >>> Hope this is not too late to (re)start the discussion on HDMI-CEC. >>> >>> Thank you very much. >>> -- >>> Florian >>> -- >>> 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 >> ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2012-04-12 20:36 ` Oliver Schinagl 2012-04-13 5:03 ` Hans Verkuil @ 2012-04-17 13:31 ` Anssi Hannula 2012-04-17 13:44 ` Oliver Schinagl 1 sibling, 1 reply; 25+ messages in thread From: Anssi Hannula @ 2012-04-17 13:31 UTC (permalink / raw) To: Oliver Schinagl; +Cc: Florian Fainelli, linux-media, marbugge, hverkuil 12.04.2012 23:36, Oliver Schinagl kirjoitti: > Since a lot of video cards dont' support CEC at all (not even > connected), don't have hdmi, but work perfectly fine with dvi->hdmi > adapters, CEC can be implemented in many other ways (think media centers) > > One such exammple is using USB/Arduino > > http://code.google.com/p/cec-arduino/wiki/ElectricalInterface > > Having an AVR with v-usb code and cec code doesn't look all that hard > nor impossible, so one could simply have a USB plug on one end, and an > HDMI plug on the other end, utilizing only the CEC pins. > > This would make it more something like LIRC if anything. There already exists a device like this (USB CEC adapter with hdmi in/out) with open source userspace driver, developed for the XBMC Media Center (apparently MythTV is also supported): http://www.pulse-eight.com/store/products/104-usb-hdmi-cec-adapter.aspx http://libcec.pulse-eight.com/ https://github.com/Pulse-Eight/libcec -- Anssi Hannula ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2012-04-17 13:31 ` Anssi Hannula @ 2012-04-17 13:44 ` Oliver Schinagl 0 siblings, 0 replies; 25+ messages in thread From: Oliver Schinagl @ 2012-04-17 13:44 UTC (permalink / raw) To: Anssi Hannula; +Cc: Florian Fainelli, linux-media, marbugge, hverkuil Yes, the library to talk to the device is opensource, the hardware, not so much. :) On 17-04-12 15:31, Anssi Hannula wrote: > 12.04.2012 23:36, Oliver Schinagl kirjoitti: >> Since a lot of video cards dont' support CEC at all (not even >> connected), don't have hdmi, but work perfectly fine with dvi->hdmi >> adapters, CEC can be implemented in many other ways (think media centers) >> >> One such exammple is using USB/Arduino >> >> http://code.google.com/p/cec-arduino/wiki/ElectricalInterface >> >> Having an AVR with v-usb code and cec code doesn't look all that hard >> nor impossible, so one could simply have a USB plug on one end, and an >> HDMI plug on the other end, utilizing only the CEC pins. >> >> This would make it more something like LIRC if anything. > There already exists a device like this (USB CEC adapter with hdmi > in/out) with open source userspace driver, developed for the XBMC Media > Center (apparently MythTV is also supported): > > http://www.pulse-eight.com/store/products/104-usb-hdmi-cec-adapter.aspx > http://libcec.pulse-eight.com/ > https://github.com/Pulse-Eight/libcec > ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <CAH-Z1=WtUrS0HYMsOb9CarAcXhR72cO8QWAnUJdP+zDuj92Rxg@mail.gmail.com>]
* Re: [RFC] HDMI-CEC proposal [not found] <CAH-Z1=WtUrS0HYMsOb9CarAcXhR72cO8QWAnUJdP+zDuj92Rxg@mail.gmail.com> @ 2012-05-10 11:43 ` Florian Fainelli 2012-05-10 12:11 ` Hans Verkuil 0 siblings, 1 reply; 25+ messages in thread From: Florian Fainelli @ 2012-05-10 11:43 UTC (permalink / raw) To: muralidhar dixit; +Cc: linux-media, hverkuil Hello Murali, On Thursday 10 May 2012 12:40:05 muralidhar dixit wrote: > Hello Florian, > > I do have similar implementation for my CEC driver. > And I prefer most of the CEC messaged to be handled in the user space and > have the kernel driver bare minimum with interfaces to > 1) REGISTER CEC device( I have support for multiple logical devices) > 2) SEND CEC MESSAGE > 3) RECV CEC MESSAGE > > But one issue with this was the response time to the TV remote actions. Well, I think this is specific to your platform, because I don't have any such issue here with my implementation. The specification says that the desired response time is of 200 ms and the maximum 1s, even with multiple context switches you should be able to achieve that. Not knowing exactly how your hardware works, maybe there is a bottleneck somewhere. > Initially I was sending the UI control messages also to user space but > response time was too bad. Hence I wrote a CEC Keyboard driver which will > process the CEC UI control messages. From the CEC driver if I recv any CEC > UI control messages I will route it to CEC Keyboard driver in the kernel > and all other messages have to be handled by user space application. This is the kind of thing that I want to avoid, on my platform, all the input is processed in user-land and exposed as a HID device (thus self-describing), forwarding CEC UI key codes to the kernel does not seem like a good solution to me because it means we have to know about the CEC protocol itself. I fear that if we start doing this with the CEC UI codes, we end-up doing the same for the system-related messages (Power, standby etc ...) and this is also to be avoided. > > Best Regards, > Murali > From: Florian Fainelli <f.fainelli <at> gmail.com> > Subject: Re: [RFC] HDMI-CEC > proposal<http://news.gmane.org/find- root.php?message_id=%3c4F87F195.5080504%40gmail.com%3e> > Newsgroups: gmane.linux.drivers.video-input- infrastructure<http://news.gmane.org/gmane.linux.drivers.video-input- infrastructure> > Date: 2012-04-13 09:27:49 GMT (3 weeks, 5 days, 21 hours and 33 minutes ago) > > Hi Hans, > > Le 04/13/12 07:03, Hans Verkuil a écrit : > > You both hit the main problem of the *CEC* support: how to implement the API. > > Well, the API that I propose here [1] is quite simple: > > - a kernel-side API for defining *CEC* adapters drivers > - a character device with an ioctl() control path and read/write/poll > data-path > > [1]: https://github.com/ffainelli/linux-*hdmi*-*cec* > <https://github.com/ffainelli/linux-hdmi-cec> > > > > > Cisco's work on *CEC* has been stalled as we first want to get *HDMI* support in > > V4L. Hopefully that will happen in the next few months. After that we will > > resume working on the *CEC* API. > > Well, I don't think that tighting *HDMI* into V4L is such a good idea > either. *HDMI* is also a separate bus and deserves its own subsystem and > even subsystems (audio, video, HDCP, *CEC*). For instance, the STB I am > working with does not use the V4L API at all, however, I would like to > be able to integrate within the Linux *HDMI* stack once there, think about > nvidia's driver too. > > I can understand that you want to hold on your efforts on *CEC* while you > want to get *HDMI* in, but don't make it entirely driven by Cisco and > accept the community feedback. > > > > > Regards, > > > > Hans > > > > On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote: > >> Since a lot of video cards dont' support *CEC* at all (not even > >> connected), don't have *hdmi*, but work perfectly fine with dvi->*hdmi* > >> adapters, *CEC* can be implemented in many other ways (think media centers) > >> > >> One such exammple is using USB/Arduino > >> > >> http://code.google.com/p/*cec*-arduino/wiki/ElectricalInterface <http://code.google.com/p/cec-arduino/wiki/ElectricalInterface> > >> > >> Having an AVR with v-usb code and *cec* code doesn't look all that hard > >> nor impossible, so one could simply have a USB plug on one end, and an > >> *HDMI* plug on the other end, utilizing only the *CEC* pins. > >> > >> This would make it more something like LIRC if anything. > >> > >> On 04/12/12 17:24, Florian Fainelli wrote: > >>> Hi Hans, Martin, > >>> > >>> Sorry to jump in so late in the *HDMI*-*CEC* discussion, here are some > >>> comments from my perspective on your *proposal*: > >>> > >>> - the *HDMI*-*CEC* implementation deserves its own bus and class of devices > >>> because by definition it is a physical bus, which is even electrically > >>> independant from the rest of the *HDMI* bus (A/V path) > >>> > >>> - I don't think it is a good idea to tight it so closely to v4l, because > >>> one can perfectly have *CEC*-capable hardware without video, or at least > >>> not use v4l and have *HDMI*-*CEC* hardware > >>> > >>> - it was suggested to use sockets at some point, I think it is > >>> over-engineered and should only lead > >>> > >>> - processing messages in user-space is definitively the way to go, even > >>> input can be either re-injected using an uinput driver, or be handled in > >>> user-space entirely, eventually we might want to install "filters" based > >>> on opcodes to divert some opcodes to a kernel consumer, and the others > >>> to an user-space one > >>> > >>> Right now, I have a very simple implementation that I developed for the > >>> company I work for which can be found here: > >>> https://github.com/ffainelli/linux-*hdmi*-*cec* <https://github.com/ffainelli/linux-hdmi-cec> > >>> > >>> It is designed like this: > >>> > >>> 1) A core module, which registers a *cec* bus, and provides an abstraction > >>> for a *CEC* adapter (both device& driver): > >>> - basic *CEC* adapter operations: logical address setting, queueing > >>> management > >>> - counters, rx filtering > >>> - host attaching/detaching in case the hardware is capable of > >>> self-processing *CEC* messages (for wakeup in particular) > >>> > >>> 2) A character device module, which exposes a character device per *CEC* > >>> adapter and only allows one consumer at a time and exposes the following > >>> ioctl's: > >>> > >>> - SET_LOGICAL_ADDRESS > >>> - RESET_DEVICE > >>> - GET_COUNTERS > >>> - SET_RX_MODE (my adapter can be set in a promiscuous mode) > >>> > >>> the character device supports read/write/poll, which are the prefered > >>> ways for transfering/receiving data > >>> > >>> 3) A *CEC* adapter implementation which registers and calls into the core > >>> module when receiving a *CEC* message, and which the core module calls in > >>> response to the IOCTLs described below. > >>> > >>> At first I thought about defining a generic netlink family in order to > >>> allow multiple user-space listeners receive *CEC* messages, but in the end > >>> having only one consumer per adapter device is fine by me and a more > >>> traditionnal approach for programmers. > >>> > >>> I am relying on external components for knowing my *HDMI* physical address. > >>> > >>> Hope this is not too late to (re)start the discussion on *HDMI*-*CEC*. > >>> > >>> Thank you very much. > >>> -- > >>> Florian > >>> -- > >>> To unsubscribe from this list: send the line "unsubscribe linux-media" in > >>> the body of a message to majordomo <at> 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 <at> vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC] HDMI-CEC proposal 2012-05-10 11:43 ` Florian Fainelli @ 2012-05-10 12:11 ` Hans Verkuil 0 siblings, 0 replies; 25+ messages in thread From: Hans Verkuil @ 2012-05-10 12:11 UTC (permalink / raw) To: Florian Fainelli; +Cc: muralidhar dixit, linux-media On Thu 10 May 2012 13:43:16 Florian Fainelli wrote: > Hello Murali, > > On Thursday 10 May 2012 12:40:05 muralidhar dixit wrote: > > Hello Florian, > > > > I do have similar implementation for my CEC driver. > > And I prefer most of the CEC messaged to be handled in the user space and > > have the kernel driver bare minimum with interfaces to > > 1) REGISTER CEC device( I have support for multiple logical devices) > > 2) SEND CEC MESSAGE > > 3) RECV CEC MESSAGE > > > > But one issue with this was the response time to the TV remote actions. > > Well, I think this is specific to your platform, because I don't have any such > issue here with my implementation. The specification says that the desired > response time is of 200 ms and the maximum 1s, even with multiple context > switches you should be able to achieve that. Not knowing exactly how your > hardware works, maybe there is a bottleneck somewhere. > > > Initially I was sending the UI control messages also to user space but > > response time was too bad. Hence I wrote a CEC Keyboard driver which will > > process the CEC UI control messages. From the CEC driver if I recv any CEC > > UI control messages I will route it to CEC Keyboard driver in the kernel > > and all other messages have to be handled by user space application. > > This is the kind of thing that I want to avoid, on my platform, all the input > is processed in user-land and exposed as a HID device (thus self-describing), > forwarding CEC UI key codes to the kernel does not seem like a good solution > to me because it means we have to know about the CEC protocol itself. > > I fear that if we start doing this with the CEC UI codes, we end-up doing the > same for the system-related messages (Power, standby etc ...) and this is also > to be avoided. We are also doing parsing in userspace. The CEC API just gets the hardware up and running so that we can send and receive CEC packets, but the kernel doesn't parse. The only exception to that *might* be the remote control part of the CEC specification (that's where button presses of a remote control are passed over CEC). It might make sense to pass them on to the V4L2 framework for remote controls. Then again, it might not. Or only if you set a flag or something. My personal view (but not everyone agreed at the time) is that we just need a simple API to send/receive CEC packets and do everything else in userspace. It would be nice if we have a standard library for that that everyone can use, though. Regards, Hans > > > > > Best Regards, > > Murali > > From: Florian Fainelli <f.fainelli <at> gmail.com> > > Subject: Re: [RFC] HDMI-CEC > > proposal<http://news.gmane.org/find- > root.php?message_id=%3c4F87F195.5080504%40gmail.com%3e> > > Newsgroups: gmane.linux.drivers.video-input- > infrastructure<http://news.gmane.org/gmane.linux.drivers.video-input- > infrastructure> > > Date: 2012-04-13 09:27:49 GMT (3 weeks, 5 days, 21 hours and 33 minutes ago) > > > > Hi Hans, > > > > Le 04/13/12 07:03, Hans Verkuil a écrit : > > > You both hit the main problem of the *CEC* support: how to implement the > API. > > > > Well, the API that I propose here [1] is quite simple: > > > > - a kernel-side API for defining *CEC* adapters drivers > > - a character device with an ioctl() control path and read/write/poll > > data-path > > > > [1]: https://github.com/ffainelli/linux-*hdmi*-*cec* > > <https://github.com/ffainelli/linux-hdmi-cec> > > > > > > > > Cisco's work on *CEC* has been stalled as we first want to get *HDMI* > support in > > > V4L. Hopefully that will happen in the next few months. After that we will > > > resume working on the *CEC* API. > > > > Well, I don't think that tighting *HDMI* into V4L is such a good idea > > either. *HDMI* is also a separate bus and deserves its own subsystem and > > even subsystems (audio, video, HDCP, *CEC*). For instance, the STB I am > > working with does not use the V4L API at all, however, I would like to > > be able to integrate within the Linux *HDMI* stack once there, think about > > nvidia's driver too. > > > > I can understand that you want to hold on your efforts on *CEC* while you > > want to get *HDMI* in, but don't make it entirely driven by Cisco and > > accept the community feedback. > > > > > > > > Regards, > > > > > > Hans > > > > > > On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote: > > >> Since a lot of video cards dont' support *CEC* at all (not even > > >> connected), don't have *hdmi*, but work perfectly fine with dvi->*hdmi* > > >> adapters, *CEC* can be implemented in many other ways (think media > centers) > > >> > > >> One such exammple is using USB/Arduino > > >> > > >> http://code.google.com/p/*cec*-arduino/wiki/ElectricalInterface > <http://code.google.com/p/cec-arduino/wiki/ElectricalInterface> > > >> > > >> Having an AVR with v-usb code and *cec* code doesn't look all that hard > > >> nor impossible, so one could simply have a USB plug on one end, and an > > >> *HDMI* plug on the other end, utilizing only the *CEC* pins. > > >> > > >> This would make it more something like LIRC if anything. > > >> > > >> On 04/12/12 17:24, Florian Fainelli wrote: > > >>> Hi Hans, Martin, > > >>> > > >>> Sorry to jump in so late in the *HDMI*-*CEC* discussion, here are some > > >>> comments from my perspective on your *proposal*: > > >>> > > >>> - the *HDMI*-*CEC* implementation deserves its own bus and class of > devices > > >>> because by definition it is a physical bus, which is even electrically > > >>> independant from the rest of the *HDMI* bus (A/V path) > > >>> > > >>> - I don't think it is a good idea to tight it so closely to v4l, because > > >>> one can perfectly have *CEC*-capable hardware without video, or at least > > >>> not use v4l and have *HDMI*-*CEC* hardware > > >>> > > >>> - it was suggested to use sockets at some point, I think it is > > >>> over-engineered and should only lead > > >>> > > >>> - processing messages in user-space is definitively the way to go, even > > >>> input can be either re-injected using an uinput driver, or be handled in > > >>> user-space entirely, eventually we might want to install "filters" based > > >>> on opcodes to divert some opcodes to a kernel consumer, and the others > > >>> to an user-space one > > >>> > > >>> Right now, I have a very simple implementation that I developed for the > > >>> company I work for which can be found here: > > >>> https://github.com/ffainelli/linux-*hdmi*-*cec* > <https://github.com/ffainelli/linux-hdmi-cec> > > >>> > > >>> It is designed like this: > > >>> > > >>> 1) A core module, which registers a *cec* bus, and provides an > abstraction > > >>> for a *CEC* adapter (both device& driver): > > >>> - basic *CEC* adapter operations: logical address setting, queueing > > >>> management > > >>> - counters, rx filtering > > >>> - host attaching/detaching in case the hardware is capable of > > >>> self-processing *CEC* messages (for wakeup in particular) > > >>> > > >>> 2) A character device module, which exposes a character device per *CEC* > > >>> adapter and only allows one consumer at a time and exposes the following > > >>> ioctl's: > > >>> > > >>> - SET_LOGICAL_ADDRESS > > >>> - RESET_DEVICE > > >>> - GET_COUNTERS > > >>> - SET_RX_MODE (my adapter can be set in a promiscuous mode) > > >>> > > >>> the character device supports read/write/poll, which are the prefered > > >>> ways for transfering/receiving data > > >>> > > >>> 3) A *CEC* adapter implementation which registers and calls into the > core > > >>> module when receiving a *CEC* message, and which the core module calls > in > > >>> response to the IOCTLs described below. > > >>> > > >>> At first I thought about defining a generic netlink family in order to > > >>> allow multiple user-space listeners receive *CEC* messages, but in the > end > > >>> having only one consumer per adapter device is fine by me and a more > > >>> traditionnal approach for programmers. > > >>> > > >>> I am relying on external components for knowing my *HDMI* physical > address. > > >>> > > >>> Hope this is not too late to (re)start the discussion on *HDMI*-*CEC*. > > >>> > > >>> Thank you very much. > > >>> -- > > >>> Florian > > >>> -- > > >>> To unsubscribe from this list: send the line "unsubscribe linux-media" > in > > >>> the body of a message to majordomo <at> 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 <at> 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 > ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2012-05-10 12:11 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-03-01 9:59 [RFC] HDMI-CEC proposal Martin Bugge (marbugge) 2011-03-01 12:28 ` Mauro Carvalho Chehab 2011-03-01 14:38 ` Hans Verkuil 2011-03-01 15:20 ` Mauro Carvalho Chehab 2011-03-01 15:49 ` Hans Verkuil 2011-03-01 16:19 ` Mauro Carvalho Chehab 2011-03-01 17:09 ` Hans Verkuil 2011-03-01 13:47 ` Andy Walls 2011-03-01 14:59 ` Martin Bugge (marbugge) 2011-03-01 17:31 ` Hans Verkuil 2011-03-01 17:52 ` Alex Deucher 2011-03-02 9:13 ` Hans Verkuil 2011-03-02 15:49 ` Alex Deucher 2011-03-01 23:38 ` Daniel Glöckner 2011-03-02 9:34 ` Martin Bugge (marbugge) 2011-03-03 10:37 ` Laurent Pinchart 2011-03-03 12:11 ` Martin Bugge (marbugge) 2012-04-12 15:24 Florian Fainelli 2012-04-12 20:36 ` Oliver Schinagl 2012-04-13 5:03 ` Hans Verkuil 2012-04-13 9:27 ` Florian Fainelli 2012-04-17 13:31 ` Anssi Hannula 2012-04-17 13:44 ` Oliver Schinagl [not found] <CAH-Z1=WtUrS0HYMsOb9CarAcXhR72cO8QWAnUJdP+zDuj92Rxg@mail.gmail.com> 2012-05-10 11:43 ` Florian Fainelli 2012-05-10 12:11 ` Hans Verkuil
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.