Skip to contentSkip to conversation

HDMI-CEC proposal

RFC Martin Bugge (marbugge) 8 participants 17 messages Mar 1, 2011 – Mar 3, 2011 Media (V4L/DVB)

lore
Share & tools
lore

Martin Bugge (marbugge)

author
#0 lore raw

Author: Martin Bugge <[email protected]>
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)
--

#1 lore raw

Hi Martin,

Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu:

Quoted 31 lines

Author: Martin Bugge <[email protected]>
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

Quoted 6 lines

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.

Quoted 108 lines

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

Signature · 7 lines
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#7 lore raw
In reply to Martin Bugge (marbugge)
Quoted 28 lines · Martin Bugge (marbugge)

Author: Martin Bugge <[email protected]>
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)

Quoted 8 lines

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

Quoted 117 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw
In reply to Mauro Carvalho Chehab

Hi Mauro,

Quoted 8 lines · On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote:

Hi Martin,

Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu:

Quoted 5 lines

Author: Martin Bugge <[email protected]>
Date: Tue, 1 March 2010
======================

This is a proposal for adding a Consumer Electronic Control (CEC) API to

V4L2.

Quoted 7 lines
Quoted 7 lines

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.

Quoted 1 line
Quoted 1 line

It is an optional supplement to the High-Definition Multimedia Interface

Specification (HDMI).

Quoted 1 line
Quoted 1 line

Physical layer is a one-wire bidirectional serial bus that uses the

industry-standard AV.link protocol.

Quoted 2 lines
Quoted 2 lines

In short: CEC uses pin 13 on the HDMI connector to transmit and receive

small data-packets

Quoted 1 line
Quoted 1 line

(maximum 16 bytes including a 1 byte header) at low data rates

(~400 bits/s).

Quoted 5 lines
Quoted 5 lines

A CEC device may have any of 15 logical addresses (0 - 14). (address 15 is broadcast and some addresses are reserved)

Quoted 7 lines
Quoted 7 lines

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

Quoted 10 lines
Quoted 8 lines

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

Quoted 1 line

Remote Controller data, and should be interacting with the proper Kernel

subsystems, e. g.,

Quoted 1 line

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.

Quoted 2 lines

I don't think we need two ioctls for that, as RC capabilities are already

exported via

Quoted 1 line

sysfs, and we have two interfaces already for receiving events (input/event

and lirc).

Quoted 1 line

For sending, lirc interface might be used, but it is currently focused only

on sending

Quoted 1 line

raw pulse/space sequences. So, we'll need to add some capability there for

IR/CEC TX.

Quoted 1 line

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

Quoted 6 lines
Quoted 6 lines

VIDIOC_CEC_CAP:
---------------

Quoted 6 lines
Quoted 6 lines
struct vl2_cec_cap {
       __u32 logicaldevices;
       __u32 reserved[7];
};

The capability ioctl will return the number of logical devices/addresses

which can be

Quoted 40 lines
Quoted 40 lines

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)
Quoted 7 lines
Quoted 7 lines

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.

Quoted 9 lines
Quoted 9 lines

* 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

Quoted 7 lines
Quoted 7 lines

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.

Quoted 5 lines
Quoted 5 lines

Events
------

In the case of non-blocking mode the driver will issue the following

events:

Quoted 37 lines
Quoted 13 lines

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;
}
Quoted 17 lines

V4L2_EVENT_CEC_RX
-----------------
* received a complete message

Comments ?

Martin Bugge

Signature · 7 lines
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 [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#8 lore raw
In reply to Andy Walls
Quoted 68 lines · Andy Walls
Quoted 28 lines · Martin Bugge (marbugge)

Author: Martin Bugge<[email protected]>
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)

Quoted 9 lines

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.

Quoted 7 lines

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

Quoted 121 lines
Quoted 119 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#3 lore raw
In reply to Hans Verkuil

Em 01-03-2011 11:38, Hans Verkuil escreveu:

Quoted 84 lines

Hi Mauro,

Quoted 8 lines · On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote:

Hi Martin,

Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu:

Quoted 5 lines

Author: Martin Bugge <[email protected]>
Date: Tue, 1 March 2010
======================

This is a proposal for adding a Consumer Electronic Control (CEC) API to

V4L2.

Quoted 7 lines
Quoted 7 lines

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.

Quoted 1 line
Quoted 1 line

