Re: [PATCH] USB: add Sensoray 2255 v4l driver
From: Mauro Carvalho Chehab
Date: Fri May 16 2008 - 11:35:38 EST
On Fri, 16 May 2008 07:53:46 -0700
dean <dean@xxxxxxxxxxxx> wrote:
> >Btw, I noticed the lack of Dean's SOB. Is this intentional?
> It's not intentional, I can sign off on it.
Thanks. Please send your SOB at the next version.
> I have a few other questions. First, is Video for Linux version 1 going
> to be obsoleted soon?
We intend to, but people are currently lacking time to port old drivers to V4L2.
> Do the V4L1 compatibility routines still work in
> the latest driver?
V4L1 compat will still be kept for some time after the end of V4L1 drivers.
> I had problems running the VIVI (virtual video
> driver) driver with VideoLan/VLC 0.8.6a-f, but it worked with VLC 9.0
> with the new V4L2 interface.
VLC V4L1 implementation were broken. It first starts DMA and streaming, then,
it calls some ioctls that changes the buffer size. The compat handler doesn't
accept this behaviour, since it would cause buffer overflow. AFAIK, only bttv
driver used to support this behaviour. On V4L1 mode, bttv were allocating
enough memory for the maximum resolution. So, subsequent buffer changes works
It would be valuable if you could work on a safe way to implement backward
compat for this broken behaviour. In this case, you would need to change the
compat implementation at videobuf, and let v4l1-compat module to be aware that
it is safe to allow buffer size changes.
Yet, this seems to much work for something that should be already removed from
> "videodev: "s2255v" has no release callback. Please fix your driver for
> proper sysfs support, see http://lwn.net/Articles/36850/"
> Should we get rid of the warning message above? It's also been present
> in VIVI for quite a few kernel releases.
The message doesn't cause any harm, but the better is to fix this also. This
were already corrected at the latest vivi versions.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/