date:20100917


I see that the build now succeeded.

Ole: this is something that should have been fixed a long time ago, but 
isn't.

make allyesmod
should set only those divers that do actually compile.
Unfortunately, the FIREDTV driver has bugs for as long as I remember.

In the 4vl directory, edit .config
and change the line
CONFIG_DVB_FIREDTV=m
into
CONFIG_DVB_FIREDTV=n

It should compile fine then.

Jan Hoogenraad wrote:

Douglas;

Could you please check your last putback ?

the build is broken.

see:
http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

and the mail
[cron job] v4l-dvb daily build 2.6.26 and up: ERRORS

Yours,
Jan

Ole W. Saastad wrote:

Trouble building v4l-dvb
Asus eee netbook, running EasyPeasy.

o...@ole-eee:~$ cat /etc/issue
Ubuntu 9.04 \n \l
o...@ole-eee:~$ uname -a
Linux ole-eee 2.6.30.5-ep0 #10 SMP PREEMPT Thu Aug 27 19:45:06 CEST 2009
i686 GNU/Linux

Rationale for building from source: I have bought a USB TV with mpg4 
support from Sandberg, Mini DVB-T

dongle. I also received an archive with driver routines for this from
Sandberg. These should be copied into the v4l-dvd three and just rebuild
with make.
I have installed the kernel headers:
apt-get install mercurial linux-headers-$(uname -r) build-essential

Then I have downloaded the v4l-dvb source (assuming this is a stable
release): hg clone http://linuxtv.org/hg/v4l-dvb


I wanted to try to build before applying the patch from Sandberg. 
Issuing make yield the following :


LIRC: Requires at least kernel 2.6.36
IR_LIRC_CODEC: Requires at least kernel 2.6.36
IR_IMON: Requires at least kernel 2.6.36
IR_MCEUSB: Requires at least kernel 2.6.36
VIDEOBUF_DMA_CONTIG: Requires at least kernel 2.6.31
V4L2_MEM2MEM_DEV: Requires at least kernel 2.6.33
and a few more lines

Ignoring these and just continuing :

  CC [M]  /home/ole/work/v4l-dvb/v4l/firedtv-dvb.o
  CC [M]  /home/ole/work/v4l-dvb/v4l/firedtv-fe.o
  CC [M]  /home/ole/work/v4l-dvb/v4l/firedtv-1394.o
/home/ole/work/v4l-dvb/v4l/firedtv-1394.c:22:17: error: dma.h: No such
file or directory
/home/ole/work/v4l-dvb/v4l/firedtv-1394.c:23:21: error: csr1212.h: No
such file or directory
/home/ole/work/v4l-dvb/v4l/firedtv-1394.c:24:23: error: highlevel.h: No
such file or directory
and many many more similar errors.

After some time the make bails out.


I assume this have some connection with the 9.04 being too old.

Hints ?



Regards,
Ole W. Saastad




--
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







--
Jan Hoogenraad
Hoogenraad Interface Services
Postbus 2717
3500 GS Utrecht
--
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: Remaining BKL users, what to do

On Thursday 16 September 2010, Anton Altaparmakov wrote:
 On 16 Sep 2010, at 16:04, Jan Kara wrote:
  On Thu 16-09-10 16:32:59, Arnd Bergmann wrote:
  The big kernel lock is gone from almost all code in linux-next, this is
  the status of what I think will happen to the remaining users:
  ...
  fs/ncpfs:
   Should be fixable if Petr still cares about it. Otherwise suggest
   moving to drivers/staging if there are no users left.
   I think some people still use this...
 
 Yes, indeed.  Netware is still alive (unfortunately!) and ncpfs is used in a 
 lot of 
 Universities here in the UK at least (we use it about a thousand workstations 
 and
 servers here at Cambridge University!).

Ok, that means at least when someone gets around to fix it, there will be
people that can test the patches.

If you know someone who would like to help on this, it would be nice to try
out the patch below, unless someone can come up with a better solution.
My naïve understanding of the code tells me that simply using the super block
lock there may work. In fact it makes locking stricter, so if it still works
with that patch, there are probably no subtle regressions.
The patch applies to current linux-next of my bkl/vfs series.

Arnd

---
ncpfs: replace BKL with lock_super

This mindlessly changes every instance of lock_kernel in ncpfs to
lock_super. I haven't tested this, it may work or may break horribly.
Please test with CONFIG_LOCKDEP enabled.

Signed-off-by: Arnd Bergmann a...@arndb.de

diff --git a/fs/ncpfs/dir.c b/fs/ncpfs/dir.c
index 9578cbe..303338d 100644
--- a/fs/ncpfs/dir.c
+++ b/fs/ncpfs/dir.c
@@ -19,7 +19,6 @@
 #include linux/mm.h
 #include asm/uaccess.h
 #include asm/byteorder.h
-#include linux/smp_lock.h
 
 #include linux/ncp_fs.h
 
@@ -339,9 +338,10 @@ static int
 ncp_lookup_validate(struct dentry * dentry, struct nameidata *nd)
 {
int res;
-   lock_kernel();
+   struct super_block *sb = dentry-d_inode-i_sb;
+   lock_super(sb);
res = __ncp_lookup_validate(dentry);
-   unlock_kernel();
+   unlock_super(sb);
return res;
 }
 
