Hello Tom,
Yes, and it would be even more nasty for parallel capture of video and
VBI. Imagine some background data harvesting VBI app is running without
a GUI. The user would basically have to use ps|grep and kill everytime
he/she would like to switch the channel in a TV app. Would be a huge
step backwards, far beyond v4l1.
Please keep in mind that v4l1 basically meant bttv. It might have worked
for bttv, but that was a policy that was not specified anywhere. Most of
the time it was pure luck that it simply worked.
Other drivers simply had to behave like bttv, otherwise apps would not
work. A "good" example was the vbi counter, that was embedded in the raw
vbi data, because there was no way to tell if one vbi "packet" has been
lost. That code had to be duplicated in every driver.
Therefore I also think norm switching should be possible while capture
is enabled.
There are both technical problems as well as policy problems.
If you change the norm, the maximum capture size can change, so you have
to reprogram your capture engine. In that case, you have to check all
capture buffers if they can handle the new size. Most of the time, the
size will shrink (let's say you have a fullscreen PAL and change to
NTSC), but there is no way that the driver can tell "Hey, I'm capturing
with 640x480 now in your 720x576 sized buffer".
There is a hidden policy in there that says "If the user changes the
norm and the maximum size is lower, then simply write to the buffer with
a smaller resolution". But hidden policies are always a bad thing.
Although I too would stop capture when I change norms for
my own capture process, however a parallel VBI capture or overlay should
not limit my capabilities to switch
Switching and norm changes can occur at the same time. In some parts of
Germany, there are still channels from the British Army that broadcast
with PAL-I. If you switch to that channel, you'll need to change the
norm, too.
(see also the newly introduced
priority handling: a background app should be able to avoid interfering
with interactive/foreground apps in any way)
The problem with that is, that the code has to be duplicated in each and
every driver. It adds bloat to the driver that needs to be debugged. But
kernel drivers should be small and simple, everything else should be
done in userspace.
So why not write a v4l2-dispatch-daemon, that lets your vbi application
harvest data in the background, gives exclusive capture access to
another application and manages channel switching and norm changing?
(I admit that this is probably not easy to solve either and other
problems might arise...)
bye,
-tom
CU
Michael.
