On Thursday, December 23, 2010 14:04:38 Andy Walls wrote: > On Thu, 2010-12-23 at 10:02 +0100, Laurent Pinchart wrote: > > Hi Hans, > > > > On Monday 20 December 2010 14:09:40 Hans Verkuil wrote: > > > On Monday, December 20, 2010 13:48:51 Laurent Pinchart wrote: > > > > > > > > What if the application wants to change the resolution during capture ? > > > > It will have to stop capture, call REQBUFS(0), change the format, > > > > request buffers and restart capture. If filehandle ownership is dropped > > > > after REQBUFS(0) that will open the door to a race condition. > > > > > > That's why S_PRIORITY was invented. > > > > Right, I should implement that. I think the documentation isn't clear though. > > What is the background priority for exactly ? > > http://linuxtv.org/downloads/v4l-dvb-apis/app-pri.html > > "Another objective is to permit low priority applications working in > background, which can be preempted by user controlled applications and > automatically regain control of the device at a later time." > > <contrived examples> > A use case would be for a daemon that does background channel scanning > or VBI data collection when the user isn't doing something else with the > video device. > > For a camera, maybe it would be an application that does device health > monitoring, some sort of continuous calibration, or motion detection > when the device isn't in use by the user for viewing. > </contrived examples> > > > And the "unset" priority ? > > When checking for the maximum priority in use, it indicates that no > nodes have any priorities. See v4l2_prio_max(). For a driver that > supports priorities, it means no device nodes are opened, since any > device node being open would get a priority of > V4L2_PRIORITY_INTERACTIVE/_DEFAULT by default in v4l2_prio_open(). > > V4L2_PRIORITY_UNSET is also used to indicate to the v4l2_prio_*() > functions that a struct v4l2_prio_state hasn't been initialized (i.e. > has just been kzalloc()'ed). > > > Are > > other applications allowed to change controls when an application has the > > record priority ? > > According to the spec, no: > > "V4L2_PRIORITY_RECORD 3 Highest priority. Only one file descriptor can > have this priority, it blocks any other fd from changing device > properties." > > Once an automated, scheduled-recording process is recording, one really > wouldn't want another process changing them. I personally would not > like unpredictable volume level variations on my TV show recordings. > > > In cx18-controls.c one can find an implementation example for the old > control framework: > > int cx18_s_ext_ctrls(struct file *file, void *fh, struct v4l2_ext_controls *c) > { > struct cx18_open_id *id = fh; > struct cx18 *cx = id->cx; > int ret; > struct v4l2_control ctrl; > > ret = v4l2_prio_check(&cx->prio, id->prio); > if (ret) > return ret; > [...] > > However, the new control framework in v4l2-ctrl.c seems to be missing > any v4l2_prio_check() calls. The ioctl() handling in v4l2-ioctl.c > doesn't have any either. Oops, I'd forgotten about that. The priority support really should be moved into the v4l2 core framework where it belongs. I'll see if I can spend some time on that after Christmas. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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