@@ -404,6 +404,7 @@ static int ncp_readdir(struct file *filp, void *dirent, 
filldir_t filldir)
 {
struct dentry *dentry = filp-f_path.dentry;
struct inode *inode = dentry-d_inode;
+   struct super_block *sb = inode-i_sb;
struct page *page = NULL;
struct ncp_server *server = NCP_SERVER(inode);
union  ncp_dir_cache *cache = NULL;
@@ -411,7 +412,7 @@ static int ncp_readdir(struct file *filp, void *dirent, 
filldir_t filldir)
int result, mtime_valid = 0;
time_t mtime = 0;
 
-   lock_kernel();
+   lock_super(sb);
 
ctl.page  = NULL;
ctl.cache = NULL;
@@ -546,7 +547,7 @@ finished:
page_cache_release(ctl.page);
}
 out:
-   unlock_kernel();
+   unlock_super(sb);
return result;
 }
 
@@ -794,12 +795,13 @@ out:
 static struct dentry *ncp_lookup(struct inode *dir, struct dentry *dentry, 
struct nameidata *nd)
 {
struct ncp_server *server = NCP_SERVER(dir);
+   struct super_block *sb = dir-i_sb;
struct inode *inode = NULL;
struct ncp_entry_info finfo;
int error, res, len;
__u8 __name[NCP_MAXPATHLEN + 1];
 
-   lock_kernel();
+   lock_super(sb);
error = -EIO;
if (!ncp_conn_valid(server))
goto finished;
@@ -846,7 +848,7 @@ add_entry:
 
 finished:
PPRINTK(ncp_lookup: result=%d\n, error);
-   unlock_kernel();
+   unlock_super(sb);
return ERR_PTR(error);
 }
 
@@ -880,6 +882,7 @@ int ncp_create_new(struct inode *dir, struct dentry 
*dentry, int mode,
 {
struct ncp_server *server = NCP_SERVER(dir);
struct ncp_entry_info finfo;
+   struct super_block *sb = dir-i_sb;
int error, result, len;
int opmode;
__u8 __name[NCP_MAXPATHLEN + 1];
@@ -888,7 +891,7 @@ int ncp_create_new(struct inode *dir, struct dentry 
*dentry, int mode,
dentry-d_parent-d_name.name, dentry-d_name.name, mode);
 
error = -EIO;
-   lock_kernel();
+   lock_super(sb);
if (!ncp_conn_valid(server))
goto out;
 
@@ -935,7 +938,7 @@ int ncp_create_new(struct inode *dir, struct dentry 
*dentry, int mode,
 
error = ncp_instantiate(dir, dentry, finfo);
 out:
-   unlock_kernel();
+   unlock_super(sb);
return error;
 }
 
@@ -949,6 +952,7 @@ static int ncp_mkdir(struct inode *dir, struct dentry 
*dentry, int mode)
 {
struct ncp_entry_info finfo;
struct ncp_server *server = NCP_SERVER(dir);
+   struct super_block *sb = dir-i_sb;
int error, len;
__u8 __name[NCP_MAXPATHLEN + 1];
 
@@ -956,7 +960,7 @@ static int ncp_mkdir(struct inode *dir, struct dentry 
*dentry, int mode)
dentry-d_parent-d_name.name, dentry-d_name.name);
 
error = -EIO;
-   lock_kernel();
+   lock_super(sb);
if

Re: Trouble building v4l-dvb

Em 17-09-2010 06:35, Jan Hoogenraad escreveu:
 I see that the build now succeeded.
 
 Ole: this is something that should have been fixed a long time ago, but isn't.
 make allyesmod
 should set only those divers that do actually compile.
 Unfortunately, the FIREDTV driver has bugs for as long as I remember.

The problem are not related to bugs at firedtv driver, but, instead, due to the 
fact
that the provided firewire drivers and fw-core don't match the drivers that are 
shipped
with the distro kernel. In order words, at Ubuntu (and some other deb-based 
distros),
they're shipping the wrong include files at /lib/modules/`uname -r`/build/. So, 
there's
no way to build and run any module based on that wrong broken headers.

Up to a certain amount, the same happens with -alsa files on Ubuntu: although 
they
will compile [1], as the provided headers at /lib/modules/`uname -r`/build/ are 
from a different
version than the alsa modules provided with Ubuntu, the drivers that depend on 
-alsa will 
generally compile, but they generally won't load (and, if they load, they'll 
can cause
an OOPS and some other random troubles), as the symbol dependency will not 
match.

While a hack might be added at v4l-dvb -hg tree to make firedtv to compile 
against a broken
header, the firedtv driver will not work anyway.

The only real solution for it is to fix this issue at the distro.

Cheers,
Mauro

[1] The v4l-dvb is smart enough to adapt to -alsa API changes that are 
backported into
an older kernel, since it checks for the API symbols that changed, instead of 
just looking
for the kernel version. This works fine with all distros (like Fedora, RHEL, 
SUSE, OpenSUSE,
Mandriva, ...) where the include files for alsa are at the right place:
/lib/modules/`uname -r`/build/).
--
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: RFC: Move ivtv utilities and ivtv X video extension to v4l-utils

2010-09-17 Thread Andy Walls

