Hi Hans,
> 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. I guess dv timings will be valid for DVI too. If yes, then there is no audio. There's no video device for this, just subdev. > 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. Okay, if it gives the already fired event, then it's good. There is one concern for this v4l2_src_change_event_subscribe(). I was using v4l2_subscribed_event_ops for storing the "struct v4l2_subscribed_event sev." Later take out from list so, that I can call v4l2_event_queue() from the async event handler. I didn't had to worry for addition/deletion of "sev" from my list as this was managed by event framework calling these ops. So, now with v4l2_src_change_event_subscribe(), I cannot use the ops, and I have to manage "fh" using list. This addition deletion must now be handled by me, and cannot be taken care by v4l2_event_subdev_unsubscribe(). I hope I have not missed any trivial stuff ;) > But what has that to do with audio? For video, we have VIDIOC_SUBDEV_G_FMT, for audio, there's nothing. Regards, Divneil -- 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
