Hi,
Thanks to everyone who has commented so far.
Gerd Knorr wrote:
Accordingly we could have a V4L2_BUF_TYPE_EVENT and extend struct
v4l2_format to set up the event mechanism.
I was thinking about exactly the same while reading the event
proposal.
So did I when I wrote it :) However I chose to use a separate type
and variable simply to reduce the risk of side-effects, since
v4l2_buf_type is used in a lot of places. But I'd consider this
only a detail in implementation.
Any pro/cons to event handling in general?
(I've added only what I consider useful for VBI apps so far, maybe
there's other significant global parameters for other capture types,
e.g. audio mute?)
I'd propose to offer the following 4 priority levels: (...)
Why 2+3? One level for that would be enougth IMHO, any serious
recording is exclusive anyway (see STREAMON/OFF in the specs) ...
The main reason is that priority levels and exclusive use of a level
are different privileges. Offering exclusive mode separately gives
applications the choice if they require only one or both.
I'm aware that you cannot supersede an ongoing recording, but the
non-exclusive level would allow the user to consciously override
a channel setting (which might be useful while the recorded show is
interrupted by a commercial break; the TV app could then temporarily
raise it's prio level to "record" for the time of a channel change
by the user's permission.) There also might be recording applications
which use multiple processes, e.g. one for recording the stream and
one for control.
But I do see that having two "record" levels might be confusing as
you're not the first who asked about this :)
BTW: any suggestions regarding handling of radio, in particular
the mode change upon open? (Possibly reject the device open with
EBUSY when a recording is active or delay radio mode change until
the first frequency is tuned?)
Wolfram.Gloger wrote:
Gerd wrote:
This adds a race window. Between looking for /dev/video users and
invoking the ioctl another application might have opened the
device.
True. However, as I understood the proposal, this race wasn't
considered significant.
My fault then for not mentioning it. Avoiding a race condition was
one of the design goals, because else a low-prio background app might
destroy a scheduled recording (e.g. you might record 2 hours of RTL2
instead of your movie if you're running an nxtvepg daemon - since
you seem to live in Germany you'll be able to imagine the horror in
that :)
Gerd wrote:
mschimek@xxxxxx writes:
We kept /dev/vbi for compatibility, now we have to deal with apps
using it. The proxy compares the device file names to see if apps
want to read from the same device.
Huh? Why do you need that? Is there some LD_PRELOAD library to make
existing apps use the proxy instead of /dev/{vbi|video} without
patching them? Otherwise I can't see a reason why the proxy has to
care ...
Ok, I'll try to explain: the underlying problem we want to solve is:
given two different device paths, we want to decide if they refer to
the same piece of hardware.
This problem occured in the implementation of the VBI proxy: the proxy
daemon is given a list of device paths it's supposed to serve on the
command line. When a client connects, it provides a device path to the
proxy to identify which device it requests. This one may be an arbitrary
default path compiled into the application or have been provided to the
app on its command line. Now the proxy must match the given path against
its internal list (i) to check if it's supposed to serve that device and
(ii) to make sure it doesn't attempt to capture from the same device
twice which would not work.
Anyway, bus_info should do the trick.
Could we make this info mandatory for all v4l2 drivers then? If the
driver doesn't have anything like a bus_info it could still provide an
instance number instead. In combination with the driver name the info
should be unique.
-tom
