2012/8/3 Hans Verkuil <hverk...@xs4all.nl>:
> On Fri August 3 2012 07:37:13 Jun Nie wrote:
>> 2012/8/1 Hans Verkuil <hverk...@xs4all.nl>:
>> > On Tue 31 July 2012 19:58:23 Mauro Carvalho Chehab wrote:
>> >> In order to sum-up the discussions around the media summit,
>> >> this is what we've got so far:
>> >>
>> >> Proposals                                                                 
>> >>             proposed by
>> >> =====================================================================================|=========================================================================================
>> >> Common device tree bindings for media devices                             
>> >>             Sylvester Nawrocki / Guennadi Liakhovetski
>> >> ALSA and V4L/Media Controller                                             
>> >>             Steven Toth / Laurent Pinchart
>> >> ARM and needed features for V4L/DVB                                       
>> >>             Steven Toth
>> >> Intel media SDK                                                           
>> >>                     Steven Toth
>> >> V4L compiance tool                                                        
>> >>             Hans Verkuil
>> >> V4L2 API ambiguities                                                      
>> >>             Hans Verkuil
>> >> Media Controller library                                                  
>> >>             Laurent Pincart / Sakari Ailus
>> >> SoC Vendors feedback – how to help them to go upstream – Android's V4L2 
>> >> cam library   Laurent Pincart / Guennadi Liakhovetski / Palash 
>> >> Bandyopadhyay / Naveen Krishnamurthy
>> >> Synchronization, shared resource and optimizations                        
>> >>             Pawel Osciak
>> >> V4L2/DVB issues from userspace perspective                                
>> >>             Rémi Denis-Courmont
>> >>
>> >> As we'll have only one day for the summit, we may need to remove some
>> >> themes, or maybe to get an extra time during LPC for the remaining
>> >> discussions.
>> >>
>> >> Possible attendents:
>> >> ===================
>> >>
>> >> Guennadi Liakhovetski
>> >> Laurent Pinchart
>> >> Mauro Carvalho Chehab
>> >> Michael Krufky
>> >> Naveen Krishnamurthy
>> >> +1 seat from ST (waiting Naveen to define who will be the other seat)
>> >> Palash Bandyopadhyay
>> >> Pawel Osciak
>> >> Rémi Denis-Courmont
>> >> Sakari Ailus
>> >> Steven Toth
>> >> Sylvester Nawrocki
>> >>
>> >> Am I missing something?
>> >>
>> >> Are there other proposals or people intending to participate?
>> >
>> > Yes: I would like to discuss how to add support for HDMI CEC to the kernel.
>> > In particularly I need some feedback from the GPU driver developers on what
>> > their ideas are, since CEC is something that touches both V4L2 and GPU.
>> >
>> I am not familiar with CEC implementation in GPU.
>
> As far as I am aware there isn't any.
>
>> But CEC should be
>> independent in functionality with audio/video though it is A/V
>> related. I prefer to support only CEC frame TX/RX in kernel. CEC
>> include different category features that need parsing and may need
>> application interaction. Venders may also configure some features as
>> not supported.  If kernel support more than TX/RX, policy may be
>> separated to user space part and kernel space part. The kernel
>> interface also becomes complex, maybe ambiguous too. An user space
>> library is more suitable for this task to interact with OS/media
>> player/audio control/etc.
>
> I wish that were possible. Our current implementation internally is as you
> proposed, but we recently discovered that for HDMI 1.4a this won't fly.
>
> There the CEC channel is also used for control of the ethernet and audio
> return channel, and even for hotplug detect in some cases.
>
> That's something that has to be handled entirely in kernelspace. So some
> parts of the CEC protocol have to be internally processed, other parts
> have to be processed in userspace.
>
Thanks for your reminder. I was not aware of HEAC/ARC dependence on
CEC for our product does not include these features. Maybe we can
parse CDC CEC message in kernel and leave others to user space. But it
is also an ugly propose.
BTW: Do you see any scenario that EDID is changed dynamically? I do
not know why to add hot-plug to CEC control while no physical HPD
changes.

> This really complicates things and it makes it even more important that
> the subsystems that need CEC work together on this.
>
> Regards,
>
>         Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to