f5580d8d6f
The CEC_MSG_INITIATE_ARC message is special since it is the ONLY CEC message that accepts two possible valid replies: CEC_MSG_REPORT_ARC_INITIATED and CEC_MSG_REPORT_ARC_TERMINATED. So if the transmitted message is CEC_MSG_INITIATE_ARC and the remote side replied with CEC_MSG_REPORT_ARC_INITIATED or CEC_MSG_REPORT_ARC_TERMINATED, then a msg->reply value of CEC_MSG_REPORT_ARC_INITIATED or CEC_MSG_REPORT_ARC_TERMINATED will match either reply. I thought about either adding a second reply2 field, but that's ugly for all other messages that have only one reply, and what if in the future a new message is added that can have three replies? Another option would be to add a cec_msg flag, but really, the combination of CEC_MSG_REPORT_ARC_INITIATED and a reply value of one of the two possible replies already functions as a flag. Another advantage of this approach is that it is safe to re-use a cec_msg struct. No need to zero a flags field or a reply2 field. So since this really is an exception in the CEC specification, I decided to implement it as an exception as well. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> |
||
|---|---|---|
| .. | ||
| dvb-drivers | ||
| kapi | ||
| media_api_files | ||
| uapi | ||
| v4l-drivers | ||
| audio.h.rst.exceptions | ||
| ca.h.rst.exceptions | ||
| cec.h.rst.exceptions | ||
| conf.py | ||
| conf_nitpick.py | ||
| dmx.h.rst.exceptions | ||
| frontend.h.rst.exceptions | ||
| index.rst | ||
| intro.rst | ||
| lirc.h.rst.exceptions | ||
| Makefile | ||
| media.h.rst.exceptions | ||
| media_kapi.rst | ||
| media_uapi.rst | ||
| net.h.rst.exceptions | ||
| video.h.rst.exceptions | ||
| videodev2.h.rst.exceptions | ||