It is an optional supplement to the High-Definition Multimedia Interface

Specification (HDMI).

Quoted 1 line
Quoted 1 line

Physical layer is a one-wire bidirectional serial bus that uses the

industry-standard AV.link protocol.

Quoted 2 lines
Quoted 2 lines

In short: CEC uses pin 13 on the HDMI connector to transmit and receive

small data-packets

Quoted 1 line
Quoted 1 line

(maximum 16 bytes including a 1 byte header) at low data rates

(~400 bits/s).

Quoted 5 lines
Quoted 5 lines

A CEC device may have any of 15 logical addresses (0 - 14). (address 15 is broadcast and some addresses are reserved)

Quoted 7 lines
Quoted 7 lines

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

Quoted 10 lines
Quoted 8 lines

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

Quoted 1 line

Remote Controller data, and should be interacting with the proper Kernel

subsystems, e. g.,

Quoted 1 line

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.

Quoted 2 lines

I don't think we need two ioctls for that, as RC capabilities are already

exported via

Quoted 1 line

sysfs, and we have two interfaces already for receiving events (input/event

and lirc).

Quoted 1 line

For sending, lirc interface might be used, but it is currently focused only

on sending

Quoted 1 line

raw pulse/space sequences. So, we'll need to add some capability there for

IR/CEC TX.

Quoted 1 line

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.

Quoted 5 lines

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.

#4 lore raw
Quoted 53 lines · On Tuesday, March 01, 2011 16:20:25 Mauro Carvalho Chehab wrote:

Em 01-03-2011 11:38, Hans Verkuil escreveu:

Quoted 52 lines

Hi Mauro,

Quoted 8 lines · On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote:

Hi Martin,

Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu:

Quoted 5 lines

Author: Martin Bugge <[email protected]>
Date: Tue, 1 March 2010
======================

This is a proposal for adding a Consumer Electronic Control (CEC) API to

V4L2.

Quoted 7 lines
Quoted 7 lines

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.

Quoted 1 line
Quoted 1 line

It is an optional supplement to the High-Definition Multimedia Interface

Specification (HDMI).

Quoted 1 line
Quoted 1 line

Physical layer is a one-wire bidirectional serial bus that uses the

industry-standard AV.link protocol.

Quoted 2 lines
Quoted 2 lines

In short: CEC uses pin 13 on the HDMI connector to transmit and receive

small data-packets

Quoted 1 line
Quoted 1 line

(maximum 16 bytes including a 1 byte header) at low data rates

(~400 bits/s).

Quoted 5 lines
Quoted 5 lines

A CEC device may have any of 15 logical addresses (0 - 14). (address 15 is broadcast and some addresses are reserved)

Quoted 7 lines
Quoted 7 lines

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

Quoted 10 lines
Quoted 8 lines

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

Quoted 8 lines
Quoted 8 lines

just a way to get/send

Quoted 1 line

Remote Controller data, and should be interacting with the proper Kernel

subsystems, e. g.,

Quoted 1 line

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

Quoted 2 lines
Quoted 2 lines

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

Quoted 3 lines
Quoted 3 lines

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

Quoted 1 line
Quoted 1 line

to pass such IR commands to the IR core, instead you want to retransmit

them

Quoted 6 lines
Quoted 6 lines

to a CEC output.

Quoted 2 lines

I don't think we need two ioctls for that, as RC capabilities are already

exported via

Quoted 1 line

sysfs, and we have two interfaces already for receiving events

(input/event

Quoted 2 lines
Quoted 2 lines

and lirc).

Quoted 1 line

For sending, lirc interface might be used, but it is currently focused

only

Quoted 2 lines
Quoted 2 lines

on sending

Quoted 1 line

raw pulse/space sequences. So, we'll need to add some capability there

for

Quoted 5 lines
Quoted 5 lines

IR/CEC TX.

Quoted 1 line

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

Quoted 4 lines
Quoted 4 lines

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

Quoted 1 line
Quoted 1 line

points a remote at a TV (for example), which then passes it over CEC to

your

Quoted 9 lines
Quoted 3 lines

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

Quoted 4 lines

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

Quoted 1 line

higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC,

input/event,

Quoted 1 line

vfs, tty, etc are good examples of how we do APIs in Linux. We should only

go

Quoted 1 line

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.

Quoted 2 lines

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

Quoted 1 line