On Fri, 2010-09-17 at 10:30 +0200, Hans Verkuil wrote:
 On Friday, September 17, 2010 00:58:45 Andy Walls wrote:
  Hi Hans and Hans,
  
  I'd like to move the source code maintained here:
  
  http://ivtvdriver.org/svn/
  
  to someplace where it may be less likely to suffer bit rot.
  I was hoping the v4l-utils git repo would be an appropriate place.
  
  Do either of you have any opinions on this?
 
 I agree with this, but it would require some work.

OK.  But given your comments below, I'm going to change my execution
strategy: move or port things incrementally, the most used/useful stuff
first.

Distribution packages and end users might not like that (Where did
ivtv-tune go?) but I don't have a solid block of time to do things all
in one go.


 xf86-video-ivtv really belongs at freedesktop.org as part of the X video 
 drivers.
 Nobody ever made the effort to integrate it there, but it would be the right
 thing to do.

OK.  That's going to be low on my list then.  Given my current
availability, that might end up looking like a dump and run on
freedesktop.org folks.  That wouldn't be good for anyone.  I suppose I
should get Ian Armstrong's input on this particular item.


 ivtvtv is more a private test application I made to test the MPEG 
 encoder/decoder
 API. Either this has to be turned into a more full-fledged application for the
 PVR-350 and then it definitely might be a good candidate for inclusion in
 v4l-utils, or it stays here, or I can host it on my website as a simple tar
 archive.

Ok, that one will stay on ivtvdriver.org until it becomes better or
overcome by time.


 Looking that ivtv itself: in utils we have ivtv-radio, ivtvplay, 
 ivtv-mpegindex,
 ivtv-tune and cx25840ctl.
 
 ivtv-radio is a good candidate for v4l-utils, but it would be really nice if 
 it
 could be made more general. E.g. v4l2-radio.

Yes.  There is not other application like it.  I also think that a
v4l2-radio would be a good simple candidate for exercising some of the
Media Controller API:

1. Does this device have a radio?
2. What is the radio control node?
3. Does it have an associated ALSA card? What is the ALSA PCM node?
4. Does it have a V4L2 PCM node?


 Ditto for ivtv-tune (although merging this functionality into v4l2-ctl is also
 an interesting option).

Yes.  The only reason I use ivtv-tune is that v4l2-ctl requires me to
know my analog channel frequencies by number just to change the
channel. :(

Given that, I use ivtv-tune a lot.

Merging it's functionality into v4l2-ctl seems like the way to go.  I'd
like to do it in such a way that a user preferences file isn't saved
though.


 cx25840ctl should really be integrated into v4l2-dbg.

Hmmm.  That would be an oddly specific addition to v4l2-dbg.  Given that
we have device nodes on subdev's coming soon, with subdev controls,
maybe this is obsolete?

Anyway, I never use it.  Which begs the question: If I don't use it, who
does?


 ivtv-mpegindex isn't ivtv specific and can go to contrib/test.
 
 ivtvplay I'm not sure about. There is a lot of overlap between ivtvplay and 
 ivtvtv.



 Regarding the test utilities: some of these can go to contrib/test, some
 that are really ivtv specific can go to contrib/ivtv. And some should perhaps
 just die.

Thanks for the insight on where to put things.

I agree, some things should just die.  That's part of what I meant by
bit-rot.

 Basically ivtv-utils is a bit of a mess: the really good stuff has already 
 been
 moved to v4l-utils (v4l2-ctl and v4l2-dbg both came out of ivtv and are now
 maintained in v4l-utils).
 
 So the best thing is probably to clean up the useful utilities and test tools,
 making them generic where possible, and kill off the rest.

Yes.  Good strategy.


 It could be interesting to hear which utilities from ivtv people actually use.

I'll poll the ivtv-users list later today.

My most used and useful:

1. ivtv-tune: I can't remember freq - channel mappings
2. ivtv-radio: There is no other CLI tool like it.

Others I've found useful at times:

3. ps-analyzer: Our version can decode MPEG Private ivtv/cx18 VBI
packets
4. ivtvtv: Part of it was useful to test the VIDIOC_G_ENC_INDEX ioctl()


Regards,
Andy

 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: Trouble building v4l-dvb


Thanks !

Indeed, the hack so that
make allyesmod
not select firedtv would be very helpful.

that way, it is also clear that firedtv will not work on debian-like 
distros.


Is there a way I cen help with that ?
I have no experience with Kconfig, so it would be a learning experience 
for me.



Mauro Carvalho Chehab wrote:

Em 17-09-2010 06:35, Jan Hoogenraad escreveu:

I see that the build now succeeded.

Ole: this is something that should have been fixed a long time ago, but isn't.
make allyesmod
should set only those divers that do actually compile.
Unfortunately, the FIREDTV driver has bugs for as long as I remember.


The problem are not related to bugs at firedtv driver, but, instead, due to the 
fact
that the provided firewire drivers and fw-core don't match the drivers that are 
shipped
with the distro kernel. In order words, at Ubuntu (and some other deb-based 
distros),
they're shipping the wrong include files at /lib/modules/`uname -r`/build/. So, 
there's
no way to build and run any module based on that wrong broken headers.

Up to a certain amount, the same happens with -alsa files on Ubuntu: although 
they
will compile [1], as the provided headers at /lib/modules/`uname -r`/build/ are 
from a different
version than the alsa modules provided with Ubuntu, the drivers that depend on -alsa will 
generally compile, but they generally won't load (and, if they load, they'll can cause

an OOPS and some other random troubles), as the symbol dependency will not 
match.

