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