HDMI-CIC, a raw access on one process during a RC reception or transmit

could

Quoted 3 lines

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.

Quoted 2 lines

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

#5 lore raw

Em 01-03-2011 12:49, Hans Verkuil escreveu:

Quoted 117 lines · On Tuesday, March 01, 2011 16:20:25 Mauro Carvalho Chehab wrote:
Quoted 53 lines

Em 01-03-2011 11:38, Hans Verkuil escreveu:

Quoted 52 lines

Hi Mauro,

Quoted 8 lines · On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote:

Hi Martin,

Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu:

Quoted 5 lines

Author: Martin Bugge <[email protected]>
Date: Tue, 1 March 2010
======================

This is a proposal for adding a Consumer Electronic Control (CEC) API to

V4L2.

Quoted 7 lines
Quoted 7 lines

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.

Quoted 1 line
Quoted 1 line

It is an optional supplement to the High-Definition Multimedia Interface

Specification (HDMI).

Quoted 1 line
Quoted 1 line

Physical layer is a one-wire bidirectional serial bus that uses the

industry-standard AV.link protocol.

Quoted 2 lines
Quoted 2 lines

In short: CEC uses pin 13 on the HDMI connector to transmit and receive

small data-packets

Quoted 1 line
Quoted 1 line

(maximum 16 bytes including a 1 byte header) at low data rates

(~400 bits/s).

Quoted 5 lines
Quoted 5 lines

A CEC device may have any of 15 logical addresses (0 - 14). (address 15 is broadcast and some addresses are reserved)

Quoted 7 lines
Quoted 7 lines

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

Quoted 10 lines
Quoted 8 lines

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

Quoted 8 lines
Quoted 8 lines

just a way to get/send

Quoted 1 line

Remote Controller data, and should be interacting with the proper Kernel

subsystems, e. g.,

Quoted 1 line

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

Quoted 2 lines
Quoted 2 lines

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

Quoted 3 lines
Quoted 3 lines

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

Quoted 1 line
Quoted 1 line

to pass such IR commands to the IR core, instead you want to retransmit

them

Quoted 6 lines
Quoted 6 lines

to a CEC output.

Quoted 2 lines

I don't think we need two ioctls for that, as RC capabilities are already

exported via

Quoted 1 line

sysfs, and we have two interfaces already for receiving events

(input/event

Quoted 2 lines
Quoted 2 lines

and lirc).

Quoted 1 line

For sending, lirc interface might be used, but it is currently focused

only

Quoted 2 lines
Quoted 2 lines

on sending

Quoted 1 line

raw pulse/space sequences. So, we'll need to add some capability there

for

Quoted 5 lines
Quoted 5 lines

IR/CEC TX.

Quoted 1 line

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

Quoted 4 lines
Quoted 4 lines

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

Quoted 1 line
Quoted 1 line

points a remote at a TV (for example), which then passes it over CEC to

your

Quoted 9 lines
Quoted 3 lines

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

Quoted 4 lines

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

Quoted 1 line

higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC,

input/event,

Quoted 1 line

vfs, tty, etc are good examples of how we do APIs in Linux. We should only

Quoted 8 lines

go

Quoted 1 line

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.

Quoted 3 lines

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.

Quoted 12 lines
Quoted 2 lines

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

Quoted 1 line

HDMI-CIC, a raw access on one process during a RC reception or transmit

could

Quoted 3 lines

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.

Quoted 8 lines
Quoted 2 lines

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.

#6 lore raw
Quoted 3 lines · On Tuesday, March 01, 2011 17:19:21 Mauro Carvalho Chehab wrote:

Em 01-03-2011 12:49, Hans Verkuil escreveu:

Quoted 2 lines · On Tuesday, March 01, 2011 16:20:25 Mauro Carvalho Chehab wrote:
Quoted 1 line

Em 01-03-2011 11:38, Hans Verkuil escreveu:

<snip>

Quoted 36 lines
Quoted 27 lines
Quoted 1 line
Quoted 1 line

Again, CEC != IR. All you need is a simple API to be able to send and

receive

Quoted 4 lines
Quoted 4 lines

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

Quoted 1 line
Quoted 1 line

points a remote at a TV (for example), which then passes it over CEC to

your

Quoted 9 lines
Quoted 3 lines

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

Quoted 4 lines

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

Quoted 1 line

higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC,