While a hack might be added at v4l-dvb -hg tree to make firedtv to compile 
against a broken
header, the firedtv driver will not work anyway.

The only real solution for it is to fix this issue at the distro.

Cheers,
Mauro

[1] The v4l-dvb is smart enough to adapt to -alsa API changes that are 
backported into
an older kernel, since it checks for the API symbols that changed, instead of 
just looking
for the kernel version. This works fine with all distros (like Fedora, RHEL, 
SUSE, OpenSUSE,
Mandriva, ...) where the include files for alsa are at the right place:
/lib/modules/`uname -r`/build/).




--
Jan Hoogenraad
Hoogenraad Interface Services
Postbus 2717
3500 GS Utrecht
--
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: RFC: Move ivtv utilities and ivtv X video extension to v4l-utils

2010-09-17 Thread Hans Verkuil

On Friday, September 17, 2010 12:59:09 Andy Walls wrote:
 On Fri, 2010-09-17 at 10:30 +0200, Hans Verkuil wrote:
  On Friday, September 17, 2010 00:58:45 Andy Walls wrote:
   Hi Hans and Hans,
   
   I'd like to move the source code maintained here:
   
   http://ivtvdriver.org/svn/
   
   to someplace where it may be less likely to suffer bit rot.
   I was hoping the v4l-utils git repo would be an appropriate place.
   
   Do either of you have any opinions on this?
  
  I agree with this, but it would require some work.
 
 OK.  But given your comments below, I'm going to change my execution
 strategy: move or port things incrementally, the most used/useful stuff
 first.
 
 Distribution packages and end users might not like that (Where did
 ivtv-tune go?) but I don't have a solid block of time to do things all
 in one go.

Distros should always (I hope) distribute v4l-utils these days, so together
with the remaining ivtv-utils the end-user still has a full set :-)

There is nothing to be done about this, and it is quite right that you tackle
this one utility at a time.

 
 
  xf86-video-ivtv really belongs at freedesktop.org as part of the X video 
  drivers.
  Nobody ever made the effort to integrate it there, but it would be the right
  thing to do.
 
 OK.  That's going to be low on my list then.  Given my current
 availability, that might end up looking like a dump and run on
 freedesktop.org folks.  That wouldn't be good for anyone.  I suppose I
 should get Ian Armstrong's input on this particular item.

You should certainly do that. But I don't expect this X driver to change
much. And with a bit of luck X API changes might be done for you if this
driver is on freedesktop.org.

 
 
  ivtvtv is more a private test application I made to test the MPEG 
  encoder/decoder
  API. Either this has to be turned into a more full-fledged application for 
  the
  PVR-350 and then it definitely might be a good candidate for inclusion in
  v4l-utils, or it stays here, or I can host it on my website as a simple tar
  archive.
 
 Ok, that one will stay on ivtvdriver.org until it becomes better or
 overcome by time.
 
 
  Looking that ivtv itself: in utils we have ivtv-radio, ivtvplay, 
  ivtv-mpegindex,
  ivtv-tune and cx25840ctl.
  
  ivtv-radio is a good candidate for v4l-utils, but it would be really nice 
  if it
  could be made more general. E.g. v4l2-radio.
 
 Yes.  There is not other application like it.  I also think that a
 v4l2-radio would be a good simple candidate for exercising some of the
 Media Controller API:
 
 1. Does this device have a radio?
 2. What is the radio control node?
 3. Does it have an associated ALSA card? What is the ALSA PCM node?
 4. Does it have a V4L2 PCM node?

