Re: [Workshop-2011] Media summit/KS-2012 proposals

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2012/8/3 Hans Verkuil <hverkuil@xxxxxxxxx>:
> On Fri August 3 2012 07:37:13 Jun Nie wrote:
>> 2012/8/1 Hans Verkuil <hverkuil@xxxxxxxxx>:
>> > 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux