v4l2 patch has the priority stuff in, structs + ioctls in videodev2.h, some helper functions in v4l2-common.c to keep patches for the drivers small. Only three levels. Completely untested so far. Comments?
Looks fine to me. Only, since you're using a separate semaphore for priority updates - which drivers will probably not apply in addition to the hardware access semaphore around execution of SET ioctls - it might be better to modify v4l2_prio_change() so that the new prio is set before the old one is released. Else a low-prio SET ioctl might get through in the middle (e.g. between a change from interactive to record level.)
David Balazic wrote:
The problem of using limited resources in a multi-user/tasking environment is not exactly new. Before you reinvent the wheel, you
could look up some existing solutions.
Actually the proposed event reporting mechanism is derived from poll() and the priority handling is in effect simply a semaphore. So I think I've done my share of reusing :)
IMHO the hard part is not finding a solution, but figuring out the problem, i.e. what will future video/vbi/audio input/output apps require? I'll readily admit that my proposal is mainly based on requirements which are derived from my own applications and experiences. If you have anything to add, then please speak up.
Also note that my proposal isn't about adding resource and/or rights management into the driver (*), instead it's about leaking just enough information to allow capture processes themselves to limit or manage side-effects of parameter changes in shared resources. In regard to actual capturing (including overlay and output etc.) it's still good old "first come/first serve". Multi-user isn't considered at all.
(* With the exception of priority checks which is the only way to avoid a race. But still priorities are used in a cooperative way since they can be defined freely.)
bye, -tom
-- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/video4linux-list
