Expected behavior for S_INPUT while streaming in progress?

[Devin Heitmueller <dheitmueller@kernellabs.com>]

Hello,

I'm doing some cleanup on the au8522 driver, and one thing I noticed
was that you are actually allowed to issue an S_INPUT while streaming
is active.  This seems like dangerous behavior, since it can result in
things like the standard and/or resolution changing while the device
is actively streaming video.

Should we be returning -EBUSY for S_INPUT if streaming is in progress?
 I see cases in drivers where we prevent S_STD from working while
streaming is in progress, but it seems like S_INPUT is a superset of
S_STD (it typically happens earlier in the setup process).

If we did do this, how badly do we think it would break existing
applications?  It could require applications to do a STREAMOFF before
setting the input (to handle the possibility that the call wasn't
issued previously when an app was done with the device), which I
suspect many applications aren't doing today.

Alternatively, we can based it on not just whether streamon was called
and instead base it on the combination of streamon having been called
and a filehandle actively doing streaming.  In this case case would
return EBUSY if both conditions were met, but if only streamon was
called but streaming wasn't actively being done by a filehandle, we
would internally call streamoff and then change the input.  This would
mean that if an application like tvtime were running, externally
toggling the input would return EBUSY.  But if nothing was actively
streaming via a /dev/videoX device then the call to set input would be
successful (after internally stopping the stream).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com