On Sat, 15 Jul 2006, Mauro Carvalho Chehab wrote:
> Em Sáb, 2006-07-15 às 23:08 +0000, Robert Fitzsimons escreveu:
> > The layout of struct video_device would change depending on whether
> > videodev.h (V4L1) was include or not before v4l2-dev.h, which caused
> > the structure to get corrupted.
> Hmm... good point! However, I the proper solution would be to trust on
> CONFIG_VIDEO_V4L1_COMPAT or CONFIG_VIDEO_V4L1 instead. it makes no sense
> to keep a pointer to an unsupported callback, when V4L1 is not selected.

It's not so clear that the problem is with v4l2-dev.h, because if you look
that file:

#ifdef CONFIG_VIDEO_V4L1
#include <linux/videodev.h>
#else
#include <linux/videodev2.h>
#endif

linux/videodev.h is where HAVE_V4L1 is defined (always).  So, if
CONFIG_VIDEO_V4L1 is set, then HAVE_V4L1 must also bet set.

I think that the real problem is that many drivers include the V4L1 API
file videodev.h when V4L1 is NOT on.  Should drivers be providing V4L1 API
functions, or need anything from videodev.h, if V4L1 is not on?

It seems like they either need to depend on VIDEO_V4L1 or only include the
V4L1 API header file when V4L1 is turned on.  Which also means they would
need to #ifdef out any V4L1 code when V4L1 is turned off.  The bttv driver
for example does not do this.  It includes a bunch of V4L1 functions even
when V4L1 (and V4L1_COMPAT) are turned off.

BTW, I think the CONFIG_VIDEO_V4L1 check in v4l2-dev.h should instead check
for CONFIG_VIDEO_V4L1_COMPAT.  For example, cx88-video.c includes
videodev.h when CONFIG_VIDEO_V4L1_COMPAT is turned on.