Re: [ANNOUNCE] git tree repositories libv4l
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hi, On 02/24/2010 07:05 AM, Brandon Philips wrote: On 16:51 Tue 23 Feb 2010, Hans de Goede wrote: 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 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 Do you still want me to convert to autoconf? I was still planning on doing that. We discussed it a month ago when this conversation started. http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/15009 I know that was mentioned then, but re-thinking this, as this will all be Linux specific, I don't really see a need for autotools atm, and as I personally find autotools a bit overcomplicated. I would like to try just using plain Makefiles for now. If it turns out this does not work we can always switch to autotools later. Thanks for the offer though! Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
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.
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.
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.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hans de Goede wrote: Hi, On 02/24/2010 07:05 AM, Brandon Philips wrote: On 16:51 Tue 23 Feb 2010, Hans de Goede wrote: 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 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 Do you still want me to convert to autoconf? I was still planning on doing that. We discussed it a month ago when this conversation started. http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/15009 I know that was mentioned then, but re-thinking this, as this will all be Linux specific, I don't really see a need for autotools atm, and as I personally find autotools a bit overcomplicated. I would like to try just using plain Makefiles for now. If it turns out this does not work we can always switch to autotools later. I suspect it won't work fine. There are some library dependencies at utils/contrib, like libsysfs and libqt stuff. The build system should or refuse to compile or disable some of those tools if the dependencies are missing. Of course you may create a non-autotools configure script that checks for those libraries. They aren't many, so this approach works, but it will likely require more time than using autotools. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
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.
Note that the v4l2-ctl and v4l2-dbg utilities often *do* track the latest
kernel. In particular v4l2-ctl is often used to control/test new features.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
On 13:55 Wed 24 Feb 2010, Hans de Goede wrote:
On 02/24/2010 01:58 AM, Mauro Carvalho Chehab wrote:
Hans de Goede wrote:
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.
Off the top of my head I know ethtool does this. It greatly simplifies
the work of maintaing the package:
http://git.kernel.org/?p=network/ethtool/ethtool.git;a=blob;f=ethtool-copy.h;h=09dd5480ff3488214ab67ad04459541314291f79;hb=HEAD
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.
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?
Cheers,
Brandon
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hi all, On Wed, 24 Feb 2010, Mauro Carvalho Chehab wrote: I know that was mentioned then, but re-thinking this, as this will all be Linux specific, I don't really see a need for autotools atm, and as I personally find autotools a bit overcomplicated. I would like to try just using plain Makefiles for now. If it turns out this does not work we can always switch to autotools later. I suspect it won't work fine. There are some library dependencies at utils/contrib, like libsysfs and libqt stuff. The build system should or refuse to compile or disable some of those tools if the dependencies are missing. Have a look at cmake: cmake.org . It is extremely powerful in terms of external-library--detection, it can do QT natively and all other things around library generation and dependencies. Cmake has become my favorite build-tool for user-space development. Just my 2cts. -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hello all, On 02/23/2010 10:51 AM, 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 Done! Cheers Douglas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
On 22:12 Mon 22 Feb 2010, Mauro Carvalho Chehab wrote: Mauro Carvalho Chehab wrote: According to the wiki[1] these tools are without a maintainer. So, if no one cares about them enough to make releases why merge them and clutter up the git tree with dead code? [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps That's weird. I've recently added support for ISDB-T on it: http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/ and we've got some comments at the mailing list. Btw, the patches I added there also adds DVB-S2 support to szap/scan, but tests are needed, since I don't have any satellite dish nowadays. That's said, if all the issues are the ones listed above, I can try to address them on the next months, to put it into a better shape. That's said, I don't think we should have a single maintainer for it: there are too many DTV standards already, and probably nobody with enough time has access to all of those (DVB-T, DVB-T2, DVB-S, DVB-S2, ISDB-T, ISDB-S, ATSC, DSS, ...). So, I think we need a team of volunteers that will try to help with the standards they have access. I was not suggesting a single maintainer but I wanted to make sure there was actual interest in maintaing and fixing these dvb things. I don't interact much at all with DVB so all I had to go on was the wiki page. That's said, I'm starting to agree with Hans: maybe the better seems to merge it with v4l2-apps, to get synergy in terms, at least in terms of packet management. Comments? Seems reasonable to me. I would be willing to be the merge point for all of the various maintainers of dvb and v4l things and release manager for making the actual tar.gz releases. I wrote up the conversion for dvb-apps too. The merge of the two trees conflict pretty trivially so it should be easy to clean up if we go this route: # unmerged: COPYING # unmerged: INSTALL # unmerged: Make.rules # unmerged: Makefile # unmerged: README # unmerged: lib/Makefile # unmerged: utils/Makefile If you want to give it a whirl. git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ git checkout -b dvb-apps-too origin/dvb-apps-too ./convert.sh The result will be in step3 with the merge conflicts. Cheers, Brandon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hi, On 02/22/2010 11:54 PM, Brandon Philips wrote: On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh Ok, so this will give me a local tree, how do I get this onto linuxtv.org ? Also I need someone to pull: http://linuxtv.org/hg/~hgoede/libv4l (this only contains libv4l commits) Into the: http://linuxtv.org/hg/v4l-dvb Repository, I guess I can ask this directly to Douglas? Thoughts? I've one question, I think we want to do tarbal releases from this new repo (just like I've been doing with libv4l for a while already), and then want distro's to pick up these releases, right ? Are we going to do separate tarbals for the lib and utils directories, or one combined tarbal. I personally vote for one combined tarbal. But this means we will be inflicting some pains on distro's because their libv4l packages will go away and be replaced by a new v4l-utils package. This is something distro's should be able to handle (it happens more often, and I know Fedora has procedures for this). An alternative would be to name the repo and the tarbals libv4l, either is fine with me (although I'm one of the distro packagers who is going to feel the pain of a package rename and as such wouldn't mind using libv4l as name for the repo and the new tarbals). Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hi, On 02/22/2010 11:54 PM, Brandon Philips wrote: On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh Ok, so this will give me a local tree, how do I get this onto linuxtv.org ? Also I need someone to pull: http://linuxtv.org/hg/~hgoede/libv4l (this only contains libv4l commits) Into the: http://linuxtv.org/hg/v4l-dvb Repository, I guess I can ask this directly to Douglas? Thoughts? I've one question, I think we want to do tarbal releases from this new repo (just like I've been doing with libv4l for a while already), and then want distro's to pick up these releases, right ? Are we going to do separate tarbals for the lib and utils directories, or one combined tarbal. I personally vote for one combined tarbal. But this means we will be inflicting some pains on distro's because their libv4l packages will go away and be replaced by a new v4l-utils package. I would call it media-utils. A nice name and it reflects that it contains both dvb and v4l utilities. This is something distro's should be able to handle (it happens more often, and I know Fedora has procedures for this). An alternative would be to name the repo and the tarbals libv4l, either is fine with me (although I'm one of the distro packagers who is going to feel the pain of a package rename and as such wouldn't mind using libv4l as name for the repo and the new tarbals). We never had a proper release procedure for all the utilities. It's about time that we start with that and do proper packaging. So I'd rather make a clean new start now instead of just patching things up. Just my opinions, of course. Regards. Hans Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hi, On 02/23/2010 10:01 AM, Hans Verkuil wrote: Hi, On 02/22/2010 11:54 PM, Brandon Philips wrote: On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh Ok, so this will give me a local tree, how do I get this onto linuxtv.org ? Also I need someone to pull: http://linuxtv.org/hg/~hgoede/libv4l (this only contains libv4l commits) Into the: http://linuxtv.org/hg/v4l-dvb Repository, I guess I can ask this directly to Douglas? Thoughts? I've one question, I think we want to do tarbal releases from this new repo (just like I've been doing with libv4l for a while already), and then want distro's to pick up these releases, right ? Are we going to do separate tarbals for the lib and utils directories, or one combined tarbal. I personally vote for one combined tarbal. But this means we will be inflicting some pains on distro's because their libv4l packages will go away and be replaced by a new v4l-utils package. I would call it media-utils. A nice name and it reflects that it contains both dvb and v4l utilities. Well, the judge is still out on also adding the dvb utils to this git repo. I'm neutral on that issue, but I will need a co-maintainer for those bits if they end up in the new v4l-utils repo too. About the name, if the dvb utils get added and we want to reflect that, lets call it v4l-dvb-utils. media-utils is not a very descriptive name for v4l-dvb project outsiders. This is something distro's should be able to handle (it happens more often, and I know Fedora has procedures for this). An alternative would be to name the repo and the tarbals libv4l, either is fine with me (although I'm one of the distro packagers who is going to feel the pain of a package rename and as such wouldn't mind using libv4l as name for the repo and the new tarbals). We never had a proper release procedure for all the utilities. It's about time that we start with that and do proper packaging. So I'd rather make a clean new start now instead of just patching things up. Well we need to do some patching up anyways as I would like to align the versioning of these new tarbals with libv4l versioning, so the first release / tarbal will most likely be something-0.8.0.tar.gz Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
On Tue, Feb 23, 2010 at 1:23 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 02/23/2010 10:01 AM, Hans Verkuil wrote: Hi, On 02/22/2010 11:54 PM, Brandon Philips wrote: On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh Ok, so this will give me a local tree, how do I get this onto linuxtv.org ? Also I need someone to pull: http://linuxtv.org/hg/~hgoede/libv4l (this only contains libv4l commits) Into the: http://linuxtv.org/hg/v4l-dvb Repository, I guess I can ask this directly to Douglas? Thoughts? I've one question, I think we want to do tarbal releases from this new repo (just like I've been doing with libv4l for a while already), and then want distro's to pick up these releases, right ? Are we going to do separate tarbals for the lib and utils directories, or one combined tarbal. I personally vote for one combined tarbal. But this means we will be inflicting some pains on distro's because their libv4l packages will go away and be replaced by a new v4l-utils package. I would call it media-utils. A nice name and it reflects that it contains both dvb and v4l utilities. Well, the judge is still out on also adding the dvb utils to this git repo. I'm neutral on that issue, but I will need a co-maintainer for those bits if they end up in the new v4l-utils repo too. About the name, if the dvb utils get added and we want to reflect that, lets call it v4l-dvb-utils. media-utils is not a very descriptive name for v4l-dvb project outsiders. What's the advantage in merging the dvb and v4l2 utils, other than to make the download/clone bigger ? Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Manu Abraham wrote: and we've got some comments at the mailing list. Btw, the patches I added there also adds DVB-S2 support to szap/scan, but tests are needed, since I don't have any satellite dish nowadays. Btw, I did spend time to review your code before it is pulled in. You did not even provide a reply on my last mail on the subject, or did I miss that reply of yours ? It is on my todo list. My intention is to work on it after the next kernel window. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
On Tue, Feb 23, 2010 at 3:26 AM, Hans Verkuil hverk...@xs4all.nl wrote: Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was merged into dvb-apps, but while that tool supports dvb, it also supports v4l2. Just like we merged dvb and v4l in a single repository, so I think we should also merge the tools to a media-utils repository. Alevt was never maintained. One of the guys who sent a patch wanted a place to hold his patch and hence it is there. If you have a better place to put it up, please do let me know. It's place is not in the dvb-apps tree. It has other dependencies, hence the build for it is disabled by default. It remains a fact of life that dvb and v4l are connected and trying to artificially keep them apart does not make much sense to me. In fact, I don't see anything that's what is common in the digital and analog applications. Other than that, I don't see a single line of code from you, in dvb-apps to make such assertive statements. Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hans de Goede wrote: Hi, On 02/22/2010 11:54 PM, Brandon Philips wrote: On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh Ok, so this will give me a local tree, how do I get this onto linuxtv.org ? I'll answer first the next question ;) Also I need someone to pull: http://linuxtv.org/hg/~hgoede/libv4l (this only contains libv4l commits) Into the: http://linuxtv.org/hg/v4l-dvb Repository, I guess I can ask this directly to Douglas? Request it to Douglas. Another option is to merge it locally on your repository, convert it to git. After having it converted to git, you should create a repository there for you, with the -git procedures I've emailed to the ones with accounts there. Then, ping me and I'll move it to a better place and add permissions for the others to merge there. Thoughts? I've one question, I think we want to do tarbal releases from this new repo (just like I've been doing with libv4l for a while already), and then want distro's to pick up these releases, right ? Are we going to do separate tarbals for the lib and utils directories, or one combined tarbal. I personally vote for one combined tarbal. But this means we will be inflicting some pains on distro's because their libv4l packages will go away and be replaced by a new v4l-utils package. This is something distro's should be able to handle (it happens more often, and I know Fedora has procedures for this). An alternative would be to name the repo and the tarbals libv4l, either is fine with me (although I'm one of the distro packagers who is going to feel the pain of a package rename and as such wouldn't mind using libv4l as name for the repo and the new tarbals). I think that the better is to create one single tarball. The Makefile may have multiple makefile targets for the libraries and for utils. This would help distros to create different packages if they want to. As you're the packager on Fedora, I think you should prepare it to make your life easier on the distro side. This will probably help other distros too. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Manu Abraham wrote: On Tue, Feb 23, 2010 at 1:23 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 02/23/2010 10:01 AM, Hans Verkuil wrote: Hi, On 02/22/2010 11:54 PM, Brandon Philips wrote: On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh Ok, so this will give me a local tree, how do I get this onto linuxtv.org ? Also I need someone to pull: http://linuxtv.org/hg/~hgoede/libv4l (this only contains libv4l commits) Into the: http://linuxtv.org/hg/v4l-dvb Repository, I guess I can ask this directly to Douglas? Thoughts? I've one question, I think we want to do tarbal releases from this new repo (just like I've been doing with libv4l for a while already), and then want distro's to pick up these releases, right ? Are we going to do separate tarbals for the lib and utils directories, or one combined tarbal. I personally vote for one combined tarbal. But this means we will be inflicting some pains on distro's because their libv4l packages will go away and be replaced by a new v4l-utils package. I would call it media-utils. A nice name and it reflects that it contains both dvb and v4l utilities. Well, the judge is still out on also adding the dvb utils to this git repo. I'm neutral on that issue, but I will need a co-maintainer for those bits if they end up in the new v4l-utils repo too. About the name, if the dvb utils get added and we want to reflect that, lets call it v4l-dvb-utils. media-utils is not a very descriptive name for v4l-dvb project outsiders. What's the advantage in merging the dvb and v4l2 utils, other than to make the download/clone bigger ? There aren't any big advantages on merging, nor there are big advantages on keeping them alone. Advantages to merge: - One single release control. Currently, only Hans de Goede is doing a good job with release names, on libv4l. By having everything into one place, all other v4l2-apps and dvb-apps will have a release name, making easier even for us when helping people with troubles (as we'll know for sure if they're using the latest version or a very old version; - One single tree for the user to download, for IR, DVB and V4L apps; - Distro packagers will have one single tarball to maintain. Disadvantages: - More people will need access to the same git master tree; - The tree will be bigger. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
On Tue, Feb 23, 2010 at 4:21 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Manu Abraham wrote: On Tue, Feb 23, 2010 at 1:23 PM, Hans de Goede hdego...@redhat.com wrote: [snip] What's the advantage in merging the dvb and v4l2 utils, other than to make the download/clone bigger ? There aren't any big advantages on merging, nor there are big advantages on keeping them alone. Advantages to merge: - One single release control. Currently, only Hans de Goede is doing a good job with release names, on libv4l. By having everything into one place, all other v4l2-apps and dvb-apps will have a release name, making easier even for us when helping people with troubles (as we'll know for sure if they're using the latest version or a very old version; - One single tree for the user to download, for IR, DVB and V4L apps; - Distro packagers will have one single tarball to maintain. Disadvantages: - More people will need access to the same git master tree; - The tree will be bigger. It is quite noble to think of having to have everything unified in the world. But that doesn't seem how things are in practice. It's quite understood that the concept of one-single-ring-to-rule-them-all doesn't work well. The mercurial dvb-apps tree has worked quite well for me as well as the other few people who have been involved with it and don't have any problems in that arena and I am very happy with it on that front. FWIW, I am not very much interested to move to git. Are we making a mockery, switching between SCM's every now and then .. ? Maybe there are others as well, who feel that way. But that's not the more important point. For me, it is like simply that a simple update is quite fast and easy. FWIW: dvb-apps is not about any real application development, but acts as an aid for other applications to be built. In some cases, it can aid as a quick test tools, which can isolate users issues, when carry forward issues from other applications. On the contrary we have had a few libs, which are in use by some applications. These came up as Andrew, myself and Julian wanted to have some libraries to setup things real quick. Johannes provided some directions in which how developments could proceed to make things look good. Later on, Andrew ran away from all v4l, dvb related developments, because he was irritated quite a lot too much. With regards to distro stuff; This is best left to distro vendors. I don't really appreciate this distro-speak that you make every now and then. In the light that which you speak, it would be even much nobler to think of a pakage or rpm such as distro-application-packages.foobar. But such a merging of all the applications and utilities do not really mean anything and is useless. All it does is: irritate people. With regards to release control, we have had a 1.1.1 release. Looking back, we haven't had a proper stable state yet, for another release. Thinking of which, it is more of these discussions that hold back real development rather than anything else. Moving to git, or have a merged tree with v4l2 and dvb utils is not going to make dvb-apps development any faster. On the contrary, I don't think it is going to help dvb-apps in anyway on the development front, but rather make it worser. My few cents, being one of the dvb-apps maintainers and author of some the bits and pieces in it. Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Brandon Philips wrote: On 22:12 Mon 22 Feb 2010, Mauro Carvalho Chehab wrote: Mauro Carvalho Chehab wrote: That's said, if all the issues are the ones listed above, I can try to address them on the next months, to put it into a better shape. That's said, I don't think we should have a single maintainer for it: there are too many DTV standards already, and probably nobody with enough time has access to all of those (DVB-T, DVB-T2, DVB-S, DVB-S2, ISDB-T, ISDB-S, ATSC, DSS, ...). So, I think we need a team of volunteers that will try to help with the standards they have access. I was not suggesting a single maintainer but I wanted to make sure there was actual interest in maintaing and fixing these dvb things. I don't interact much at all with DVB so all I had to go on was the wiki page. The wiki seems wrong to me. I'll update it. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
On Tue, Feb 23, 2010 at 5:36 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Manu Abraham wrote: What's the advantage in merging the dvb and v4l2 utils, other than to make the download/clone bigger ? There aren't any big advantages on merging, nor there are big advantages on keeping them alone. Advantages to merge: - One single release control. Currently, only Hans de Goede is doing a good job with release names, on libv4l. By having everything into one place, all other v4l2-apps and dvb-apps will have a release name, making easier even for us when helping people with troubles (as we'll know for sure if they're using the latest version or a very old version; - One single tree for the user to download, for IR, DVB and V4L apps; - Distro packagers will have one single tarball to maintain. Disadvantages: - More people will need access to the same git master tree; - The tree will be bigger. It is quite noble to think of having to have everything unified in the world. But that doesn't seem how things are in practice. It's quite understood that the concept of one-single-ring-to-rule-them-all doesn't work well. The mercurial dvb-apps tree has worked quite well for me as well as the other few people who have been involved with it and don't have any problems in that arena and I am very happy with it on that front. FWIW, I am not very much interested to move to git. Are we making a mockery, switching between SCM's every now and then .. ? Maybe there are others as well, who feel that way. But that's not the more important point. For me, it is like simply that a simple update is quite fast and easy. I don't think moving it to git would bring any significant advantage or disadvantage. With regards to distro stuff; This is best left to distro vendors. Agreed. With regards to release control, we have had a 1.1.1 release. Looking back, we haven't had a proper stable state yet, for another release. Hmm... http://www.linuxtv.org/downloads/ May, 18 2006... $ hg log -d 05/18/2006 -p|diffstat -p1|grep changed 1402 files changed, 66559 insertions(+), 16267 deletions(-) Sorry, but it is really failing with release control. There were _lots_ of change since 2006, including several new applications, and tons of new channel/transponders added to it. I don't simply see how adding in a version number is going to help in moving things ahead. Anyone wishing to download the latest tip can dowload from http://linuxtv.org/hg/dvb-apps/archive/tip.tar.bz2 if one is not content with cloning the whole tree. Thinking of which, it is more of these discussions that hold back real development rather than anything else. Moving to git, or have a merged tree with v4l2 and dvb utils is not going to make dvb-apps development any faster. On the contrary, I don't think it is going to help dvb-apps in anyway on the development front, but rather make it worser. Why would it be worse? Anything that which doesn't make things better, but that brings in an overhead, is something worser. - I would need to get going on with git - It's going to be the 3rd time there is a SCM change. Changing it all the time doesn't help the users nor the people who work on it. - The additional overhead to download larger content, however small that might be initially to start up with. - mixing up things that which are not really tied to each other My few cents, being one of the dvb-apps maintainers and author of some the bits and pieces in it. PS.: while removing that need maintainer warning from the wiki, I noticed that, just like v4l2-apps, there's one application there for IR (util/av7110_loadkeys). Even if we decide to keep the trees separate, we should really put this utility and the IR code at v4l2-apps at the same place. It has been there for ages, originally Holger had it there, during the time of convergence. FF card users have been using it since. Probably FF users would like to mention what they would like to have and comment on that. Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
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 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 When I'm satisfied (and have created some proof of concept packages for Fedora to make sure everything is reasonably usable for distros). I'll send a mail to the list announcing my intend to release a 0.8.0 version (building on top of existing libv4l release scheme to make clear which libv4l version is included). If there are then no objections / bugs found I'll do a 0.8.0 release . Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
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. 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. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Am Dienstag, den 23.02.2010, 13:45 +0400 schrieb Manu Abraham: On Tue, Feb 23, 2010 at 4:41 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Brandon Philips wrote: On 00:26 Tue 23 Feb 2010, Hans Verkuil wrote: On Monday 22 February 2010 23:54:26 Brandon Philips wrote: On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh Thoughts? Let me know how we should proceed with dropping v4l2-apps from v4l-dvb. Re: code style cleanup. I think we should do that once we drop v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream. Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was merged into dvb-apps, but while that tool supports dvb, it also supports v4l2. Just like we merged dvb and v4l in a single repository, so I think we should also merge the tools to a media-utils repository. It remains a fact of life that dvb and v4l are connected and trying to artificially keep them apart does not make much sense to me. Easy to do but who should be the maintainer of the dvb things? According to the wiki[1] these tools are without a maintainer. So, if no one cares about them enough to make releases why merge them and clutter up the git tree with dead code? Cheers, Brandon [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps That's weird. I've recently added support for ISDB-T on it: http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/ That's probably Michael Krufky (user: Jon2856) from what i guess, he has been the one who has been making ground for propaganda's on the wiki. Manu, you are actively calling the trolls back again with such accusations! It is the other way round, you own him at least one clear excuse. Cheers, Hermann and we've got some comments at the mailing list. Btw, the patches I added there also adds DVB-S2 support to szap/scan, but tests are needed, since I don't have any satellite dish nowadays. Btw, I did spend time to review your code before it is pulled in. You did not even provide a reply on my last mail on the subject, or did I miss that reply of yours ? Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
On 16:51 Tue 23 Feb 2010, Hans de Goede wrote: 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 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 Do you still want me to convert to autoconf? I was still planning on doing that. We discussed it a month ago when this conversation started. http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/15009 When I'm satisfied (and have created some proof of concept packages for Fedora to make sure everything is reasonably usable for distros). I'll send a mail to the list announcing my intend to release a 0.8.0 version (building on top of existing libv4l release scheme to make clear which libv4l version is included). If there are then no objections / bugs found I'll do a 0.8.0 release . Ack, sounds good. Thanks, Brandon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh Thoughts? Let me know how we should proceed with dropping v4l2-apps from v4l-dvb. Re: code style cleanup. I think we should do that once we drop v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream. Cheers, Brandon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
On 00:26 Tue 23 Feb 2010, Hans Verkuil wrote: On Monday 22 February 2010 23:54:26 Brandon Philips wrote: On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh Thoughts? Let me know how we should proceed with dropping v4l2-apps from v4l-dvb. Re: code style cleanup. I think we should do that once we drop v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream. Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was merged into dvb-apps, but while that tool supports dvb, it also supports v4l2. Just like we merged dvb and v4l in a single repository, so I think we should also merge the tools to a media-utils repository. It remains a fact of life that dvb and v4l are connected and trying to artificially keep them apart does not make much sense to me. Easy to do but who should be the maintainer of the dvb things? According to the wiki[1] these tools are without a maintainer. So, if no one cares about them enough to make releases why merge them and clutter up the git tree with dead code? Cheers, Brandon [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
On Monday 22 February 2010 23:54:26 Brandon Philips wrote: On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh Thoughts? Let me know how we should proceed with dropping v4l2-apps from v4l-dvb. Re: code style cleanup. I think we should do that once we drop v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream. Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was merged into dvb-apps, but while that tool supports dvb, it also supports v4l2. Just like we merged dvb and v4l in a single repository, so I think we should also merge the tools to a media-utils repository. It remains a fact of life that dvb and v4l are connected and trying to artificially keep them apart does not make much sense to me. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Brandon Philips wrote: On 00:26 Tue 23 Feb 2010, Hans Verkuil wrote: On Monday 22 February 2010 23:54:26 Brandon Philips wrote: On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh Thoughts? Let me know how we should proceed with dropping v4l2-apps from v4l-dvb. Re: code style cleanup. I think we should do that once we drop v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream. Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was merged into dvb-apps, but while that tool supports dvb, it also supports v4l2. Just like we merged dvb and v4l in a single repository, so I think we should also merge the tools to a media-utils repository. It remains a fact of life that dvb and v4l are connected and trying to artificially keep them apart does not make much sense to me. Easy to do but who should be the maintainer of the dvb things? According to the wiki[1] these tools are without a maintainer. So, if no one cares about them enough to make releases why merge them and clutter up the git tree with dead code? Cheers, Brandon [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps That's weird. I've recently added support for ISDB-T on it: http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/ and we've got some comments at the mailing list. Btw, the patches I added there also adds DVB-S2 support to szap/scan, but tests are needed, since I don't have any satellite dish nowadays. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Mauro Carvalho Chehab wrote: According to the wiki[1] these tools are without a maintainer. So, if no one cares about them enough to make releases why merge them and clutter up the git tree with dead code? [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps That's weird. I've recently added support for ISDB-T on it: http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/ and we've got some comments at the mailing list. Btw, the patches I added there also adds DVB-S2 support to szap/scan, but tests are needed, since I don't have any satellite dish nowadays. Hmm... this got changed on Jun, 2009: http://www.linuxtv.org/wiki/index.php?title=LinuxTV_dvb-appsdiff=prevoldid=23404 Let me comment the TODO list: * Start numbering the versions. Yes, with a repo every commit is a kind of version, but in the real world of distros and end users you need to define version numbers as easy reference points. * Tag versioned releases and make src tarballs for the distros. By merging with v4l2-apps, those to will be easily handled. * Add ChangeLog and TODO files (and keep them up to date of course). ChangeLog? Git history is better than it. A TODO file is useful only when there are missing features. * Review the names of the apps and change where necessary. Perhaps scan is too ambiguous a name in a general-purpose system where all sorts of things can be scanned (with scanners, fax machines, barcode readers, etc.). I agree. All distros I know renamed scan to dvbscan. This is a trivial patch through. * Implement API version 5 scanning and zapping for DVB-S2 channels. See S2API, scan-s2 and szap-s2. It is done on my tree: http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/ I still need to review Manu's comments on it. My intention is to do it after the next merge window. Also, there are some DVB-S2 parameters that aren't present at the channels.conf format. Nothing more complex than adding printf/scanf lines on some files. * Improve the channels.conf file format so that one file can represent all the channels. Need to o (a) identify the source (S13.0E, S19.2E, Terrestrial, etc) o (b) identify the delivery system (DVB-S, DVB-S2, DVB-T etc) o (c) be able to represent all the parameters required for all the delivery systems in a unified way. For example DVB-S2 has some new paramters (e.g. rolloff). The VDR format was expanded for this, but in a messy way. * Make sure there is one true format -- no zap versus VDR format confusion. * Merge all the *zap programs. You unified the channels.conf file so this is next. Changing the channels.conf format is easy. I had to do it for ISDB-T. The hard part is that channels.conf is used on several DTV applications (mplayer, VDR, kaffeine, ...). So, any format change will require changes on all applications that use channels.conf. This will be needed anyway, in order to add all features that are present on DVB-S2, and to add ISDB-T format to the players. So, maybe someone can propose a version 3 format (assuming that VDR and ZAP are versions 1 and 2) that will be used by all applications. That's said, if all the issues are the ones listed above, I can try to address them on the next months, to put it into a better shape. That's said, I don't think we should have a single maintainer for it: there are too many DTV standards already, and probably nobody with enough time has access to all of those (DVB-T, DVB-T2, DVB-S, DVB-S2, ISDB-T, ISDB-S, ATSC, DSS, ...). So, I think we need a team of volunteers that will try to help with the standards they have access. For the channels/transponders list, Christopher (kaffeine maintainer) is doing a really great job. Maybe he could help with the last TODO items (e. g. helping to define the better format for the channels.conf output). That's said, I'm starting to agree with Hans: maybe the better seems to merge it with v4l2-apps, to get synergy in terms, at least in terms of packet management. Comments? Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hi, On 01/24/2010 01:42 AM, Mauro Carvalho Chehab wrote: Hans de Goede wrote: Hi, On 01/21/2010 08:23 AM, Hans Verkuil wrote: snip Yes, but, as we have also non-c code, some rules there don't apply. For example the rationale for not using // comments don't apply to c++, since it is there since the first definition. Most apps are already in 'kernel' style. The main exception being libv4l. Well... they are close to kernel style, but if you run checkpatch over all files there, I'm sure you'll see lots of violations. Ack, which in hind sight may not have been the best choice (I have no personal coding style, I'm used to adjusting my style to what ever the project I'm working on uses). Still I would like to keep libv4l as an exception, If we're adopting one CodingStyle, this should be done for everything, otherwise it makes no sense to standardize. Ok that makes sense. But as said this need to be done in one big bang commit then. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hi all, On 01/21/2010 08:34 AM, Hans Verkuil wrote: On Thursday 21 January 2010 03:46:05 Brandon Philips wrote: On 00:07 Thu 21 Jan 2010, Mauro Carvalho Chehab wrote: Brandon Philips wrote: On 19:50 Wed 20 Jan 2010, Hans de Goede wrote: On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote: As we're discussing about having a separate tree for v4l2-apps, maybe the better is to port it to -git (in a way that we can preserve the log history). I have a small script I used to convert the history of libv4l to git. Let me know when we are ready to drop them from the hg tree and I can do the conversion and post the result for review. This is the result from the script for just libv4l: http://ifup.org/git/?p=libv4l.git;a=summary Seems fine, but we need to import the entire v4l2-apps. Yes, I know. I will run the script over v4l2-apps to generate a git repo once v4l2-apps is ready to be dropped from v4l-dvb mercurial and we figure out the directory layout. Doing it before is just a waste of time since they will get out of sync. Also, I suggest we call the repo v4lutils? In the spirit of usbutils, pciutils, etc. Hmm... as dvb package is called as dvb-utils, it seems more logical to call it v4l2-utils, but v4l2utils would equally work. Yes, that is fine. IMO, the better is to use v4l2 instead of just v4l, to avoid causing any mess with the old v4l applications provided with xawtv. The problem I saw was that libv4l1 will be in v4l2-utils. I don't care either way though. So here is how I see v4l-utils.git being laid out based on what others have said: libv4l1/ libv4l2/ libv4lconvert/ test/ v4l2-dbg/ contrib/ qv4l2-qt3/ qv4l2-qt4/ cx25821/ etc... everything else Hmm. I think I would prefer to have a structure like this: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else And everything in lib and utils can be packaged by distros, while contrib is not packaged. +1 for this directory layout. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hi, On 01/21/2010 08:23 AM, Hans Verkuil wrote: snip Yes, but, as we have also non-c code, some rules there don't apply. For example the rationale for not using // comments don't apply to c++, since it is there since the first definition. Most apps are already in 'kernel' style. The main exception being libv4l. Ack, which in hind sight may not have been the best choice (I have no personal coding style, I'm used to adjusting my style to what ever the project I'm working on uses). Still I would like to keep libv4l as an exception, re-indenting it is not going to do it any good (I did my best to keep lines within 80 chars, but moving to tabs as indent will ruin this, and there are quite a few nasty nested if cases in there). snip Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hans de Goede wrote:
Hi,
On 01/21/2010 08:23 AM, Hans Verkuil wrote:
snip
Yes, but, as we have also non-c code, some rules there don't apply.
For example the rationale for not using // comments don't apply to c++,
since it is there since the first definition.
Most apps are already in 'kernel' style. The main exception being libv4l.
Well... they are close to kernel style, but if you run checkpatch over
all files there, I'm sure you'll see lots of violations.
Ack,
which in hind sight may not have been the best choice (I have no personal
coding style, I'm used to adjusting my style to what ever the project
I'm working on uses).
Still I would like to keep libv4l as an exception,
If we're adopting one CodingStyle, this should be done for everything, otherwise
it makes no sense to standardize.
re-indenting it is
not going to do it any good (I did my best to keep lines within 80
chars, but moving to tabs as indent will ruin this, and there are quite
a few nasty nested if cases in there).
The 80 chars limit is nowadays a soft simit. There are even some discussions
from
people that the resulting code of people sending patches that just avoids the
limit
is worse than before.
The idea behind this limit is that lines of code with more than 80 chars is an
indication
that the code is more complex than it needs to be. So, the logic there may
re-implemented
on a better way.
Just for fun, I ran this indent command (with kernel CodingStyle, except for
the 80 chars
limit), over v4l2-apps/libv4l/libv4l2:
indent -npro -kr -i8 -ts8 -sob -ss -ncs -cp1 -l260 *.c
Except for one or two things, the resulting code seems a way better. Yet, as
pointed by
Brandon, some manual work is needed to fix some parts of the result, as the
indent is not
perfect.
Again for fun, I ran a checkpatch over the resulting code, removing all
warnings due
to 80 cols (see enclosed). I think the troubles with the goto labels were
introduced by
indent.
---
From my side, it would be better to use the same CodingStyle also at v4l2-apps,
since this makes easier for people to contribute on both kernel and userspace.
Also,
I can read the code faster when it uses the Kernel CodingStyle.
Yet, not all checkpatch warnings apply to userspace, as some are specific to
usage
of kernel deprecated functions. That's said, by using an style close to the
kernel one,
it is easy to remove from checkpatch the warnings that won't apply to userspace.
Cheers,
Mauro
-
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In ' if ((result =
SYS_IOCTL(devices[index].fd, VIDIOC_REQBUFS, req)) 0) {':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:102: ERROR: do not use
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In ' if
((result = SYS_IOCTL(devices[index].fd, VIDIOC_STREAMON, type))) {':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:193: ERROR: do not use
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In ' if ((result =
SYS_IOCTL(devices[index].fd, VIDIOC_QBUF, buf))) {':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:238: ERROR: do not use
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In ' if ((result =
v4l2_map_buffers(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:255: ERROR: do not use
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In ' if
((result = SYS_IOCTL(devices[index].fd, VIDIOC_DQBUF, buf))) {':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:259: ERROR: do not use
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In ' }':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:287: warning: braces {} are
not necessary for single statement blocks
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In ' }':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:338: warning: braces {} are
not necessary for single statement blocks
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In ' if ((result =
v4l2_request_read_buffers(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:377: ERROR: do not use
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In ' if ((result =
v4l2_map_buffers(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:380: ERROR: do not use
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In ' if ((result =
v4l2_queue_read_buffers(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:383: ERROR: do not use
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In ' if ((result =
v4l2_streamoff(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:395: ERROR: do not use
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In ' if
Re: [ANNOUNCE] git tree repositories libv4l
Hans Verkuil wrote: On Thursday 21 January 2010 03:07:32 Mauro Carvalho Chehab wrote: Brandon Philips wrote: I've different experience in the projects with git I've used, as long as there are some governance rules (like never ever push -f, always do a rebase fix your stuff and then push, and if something else got in in the window in between rebase again, etc.). If the group of people with commit access is small (3-4) it generally works well. Yes. The more people touching at the same tree, the more troubles may happen. I don't object to allow a limited group of people accessing it, although I suspect that, if we open to more than one, we will have more than 4 people interested on it. In practice the only people who regularly touch v4l2-apps are Hans de Goede (libv4l), you and myself (v4l2-ctl, v4l2-dbg, qv4l2). I can't remember anyone else contributing regularly to v4l2-apps. It seems that you forgot me ;) After running the import proccess and have the contributions isolated, it would be easy to double check if nobody else is missed. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hans Verkuil wrote: On Thursday 21 January 2010 03:46:05 Brandon Philips wrote: On 00:07 Thu 21 Jan 2010, Mauro Carvalho Chehab wrote: Brandon Philips wrote: So here is how I see v4l-utils.git being laid out based on what others have said: libv4l1/ libv4l2/ libv4lconvert/ test/ v4l2-dbg/ contrib/ qv4l2-qt3/ qv4l2-qt4/ cx25821/ etc... everything else Hmm. I think I would prefer to have a structure like this: lib/ libv4l1/ libv4l2/ libv4lconvert/ I don't have a strong opinion if we should have a /lib dir here or not. utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl keytable v4l2-sysfs-path parsers/ parse_em28xx.pl parse-sniffusb2.pl test/ everything else I like the idea of putting everything else under contrib/ And everything in lib and utils can be packaged by distros, while contrib is not packaged. With respect to the parsers (parse_em28xx.pl and parse-sniffusb2.pl), in practice, they seemed more important than the v4l2-dbg, as they help to check what GPIO's are needed to support the USB devices (and it is impractical to send us a non-parsed log, due to its very long size). So, IMO, this should be installed on distros. What would also be nice is if this project http://v4l-test.sourceforge.net/ could eventually be merged in v4l2-apps. Agreed. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hi, On 01/19/2010 12:08 PM, Mauro Carvalho Chehab wrote: Hans Verkuil wrote: On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote: snip I do have one proposal: parts of our hg tree are independent of git: v4l2-apps, possibly some firmware build code (not 100% sure of that), v4l_experimental, perhaps some documentation stuff. My proposal is that we make a separate hg or git tree for those. It will make it easier to package by distros and it makes it easier to maintain v4l2-apps et al as well. It might even simplify Douglas's work by moving non-essential code out of the compat hg tree. It may make sense, but I have some comments about it: snip 4) v4l2-apps - I agree that splitting it could be a good idea, provided that we find a way to handle the few cases where we have example applications at the media docs. Note that v4l2-apps also contains libv4l, it so happens that I've been discussing moving libv4l to its own git tree with Brandon Philips. Preferably to a place which also offers some form of bug tracking. The advantages of having libv4l in its own tree are: -it is maintained independent of the hg tree anyways -it has regular versioned tarbal releases, it would be good to be able to tag these inside the used scm, which is hard to do when the scm is shared with other unrelated code which does not end up in said tarballs -this means having a much smaller tree making it easier to clone -no longer having an often old (stale) libv4l in the master hg repository (this is partially my fault as I should send pull requests for libv4l moe often, but why all this synchronization overhead when its independent anyways) As said when discussing this with Brandon we were thinking about using something like github, as that offers bug tracking too. But I can understand if you would prefer to keep libv4l at linuxtv.org . The last few fays I've been working on making a stand alone version of the uvcdynctrl tool, which is meant to send a userspace database of vendor specific controls to the uvcvideo driver, after which they will show up as regular v4l2 controls. The uvcdynctrl utility is part of the libwebcam project: http://www.quickcamteam.net/software/libwebcam But given that libwebcam is unmaintained and not used by anything AFAIK, I'm patching uvcdynctrl to no longer need it. The plan is to add uvcdynctrl to libv4l soon, as that is needed to be able to control the focus on some uvc autofocus cameras. This means that libv4l will be growing a set of utilities, currently just uvcdynctrl (and its database and udev scripts), but given this precedent we could add more utilities to libv4l. I wouldn't mind moving v4l2-ctl and v4l2-dbg to libv4l, this would also have the advantage that since most distro's ship libv4l these utilities would actually become available to end users (which AFAIK currently they are not in most distros). Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hi Hans, Hi, On 01/19/2010 12:08 PM, Mauro Carvalho Chehab wrote: Hans Verkuil wrote: On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote: snip I do have one proposal: parts of our hg tree are independent of git: v4l2-apps, possibly some firmware build code (not 100% sure of that), v4l_experimental, perhaps some documentation stuff. My proposal is that we make a separate hg or git tree for those. It will make it easier to package by distros and it makes it easier to maintain v4l2-apps et al as well. It might even simplify Douglas's work by moving non-essential code out of the compat hg tree. It may make sense, but I have some comments about it: snip 4) v4l2-apps - I agree that splitting it could be a good idea, provided that we find a way to handle the few cases where we have example applications at the media docs. Note that v4l2-apps also contains libv4l, it so happens that I've been discussing moving libv4l to its own git tree with Brandon Philips. Preferably to a place which also offers some form of bug tracking. The advantages of having libv4l in its own tree are: -it is maintained independent of the hg tree anyways -it has regular versioned tarbal releases, it would be good to be able to tag these inside the used scm, which is hard to do when the scm is shared with other unrelated code which does not end up in said tarballs -this means having a much smaller tree making it easier to clone -no longer having an often old (stale) libv4l in the master hg repository (this is partially my fault as I should send pull requests for libv4l moe often, but why all this synchronization overhead when its independent anyways) As said when discussing this with Brandon we were thinking about using something like github, as that offers bug tracking too. But I can understand if you would prefer to keep libv4l at linuxtv.org . The last few fays I've been working on making a stand alone version of the uvcdynctrl tool, which is meant to send a userspace database of vendor specific controls to the uvcvideo driver, after which they will show up as regular v4l2 controls. The uvcdynctrl utility is part of the libwebcam project: http://www.quickcamteam.net/software/libwebcam But given that libwebcam is unmaintained and not used by anything AFAIK, I'm patching uvcdynctrl to no longer need it. The plan is to add uvcdynctrl to libv4l soon, as that is needed to be able to control the focus on some uvc autofocus cameras. This means that libv4l will be growing a set of utilities, currently just uvcdynctrl (and its database and udev scripts), but given this precedent we could add more utilities to libv4l. I wouldn't mind moving v4l2-ctl and v4l2-dbg to libv4l, this would also have the advantage that since most distro's ship libv4l these utilities would actually become available to end users (which AFAIK currently they are not in most distros). It seems to me that creating a v4l2-apps tree (similar to dvb-apps) would solve most of these issues (except for bug tracking). We would need to do some rearranging in the directory structure of v4l2-apps, though. It is a bit of a mix of production code like libv4l and v4l2-ctl, v4l2-dbg. cx18-ctl and ivtv-ctl, and more test or debug oriented tools. The latter do not need to be packaged by distros. Personally I would prefer to keep v4l2-apps on linuxtv.org. But the strict commit procedure that we have for the main v4l-dvb repo can be relaxed here. So it should be possible for you to have commit rights so you can use it as your master repository. Mauro, what do you think? Regards, Hans Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hi Hans, On Wednesday 20 January 2010 09:36:08 Hans de Goede wrote: Hi, On 01/19/2010 12:08 PM, Mauro Carvalho Chehab wrote: Hans Verkuil wrote: On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote: snip I do have one proposal: parts of our hg tree are independent of git: v4l2-apps, possibly some firmware build code (not 100% sure of that), v4l_experimental, perhaps some documentation stuff. My proposal is that we make a separate hg or git tree for those. It will make it easier to package by distros and it makes it easier to maintain v4l2-apps et al as well. It might even simplify Douglas's work by moving non-essential code out of the compat hg tree. It may make sense, but I have some comments about it: snip 4) v4l2-apps - I agree that splitting it could be a good idea, provided that we find a way to handle the few cases where we have example applications at the media docs. Note that v4l2-apps also contains libv4l, it so happens that I've been discussing moving libv4l to its own git tree with Brandon Philips. Preferably to a place which also offers some form of bug tracking. The advantages of having libv4l in its own tree are: -it is maintained independent of the hg tree anyways -it has regular versioned tarbal releases, it would be good to be able to tag these inside the used scm, which is hard to do when the scm is shared with other unrelated code which does not end up in said tarballs -this means having a much smaller tree making it easier to clone -no longer having an often old (stale) libv4l in the master hg repository (this is partially my fault as I should send pull requests for libv4l moe often, but why all this synchronization overhead when its independent anyways) As said when discussing this with Brandon we were thinking about using something like github, as that offers bug tracking too. But I can understand if you would prefer to keep libv4l at linuxtv.org . The last few fays I've been working on making a stand alone version of the uvcdynctrl tool, which is meant to send a userspace database of vendor specific controls to the uvcvideo driver, after which they will show up as regular v4l2 controls. Thanks for that, it's much appreciated. If you have any concern with the uvcvideo driver userspace API I'd be happy to discuss them. The uvcdynctrl utility is part of the libwebcam project: http://www.quickcamteam.net/software/libwebcam But given that libwebcam is unmaintained and not used by anything AFAIK, I'm patching uvcdynctrl to no longer need it. The plan is to add uvcdynctrl to libv4l soon, as that is needed to be able to control the focus on some uvc autofocus cameras. This means that libv4l will be growing a set of utilities, currently just uvcdynctrl (and its database and udev scripts), but given this precedent we could add more utilities to libv4l. I wouldn't mind moving v4l2-ctl and v4l2-dbg to libv4l, this would also have the advantage that since most distro's ship libv4l these utilities would actually become available to end users (which AFAIK currently they are not in most distros). -- Cheers, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hi, The uvcdynctrl utility is part of the libwebcam project: http://www.quickcamteam.net/software/libwebcam But given that libwebcam is unmaintained and not used by anything AFAIK, I'm patching uvcdynctrl to no longer need it. The plan is to add uvcdynctrl to libv4l soon, as that is needed to be able to control the focus on some uvc autofocus cameras. Actually libwebcam is still maintained in svn: http://www.quickcamteam.net/documentation/how-to/how-to-install-the-webcam-tools but you are right just a few applications use it, and since it's not yet included in any distribution most end users will miss some advance features on their webcams. I'm just a bit worried that having two different packages providing the same set of tools may cause some compatibility problems in the future. Binary packages of libwebcam are being prepared and will be available soon, so I guess some compat tests may be in order, maybe splitting uvcdynctrl from libwebcam into a different package and making it incompatible with libv4l would be a good idea. Regards, Paulo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
libwecam uvcdynctrl (was Re: [ANNOUNCE] git tree repositories libv4l)
Hi, On 01/20/2010 10:54 AM, Paulo Assis wrote: Hi, The uvcdynctrl utility is part of the libwebcam project: http://www.quickcamteam.net/software/libwebcam But given that libwebcam is unmaintained and not used by anything AFAIK, I'm patching uvcdynctrl to no longer need it. The plan is to add uvcdynctrl to libv4l soon, as that is needed to be able to control the focus on some uvc autofocus cameras. Actually libwebcam is still maintained in svn: Looking at the clog, maintained is a very big word here, there is some activity here but very little to speak of. http://www.quickcamteam.net/documentation/how-to/how-to-install-the-webcam-tools Looking at that page, the only reason stated there to install it is uvcdynctrl, not libwebcam itself. And the installation as described there is a pain. Also the current state of uvcdynctrl + uvcvideo + the xml database is not exactly one that is end user ready. The reset pan/tilt controls don't work properly (they should be of the button type). The led controls don't work properly (the led control one should be a menu, the frequency should have a minimum of 1 not 0). I'm working on: 1) Dropping the unnecessary libwebcam dependency (done), which was surprisingly easy. There really is nothing uvcdynctrl needs libwebcam for, other then uvcvideo /dev/video devices detection, but given that uvcdynctrl's primary use will be from udev, there is no need for that, the udev rule can simply pass in the device node as argument. 2) Making installation a breeze (and getting it included in most distros) 3) Making it actually user friendly, once uvcdynctrl is executed a user should be able to startup a gui v4l2 control panel like v4l2ucp and have meaning full, working controls there, without any error messages being shown. but you are right just a few applications use it, and since it's not yet included in any distribution most end users will miss some advance features on their webcams. I'm just a bit worried that having two different packages providing the same set of tools may cause some compatibility problems in the future. Binary packages of libwebcam are being prepared and will be available soon, so I guess some compat tests may be in order, maybe splitting uvcdynctrl from libwebcam into a different package and making it incompatible with libv4l would be a good idea. My plan is to remove the dependency of uvcdynctrl on libwebcam, and then incorporate uvcdynctrl inside libv4l. I was doing this under the assumption that the libwebcam project was pretty much dead, I was already planning on mailing Martin Rubli and will do so shortly. I have various requests from users who need the additional controls (for things like focus on the Logitech Quickcam Pro 9000), and was asked to incorporate uvcdynctrl into libv4l by Laurens Pinchart. I'm sorry if this comes over as hijacking the code / project, that is not what this is about, this is about enabling the additional controls for end users in a plug and play way. Which I believe is easiest done by adding uvcdynctrl to libv4l, as that is actively maintained and packaged in most distros. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hans Verkuil wrote: 4) v4l2-apps - I agree that splitting it could be a good idea, provided that we find a way to handle the few cases where we have example applications at the media docs. Note that v4l2-apps also contains libv4l, it so happens that I've been discussing moving libv4l to its own git tree with Brandon Philips. Preferably to a place which also offers some form of bug tracking. The advantages of having libv4l in its own tree are: -it is maintained independent of the hg tree anyways -it has regular versioned tarbal releases, it would be good to be able to tag these inside the used scm, which is hard to do when the scm is shared with other unrelated code which does not end up in said tarballs -this means having a much smaller tree making it easier to clone -no longer having an often old (stale) libv4l in the master hg repository (this is partially my fault as I should send pull requests for libv4l moe often, but why all this synchronization overhead when its independent anyways) As said when discussing this with Brandon we were thinking about using something like github, as that offers bug tracking too. But I can understand if you would prefer to keep libv4l at linuxtv.org . Hans G., I prefer to keep it at linuxtv.org, and together with v4l2-apps. The rationale is that there are applications that are dependent on libv4l (like v4l2grab). We're also about to commit a gtk webcam application based on libv4l. So, IMO, the better is to keep all of those applications together. As we're discussing about having a separate tree for v4l2-apps, maybe the better is to port it to -git (in a way that we can preserve the log history). The last few fays I've been working on making a stand alone version of the uvcdynctrl tool, which is meant to send a userspace database of vendor specific controls to the uvcvideo driver, after which they will show up as regular v4l2 controls. The uvcdynctrl utility is part of the libwebcam project: http://www.quickcamteam.net/software/libwebcam But given that libwebcam is unmaintained and not used by anything AFAIK, I'm patching uvcdynctrl to no longer need it. The plan is to add uvcdynctrl to libv4l soon, as that is needed to be able to control the focus on some uvc autofocus cameras. This means that libv4l will be growing a set of utilities, currently just uvcdynctrl (and its database and udev scripts), but given this precedent we could add more utilities to libv4l. I wouldn't mind moving v4l2-ctl and v4l2-dbg to libv4l, this would also have the advantage that since most distro's ship libv4l these utilities would actually become available to end users (which AFAIK currently they are not in most distros). IMO, we should not mix libv4l with the applications that use libv4l. It is good to have separate dirs for different things, like what we currently have under v4l2-apps. It seems to me that creating a v4l2-apps tree (similar to dvb-apps) would solve most of these issues Agreed. (except for bug tracking). Well, I don't see why not adding a bug tracking system for v4l2-apps an dvb-apps, if needed. Are you thinking on something specific? We would need to do some rearranging in the directory structure of v4l2-apps, though. Yes. Maybe we can move the tools that aren't meant to be used on distros on a separate dir, like contrib, having a separate make install for building them. Also, we need to use some config tool like autoconf that will seek for dependencies and or require the needed ones or not compile the applications that depends on some library. It is a bit of a mix of production code like libv4l and v4l2-ctl, v4l2-dbg. cx18-ctl and ivtv-ctl, and more test or debug oriented tools. The latter do not need to be packaged by distros. Yes. Personally I would prefer to keep v4l2-apps on linuxtv.org. But the strict commit procedure that we have for the main v4l-dvb repo can be relaxed here. What do you mean by a relaxed one? Currently, there's no defined procedure for the applications there: several different CodingStyles were used on the different applications and no standard criteria were used to ack/nack changes there. IMO, we should go on the opposite direction: we need to have some standard rules also for it (but, it can be more relaxed than what we have in kernel). For sure, one rule we need to define is what criteria will be used to classify an application as something that will be compiled/installed by default, and what applications are development-oriented applications. On some cases, this is clear (for example, the API compliance test applications are developer-oriented, while libv4l is a standard user-oriented one). However, a debug application (like v4l2-dbg) is a development application, but it may be nice to have it available at the distros, to help users to help check/report problems). It may also be useful to define a minimum set of coding style, like how
Re: [ANNOUNCE] git tree repositories libv4l
Hi, On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote: Hans Verkuil wrote: 4) v4l2-apps - I agree that splitting it could be a good idea, provided that we find a way to handle the few cases where we have example applications at the media docs. Note that v4l2-apps also contains libv4l, it so happens that I've been discussing moving libv4l to its own git tree with Brandon Philips. Preferably to a place which also offers some form of bug tracking. The advantages of having libv4l in its own tree are: -it is maintained independent of the hg tree anyways -it has regular versioned tarbal releases, it would be good to be able to tag these inside the used scm, which is hard to do when the scm is shared with other unrelated code which does not end up in said tarballs -this means having a much smaller tree making it easier to clone -no longer having an often old (stale) libv4l in the master hg repository (this is partially my fault as I should send pull requests for libv4l moe often, but why all this synchronization overhead when its independent anyways) As said when discussing this with Brandon we were thinking about using something like github, as that offers bug tracking too. But I can understand if you would prefer to keep libv4l at linuxtv.org . Hans G., I prefer to keep it at linuxtv.org, and together with v4l2-apps. The rationale is that there are applications that are dependent on libv4l (like v4l2grab). We're also about to commit a gtk webcam application based on libv4l. So, IMO, the better is to keep all of those applications together. As we're discussing about having a separate tree for v4l2-apps, maybe the better is to port it to -git (in a way that we can preserve the log history). Having a separate tree for v4l2-apps would work for me. If possible with direct commit / push rights, given that I'm doing 90% of the libv4l work. (except for bug tracking). Well, I don't see why not adding a bug tracking system for v4l2-apps an dvb-apps, if needed. Are you thinking on something specific? If I can put in wishes I would like bugzilla :) We would need to do some rearranging in the directory structure of v4l2-apps, though. Yes. Maybe we can move the tools that aren't meant to be used on distros on a separate dir, like contrib, having a separate make install for building them. Also, we need to use some config tool like autoconf that will seek for dependencies and or require the needed ones or not compile the applications that depends on some library. Ugh, I'm no fan of autoconf, but I can see this being handy, any volunteers for doing this bit ? It is a bit of a mix of production code like libv4l and v4l2-ctl, v4l2-dbg. cx18-ctl and ivtv-ctl, and more test or debug oriented tools. The latter do not need to be packaged by distros. Yes. Personally I would prefer to keep v4l2-apps on linuxtv.org. But the strict commit procedure that we have for the main v4l-dvb repo can be relaxed here. What do you mean by a relaxed one? Currently, there's no defined procedure for the applications there: several different CodingStyles were used on the different applications and no standard criteria were used to ack/nack changes there. IMO, we should go on the opposite direction: we need to have some standard rules also for it (but, it can be more relaxed than what we have in kernel). Ack, we need to at least have rules, like should build on a modern distro without issues (if the deps are there), etc. For sure, one rule we need to define is what criteria will be used to classify an application as something that will be compiled/installed by default, and what applications are development-oriented applications. On some cases, this is clear (for example, the API compliance test applications are developer-oriented, while libv4l is a standard user-oriented one). However, a debug application (like v4l2-dbg) is a development application, but it may be nice to have it available at the distros, to help users to help check/report problems). Ack, I too think having v4l2-dbg available to end users could come in very handy to remote debug stuff. It may also be useful to define a minimum set of coding style, like how applications should be indented So it should be possible for you to have commit rights so you can use it as your master repository. Maybe the better owner for v4l2-apps would be Hans G., since most of the changes there are related to libv4l. I wouldn't mind giving this a try. On the experiences we had with v4l-dvb tree, it is not a good idea to allow multiple people to commit at the master repository, since, when a conflict rises between two different developers, this can cause lots of heat. Also, it is easy to corrupt a tree, as a push with -f flag can remove (or hide, on -git) the objects inserted by someone else. I've different experience in the projects with git I've used, as long as there are some governance rules (like never ever
Re: [ANNOUNCE] git tree repositories libv4l
On 19:50 Wed 20 Jan 2010, Hans de Goede wrote: On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote: As we're discussing about having a separate tree for v4l2-apps, maybe the better is to port it to -git (in a way that we can preserve the log history). I have a small script I used to convert the history of libv4l to git. Let me know when we are ready to drop them from the hg tree and I can do the conversion and post the result for review. This is the result from the script for just libv4l: http://ifup.org/git/?p=libv4l.git;a=summary Also, I suggest we call the repo v4lutils? In the spirit of usbutils, pciutils, etc. Having a separate tree for v4l2-apps would work for me. If possible with direct commit / push rights, given that I'm doing 90% of the libv4l work. I am fine with Hans doing this. Thanks Hans. We would need to do some rearranging in the directory structure of v4l2-apps, though. Yes. Maybe we can move the tools that aren't meant to be used on distros on a separate dir, like contrib, having a separate make install for building them. Also, we need to use some config tool like autoconf that will seek for dependencies and or require the needed ones or not compile the applications that depends on some library. Ugh, I'm no fan of autoconf, but I can see this being handy, any volunteers for doing this bit ? I started getting libv4l converted to autoconf earlier. If you are OK with it I can provide patches after we get the repo converted. For sure, one rule we need to define is what criteria will be used to classify an application as something that will be compiled/installed by default, and what applications are development-oriented applications. On some cases, this is clear (for example, the API compliance test applications are developer-oriented, while libv4l is a standard user-oriented one). However, a debug application (like v4l2-dbg) is a development application, but it may be nice to have it available at the distros, to help users to help check/report problems). Ack, I too think having v4l2-dbg available to end users could come in very handy to remote debug stuff. Indeed. Any tools that allow us to get insight would be great. Our current debugging tool belt is pretty poor in a lot of cases: lsusb, lspci, dmesg, does cheese work? It may also be useful to define a minimum set of coding style, like how applications should be indented Adopting Documentation/CodingStyle from the kernel with a few tweaks should work. That way we could use existing infrastructure like checkpatch.pl to check incoming stuff out. Shall we just go through and convert everything at once then? Bulk coding style conversions with cstyle, etc never works 100% and so someone will need to review the diffs by hand. Volunteers with experience doing that? On the experiences we had with v4l-dvb tree, it is not a good idea to allow multiple people to commit at the master repository, since, when a conflict rises between two different developers, this can cause lots of heat. Also, it is easy to corrupt a tree, as a push with -f flag can remove (or hide, on -git) the objects inserted by someone else. I've different experience in the projects with git I've used, as long as there are some governance rules (like never ever push -f, always do a rebase fix your stuff and then push, and if something else got in in the window in between rebase again, etc.). If the group of people with commit access is small (3-4) it generally works well. Cheers, Brandon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Brandon Philips wrote: On 19:50 Wed 20 Jan 2010, Hans de Goede wrote: On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote: As we're discussing about having a separate tree for v4l2-apps, maybe the better is to port it to -git (in a way that we can preserve the log history). I have a small script I used to convert the history of libv4l to git. Let me know when we are ready to drop them from the hg tree and I can do the conversion and post the result for review. This is the result from the script for just libv4l: http://ifup.org/git/?p=libv4l.git;a=summary Seems fine, but we need to import the entire v4l2-apps. Also, I suggest we call the repo v4lutils? In the spirit of usbutils, pciutils, etc. Hmm... as dvb package is called as dvb-utils, it seems more logical to call it v4l2-utils, but v4l2utils would equally work. IMO, the better is to use v4l2 instead of just v4l, to avoid causing any mess with the old v4l applications provided with xawtv. Having a separate tree for v4l2-apps would work for me. If possible with direct commit / push rights, given that I'm doing 90% of the libv4l work. I am fine with Hans doing this. Thanks Hans. Ok. We would need to do some rearranging in the directory structure of v4l2-apps, though. Yes. Maybe we can move the tools that aren't meant to be used on distros on a separate dir, like contrib, having a separate make install for building them. Also, we need to use some config tool like autoconf that will seek for dependencies and or require the needed ones or not compile the applications that depends on some library. Ugh, I'm no fan of autoconf, but I can see this being handy, any volunteers for doing this bit ? I started getting libv4l converted to autoconf earlier. If you are OK with it I can provide patches after we get the repo converted. Seems good enough for me. For sure, one rule we need to define is what criteria will be used to classify an application as something that will be compiled/installed by default, and what applications are development-oriented applications. On some cases, this is clear (for example, the API compliance test applications are developer-oriented, while libv4l is a standard user-oriented one). However, a debug application (like v4l2-dbg) is a development application, but it may be nice to have it available at the distros, to help users to help check/report problems). Ack, I too think having v4l2-dbg available to end users could come in very handy to remote debug stuff. Indeed. Any tools that allow us to get insight would be great. Our current debugging tool belt is pretty poor in a lot of cases: lsusb, lspci, dmesg, does cheese work? It may also be useful to define a minimum set of coding style, like how applications should be indented Adopting Documentation/CodingStyle from the kernel with a few tweaks should work. That way we could use existing infrastructure like checkpatch.pl to check incoming stuff out. Yes, but, as we have also non-c code, some rules there don't apply. For example the rationale for not using // comments don't apply to c++, since it is there since the first definition. Shall we just go through and convert everything at once then? Bulk coding style conversions with cstyle, etc never works 100% and so someone will need to review the diffs by hand. Volunteers with experience doing that? I have no strong opinion if we should or not convert the code to some codingstyle, but, if we do, the better is to do everything at once. On the experiences we had with v4l-dvb tree, it is not a good idea to allow multiple people to commit at the master repository, since, when a conflict rises between two different developers, this can cause lots of heat. Also, it is easy to corrupt a tree, as a push with -f flag can remove (or hide, on -git) the objects inserted by someone else. I've different experience in the projects with git I've used, as long as there are some governance rules (like never ever push -f, always do a rebase fix your stuff and then push, and if something else got in in the window in between rebase again, etc.). If the group of people with commit access is small (3-4) it generally works well. Yes. The more people touching at the same tree, the more troubles may happen. I don't object to allow a limited group of people accessing it, although I suspect that, if we open to more than one, we will have more than 4 people interested on it. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
On 00:07 Thu 21 Jan 2010, Mauro Carvalho Chehab wrote: Brandon Philips wrote: On 19:50 Wed 20 Jan 2010, Hans de Goede wrote: On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote: As we're discussing about having a separate tree for v4l2-apps, maybe the better is to port it to -git (in a way that we can preserve the log history). I have a small script I used to convert the history of libv4l to git. Let me know when we are ready to drop them from the hg tree and I can do the conversion and post the result for review. This is the result from the script for just libv4l: http://ifup.org/git/?p=libv4l.git;a=summary Seems fine, but we need to import the entire v4l2-apps. Yes, I know. I will run the script over v4l2-apps to generate a git repo once v4l2-apps is ready to be dropped from v4l-dvb mercurial and we figure out the directory layout. Doing it before is just a waste of time since they will get out of sync. Also, I suggest we call the repo v4lutils? In the spirit of usbutils, pciutils, etc. Hmm... as dvb package is called as dvb-utils, it seems more logical to call it v4l2-utils, but v4l2utils would equally work. Yes, that is fine. IMO, the better is to use v4l2 instead of just v4l, to avoid causing any mess with the old v4l applications provided with xawtv. The problem I saw was that libv4l1 will be in v4l2-utils. I don't care either way though. So here is how I see v4l-utils.git being laid out based on what others have said: libv4l1/ libv4l2/ libv4lconvert/ test/ v4l2-dbg/ contrib/ qv4l2-qt3/ qv4l2-qt4/ cx25821/ etc... everything else Are there things in v4l2-apps that should be imported? Other suggestions? Cheers, Brandon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
On Thursday 21 January 2010 03:07:32 Mauro Carvalho Chehab wrote: Brandon Philips wrote: On 19:50 Wed 20 Jan 2010, Hans de Goede wrote: On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote: As we're discussing about having a separate tree for v4l2-apps, maybe the better is to port it to -git (in a way that we can preserve the log history). I have a small script I used to convert the history of libv4l to git. Let me know when we are ready to drop them from the hg tree and I can do the conversion and post the result for review. This is the result from the script for just libv4l: http://ifup.org/git/?p=libv4l.git;a=summary Seems fine, but we need to import the entire v4l2-apps. Also, I suggest we call the repo v4lutils? In the spirit of usbutils, pciutils, etc. Hmm... as dvb package is called as dvb-utils, it seems more logical to call it v4l2-utils, but v4l2utils would equally work. IMO, the better is to use v4l2 instead of just v4l, to avoid causing any mess with the old v4l applications provided with xawtv. I also prefer v4l2-utils. It certainly should start with v4l2, not just v4l. Having a separate tree for v4l2-apps would work for me. If possible with direct commit / push rights, given that I'm doing 90% of the libv4l work. I am fine with Hans doing this. Thanks Hans. Ok. We would need to do some rearranging in the directory structure of v4l2-apps, though. Yes. Maybe we can move the tools that aren't meant to be used on distros on a separate dir, like contrib, having a separate make install for building them. Also, we need to use some config tool like autoconf that will seek for dependencies and or require the needed ones or not compile the applications that depends on some library. Ugh, I'm no fan of autoconf, but I can see this being handy, any volunteers for doing this bit ? I started getting libv4l converted to autoconf earlier. If you are OK with it I can provide patches after we get the repo converted. Seems good enough for me. For sure, one rule we need to define is what criteria will be used to classify an application as something that will be compiled/installed by default, and what applications are development-oriented applications. On some cases, this is clear (for example, the API compliance test applications are developer-oriented, while libv4l is a standard user-oriented one). However, a debug application (like v4l2-dbg) is a development application, but it may be nice to have it available at the distros, to help users to help check/report problems). Ack, I too think having v4l2-dbg available to end users could come in very handy to remote debug stuff. Indeed. Any tools that allow us to get insight would be great. Our current debugging tool belt is pretty poor in a lot of cases: lsusb, lspci, dmesg, does cheese work? It may also be useful to define a minimum set of coding style, like how applications should be indented Adopting Documentation/CodingStyle from the kernel with a few tweaks should work. That way we could use existing infrastructure like checkpatch.pl to check incoming stuff out. Yes, but, as we have also non-c code, some rules there don't apply. For example the rationale for not using // comments don't apply to c++, since it is there since the first definition. Most apps are already in 'kernel' style. The main exception being libv4l. Shall we just go through and convert everything at once then? Bulk coding style conversions with cstyle, etc never works 100% and so someone will need to review the diffs by hand. Volunteers with experience doing that? I have no strong opinion if we should or not convert the code to some codingstyle, but, if we do, the better is to do everything at once. I agree. On the experiences we had with v4l-dvb tree, it is not a good idea to allow multiple people to commit at the master repository, since, when a conflict rises between two different developers, this can cause lots of heat. Also, it is easy to corrupt a tree, as a push with -f flag can remove (or hide, on -git) the objects inserted by someone else. I've different experience in the projects with git I've used, as long as there are some governance rules (like never ever push -f, always do a rebase fix your stuff and then push, and if something else got in in the window in between rebase again, etc.). If the group of people with commit access is small (3-4) it generally works well. Yes. The more people touching at the same tree, the more troubles may happen. I don't object to allow a limited group of people accessing it, although I suspect that, if we open to more than one, we will have more than 4 people interested on it. In practice the only people who regularly touch v4l2-apps are Hans de Goede (libv4l), you and myself (v4l2-ctl, v4l2-dbg, qv4l2). I can't remember anyone else
Re: [ANNOUNCE] git tree repositories libv4l
On Thursday 21 January 2010 03:46:05 Brandon Philips wrote: On 00:07 Thu 21 Jan 2010, Mauro Carvalho Chehab wrote: Brandon Philips wrote: On 19:50 Wed 20 Jan 2010, Hans de Goede wrote: On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote: As we're discussing about having a separate tree for v4l2-apps, maybe the better is to port it to -git (in a way that we can preserve the log history). I have a small script I used to convert the history of libv4l to git. Let me know when we are ready to drop them from the hg tree and I can do the conversion and post the result for review. This is the result from the script for just libv4l: http://ifup.org/git/?p=libv4l.git;a=summary Seems fine, but we need to import the entire v4l2-apps. Yes, I know. I will run the script over v4l2-apps to generate a git repo once v4l2-apps is ready to be dropped from v4l-dvb mercurial and we figure out the directory layout. Doing it before is just a waste of time since they will get out of sync. Also, I suggest we call the repo v4lutils? In the spirit of usbutils, pciutils, etc. Hmm... as dvb package is called as dvb-utils, it seems more logical to call it v4l2-utils, but v4l2utils would equally work. Yes, that is fine. IMO, the better is to use v4l2 instead of just v4l, to avoid causing any mess with the old v4l applications provided with xawtv. The problem I saw was that libv4l1 will be in v4l2-utils. I don't care either way though. So here is how I see v4l-utils.git being laid out based on what others have said: libv4l1/ libv4l2/ libv4lconvert/ test/ v4l2-dbg/ contrib/ qv4l2-qt3/ qv4l2-qt4/ cx25821/ etc... everything else Hmm. I think I would prefer to have a structure like this: lib/ libv4l1/ libv4l2/ libv4lconvert/ utils/ v4l2-dbg v4l2-ctl cx18-ctl ivtv-ctl contrib/ test/ everything else And everything in lib and utils can be packaged by distros, while contrib is not packaged. What would also be nice is if this project http://v4l-test.sourceforge.net/ could eventually be merged in v4l2-apps. Are there things in v4l2-apps that should be imported? I'm sorry, but I'm not sure what you mean. Regards, Hans Other suggestions? Cheers, Brandon -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
