Hans de Goede wrote: > Hi, > > On 02/24/2010 01:58 AM, Mauro Carvalho Chehab wrote: >> Hans de Goede wrote: >>> Hi, >>> >>> On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote: >>>> Hans de Goede wrote: >>>> >>>>> Ok, so this will give me a local tree, how do I get this onto >>>>> linuxtv.org ? >>>> >>>> I added it. In thesis, it is open for commit to you, me, hverkuil and >>>> dougsland. >>>> >>> >>> I see good, thanks! Can someone (Douglas ?) with better hg / git powers >>> then me please >>> somehow import all the libv4l changes from: >>> http://linuxtv.org/hg/~hgoede/libv4l >> >> Ok, I added there. The procedure were simple: I ran Brandon script again, >> but after pulling from your tree. Then, I used git format-patch to >> generate >> a quilt series, and used git quiltimport on the correct -git tree. >> > > Thanks! > > >>> Once that is done I'll retire my own tree, and move all my userspace >>> work to >>> the git tree. >>> >>> For starters I plan to create / modify Makefiles so that everything will >>> build >>> out of the box, and has proper make install targets which can be used by >>> distro's >>> >>> So: >>> -proper honoring of CFLAGS >>> -work with standard (and possibly somewhat older kernel headers) >>> -honor DESTDIR, PREFIX and LIBDIR when doing make install >> >> The better here is to have the latest kernel headers copied on the tree. >> This way, it is possible to compile libv4l2 with an older kernel >> version and >> later upgrade the kernel, if needed, or to use a fast machine to compile >> it, and then use it on another machine. >> > > If possible I would like to avoid this, afaik no other userspace utility > packages > are doing this. > > 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 > > So libv4l (in its current state) will already compile fine with older > kernel > headers. I expect that the other utilities will not need a lot of > recent kernel ABI. So for now I would like to try and extend the above > approach > to the other utilities. I think build will fail. I remember I had some such troubles when compiling it against RHEL5, before we did the merge with the in-tree videodev2.h. It should be reminded that, when people upgrade their kernels by hand, they generally don't run "make headers_install". So, the kernel headers on /usr/include/linux are the ones found on the original distro kernel, and not the ones that are needed by the user. > 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, The sync problem will keep existing, since some of the tools from this tree are used as examples on media-specs. > 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. > > 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: > #ifndef V4L2_PIX_FMT_SPCA501 > #define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per > line */ > #endif > > 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. True, but the additional work for those occasional changes are minimum, and may save some time when handling complains about why the tree don't build on his machine. -- Cheers, Mauro -- 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