And what would be also great is if it could handle RDS data. We still need a
good test tool for that...

 
 
  Ditto for ivtv-tune (although merging this functionality into v4l2-ctl is 
  also
  an interesting option).
 
 Yes.  The only reason I use ivtv-tune is that v4l2-ctl requires me to
 know my analog channel frequencies by number just to change the
 channel. :(
 
 Given that, I use ivtv-tune a lot.
 
 Merging it's functionality into v4l2-ctl seems like the way to go.  I'd
 like to do it in such a way that a user preferences file isn't saved
 though.

I frankly always intended to add this functionality to v4l2-ctl, but I never
got around to doing that. The frequency tables are already in v4l-utils.

 
 
  cx25840ctl should really be integrated into v4l2-dbg.
 
 Hmmm.  That would be an oddly specific addition to v4l2-dbg.  Given that
 we have device nodes on subdev's coming soon, with subdev controls,
 maybe this is obsolete?

Actually, similar functionality already exists in v4l2-dbg for some devices.

The purpose of cx25840ctl is to set/get registers using symbolic names, so that
has nothing to do with subdev controls (those are definitely not meant for
debugging, instead their purpose is to provide more fine-grained control over
the subdev).
 
 Anyway, I never use it.  Which begs the question: If I don't use it, who
 does?

I never used it either. Mainly because I find the symbolic names useless since
all datasheets are always organized around the register address and not the 
name.
So if I have to use the name then I am forever searching like mad in the
datasheet. I much prefer a raw register address with a useful comment over a
symbolic name.

Looking at v4l2-dbg I would say that it should be easy to add at least the
symbolic register names to that tool. And then we can kill cx25840ctl.

 
 
  ivtv-mpegindex isn't ivtv specific and can go to contrib/test.
  
  ivtvplay I'm not sure about. There is a lot of overlap between ivtvplay and 
  ivtvtv.
 
 
 
  Regarding the test utilities: some of these can go to contrib/test, some
  that are really ivtv specific can go to contrib/ivtv. And some should 
  perhaps
  just die.
 
 Thanks for the insight on where to put things.
 
 I agree, some things should just die.

Re: Remaining BKL users, what to do

2010-09-17 Thread Christoph Hellwig

On Fri, Sep 17, 2010 at 12:45:41PM +0200, Arnd Bergmann wrote:
 ncpfs: replace BKL with lock_super

Err, no.  lock_super is just as much on it's way out as the BKL.  We've
managed to move it down from the VFS into a few remaining filesystems
and now need to get rid of those users.  Please don't add any new ones.

--
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: Remaining BKL users, what to do

On Friday 17 September 2010, Christoph Hellwig wrote:
 
 On Fri, Sep 17, 2010 at 12:45:41PM +0200, Arnd Bergmann wrote:
  ncpfs: replace BKL with lock_super
 
 Err, no.  lock_super is just as much on it's way out as the BKL.  We've
 managed to move it down from the VFS into a few remaining filesystems
 and now need to get rid of those users.  Please don't add any new ones.

Ok. I guess that's also a NAK for my the isofs patch I posted yesterday
then. Do you have any suggestions for an alternative approach?

Arnd
--
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: Remaining BKL users, what to do

2010-09-17 Thread Christoph Hellwig

On Fri, Sep 17, 2010 at 03:50:49PM +0200, Arnd Bergmann wrote:
 On Friday 17 September 2010, Christoph Hellwig wrote:
  
  On Fri, Sep 17, 2010 at 12:45:41PM +0200, Arnd Bergmann wrote:
   ncpfs: replace BKL with lock_super
  
  Err, no.  lock_super is just as much on it's way out as the BKL.  We've
  managed to move it down from the VFS into a few remaining filesystems
  and now need to get rid of those users.  Please don't add any new ones.
 
 Ok. I guess that's also a NAK for my the isofs patch I posted yesterday
 then. Do you have any suggestions for an alternative approach?

Just add a per-sb mutex inside the filesystem.  Given that lock_super
isn't used by the VFS anymore that's actually equivalent.

--
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: Trouble building v4l-dvb

Em 17-09-2010 08:08, Jan Hoogenraad escreveu:
 Thanks !
 
 Indeed, the hack so that
 make allyesmod
 not select firedtv would be very helpful.
 
 that way, it is also clear that firedtv will not work on debian-like distros.
 
 Is there a way I cen help with that ?
 I have no experience with Kconfig, so it would be a learning experience for 
 me.

You don't need to look at Kconfig. there are some scripts under v4l/scripts
that will deal with Kconfig dependencies. They are meant to identify kernel 
versions
and features. Those scripts are, mainly:

v4l/scripts/make_config_compat.pl - Checks for backported features, 
enabling workarounds at v4l/compat.h
v4l/scripts/make_kconfig.pl - Generates a .config file that will 
compile with an older kernel
v4l/scripts/make_makefile.pl - Generates a Makefile that will 
build/install/remove the kernel modules

Basically, you need to add some intelligence to one of the above scripts 
(likely make_kconfig)
to identify that the kernel has broken firewire headers, and disable its 
compilation, printing
a warning message to the user.

You'll find a logic at make_makefile.pl to detect an Ubuntu broken kernel that 
stores the in-kernel
drivers at the wrong install place. I'm not sure if all Ubuntu kernels/versions 
do the same
thing, nor if this is broken for all distro-variants.

Perhaps you may use this logic at make_kconfig.pl. The logic assumes that 
broken distros
are the ones that store V4L/DVB files at 
/lib/modules/\$(KERNELRELEASE)/ubuntu/media. 
This is probably not true for all broken distros (as Ubuntu clones - and maybe 
Debian - could
have the same problem, but storing the media files on a different place), so 
you may
need to generalize that logic, in order to cover any other distros that don't 
compile
firewire.

While you're there, the better is to also disable CONFIG_ALSA on Ubuntu, as the 
drivers
won't work anyway.

As we don't want to have complains from users about why driver foo is not 
compiling for me,
IMO, it should be printing a warning message saying that compilation of 
ALSA/FIREWIRE drivers with
that specific kernel version is not possible, due to the back packaging of 
kernel headers,
recommending to the user to get a vanilla upstream kernel, if he needs one of 
the disabled
drivers.

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

[PATCH -hg] Warn user that driver is backported and might not work as expected

Since the migration to -git, less developers are using the -hg tree. Also, some
changes are happening upstream that would require much more than just compiling
the tree with an older version, to be sure that the backport won't break 
anything,
like the removal of BKL.

As normal users might not be aware of those issues, and bug reports may be sent
based on a backported tree, add some messages to warn about the usage of a
backported experimental (unsupported) tree.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff -r 60edc4bd92b7 linux/drivers/media/dvb/dvb-core/dvbdev.c
--- a/linux/drivers/media/dvb/dvb-core/dvbdev.c Sun Jun 27 17:17:06 2010 -0300
+++ b/linux/drivers/media/dvb/dvb-core/dvbdev.c Fri Sep 17 11:49:02 2010 -0300
@@ -521,6 +521,12 @@
 #elif LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 31)
dvb_class-devnode = dvb_devnode;
 #endif
+#ifdef EXPERIMENTAL_TREE
+   printk(KERN_ERR WARNING: You're using an experimental version of the 
DVB stack. As the driver\n
+is backported to an older kernel, it doesn't 
offer enough quality for\n
+its usage in production.\n
+Use it with care.\n);
+#endif
return 0;
 
 error:
diff -r 60edc4bd92b7 linux/drivers/media/video/v4l2-dev.c
--- a/linux/drivers/media/video/v4l2-dev.c  Sun Jun 27 17:17:06 2010 -0300
+++ b/linux/drivers/media/video/v4l2-dev.c  Fri Sep 17 11:49:02 2010 -0300
@@ -686,6 +686,12 @@
int ret;
 
printk(KERN_INFO Linux video capture interface: v2.00\n);
+#ifdef EXPERIMENTAL_TREE
+   printk(KERN_ERR WARNING: You're using an experimental version of the 
V4L stack. As the driver\n
+is backported to an older kernel, it doesn't 
offer enough quality for\n
+its usage in production.\n
+Use it with care.\n);
+#endif
ret = register_chrdev_region(dev, VIDEO_NUM_DEVICES, VIDEO_NAME);
if (ret  0) {
printk(KERN_WARNING videodev: unable to get major %d\n,
diff -r 60edc4bd92b7 v4l/compat.h
--- a/v4l/compat.h  Sun Jun 27 17:17:06 2010 -0300
+++ b/v4l/compat.h  Fri Sep 17 11:49:02 2010 -0300
@@ -14,6 +14,8 @@
 #define INIT_DELAYED_WORK(a,b,c)   INIT_WORK(a,b,c)
 #endif
 
+#define EXPERIMENTAL_TREE
+
 #if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 35)
 #define usb_buffer_alloc(dev, size, mem_flags, dma) usb_alloc_coherent(dev, 
size, mem_flags, dma)
 #define usb_buffer_free(dev, size, addr, dma) usb_free_coherent(dev, size, 
addr, dma)
diff -r 60edc4bd92b7 v4l/scripts/make_kconfig.pl
--- a/v4l/scripts/make_kconfig.pl   Sun Jun 27 17:17:06 2010 -0300
+++ b/v4l/scripts/make_kconfig.pl   Fri Sep 17 11:49:02 2010 -0300
@@ -671,4 +671,13 @@
 
 EOF2
}
+print  EOF3;
+WARNING: This is the V4L/DVB backport tree, with experimental drivers
+backported to run on legacy kernels from the development tree at:
+   http://git.linuxtv.org/media-tree.git.
+It is generally safe to use it for testing a new driver or
+feature, but its usage on production environments is risky.
+Don't use it at production. You've being warned.
+EOF3
+   sleep 5;
 }
