Re: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux