On Mon August 6 2012 15:22:38 Jun Nie wrote: > 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. Switching between an EDID for analog or digital input when using a DVI-I cable is the most common use-case that I know of. But this does not apply as such to an HDMI connector since that's digital only. Another might be that a simple EDID is setup when the device boots, and once it is booted and all the features of the device are known a more advanced EDID might be written. I'm sure that there are more creative uses as well... 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
