Commit | Line | Data |
---|---|---|
56967c77 HV |
1 | The reason why cec.c is still in staging is that I would like |
2 | to have a bit more confidence in the uABI. The kABI is fine, | |
3 | no problem there, but I would like to let the public API mature | |
4 | a bit. | |
5 | ||
6 | Once I'm confident that I didn't miss anything then the cec.c source | |
7 | can move to drivers/media and the linux/cec.h and linux/cec-funcs.h | |
8 | headers can move to uapi/linux and added to uapi/linux/Kbuild to make | |
9 | them public. | |
10 | ||
11 | Hopefully this will happen later in 2016. | |
12 | ||
13 | Other TODOs: | |
14 | ||
260ff114 | 15 | - There are two possible replies to CEC_MSG_INITIATE_ARC. How to handle that? |
56967c77 HV |
16 | - Add a flag to inhibit passing CEC RC messages to the rc subsystem. |
17 | Applications should be able to choose this when calling S_LOG_ADDRS. | |
56967c77 HV |
18 | - If the reply field of cec_msg is set then when the reply arrives it |
19 | is only sent to the filehandle that transmitted the original message | |
20 | and not to any followers. Should this behavior change or perhaps | |
21 | controlled through a cec_msg flag? | |
22 | - Should CEC_LOG_ADDR_TYPE_SPECIFIC be replaced by TYPE_2ND_TV and TYPE_PROCESSOR? | |
23 | And also TYPE_SWITCH and TYPE_CDC_ONLY in addition to the TYPE_UNREGISTERED? | |
24 | This should give the framework more information about the device type | |
25 | since SPECIFIC and UNREGISTERED give no useful information. | |
5bb2399a HV |
26 | - Once this is out of staging this should no longer be a separate |
27 | config option, instead it should be selected by drivers that want it. | |
28 | - Revisit the IS_REACHABLE(RC_CORE): perhaps the RC_CORE support should | |
29 | be enabled through a separate config option in drivers/media/Kconfig | |
30 | or rc/Kconfig? | |
56967c77 HV |
31 | |
32 | Hans Verkuil <hans.verkuil@cisco.com> |