Hi Divneil, On 07/04/2014 11:30 AM, Divneil Wadhawan wrote: > Hi Hans, > > >> To my knowledge nobody has done much if any work on this. Usually >> the audio part is handled by alsa, but it is not clear if support >> is also needed from the V4L2 API. > > Actually, the application needs to know when to ask the capture > device to start capturing. > > Let's say, the cable is already plugged in/or plugged out. > > So, any events will be missed as the driver state machine starts > during boot up and app is not started. > > App starts later, registers for (V4L2_EVENT_SOURCE_CHANGE back > ported to 3.10) and listens, but will not receive any as they are > already generated. I don't understand the problem. When the application starts the first thing it should do is to call VIDIOC_QUERY_DV_TIMINGS: that will tell it if any signal is present. An alternative might be to extend v4l2_src_change_event_subscribe() and have it honor the V4L2_EVENT_SUB_FL_SEND_INITIAL flag: if set, it should issue this event at once. That might actually be a nice improvement. > > > So, the application is in a blind spot whether to start capture or > not. But what has that to do with audio? > If we get the same interface as video it's good. I mean G_FMT with a > union for audio as well. > > Otherwise, I can go with a proprietary control/ioctl indicating > whether audio is valid or not. > > ioctl seems to be an easy choice, because this subdev is not > exposing any controls, so, registration with ctrl framework for a > single one seems a bit of overload. It's perfectly fine to have a single control. Nothing wrong with that. Still not sure what you actually need in V4L2 w.r.t. the audio information. 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
