[deliverable/linux.git] / drivers / staging / media / cec / TODO

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:

- There are two possible replies to CEC_MSG_INITIATE_ARC. How to handle that?
- 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.
- 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.
- Once this is out of staging this should no longer be a separate
  config option, instead it should be selected by drivers that want it.
- Revisit the IS_REACHABLE(RC_CORE): perhaps the RC_CORE support should
  be enabled through a separate config option in drivers/media/Kconfig
  or rc/Kconfig?

Hans Verkuil <hans.verkuil@cisco.com>
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.
56967c77 HV	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
56967c77 HV	32	Hans Verkuil <hans.verkuil@cisco.com>