diff options
author | Hans Verkuil <hans.verkuil@cisco.com> | 2016-04-25 10:02:13 (GMT) |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@s-opensource.com> | 2016-06-28 12:59:51 (GMT) |
commit | 56967c77d4c22bb31dbf18cc058147f4df433dd7 (patch) | |
tree | f8ad6966f6d52d9728736414516f4d4e89265c1e /drivers/staging | |
parent | ca684386e6e21ba1511061f71577cdb6c3f2b3d3 (diff) | |
download | linux-56967c77d4c22bb31dbf18cc058147f4df433dd7.tar.xz |
[media] cec/TODO: add TODO file so we know why this is still in staging
Explain why cec.c is still in staging.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Diffstat (limited to 'drivers/staging')
-rw-r--r-- | drivers/staging/media/cec/TODO | 27 |
1 files changed, 27 insertions, 0 deletions
diff --git a/drivers/staging/media/cec/TODO b/drivers/staging/media/cec/TODO new file mode 100644 index 0000000..a8f4b7d --- /dev/null +++ b/drivers/staging/media/cec/TODO @@ -0,0 +1,27 @@ +The reason why cec.c is still in staging is that I would like +to have a bit more confidence in the uABI. The kABI is fine, +no problem there, but I would like to let the public API mature +a bit. + +Once I'm confident that I didn't miss anything then the cec.c source +can move to drivers/media and the linux/cec.h and linux/cec-funcs.h +headers can move to uapi/linux and added to uapi/linux/Kbuild to make +them public. + +Hopefully this will happen later in 2016. + +Other TODOs: + +- Add a flag to inhibit passing CEC RC messages to the rc subsystem. + Applications should be able to choose this when calling S_LOG_ADDRS. +- Convert cec.txt to sphinx. +- If the reply field of cec_msg is set then when the reply arrives it + is only sent to the filehandle that transmitted the original message + and not to any followers. Should this behavior change or perhaps + controlled through a cec_msg flag? +- Should CEC_LOG_ADDR_TYPE_SPECIFIC be replaced by TYPE_2ND_TV and TYPE_PROCESSOR? + And also TYPE_SWITCH and TYPE_CDC_ONLY in addition to the TYPE_UNREGISTERED? + This should give the framework more information about the device type + since SPECIFIC and UNREGISTERED give no useful information. + +Hans Verkuil <hans.verkuil@cisco.com> |