input/event,

Quoted 1 line

vfs, tty, etc are good examples of how we do APIs in Linux. We should only

Quoted 8 lines

go

Quoted 1 line

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.

Quoted 3 lines

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.

Quoted 6 lines
Quoted 4 lines

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.

Quoted 22 lines
Quoted 13 lines
Quoted 3 lines

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

Quoted 1 line

HDMI-CIC, a raw access on one process during a RC reception or transmit

could

Quoted 3 lines

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.

Quoted 8 lines
Quoted 2 lines

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.

Quoted 8 lines

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

Signature · 1 line
Hans Verkuil - video4linux developer - sponsored by Cisco
#9 lore raw
In reply to Martin Bugge (marbugge)
Quoted 87 lines · On Tuesday, March 01, 2011 15:59:21 Martin Bugge (marbugge) wrote:
Quoted 68 lines · Andy Walls
Quoted 28 lines · Martin Bugge (marbugge)

Author: Martin Bugge<[email protected]>
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)

Quoted 9 lines

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.

Quoted 7 lines

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.

Quoted 8 lines

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

Signature · 1 line
Hans Verkuil - video4linux developer - sponsored by Cisco
#10 lore raw
In reply to Martin Bugge (marbugge)
Quoted 19 lines · Martin Bugge (marbugge)

Author: Martin Bugge <[email protected]>
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.

Quoted 8 lines

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

Quoted 129 lines

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

#13 lore raw
In reply to Martin Bugge (marbugge)
Quoted 6 lines · Martin Bugge (marbugge)

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

#11 lore raw
In reply to Alex Deucher

Hi Alex,

Quoted 10 lines · On Tuesday, March 01, 2011 18:52:28 Alex Deucher wrote:
Quoted 8 lines · Martin Bugge (marbugge)

Author: Martin Bugge <[email protected]>
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.

Quoted 5 lines
Quoted 5 lines

Version 1.0 (This is first version)

Background
==========
CEC is a protocol that provides high-level control functions between

various

Quoted 11 lines
Quoted 11 lines

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).

Quoted 6 lines
Quoted 3 lines

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

Quoted 95 lines

Alex

Quoted 92 lines

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

Quoted 6 lines
Quoted 6 lines

transmit.

Events
------

In the case of non-blocking mode the driver will issue the following

events:

Quoted 33 lines
Quoted 31 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#14 lore raw
In reply to Daniel Glöckner
Quoted 32 lines · Daniel Glöckner
Quoted 7 lines · Martin Bugge (marbugge)

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.

Quoted 4 lines

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

#12 lore raw
In reply to Hans Verkuil
Quoted 34 lines · Hans Verkuil

Hi Alex,

Quoted 10 lines · On Tuesday, March 01, 2011 18:52:28 Alex Deucher wrote:
Quoted 8 lines · Martin Bugge (marbugge)

Author: Martin Bugge <[email protected]>
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.

Quoted 5 lines
Quoted 5 lines

Version 1.0 (This is first version)

Background
==========
CEC is a protocol that provides high-level control functions between

various

Quoted 15 lines
Quoted 14 lines

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)

Quoted 7 lines
Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 4 lines

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

Quoted 142 lines

Regards,

       Hans

Quoted 95 lines

Alex

Quoted 92 lines

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

Quoted 6 lines
Quoted 6 lines

transmit.

Events
------

In the case of non-blocking mode the driver will issue the following

events:

Quoted 33 lines
Quoted 31 lines

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

#15 lore raw
In reply to Martin Bugge (marbugge)

Hi Martin,

Quoted 130 lines · On Tuesday 01 March 2011 10:59:07 Martin Bugge (marbugge) wrote:

Author: Martin Bugge <[email protected]>
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

Quoted 8 lines

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.

Quoted 3 lines

V4L2_EVENT_CEC_RX
-----------------
* received a complete message

Signature · 3 lines
Regards,

Laurent Pinchart
author
#16 lore raw
Quoted 139 lines · Laurent Pinchart

Hi Martin,

Quoted 135 lines · On Tuesday 01 March 2011 10:59:07 Martin Bugge (marbugge) wrote:

Author: Martin Bugge<[email protected]>
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

Quoted 8 lines
Quoted 4 lines
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

Quoted 5 lines
Quoted 4 lines

V4L2_EVENT_CEC_RX
-----------------
* received a complete message