On Monday, June 27, 2011 23:20:07 Mauro Carvalho Chehab wrote: > Em 07-06-2011 12:05, Hans Verkuil escreveu: > > From: Hans Verkuil <hans.verkuil@xxxxxxxxx> > > > > When an application changes a control you want to generate an event. > > However, you want to avoid sending such an event back to the application > > (file handle) that caused the change. > > Why? > > I can see two usecases for an event-triggered control change: > 1) when two applications are used, and one changed a value that could > affect the other; > 2) as a way to implement async changes. > > However, it seems, from your comments, that you're covering only case (1). > > There are several reasons why we need to support case (2): > > Some controls may be associated to a servo mechanism (like zoom, optical > focus, etc), or may require some time to happen (like charging a flash device). > So, it makes sense to have events back to the application that caused the change. > > Kernel should not assume that the application that requested a change on a control > doesn't want to receive the notification back when the event actually happened. > This way, both cases will be covered. > > Yet, I failed to see where, in the code, such restriction were imposed. Async changes are triggered by the driver, not an application. Any changes made by the driver will be sent to all applications. That said, I think I should add a flag like V4L2_EVENT_SUB_FL_NO_FEEDBACK to explicitly let applications decide. That's easy enough. 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
