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
Mauro Carvalho Chehab, 2010-01-19: Yes. I personally prefer to have a bare clone (bare trees have just the -git objects, and not a workig tree), and several working copies. I do the work at the working copies, and, after they are fine, I push into the bare and send the branches from bare to upstream. Do you know git-new-workdir? It's included in the contrib area of the git installation. Instead of cloning your own local repository to get a new working directory, with this script you really only get a new working directory and can work in it as if it was the original clone. Then you don't have to deal with pushes between local repositories. Markus -- 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
Re: [ANNOUNCE] git tree repositories
Moin Andy, On Tue, 19 Jan 2010, Andy Walls wrote: On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Assuming 53.333 kbps download speed, 0% overhead, no compression: 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr = 15.95 hours :( Wow, that's about twice as fast as my first clone of the various SCM trees, mostly with CVSup, many years ago, after leaving the world of high-speedLand. Actually, when I made my first git kernel clone, I think it was less than 100MB yet still elicited the same astoundment I see now. And basically I did dial in and let all the checkouts run overnight from whichever provider was affordable, back when the per-minute costs were ten to 100 times what I see today. Although many other BSD full trees were updates of changes that had then occurred in five years, and CVSup/rsync and the like can do the work in bits and pieces. Can git resume aborted clones? It could be many weeks before I have a 20 hour window where I don't have to use my land line phone for voice... Unfortunately, my experience has been no, both in initial checkouts, and in large updates -- if I go for a month without pulling Linus' latest changes, with the poor connectivity I have, sometimes it will take three or four attempts until I can get all those handful of megabytes of chunks intact at once. Worse is if your ISP has you on a configuration that doesn't preserve your IP for the duration of your download, changing it every few minutes, or hours, as is a common practice to keep customers from running servers or doing anything useful. The net was made for surfing, not downloading, dammit. I am writing from the point of view of a beginner who knows nothing about the advantages of `git' or `hg' or `svn' and friends and who only wants to clone the entire development tree locally for off-line work with access to any point of development, and as such I don't know of any possible expert flags like ``--partial'' or something to instruct `git' not to discard any complete or partial chunks. In fact, I don't remember if I downloaded the original kernel in any special way, such as a .tbz file to be used as a base and then updated from there. So don't take my word as gospel. barry bouwsma in the middle of an aborted-after-four-hours update of FreeBSD during the bandwidth-hungry ``fixup'' process that thanks to their accursed move to `svn' seems to take much longer than just pulling the deltas alone, but luckily which I can resume once I get ``better'' connectivity and not lose much of anything. grumble mumble old fart grumble -- 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
On Wed, 20 Jan 2010, Mauro Carvalho Chehab wrote:
Andy Walls wrote:
On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:
BTW: I just made a clone of the git-tree - 365MB *ouff*.
Assuming 53.333 kbps download speed, 0% overhead, no compression:
365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr =
15.95 hours
It is an one time download, since, once you got it, the updates are cheap.
Getting a bit off-topic here, but hey
Yes, but it is that first step of getting the download that is
the problem.
Until the tree ends up with a conflicted merge (has happened to
me a few times), and then a beginner such as myself has no idea
what to do and pushes the tree out of the way and starts anew
(or decides to give up on the tree that's no longer so much of
interest), but that's when I've had better connectivity than
Sir Walls here.
A big problem I see and which will affect the majority of people
on less-than-ideal connections is that the initial clone is that
the `git clone' for such a large tree is not something you can
pick up if interrupted in the middle. I'd hate to be in Andy's
house as he's drenched with sweat clenching the arms of his
chair watching the progress bar go from 98% to 99% to
^%{3f{NO CARRIER as someone on his party line down the road
picks up the phone to chat with their sister in the next room.
Actually, that's not true, I'd love to hear it as I'm sure there
are a good variety of swear words I haven't learned from the time
I had me mouth washed out with Irish Spring, carried on to this
day by gargling every evening with Fairy Liquid.
Btw, it is a way small than a single CD needed for you to install Linux.
But `wget' has an option to resume the download, even if it takes
a week to get the entire CD as it did me. Or better, as I used,
`jigdo' which splits the download even further, automagically
uses `wget' in shortened `retry' mode, and allows me to get the
missing parts elsewhere -- before, like `git' or other SCM
frontends, getting incremental updates.
That is what seems to be missing from `git', in spite of its
other advantages over `rsync' or `CVSup', for an initial download.
If you want to get it and you're not willing to pay to a decent Internet
connection, just ask someone to get it for you and save on a CD.
This is not a good attitude to have -- I have been in places with
no practical internet connection and places where it was not worth
it to pay for a ``decent'' connection. Still, I tried to get on-
line when possible.
You are also working with volunteers who are putting out their own
money to get connectivity. I'm sure that I am not the only one on
the list who is unable to get a satisfactory decent-paying job at
present, but who is willing to donate time and some resources to
advance Linux and other free software. To do so I rely on more
fortunate friends who can afford a decent connection, when most of
my usage wouldn't even be noticed on a dial-up connection.
Sorry, I'm just ranting. Ignore me. Or I'll blow you all
sky-high after a week.
barry bouwsma
no-fly zone, until spring
--
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
Hi Devin, I think Mauro made it quite clear that this was just an announcement for work in progress that has been started on git support and that we still need to discuss how we will handle backports/compatibility with older kernels, so I'll go straight to the point I want to make. On Tuesday 19 January 2010 11:04:13 Devin Heitmueller wrote: [snip] I want to focus my development on v4l-dvb. That said, I want a stable codebase on which I can write v4l-dvb drivers, without having to worry about whether or not my wireless driver is screwed up this week, or whether the ALSA guys broke my audio support for the fifth time in two years. I don't want to wonder whether the crash I just experienced is because they've replaced the scheduler yet again and they're still shaking the bugs out. I don't want to be at the mercy of whatever ABI changes they're doing this week which break my Nvidia card (and while I recognize as open source developers we care very little about closed source drivers, we shouldn't really find it surprising that many developers who are rendering HD video might be using Nvidia cards). I totally agree with you here. We obviously don't support developers who still want to use a 2.4.x kernel on their computer, so a line as to be drawn at some point. This being said, I think we should not base the v4l-dvb git tree on the very latest Linus' tree. Linus himself stated during the LPC 2009 that subsystems should not pull from his tree at random point, but should rather use main kernel versions, or at least -rc versions. I think that basing the v4l-dvb tree on top of the last tag from mainline would be a better practice than pulling from it everyday. This will obviously not solve the issue you mention, which is why we still need to agree on a nice way to handle backports, but that will make life easier for developers who want to try the v4l-dvb subsystem on top of the most recent kernel. -- Regards, 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
Laurent Pinchart wrote: Hi Devin, I totally agree with you here. We obviously don't support developers who still want to use a 2.4.x kernel on their computer, so a line as to be drawn at some point. Currently, the backport starts on 2.6.16. I think it is ok to keep this as the basis version. This being said, I think we should not base the v4l-dvb git tree on the very latest Linus' tree. Linus himself stated during the LPC 2009 that subsystems should not pull from his tree at random point, but should rather use main kernel versions, or at least -rc versions. I think that basing the v4l-dvb tree on top of the last tag from mainline would be a better practice than pulling from it everyday. A good compromise here would be to use the latest main kernel version for fix patches that needs to go also to -stable and -rc1 for the other fixes and development patches. This will obviously not solve the issue you mention, which is why we still need to agree on a nice way to handle backports, but that will make life easier for developers who want to try the v4l-dvb subsystem on top of the most recent kernel. 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
Andy Walls wrote: On Wed, 2010-01-20 at 01:29 -0200, Mauro Carvalho Chehab wrote: Andy Walls wrote: On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Assuming 53.333 kbps download speed, 0% overhead, no compression: 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr = 15.95 hours It is an one time download, since, once you got it, the updates are cheap. Btw, it is a way small than a single CD needed for you to install Linux. If you want to get it and you're not willing to pay to a decent Internet connection, If only I could pay for a *decent* one. If I just want bandwidth at a poor level of service, poor reliability and high cost, then I'll pay for the local cable TV internet service. I'm in one of the white areas on the map on page 33 of: http://www.tccsmd.org/downloads/Broadband%20Final%20Report.pdf I don't really have options for getting a good value for my dollar on broadband internet. (The residential broadband deployment in the US is just terrible IMO.) Rural areas are more problematic. Here, in Brazil, we have a good coverage at low and fixed cost via cellular (about US$40,00/mo for 1Mb bandwidth). Yet, on rural areas, there's no 3G support, so it drops to EDGE or 2G speed. I have one of this, plus a xDSL link. just ask someone to get it for you and save on a CD. Nah. Next time I head to the library, I'll just bring a laptop along: free WiFi. Yeah, this should work. After you've pulled the tree, the updates are not that bad. Of course you can also keep using -hg. That was my plan. Regards, Andy 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
Markus Heidelberg wrote: Mauro Carvalho Chehab, 2010-01-19: Yes. I personally prefer to have a bare clone (bare trees have just the -git objects, and not a workig tree), and several working copies. I do the work at the working copies, and, after they are fine, I push into the bare and send the branches from bare to upstream. Do you know git-new-workdir? It's included in the contrib area of the git installation. Instead of cloning your own local repository to get a new working directory, with this script you really only get a new working directory and can work in it as if it was the original clone. Then you don't have to deal with pushes between local repositories. No, I never used. Sometimes, I use to manually create a new workdir copy, but it is good to know that there's an script ready for doing this. Thanks for pointing 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
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
Thank you, Mauro, for doing this work! It is highly appreciated! Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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/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
Johannes Stezenbach wrote: Hi, may I humbly request to make it mandatory to enter a description when a user creates a new tree on linuxtv.org? IMHO foobar development repository isn't useful at all. Ok, I changed the git-menu script to ask for the description before creating the clone. If I look at http://linuxtv.org/hg/ many times I have no clue what a repo is about or why it exists at all. Let's not repeat the same mistake with git. Agreed. OTOH, since with git it is common to have multiple branches within one repository, I'm not sure how it works. It would be cool if git would support per-branch descriptions, and git web could display them. I don't think git supports it. In kernel.org, people prefer to use more than one repository when they have more than one need. 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
On Thu, 21 Jan 2010, Mauro Carvalho Chehab wrote: OTOH, since with git it is common to have multiple branches within one repository, I'm not sure how it works. It would be cool if git would support per-branch descriptions, and git web could display them. I don't think git supports it. In kernel.org, people prefer to use more than one repository when they have more than one need. stgit lets me set descriptions for each branch. The descriptions are there under the branch in the config file. I don't think git-branch shows any kind of description for the branch. -- 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
Trent Piepho wrote: On Thu, 21 Jan 2010, Mauro Carvalho Chehab wrote: OTOH, since with git it is common to have multiple branches within one repository, I'm not sure how it works. It would be cool if git would support per-branch descriptions, and git web could display them. I don't think git supports it. In kernel.org, people prefer to use more than one repository when they have more than one need. stgit lets me set descriptions for each branch. The descriptions are there under the branch in the config file. I don't think git-branch shows any kind of description for the branch. stgit is a very interesting git porcelain. I used it a lot when I started with git. It were very useful at the time git weren't implementing tools like rebase. However, stgit produces objects that aren't referenced, generating errors when you run git fsck. So, I don't recomend using stgit anymore. 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 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
Re: [ANNOUNCE] git tree repositories
Hi Mauro, I would like to personally thank you for spending time on git support at linuxtv.org. Git support was a long-awaited feature for many developers (and I certainly was one of them). All the work done behind the scene on linuxtv.org isn't seen by end-users and can thus be less rewarding than working on the code. However, it's of critical importance to make the development process as smooth as possible. For that reason, thank you again. Thanks to Douglas too for agreeing to manage backports. Getting the latest version of our drivers working on older kernels make the test base much larger, leading to better quality code (or at least to more bug reports :-)). -- Regards, 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
On Tuesday 19 January 2010 08:53:10 Hans Verkuil wrote: On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote: He already started doing that, fixing some incompatibility troubles between some drivers and older kernels. Mauro, I just wanted to thank you for doing all the hard work in moving to git! And a big 'thank you' to Douglas as well for taking over hg maintenance! A big thank you also from me. This is really outstanding work you're doing there and it's highly appreciated. 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. In terms of the out-of-tree building system evolution (e. g. the building system concept behind the -hg tree), If people think it is worthy enough, maybe later this could also be converted also to -git, but preserving the building system and the backport patches. Another alternative would be to split the building systems and the backport patches, and apply them into the drivers/media files. I'm strongly in need of a build-only-v4l-dvb build system. Because I'm most of the time using distro-kernels in my productive environments and I'm replacing v4l/dvb drivers with the one from v4l-dvb. One step into the direction of a solution might be: Why not including the v4l-dvb/v4l/Makefile and the related files into that separate repository Hans is describing here and then telling 'make' to make links to ../../v4l-dvb/ instead of ../linux as of today. But I don't know how to solve the ifdef KERNEL_VERSION for having backward compatibility in the source files. Maybe with a patch for each kernel version? BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to mention right now, that one big difference to HG in the way we have used it, is that one developer now can do all the work only with one clone of v4l-dvb and using branches for each development. best regards, -- Patrick Boettcher - KernelLabs 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
Hello Mauro, I find it somewhat unfortunate that this is labeled ANNOUNCE instead of RFC. It shows how little you care about soliciting the opinions of the other developers. Rather than making a proposal for how the process can be improved and soliciting feedback, you have chosen to decide for all of us what the best approach is and how all of us will develop in the future. I know you'll continue to receive alot of thank you and great job comments from some of the developers who have been pushing for this, so I'll be the bad guy and point out the downsides to what you are proposing. First off, I would like to note that I have absolutely no problem with git. I think it's a great tool and I use it for other projects. If the question today was which source control software to use, I have no doubt I would choose git over mercurial. I've used a variety of different source control systems both open source and commercial, and git is a really good tool. That said, my real problem is with the change requiring all the active developers to be developing on the latest Linux kernel. Before I renew my arguments, I will openly acknowledge that your approach does make numerous things easier. I have little doubt that it will make merging easier for you personally, as well as addresses issues with patches that have architecture specific changes (or other changes that are outside of the current v4l-dvb tree). So let's talk about why this is bad I want to focus my development on v4l-dvb. That said, I want a stable codebase on which I can write v4l-dvb drivers, without having to worry about whether or not my wireless driver is screwed up this week, or whether the ALSA guys broke my audio support for the fifth time in two years. I don't want to wonder whether the crash I just experienced is because they've replaced the scheduler yet again and they're still shaking the bugs out. I don't want to be at the mercy of whatever ABI changes they're doing this week which break my Nvidia card (and while I recognize as open source developers we care very little about closed source drivers, we shouldn't really find it surprising that many developers who are rendering HD video might be using Nvidia cards). Like most smart developers, I want to have a *controlled* environment where I can be confident that if a problem arises that it's *my* changes at fault. Any time that I spend trying to figure out why my PC doesn't work is time that I'm not debugging v4l-dvb drivers. And *THAT* is why it's critical that the mainline not be treated as alpha quality like you suggested last week. For example, when you check in alpha code that causes an OOPS whenever any tuner with IR support is plugged in, I waste several hours debugging the regression you introduced instead of doing my own work. Further, we're also changing from a system where we build a relatively small tree of modules to one where we're going to be building/installing entire kernels. Even on my relatively recent hardware, this is process that takes upwards to an hour (and yes, I do have ccache). Even a make modules_install can several minutes. So now I'm going from being able to make make install make unload twenty times an hour to a *MUCH* slower process. We're giving up the ability to have a fast debug-compile-test cycle for developers in exchange for easier merging of the final result. This seems like a poor optimization choice for those of us who spend all day compiling, debugging, and testing. Personally, I spend about 98% of my time actively debugging code, and about 2% of my time dealing with merge issues. So I *really* care about things like how long it takes to compile and install the tree. I hope other developers will offer their opinions on this approach, since it's all of us who will pay the price in time as a result of this change. If all the developers who are writing the code think it's a good idea to be half as efficient in order to make the merging easier for one person, then so be it. The point I'm trying to make is that we need to be having a discussion about what we are optimizing for, and what are the costs to other developers. This is why I'm perhaps a bit pissed to see an announcement declaring how development will be done in the future as opposed to a discussion of what we could be doing and what are the trade-offs. Devin -- Devin J. Heitmueller - 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
Hans Verkuil wrote: On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote: Hi, Due to that, I'm delegating the task of keeping -hg in sync with upstream and backporting patches to run on older kernels to another person: Douglas has offered his help to keep the tree synchronized with the -git tree, and to add backport support. He already started doing that, fixing some incompatibility troubles between some drivers and older kernels. Mauro, I just wanted to thank you for doing all the hard work in moving to git! Anytime! 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: 1) v4l_experimental - I think we may just drop it. It was meant to be a staging area in the old days, but never worked. The 3 drivers there never suffered any maintanership. Even the firewire driver that used to be there were developed independently. So, IMO, we can just remove it and, if anyone needs those drivers, they can just look inside the -hg history. 2) firmware - the code there is just what we have in kernel. While this can be broken, I can't see much sense, as I don't foresee any changes there: new firmwares are going to linux-firmware tree and have an upstream maintainership in separate; 3) media docs - the docs are part of upstream tree. So, it doesn't make sense to have a separate tree for it. IMO, the proper direction is to merge upstream the capability of automatic generation of some xml scripts (like videobuf2.h.xml). Yet, there are a few files present on v4l2-apps that are also converted to xml, as they are usage examples at the API. I'm not sure what to do with them. 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. I'll be updating my daily build scripts to start using git soon (I'll keep using hg for the older kernels of course). That's good! I always check if the -git compiles with x86_64, but I generally don't check all architectures on my checks. 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
Laurent Pinchart wrote: Hi Mauro, I would like to personally thank you for spending time on git support at linuxtv.org. Git support was a long-awaited feature for many developers (and I certainly was one of them). All the work done behind the scene on linuxtv.org isn't seen by end-users and can thus be less rewarding than working on the code. However, it's of critical importance to make the development process as smooth as possible. For that reason, thank you again. You're welcome! Working at the infrastructure spends lots of time and, as you said, people generally only note when there's something broken. I'm quite confident that supporting -git is the proper path to make life easier for contributors and developers and opening a new road to the future of the subsystem. 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
On Tue, Jan 19, 2010 at 09:10:39AM +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to mention right now, that one big difference to HG in the way we have used it, is that one developer now can do all the work only with one clone of v4l-dvb and using branches for each development. Please note that you SHOULD NOT clone from linuxtv.org. Please follow the description on the top of http://linuxtv.org/git/ Most linux developers will have a clone of Linus' tree already, and you can add as many remotes to that tree as you like. It's much faster and more flexible that way. If you once pulled a clone of Linus' tree there is simply no need to ever clone any other Linux tree ever again. Oh, and if you manage to get your git tree in a state where you don't know how to fix the mess, don't throw it away. Go to the git mailing list and ask for advice. They love customer feeedback. Helps them to improve their product and make it more user friendly ;-) Johannes -- 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
On Tue, 19 Jan 2010, Johannes Stezenbach wrote: On Tue, Jan 19, 2010 at 09:10:39AM +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to mention right now, that one big difference to HG in the way we have used it, is that one developer now can do all the work only with one clone of v4l-dvb and using branches for each development. Please note that you SHOULD NOT clone from linuxtv.org. Please follow the description on the top of http://linuxtv.org/git/ Of course I cloned from git.kernel.org and not from linuxtv.org. Still it was my first clone of linux ever. -- 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
Hi Devin, On Tue, 19 Jan 2010, Devin Heitmueller wrote: [..] I want to focus my development on v4l-dvb. That said, I want a stable codebase on which I can write v4l-dvb drivers, without having to worry about whether or not my wireless driver is screwed up this week, or whether the ALSA guys broke my audio support for the fifth time in two years. I don't want to wonder whether the crash I just experienced is because they've replaced the scheduler yet again and they're still shaking the bugs out. I don't want to be at the mercy of whatever ABI changes they're doing this week which break my Nvidia card (and while I recognize as open source developers we care very little about closed source drivers, we shouldn't really find it surprising that many developers who are rendering HD video might be using Nvidia cards). I agree with Devin. We can't lose and off-tree build system like we have it today in v4l-dvb. What I suggested in my first Email was to put the build system outside the v4l-dvb into another repo (e.g. 'v4l-dvb-build') and then telling it to make links from the linux-v4l-dvb/ clone. I'm not sure what needs to be done for the backward-compat with #if KERNEL_VERSION ... But I'm sure we can find a solution for that. -- 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
Patrick Boettcher wrote: On Tuesday 19 January 2010 08:53:10 Hans Verkuil wrote: On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote: He already started doing that, fixing some incompatibility troubles between some drivers and older kernels. Mauro, I just wanted to thank you for doing all the hard work in moving to git! And a big 'thank you' to Douglas as well for taking over hg maintenance! A big thank you also from me. Wou're welcome. I'm strongly in need of a build-only-v4l-dvb build system. Because I'm most of the time using distro-kernels in my productive environments and I'm replacing v4l/dvb drivers with the one from v4l-dvb. We all need to have some ways to run the new drivers on distro kernels. If not as a developer, at least as an user. So, I keep believing that the out-of-tree compilation is fundamental to the success of the subsystem. One step into the direction of a solution might be: Why not including the v4l-dvb/v4l/Makefile and the related files into that separate repository Hans is describing here and then telling 'make' to make links to ../../v4l-dvb/ instead of ../linux as of today. This is about what make kernel-links do, but in the opposite direction. It shouldn't be hard do do that, but we need to fix the backports. In the case of -alsa, they opted to use this strategy for their backported tree, patching the kernel when building it. But I don't know how to solve the ifdef KERNEL_VERSION for having backward compatibility in the source files. Maybe with a patch for each kernel version? It can be a patch for each kernel version, but this will remove support for some distro-kernels where the KABI has changed. Another solution is to have a pile of patches that will be applied as the compilation breaks. This can work, but we need to find a way to produce those patches. Maybe the simplest solution is to keep maintaining the -hg and having an auto-generated tree that will have just the building system and a diff between -git and -hg. If both are synchronized, the only difference will be the backports. BTW: I just made a clone of the git-tree - 365MB *ouff*. Yes, this is one problem with -git: as it contains the entire kernel struct, and an history since 2.6.11, it is about 9 times bigger than the -hg tree, where only the media files are stored. Yet, git clone has a way to allow removing the history of the kernel, producing a small result --depth: $ git clone --depth 1 --bare v4l-dvb tmp This gives about 128M (about 3x -hg). Yet, trees generated with --depth have some disadvantages. Maybe it's worth to mention right now, that one big difference to HG in the way we have used it, is that one developer now can do all the work only with one clone of v4l-dvb and using branches for each development. Yes. The cost for a new branch is zero. Also, the cost of a new clone is less than 1M, if you use the --shared. On my daily usage, I use a lot to clone with --shared, and doing my work on independent directories. The advantage is that you avoid messing your temporary work. You may even pull or push just one branch into another tree. So, working with git offers lots of new possibilities to the developers. Cheers, Mauro. best regards, -- 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
Devin Heitmueller wrote: Hello Mauro, I find it somewhat unfortunate that this is labeled ANNOUNCE instead of RFC. It shows how little you care about soliciting the opinions of the other developers. Rather than making a proposal for how the process can be improved and soliciting feedback, you have chosen to decide for all of us what the best approach is and how all of us will develop in the future. The announcement by purpose doesn't contain any changes on the process, since it requires some discussions before we go there. It is just the first step, where -git tree support were created. It also announces that I personally won't keep maintaining -hg, delegating its task to Douglas. The point I'm trying to make is that we need to be having a discussion about what we are optimizing for, and what are the costs to other developers. This is why I'm perhaps a bit pissed to see an announcement declaring how development will be done in the future as opposed to a discussion of what we could be doing and what are the trade-offs. I fully understand that supporting the development and tests with an out of tree building is important to everybody. So, the plans are to keep the out-of-tree building system maintained, and even improving it. I'd like to thank to Douglas for his help on making this happen. 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
So am I. I hope the future will prove us right :-) :) How do your new git scripts process commits ? In particular, does the Priority: line still applies ? For patches imported from -hg, the script will handle Priority. For patches generated against -git, maybe the better is to have separate branches or trees: one for fixes and another for new stuff, and an indication, at the pull request, to what tree the patch will be applied. We still need some discussions about the process. One of the issues is how do we'll handle SOB's. My SOB should be added on all patches. Also, sometimes, patches may need to receive other SOB-like tags, like acked-by. I'm not sure yet how should we handle it, since a change at the patch description will change the hash code. -git merge is generally smart enough to not generate a conflict between two patches with identical diffs, but we need to do some tests in order to check what would be the better procedure. 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
Patrick Boettcher wrote: Hi Devin, On Tue, 19 Jan 2010, Devin Heitmueller wrote: [..] I want to focus my development on v4l-dvb. That said, I want a stable codebase on which I can write v4l-dvb drivers, without having to worry about whether or not my wireless driver is screwed up this week, or whether the ALSA guys broke my audio support for the fifth time in two years. I don't want to wonder whether the crash I just experienced is because they've replaced the scheduler yet again and they're still shaking the bugs out. I don't want to be at the mercy of whatever ABI changes they're doing this week which break my Nvidia card (and while I recognize as open source developers we care very little about closed source drivers, we shouldn't really find it surprising that many developers who are rendering HD video might be using Nvidia cards). I agree with Devin. We can't lose and off-tree build system like we have it today in v4l-dvb. What I suggested in my first Email was to put the build system outside the v4l-dvb into another repo (e.g. 'v4l-dvb-build') and then telling it to make links from the linux-v4l-dvb/ clone. I'm not sure what needs to be done for the backward-compat with #if KERNEL_VERSION ... But I'm sure we can find a solution for that. I started a branch with an alternative for if KERNEL_VERSION. Please see: http://linuxtv.org/hg/~mchehab/backport/ Basically, it has some perl rules that identifies the points on the source code where an KABI function has changed and dynamically patches the code. On my tests, this strategy works fine, but I haven't finished removing all KERNEL_VERSION checks from the code. If someone is interested, please be my guest fixing the code and improving it. Cheers, Mauro. -- 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
Johannes Stezenbach wrote: On Tue, Jan 19, 2010 at 09:10:39AM +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to mention right now, that one big difference to HG in the way we have used it, is that one developer now can do all the work only with one clone of v4l-dvb and using branches for each development. Please note that you SHOULD NOT clone from linuxtv.org. Please follow the description on the top of http://linuxtv.org/git/ Most linux developers will have a clone of Linus' tree already, and you can add as many remotes to that tree as you like. Yes. I have here one stable tree that have one remote for every stable tree since 2.6.16. It's much faster and more flexible that way. If you once pulled a clone of Linus' tree there is simply no need to ever clone any other Linux tree ever again. Yes. I personally prefer to have a bare clone (bare trees have just the -git objects, and not a workig tree), and several working copies. I do the work at the working copies, and, after they are fine, I push into the bare and send the branches from bare to upstream. Oh, and if you manage to get your git tree in a state where you don't know how to fix the mess, don't throw it away. Go to the git mailing list and ask for advice. They love customer feeedback. Helps them to improve their product and make it more user friendly ;-) Yes. One good thing to do is to take a look at git reflog. It tracks all the changes you do, and you can always ask git to move to a different object at the tree, undoing the bad thing you did ;) Johannes -- 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
Hi Mauro, I've started playing with the linuxtv git repositories. I've cloned v4l- dvb.git into git://linuxtv.org/pinchartl/uvcvideo.git using git-menu and now have trouble pushing changes: $ git push -v uvcvideo Pushing to git://linuxtv.org/pinchartl/uvcvideo.git fatal: The remote end hung up unexpectedly What URL should I use to push changes ? -- Regards, 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
Laurent Pinchart wrote: Hi Mauro, I've started playing with the linuxtv git repositories. I've cloned v4l- dvb.git into git://linuxtv.org/pinchartl/uvcvideo.git using git-menu and now have trouble pushing changes: $ git push -v uvcvideo Pushing to git://linuxtv.org/pinchartl/uvcvideo.git fatal: The remote end hung up unexpectedly What URL should I use to push changes ? Push will only work if you use the ssh url. the url is basically the same of http, but replacing to ssh: ssh://linuxtv.org/git/tree On your case ssh://linuxtv.org/git/pinchartl/uvcvideo.git 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
Hi Mauro, On Tuesday 19 January 2010 14:07:39 Mauro Carvalho Chehab wrote: Laurent Pinchart wrote: Hi Mauro, I've started playing with the linuxtv git repositories. I've cloned v4l- dvb.git into git://linuxtv.org/pinchartl/uvcvideo.git using git-menu and now have trouble pushing changes: $ git push -v uvcvideo Pushing to git://linuxtv.org/pinchartl/uvcvideo.git fatal: The remote end hung up unexpectedly What URL should I use to push changes ? Push will only work if you use the ssh url. the url is basically the same of http, but replacing to ssh: ssh://linuxtv.org/git/tree On your case ssh://linuxtv.org/git/pinchartl/uvcvideo.git One step further: $ git push -v uvcvideo Pushing to ssh://linuxtv.org/git/pinchartl/uvcvideo.git Permission denied (publickey). fatal: The remote end hung up unexpectedly Do I need to upload my public key somewhere ? I already use it with hg push (and ssh git-menu) without any issue. -- 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
On 01/19/2010 04:16 AM, Mauro Carvalho Chehab wrote: Devin Heitmueller wrote: Hello Mauro, I find it somewhat unfortunate that this is labeled ANNOUNCE instead of RFC. It shows how little you care about soliciting the opinions of the other developers. Rather than making a proposal for how the process can be improved and soliciting feedback, you have chosen to decide for all of us what the best approach is and how all of us will develop in the future. The announcement by purpose doesn't contain any changes on the process, since it requires some discussions before we go there. It is just the first step, where -git tree support were created. It also announces that I personally won't keep maintaining -hg, delegating its task to Douglas. The point I'm trying to make is that we need to be having a discussion about what we are optimizing for, and what are the costs to other developers. This is why I'm perhaps a bit pissed to see an announcement declaring how development will be done in the future as opposed to a discussion of what we could be doing and what are the trade-offs. I fully understand that supporting the development and tests with an out of tree building is important to everybody. So, the plans are to keep the out-of-tree building system maintained, and even improving it. I'd like to thank to Douglas for his help on making this happen. Cheers, Mauro. I'm primarily a lurker on this list, generally content to wait for v4l driver updates until they appear in the Fedora 12 and Ubuntu 9.10 updates. However, I also keep a v4l source tree around that I update and build whenever any significant changes occur that affect my HVR-950Q, so I can provide rapid feedback to the developers. My process is to update my local tree, build the drivers. build the package, install the package, test it, then either revert immediately if there are problems (after posting to the list), or update again when the changes appear in the Fedora repositories. Am I correct to believe my process will not be affected by the shift to git? That is, will existing kernels will still have access to the current v4l code via hg? I also hope to one day start working on an unsupported USB tuner I have laying around (should be simple, but after nearly a year I still haven't gotten to it). Will I be permitted to do my development, and contribute changes, using hg and the current Fedora kernel? Lurker testers and wannabe developers need to know! -BobC -- 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
Hi, may I humbly request to make it mandatory to enter a description when a user creates a new tree on linuxtv.org? IMHO foobar development repository isn't useful at all. If I look at http://linuxtv.org/hg/ many times I have no clue what a repo is about or why it exists at all. Let's not repeat the same mistake with git. OTOH, since with git it is common to have multiple branches within one repository, I'm not sure how it works. It would be cool if git would support per-branch descriptions, and git web could display them. Johannes -- 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
Hi Bob, Am Dienstag, den 19.01.2010, 13:21 -0800 schrieb Bob Cunningham: On 01/19/2010 04:16 AM, Mauro Carvalho Chehab wrote: Devin Heitmueller wrote: Hello Mauro, I find it somewhat unfortunate that this is labeled ANNOUNCE instead of RFC. It shows how little you care about soliciting the opinions of the other developers. Rather than making a proposal for how the process can be improved and soliciting feedback, you have chosen to decide for all of us what the best approach is and how all of us will develop in the future. The announcement by purpose doesn't contain any changes on the process, since it requires some discussions before we go there. It is just the first step, where -git tree support were created. It also announces that I personally won't keep maintaining -hg, delegating its task to Douglas. The point I'm trying to make is that we need to be having a discussion about what we are optimizing for, and what are the costs to other developers. This is why I'm perhaps a bit pissed to see an announcement declaring how development will be done in the future as opposed to a discussion of what we could be doing and what are the trade-offs. I fully understand that supporting the development and tests with an out of tree building is important to everybody. So, the plans are to keep the out-of-tree building system maintained, and even improving it. I'd like to thank to Douglas for his help on making this happen. Cheers, Mauro. I'm primarily a lurker on this list, generally content to wait for v4l driver updates until they appear in the Fedora 12 and Ubuntu 9.10 updates. However, I also keep a v4l source tree around that I update and build whenever any significant changes occur that affect my HVR-950Q, so I can provide rapid feedback to the developers. My process is to update my local tree, build the drivers. build the package, install the package, test it, then either revert immediately if there are problems (after posting to the list), or update again when the changes appear in the Fedora repositories. Am I correct to believe my process will not be affected by the shift to git? That is, will existing kernels will still have access to the current v4l code via hg? I also hope to one day start working on an unsupported USB tuner I have laying around (should be simple, but after nearly a year I still haven't gotten to it). Will I be permitted to do my development, and contribute changes, using hg and the current Fedora kernel? Lurker testers and wannabe developers need to know! -BobC if you look at the history of v4l, you can be sure that we always tried to have as much testers as possible. During the 2.5.x development cycle, in fact all testing and development was done on 2.4.x. We did not even have any SCM that time, but on 2.5.x problems Devin is pointing to were enormous. Mike Krufky and Mauro were always strong in defending backward compat, also after taking over Gerd's cvs he later had. Mauro, in the beginning, even always tried to keep usability back to 2.4.x kernels with v4l2 revision 1 and I did warn him, that this task is quite impossible to satisfy, but we had developers on totally outdated semi proprietary stuff, years in delay, asking exactly for that. On latest discussions, how far we should keep backward compat after i2c improvements, you saw Mauro again voting for as far as ever possible. Be sure, we don't want to lose you guys! Cheers, Hermann -- 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
On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Assuming 53.333 kbps download speed, 0% overhead, no compression: 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr = 15.95 hours :( Can git resume aborted clones? It could be many weeks before I have a 20 hour window where I don't have to use my land line phone for voice... Regards, Andy -- 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
Am Dienstag, den 19.01.2010, 18:38 -0500 schrieb Andy Walls: On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Assuming 53.333 kbps download speed, 0% overhead, no compression: 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr = 15.95 hours :( Can git resume aborted clones? It could be many weeks before I have a 20 hour window where I don't have to use my land line phone for voice... Regards, Andy Hi Andy, :) please take it only as that. What about assuming a 1800 kbps low level flat rate and all phone calls for free, except for some exotic ;) mobile net providers, for the whole family, including a mobile flat, 4 different phone numbers, video on demand, and much more you don't need, for 30€ per months? It is always said, we are so much in delay with such here, but seeing the above calculation, it is ten years back paying for nothing the triple money and wait for a day. And preferably the phone of course is blocked during that. You are living in the USA? Seems sending CDs per express air mail is much cheaper ..., even using Brazil as a relay ;) Are you sure, you did not miss to update your provider ten years back the first time? We have local traffic since years, leaving Germany in the north, coming in over there through Canada, crossing the whole States, and coming back from Florida to arrive a few miles away from me, just because of unused backbones. Also VOIP calls are quite fine these days, but local thunderstorms in between are still often a disaster for hours in summer. Taking the smileys out now, in fact distributions have Gigas of updates within a few weeks these days. Andy for sure has an argument. Cheers, Hermann -- 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
Andy Walls wrote: On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Assuming 53.333 kbps download speed, 0% overhead, no compression: 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr = 15.95 hours It is an one time download, since, once you got it, the updates are cheap. Btw, it is a way small than a single CD needed for you to install Linux. If you want to get it and you're not willing to pay to a decent Internet connection, just ask someone to get it for you and save on a CD. Of course you can also keep using -hg. 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
On Wed, 2010-01-20 at 02:10 +0100, hermann pitton wrote: Am Dienstag, den 19.01.2010, 18:38 -0500 schrieb Andy Walls: On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Assuming 53.333 kbps download speed, 0% overhead, no compression: 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr = 15.95 hours :( Can git resume aborted clones? It could be many weeks before I have a 20 hour window where I don't have to use my land line phone for voice... Regards, Andy Hi Andy, :) please take it only as that. :) What about assuming a 1800 kbps low level flat rate and all phone calls for free, except for some exotic ;) mobile net providers, for the whole family, including a mobile flat, 4 different phone numbers, video on demand, and much more you don't need, for 30€ per months? It is always said, we are so much in delay with such here, but seeing the above calculation, it is ten years back paying for nothing the triple money and wait for a day. And preferably the phone of course is blocked during that. Yes, I realize I am in the dark ages. I haven't been able to build a cost case for my normal home communications needs to pay for Cable or Satellite internet service. I really dislike monthly recurring household costs for services that bill me whether I use them or not, like communications. I try to pay only for plans that meet my common usage needs and no more. My oldest child is to the point where she will need to start using the internet for research for school next year. I'll have to open my wallet soon, as my household communications needs are growing. You are living in the USA? Seems sending CDs per express air mail is much cheaper ..., even using Brazil as a relay ;) You beat me to that joke. Although I was going to say New Zealand... Are you sure, you did not miss to update your provider ten years back the first time? I live in a very rural area: No fiber optic, no DSL, EV-DO requires directional antenna and amplifier. Cable TV internet is available, but is unreliable and expensive. Satellite internet is available, of course. Regards, Andy Taking the smileys out now, in fact distributions have Gigas of updates within a few weeks these days. Andy for sure has an argument. Cheers, Hermann -- 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
On Wed, 2010-01-20 at 01:29 -0200, Mauro Carvalho Chehab wrote: Andy Walls wrote: On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Assuming 53.333 kbps download speed, 0% overhead, no compression: 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr = 15.95 hours It is an one time download, since, once you got it, the updates are cheap. Btw, it is a way small than a single CD needed for you to install Linux. If you want to get it and you're not willing to pay to a decent Internet connection, If only I could pay for a *decent* one. If I just want bandwidth at a poor level of service, poor reliability and high cost, then I'll pay for the local cable TV internet service. I'm in one of the white areas on the map on page 33 of: http://www.tccsmd.org/downloads/Broadband%20Final%20Report.pdf I don't really have options for getting a good value for my dollar on broadband internet. (The residential broadband deployment in the US is just terrible IMO.) just ask someone to get it for you and save on a CD. Nah. Next time I head to the library, I'll just bring a laptop along: free WiFi. Of course you can also keep using -hg. That was my plan. Regards, Andy 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
On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote: Hi, Today, a step to the future was given, in order to help developers to better do their work: the addition of -git support at linuxtv.org server. This is one idea that is being recurrent along the last years: to start using -git as our primary resource for managing the patches at the development[1]. At the beginning, the usage CVS for of a SCM (Source Code Management) were choosen on V4L/DVB. Both of the original V4L and DVB trees were developed with the help of cvs. On that time, upstream Linux kernel used to have another tree (BitKeeper). In 2005, both V4L and DVB trees got merged into one cvs repository, and we've discussed about what would be the better SCM solution. We've discussed more about using svn, hg and git. On that time, both hg and git were new technologies, based on the concept of a distributed SCM, where you don't need to go to the server every time you're doing a command at the SCM. Yet, Mercurial were more stable and used, while -git were giving his first steps[2], being used almost only by the Linux Kernel, and several distros didn't use to package it. Git objects were stored uncompressed, generating very large trees. Also, -git tools were complex to use, and some porcelain packages were needed, in order to be used by a normal user. So, the decision was made to use mercurial. However, as time goes by, -git got much more eyes than any other SCM, having all their weakness solved, and being developed really fast. Also, it got adopted by several other projects, due to its capability and its number of features. Technically speaking, -git is currently the most advanced distributed open-source SCM application I know. Yet, Mercurial has been doing a very good job maintaining the V4L/DVB trees, and, except for a few points, it does the job. However, the entire Linux Kernel development happens around -git. Even the ones that were adopting other tools (like -alsa, that used to have also Mercurial repositories) migrated to -git. Despite all technical advantages, the rationale for the migration is quite simple: converting patches between different repositories and SCM tools cause development and merge delays, may cause patch mangling and eats lot of the time for people that are part of the process. Also, every time a patch needs to touch on files outside the incomplete tree used at the subsystem, an workaround need to be done, in order to avoid troubles and to be able to send the patch upstream. So, it is simpler to just use -git. Due to all the above reasons, I took some time to add -git support at linuxtv servers. Both http and git methods to retrieve trees were enabled. The new trees will be available at: http://linuxtv.org/git/ The merge tree, where all submitted patches will be merged, before sending upstream is: http://linuxtv.org/git?p=v4l-dvb.git;a=summary This tree is basically a clone of Linus tree, so it runs the latest development kernel. It is also (almost) in sync with our -hg tree (needing just a few adjustments). The above tree will never be rebased, so it should be safe to use it for development. I'll basically merge there all patches I receive. It is OK to submit patches against -hg, since I can still run my old conversion stripts to convert them to -git. However, as the conversion script is not fast (it takes between 15-30 secs to convert a single patch to -git, since it needs to re-generate the entire tree with v4l/scripts/gentree.pl, for ever patch), I kindly ask you to prefer submit me patches directly to -git. With respect to the -hg tree with the out-of-tree building system, We really want to keep having a way to allow running the drivers with kernels other than the latest -rc one, for both development and testing. As you all know, the number of drivers and the average number of merges per day is being increasing, among with more complexity on some drivers that also touches arch and other files outside drivers/media tree. Due to that, lots of my current time is devoted to keep -hg and -git in sync, distracting me from my develoment and maintanership tasks to do it. So, I simply don't have more time to keep maintaining both -hg and -git. Due to that, I'm delegating the task of keeping -hg in sync with upstream and backporting patches to run on older kernels to another person: Douglas has offered his help to keep the tree synchronized with the -git tree, and to add backport support. He already started doing that, fixing some incompatibility troubles between some drivers and older kernels. Mauro, I just wanted to thank you for doing all the hard work in moving to git! And a big 'thank you' to Douglas as well for taking over hg maintenance! I do have one proposal: parts of our hg tree are independent of git:
