Hi,
On 02/24/2010 03:32 PM, Brandon Philips wrote:
On 13:55 Wed 24 Feb 2010, Hans de Goede wrote:
<snip>
Where necessary libv4l currently has code snippets like:
#ifndef V4L2_PIX_FMT_SPCA501
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line */
#endif
I don't think this is less work than copying the header file from the
Kernel. Test building under all versions of the Kernel headers that
exist to make sure something isn't missed isn't possible. It really is
easier just to sync the header file up.
The reason for this is that I want to avoid carrying a copy of a dir
from some other tree, with all getting stale and needing sync all
the time issues that come with that, not to mention chicken and egg
problems in the case of new formats which simultaneously need to be
added to both libv4l and the kernel.
Worst case is that if it is stale then it won't build since it depends
on fancy new feature XYZ. But, at least it won't build on all systems
instead of randomly breaking based on installed kernel headers
version.
For example often I add support for V4L2_PIX_FMT_NEW_FOO to libv4l, before it
hits any official v4l-dvb kernel tree, with the:
Please don't add features to releases before they are merged with
Linus. It would suck to ship a copy of libv4l that has a different
idea of structs or constants then the upstream Kernel.
Note the only thing added is a V4L2_PIX_FMT_xxx define, IOW this makes libv4l
recognize (and convert from) a new video format, which is to be generated
by a going upstream soon driver. With older kernels this won't make any
difference as those don't generate that format.
Approach this works fine, if I were to carry an include tree copy, that would
now need to become a patched include tree copy, and with the next sync I then
need to ensure that any needed patches are either already in the sync source,
or applied again.
Or just fix it upstream with #ifdef __KERNEL__ tags once and for all,
right?
I wasn't even talking about #ifdef __KERNEL__ issues, although yes those
exist too.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
