Hello Gerd and all the others,
> > > No. videodev.o allows only one process to open the device. Any chance
> My plan is to simply pass down the struct file* instead of struct
> video_device* (except for open). [...]
> This requires changes of the driver callbacks, i.e. we need a second
> set of hooks (called open2/close2/... for example), depending on the flag
> the old/new ones are called by videodev.c.
[...]
> Another minor problem is that allowing multiple opens implies some minor
> API changes. Right now a application can do anything once it has opened
> (i.e. allocated) the device. With multiple opens allowed only a few ioctls
> (basically VIDIOG*) work all the time, other ones might return -EBUSY if
> another application uses the driver in parallel. Should I care? Maybe
> allow apps to open the driver with O_EXCL like the floppy driver does?
I have been following this discussion silently for quite some time now.
I cannot understand why on the one side changing the exsting (and in my
eyes obsolete) v4l-api is suggested which would definetely break
existing driver- as well as user-code, when on the other side
there is an existing and very-well designed api that already
features most things people are always asking for: v4l2.
v4l2 fixed all problems and inconsistencies in comparision to v4l
I had, when developing drivers for both apis:
Here is a short list:
1) v4l2 uses queues to for the capture buffers. With v4l it was
up to the user-application to arrange the capture buffers. But with
more than 2 buffers, the driver might change the ordering of buffers
to improve capture performance. With v4l this might lead to the problem
that capturing mixes buffers.
(Example: v4l queues the buffers 1,2,3, the hardware captures to buffers
1 and 2, v4l deques buffers 1 and 2, but only re-queues buffer 1.
My driver now would use buffer 1 to capture in order to increase
performance,
but v4l would rely on buffer 3 being filled... 8-(
2) One problem that Gerd states in his programming-faq within `xawtv':
> One problem is that the TV norm (PAL/NTSC/...) is in struct
> video_tuner, not struct video_channel. That's bad if you have a board
> without tuner at all and a PAL video recorder connected to Composite1
> and a NTSC Camera to Composite2...
> Fixing this required changes in both structs and the VIDIOCSCHAN
> ioctl.
I have two demonstration-boards that don�t feature a tuner and have
encountered problems with getting my old v4l driver to work with
'kwintv',
because it expects a tuner of some sort...
3) Another big thing is the inconsistency within different capture
formats. For example: in v4l the byte-order for, say, YUV422 is
not defined. Whereas the natural byte-order for bt8x8-based hardware
seems to be UYVY, it is YUYV for saa7146-based hardware for
example.
v4l2 clearly separates these two capture formats.
4) ...
----
So I cannot understand why v4l2 is not seen as an successor
for v4l.
My suggestion would be: bring in v4l2 into the kernel with a
new major number as well as the existing v4l2-drivers.
As long as not all drivers have been ported, v4l could stay
in the kernel being marked 'obsolete', preventing users
from developping programs for the old api.
Isn�t this the best way to introduce new stuff into the kernel?
(I think of the transition from the ext-fs to the ext2-fs.)
CU,
Michael.
--
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