--
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: Remaining BKL users, what to do

On Friday 17 September 2010, Christoph Hellwig wrote:
 
 Just add a per-sb mutex inside the filesystem.  Given that lock_super
 isn't used by the VFS anymore that's actually equivalent.

Ok, thanks for the hint. I'll fix that for isofs.

Arnd
--
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: Trouble building v4l-dvb

2010-09-17 Thread Devin Heitmueller

On Fri, Sep 17, 2010 at 10:49 AM, Mauro Carvalho Chehab
mauroche...@gmail.com wrote:
 While you're there, the better is to also disable CONFIG_ALSA on Ubuntu, as 
 the drivers
 won't work anyway.

Note: while building ALSA modules did fail in some versions for
Ubuntu, it has been over a years since I've seen that problem.
Blindly disabling ALSA for all Ubuntu users would be a huge regression
for users.

 As we don't want to have complains from users about why driver foo is not 
 compiling for me,
 IMO, it should be printing a warning message saying that compilation of 
 ALSA/FIREWIRE drivers with
 that specific kernel version is not possible, due to the back packaging of 
 kernel headers,
 recommending to the user to get a vanilla upstream kernel, if he needs one of 
 the disabled
 drivers.

I agree with this premise for firedtv, but see my comment above about ALSA.

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: Trouble building v4l-dvb

Em 17-09-2010 12:00, Devin Heitmueller escreveu:
 On Fri, Sep 17, 2010 at 10:49 AM, Mauro Carvalho Chehab
 mauroche...@gmail.com wrote:
 While you're there, the better is to also disable CONFIG_ALSA on Ubuntu, as 
 the drivers
 won't work anyway.
 
 Note: while building ALSA modules did fail in some versions for
 Ubuntu, it has been over a years since I've seen that problem.
 Blindly disabling ALSA for all Ubuntu users would be a huge regression
 for users.

Yeah, blindly disabling it, if some versions work is not the right thing to do.

I'm not an Ubuntu user, so, I'm not sure when it was fixed. Still, from time to 
time,
people complain to me about this problem with some Ubuntu versions. The last 
complains I
heard were with some netbook versions of Ubuntu-based distros.

If there's a way to check what versions have broken alsa headers, then the 
checker should
just disable to the broken ones. Otherwise, the better way seems to just print 
a warning
message that ALSA might not be working, but keep it enabled.

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: Trouble building v4l-dvb

Really, the only thing I would do is disable the ones that break
compilation. this is ONLY firedtv.

I doubt if anyone would read the messages during compilation.
I'll have a look at the logic.

Mauro Carvalho Chehab wrote:

Em 17-09-2010 08:08, Jan Hoogenraad escreveu:

Thanks !

Indeed, the hack so that
make allyesmod
not select firedtv would be very helpful.

that way, it is also clear that firedtv will not work on debian-like distros.

Is there a way I cen help with that ?
I have no experience with Kconfig, so it would be a learning experience for me.

You don't need to look at Kconfig. there are some scripts under v4l/scripts
that will deal with Kconfig dependencies. They are meant to identify kernel
versions
and features. Those scripts are, mainly:

v4l/scripts/make_config_compat.pl - Checks for backported features,
enabling workarounds at v4l/compat.h
v4l/scripts/make_kconfig.pl - Generates a .config file that will
compile with an older kernel
v4l/scripts/make_makefile.pl - Generates a Makefile that will
build/install/remove the kernel modules

Basically, you need to add some intelligence to one of the above scripts
(likely make_kconfig)
to identify that the kernel has broken firewire headers, and disable its
compilation, printing
a warning message to the user.

You'll find a logic at make_makefile.pl to detect an Ubuntu broken kernel that
stores the in-kernel
drivers at the wrong install place. I'm not sure if all Ubuntu kernels/versions
do the same
thing, nor if this is broken for all distro-variants.

Perhaps you may use this logic at make_kconfig.pl. The logic assumes that
broken distros
are the ones that store V4L/DVB files at /lib/modules/\$(KERNELRELEASE)/ubuntu/media.
This is probably not true for all broken distros (as Ubuntu clones - and maybe Debian - could

have the same problem, but storing the media files on a different place), so
you may
need to generalize that logic, in order to cover any other distros that don't
compile
firewire.

While you're there, the better is to also disable CONFIG_ALSA on Ubuntu, as the
drivers
won't work anyway.

As we don't want to have complains from users about why driver foo is not compiling
for me,
IMO, it should be printing a warning message saying that compilation of
ALSA/FIREWIRE drivers with
that specific kernel version is not possible, due to the back packaging of
kernel headers,
recommending to the user to get a vanilla upstream kernel, if he needs one of
the disabled
drivers.

Cheers,
Mauro

--
Jan Hoogenraad
Hoogenraad Interface Services
Postbus 2717
3500 GS Utrecht
--
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

anyone using g-webcam? (uvc gadget driver)

2010-09-17 Thread Christopher Friedt

Is anyone else on the list using / experimenting with Laurent's UVC
Gadget driver?
--
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

[PATCH -next] staging: cx25821 and go7007 depend on IR_CORE

2010-09-17 Thread Randy Dunlap

From: Randy Dunlap randy.dun...@oracle.com

Fix build errors in cx25821 and go7007.
They both use IR functions, so they should depend on IR_CORE.
(It's not safe to select VIDEO_IR when IR_CORE is not enabled.)

(.text+0x39065a): undefined reference to `ir_core_debug'
(.text+0x3906a4): undefined reference to `ir_core_debug'
ir-functions.c:(.text+0x39080b): undefined reference to `ir_core_debug'
(.text+0x390893): undefined reference to `ir_g_keycode_from_table'
(.text+0x390942): undefined reference to `ir_core_debug'
(.text+0x3909f5): undefined reference to `ir_core_debug'
(.text+0x390a3a): undefined reference to `ir_core_debug'
(.text+0x390ab1): undefined reference to `ir_core_debug'
(.text+0x390b36): undefined reference to `ir_core_debug'

Signed-off-by: Randy Dunlap randy.dun...@oracle.com
Cc: de...@driverdev.osuosl.org
---
 drivers/staging/cx25821/Kconfig |2 +-
 drivers/staging/go7007/Kconfig  |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

(originally sent to lkml, linux-next, and staging mailing lists;
now resending to linux-media)


--- linux-next-20100914.orig/drivers/staging/cx25821/Kconfig
+++ linux-next-20100914/drivers/staging/cx25821/Kconfig
@@ -1,6 +1,6 @@
 config VIDEO_CX25821
tristate Conexant cx25821 support
-   depends on DVB_CORE  VIDEO_DEV  PCI  I2C  INPUT
+   depends on DVB_CORE  VIDEO_DEV  PCI  I2C  INPUT  IR_CORE
select I2C_ALGOBIT
select VIDEO_BTCX
select VIDEO_TVEEPROM
--- linux-next-20100914.orig/drivers/staging/go7007/Kconfig
+++ linux-next-20100914/drivers/staging/go7007/Kconfig
@@ -1,6 +1,6 @@
 config VIDEO_GO7007
tristate WIS GO7007 MPEG encoder support
-   depends on VIDEO_DEV  PCI  I2C  INPUT
+   depends on VIDEO_DEV  PCI  I2C  INPUT  IR_CORE
depends on SND
select VIDEOBUF_DMA_SG
select VIDEO_IR
--
To unsubscribe from this list: send the line unsubscribe linux-next in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
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: Trouble building v4l-dvb

2010-09-17 Thread Ole W. Saastad

Thanks for all help so far.

I managed to figure out the firetv problem as soon as I discovered
the .myconfig file.

Including the drivers from Sandberg, for the rtl2832 chip and adding
some lines to Makefile, Kconfig and .myconfig it compiles and install.
Modules load and Me-TV starts, quality is poor with the small antenna.

However, there is no audio. Not even for the DAB radio channels.

Maybe this is Me-TV problem?

The version supplied with Easy Peasy Ubuntu 9.10 is old,  0.7.16.


Regards,
Ole W. Saastad






fr., 17.09.2010 kl. 11.35 +0200, skrev Jan Hoogenraad:
 I see that the build now succeeded.
 
 Ole: this is something that should have been fixed a long time ago, but 
 isn't.
 make allyesmod
 should set only those divers that do actually compile.
 Unfortunately, the FIREDTV driver has bugs for as long as I remember.
 
 In the 4vl directory, edit .config
 and change the line
 CONFIG_DVB_FIREDTV=m
 into
 CONFIG_DVB_FIREDTV=n
 
 It should compile fine then.
 
 Jan Hoogenraad wrote:
  Douglas;
  
  Could you please check your last putback ?
  
  the build is broken.
  
  see:
  http://www.xs4all.nl/~hverkuil/logs/Wednesday.log
  
  and the mail
  [cron job] v4l-dvb daily build 2.6.26 and up: ERRORS
  
  Yours,
  Jan
  
  Ole W. Saastad wrote:
  Trouble building v4l-dvb
  Asus eee netbook, running EasyPeasy.
 
  o...@ole-eee:~$ cat /etc/issue
  Ubuntu 9.04 \n \l
  o...@ole-eee:~$ uname -a
  Linux ole-eee 2.6.30.5-ep0 #10 SMP PREEMPT Thu Aug 27 19:45:06 CEST 2009
  i686 GNU/Linux
 
  Rationale for building from source: I have bought a USB TV with mpg4 
  support from Sandberg, Mini DVB-T
  dongle. I also received an archive with driver routines for this from
  Sandberg. These should be copied into the v4l-dvd three and just rebuild
  with make.
  I have installed the kernel headers:
  apt-get install mercurial linux-headers-$(uname -r) build-essential
 
  Then I have downloaded the v4l-dvb source (assuming this is a stable
  release): hg clone http://linuxtv.org/hg/v4l-dvb
 
 
  I wanted to try to build before applying the patch from Sandberg. 
  Issuing make yield the following :
 
  LIRC: Requires at least kernel 2.6.36
  IR_LIRC_CODEC: Requires at least kernel 2.6.36
  IR_IMON: Requires at least kernel 2.6.36
  IR_MCEUSB: Requires at least kernel 2.6.36
  VIDEOBUF_DMA_CONTIG: Requires at least kernel 2.6.31
  V4L2_MEM2MEM_DEV: Requires at least kernel 2.6.33
  and a few more lines
 
  Ignoring these and just continuing :
 
CC [M]  /home/ole/work/v4l-dvb/v4l/firedtv-dvb.o
CC [M]  /home/ole/work/v4l-dvb/v4l/firedtv-fe.o
CC [M]  /home/ole/work/v4l-dvb/v4l/firedtv-1394.o
  /home/ole/work/v4l-dvb/v4l/firedtv-1394.c:22:17: error: dma.h: No such
  file or directory
  /home/ole/work/v4l-dvb/v4l/firedtv-1394.c:23:21: error: csr1212.h: No
  such file or directory
  /home/ole/work/v4l-dvb/v4l/firedtv-1394.c:24:23: error: highlevel.h: No
  such file or directory
  and many many more similar errors.
 
  After some time the make bails out.
 
 
  I assume this have some connection with the 9.04 being too old.
 
  Hints ?
 
 
 
  Regards,
  Ole W. Saastad
 
 
 
 
  -- 
  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
 
  
  
 
 


--
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

rtl2832 chip driver


Hi Ole:

Try vlc or keffeins, and see if they have the same audio problem.
Also: try playing a normal sound mp3 file with them.
me-tv and rtl2832 havce some problems:
https://bugs.launchpad.net/ubuntu/+source/me-tv/+bug/478379

Thanks for the Sandberg link.
At:
http://www.sandberg.it/support/product.aspx?id=133-59
I found Realtek stuff that looks very familiar to the RTL2831 stuff I 
put into another HG branch:

http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2

This is again code where the frontend and backend have not been 
separated. Seems realtek has their branch kind of working, based on 
their windows approach.


Antti has set up a new version from scratch at:
http://linuxtv.org/hg/~anttip/rtl2831u/



Ole W. Saastad wrote:

Thanks for all help so far.

I managed to figure out the firetv problem as soon as I discovered
the .myconfig file.

Including the drivers from Sandberg, for the rtl2832 chip and adding
some lines to Makefile, Kconfig and .myconfig it compiles and install.
Modules load and Me-TV starts, quality is poor with the small antenna.

However, there is no audio. Not even for the DAB radio channels.

Maybe this is Me-TV problem?

The version supplied with Easy Peasy Ubuntu 9.10 is old,  0.7.16.


Regards,
Ole W. Saastad




--
Jan Hoogenraad
Hoogenraad Interface Services
Postbus 2717
3500 GS Utrecht
--
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: Remaining BKL users, what to do