[PATCHv2 0/2] media: cec: add new CEC_MSG_FL_REPLY_VENDOR_ID flag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Often <Vendor Command With ID> messages start with a vendor-specific
opcode, and expect a reply with the same Vendor ID, but a different
opcode. It is very convenient if the same CEC core framework support
for waiting for replies to regular CEC messages could be used for this
as well.

Add support for this by creating the CEC_MSG_FL_REPLY_VENDOR_ID flag
and the CEC_CAP_REPLY_VENDOR_ID capability.

Also add support for <Vendor Command With ID> to the vivid driver
to allow this feature to be tested by cec-compliance in combination
with vivid.

A separate patch series will be posted for v4l-utils.

Regards,

	Hans

Changes since v1:
- The abort check in cec_received_msg_ts was accidentally
  changed to check against data->match_reply[0]. That's
  the reply, and not the opcode that was aborted.
  Revert that change, and now cec-compliance passes again.

Hans Verkuil (2):
  media: cec: core: add new CEC_MSG_FL_REPLY_VENDOR_ID flag
  media: vivid: add <Vendor Command With ID> support

 .../media/cec/cec-ioc-adap-g-caps.rst         |  6 +++
 .../media/cec/cec-ioc-receive.rst             | 15 ++++++
 drivers/media/cec/core/cec-adap.c             | 52 +++++++++++++------
 drivers/media/cec/core/cec-core.c             |  2 +-
 drivers/media/test-drivers/vivid/vivid-cec.c  | 48 +++++++++++++++--
 include/media/cec.h                           |  2 +
 include/uapi/linux/cec.h                      |  3 ++
 7 files changed, 109 insertions(+), 19 deletions(-)

-- 
2.43.0





[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux