Re: [PATCH 1/2] bttv: Move I2C IR initialization
Hi,
Jean Delvare wrote:
Move I2C IR initialization from just after I2C bus setup to right
before non-I2C IR initialization. This avoids the case where an I2C IR
device is blocking audio support (at least the PV951 suffers from
this). It is also more logical to group IR support together,
regardless of the connectivity.
Something could have gone wrong because this patch and the patch
at http://linuxtv.org/hg/v4l-dvb/rev/659e08177aa3 has the
#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30)
and
#endif
pair at different places. The current result is the following compiler
warning:
bttv-i2c.c: In function 'init_bttv_i2c':
bttv-i2c.c:440: warning: control reaches end of non-void function
Regard,
Márton Németh
This fixes bug #15184:
http://bugzilla.kernel.org/show_bug.cgi?id=15184
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
As this fixes a regression, I suggest pushing to Linus quickly. This is
a candidate for 2.6.32-stable too.
linux/drivers/media/video/bt8xx/bttv-driver.c |1 +
linux/drivers/media/video/bt8xx/bttv-i2c.c| 10 +++---
linux/drivers/media/video/bt8xx/bttvp.h |1 +
3 files changed, 9 insertions(+), 3 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/bt8xx/bttv-i2c.c 2009-12-11
09:47:47.0 +0100
+++ v4l-dvb/linux/drivers/media/video/bt8xx/bttv-i2c.c2010-02-16
18:14:34.0 +0100
@@ -409,9 +409,14 @@ int __devinit init_bttv_i2c(struct bttv
}
if (0 == btv-i2c_rc i2c_scan)
do_i2c_scan(btv-c.v4l2_dev.name, btv-i2c_client);
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30)
- /* Instantiate the IR receiver device, if present */
+ return btv-i2c_rc;
+}
+
+/* Instantiate the I2C IR receiver device, if present */
+void __devinit init_bttv_i2c_ir(struct bttv *btv)
+{
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30)
if (0 == btv-i2c_rc) {
struct i2c_board_info info;
/* The external IR receiver is at i2c address 0x34 (0x35 for
@@ -432,7 +437,6 @@ int __devinit init_bttv_i2c(struct bttv
i2c_new_probed_device(btv-c.i2c_adap, info, addr_list);
}
#endif
- return btv-i2c_rc;
}
int __devexit fini_bttv_i2c(struct bttv *btv)
--- v4l-dvb.orig/linux/drivers/media/video/bt8xx/bttvp.h 2009-04-06
10:10:24.0 +0200
+++ v4l-dvb/linux/drivers/media/video/bt8xx/bttvp.h 2010-02-16
18:13:31.0 +0100
@@ -281,6 +281,7 @@ extern unsigned int bttv_debug;
extern unsigned int bttv_gpio;
extern void bttv_gpio_tracking(struct bttv *btv, char *comment);
extern int init_bttv_i2c(struct bttv *btv);
+extern void init_bttv_i2c_ir(struct bttv *btv);
extern int fini_bttv_i2c(struct bttv *btv);
#define bttv_printk if (bttv_verbose) printk
--- v4l-dvb.orig/linux/drivers/media/video/bt8xx/bttv-driver.c
2009-12-11 09:47:47.0 +0100
+++ v4l-dvb/linux/drivers/media/video/bt8xx/bttv-driver.c 2010-02-16
18:13:31.0 +0100
@@ -4498,6 +4498,7 @@ static int __devinit bttv_probe(struct p
request_modules(btv);
}
+ init_bttv_i2c_ir(btv);
bttv_input_init(btv);
/* everything is fine */
--
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] bttv: fix compiler warning before kernel 2.6.30
From: Márton Németh nm...@freemail.hu
Fix the following compiler warnings when compiling before Linux
kernel version 2.6.30:
bttv-i2c.c: In function 'init_bttv_i2c':
bttv-i2c.c:440: warning: control reaches end of non-void function
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 41c5482f2dac linux/drivers/media/video/bt8xx/bttv-i2c.c
--- a/linux/drivers/media/video/bt8xx/bttv-i2c.cThu Mar 04 02:49:46
2010 -0300
+++ b/linux/drivers/media/video/bt8xx/bttv-i2c.cSat Mar 06 10:22:55
2010 +0100
@@ -409,7 +409,6 @@
}
if (0 == btv-i2c_rc i2c_scan)
do_i2c_scan(btv-c.v4l2_dev.name, btv-i2c_client);
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30)
return btv-i2c_rc;
}
@@ -417,6 +416,7 @@
/* Instantiate the I2C IR receiver device, if present */
void __devinit init_bttv_i2c_ir(struct bttv *btv)
{
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30)
if (0 == btv-i2c_rc) {
struct i2c_board_info info;
/* The external IR receiver is at i2c address 0x34 (0x35 for
--
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: [PATCH] bttv: fix compiler warning before kernel 2.6.30
On Sat, 06 Mar 2010 10:25:24 +0100, Németh Márton wrote:
From: Márton Németh nm...@freemail.hu
Fix the following compiler warnings when compiling before Linux
kernel version 2.6.30:
bttv-i2c.c: In function 'init_bttv_i2c':
bttv-i2c.c:440: warning: control reaches end of non-void function
Signed-off-by: Márton Németh nm...@freemail.hu
Good catch.
Acked-by: Jean Delvare kh...@linux-fr.org
Douglas, please apply quickly.
---
diff -r 41c5482f2dac linux/drivers/media/video/bt8xx/bttv-i2c.c
--- a/linux/drivers/media/video/bt8xx/bttv-i2c.c Thu Mar 04 02:49:46
2010 -0300
+++ b/linux/drivers/media/video/bt8xx/bttv-i2c.c Sat Mar 06 10:22:55
2010 +0100
@@ -409,7 +409,6 @@
}
if (0 == btv-i2c_rc i2c_scan)
do_i2c_scan(btv-c.v4l2_dev.name, btv-i2c_client);
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30)
return btv-i2c_rc;
}
@@ -417,6 +416,7 @@
/* Instantiate the I2C IR receiver device, if present */
void __devinit init_bttv_i2c_ir(struct bttv *btv)
{
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30)
if (0 == btv-i2c_rc) {
struct i2c_board_info info;
/* The external IR receiver is at i2c address 0x34 (0x35 for
--
Jean Delvare
--
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
why can't S2-3200 do APSK32 and APSK16?
seems like netup card can do apsk16+ apsk32 http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan-stv0900aac/rev/247404af8e56 what's the reason s2-3200 cannot do that modulation? I think s2-3200's hardware supports those modulations, is there a problem with the driver then? kind regards Newspaperman --- Newsy Paper newspaperman_germ...@yahoo.com schrieb am So, 19.7.2009: Von: Newsy Paper newspaperman_germ...@yahoo.com Betreff: can S2-3200 do APSK32 and APSK16? An: linux-media@vger.kernel.org Datum: Sonntag, 19. Juli, 2009 13:02 Uhr On 13e the italians use dvb2 modulation 16APSK. tp. 7 (11,334 GHz, pol. H, SR: 27500, FEC: 2/3) tp. 9 (11,373 GHz, pol. H, SR: 27500, FEC: 2/3) how to receive those channels with S2-3200? Is there a missing part in the driver for APSK? -- 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 __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.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: [PATCH] firedtv: add parameter to fake ca_system_ids in CA_INFO
Mauro Carvalho Chehab wrote:
Stefan Richter wrote:
The Digital Everywhere firmware have the shortcoming that ca_info_enq and
ca_info are not supported. This means that we can never retrieve the correct
ca_system_id to present in the CI message CA_INFO. Currently the driver uses
the application id retrieved using app_info_req and app_info, but this id
only match the correct ca_system_id as given in ca_info in some cases.
This patch adds a parameter to the driver in order for the user to override
what will be returned in the CA_INFO CI message. Up to four ca_system_ids can
be specified.
This is needed for users with CAMs that have different manufacturer id and
ca_system_id and that uses applications that take this into account, like
MythTV.
This seems an ugly workaround. The better seems to patch MythTV to accept a
different
CAM.
Ugly it is, for sure. Can't comment on application-level solutions; if
thats the proper layer at which to address this, then that would be
preferable of course.
+static int num_fake_ca_system_ids;
...
+for (i = 0; i num_fake_ca_system_ids; i++) {
+app_info[4 + i * 2] =
+(fake_ca_system_ids[i] 8) 0xff;
...
NAK. If someone put an arbitrary high value for num_fake_ca_system_id's, it
will write outside
the app_info array space, as the num_fake_ca_system_ids is not validated
against the size
of app_info.
That's what I thought at first look at the patch too, but then I noticed
that inlcude/linux/moduleparam.h and kernel/params.c properly track
kparam_arry.max = ARRAY_SIZE(array).
http://lxr.linux.no/#linux+v2.6.33/include/linux/moduleparam.h#L62
http://lxr.linux.no/#linux+v2.6.33/include/linux/moduleparam.h#L213
http://lxr.linux.no/#linux+v2.6.33/kernel/params.c#L351
http://lxr.linux.no/#linux+v2.6.33/kernel/params.c#L296
So no danger here.
Also, it makes no sense a negative value for this parameter.
I already posted an updated version of the patch which correctly defines
num_fake_ca_system_ids as an unsigned long.
--
Stefan Richter
-=-==-=- --== --==-
http://arcgraph.de/sr/
--
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: [PATCH] firedtv: add parameter to fake ca_system_ids in CA_INFO
Stefan Richter wrote: I already posted an updated version of the patch which correctly defines num_fake_ca_system_ids as an unsigned long. err, unsigned int of course, as http://patchwork.kernel.org/patch/82912/. -- Stefan Richter -=-==-=- --== --==- http://arcgraph.de/sr/ -- 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: [git:v4l-dvb/master] NFS: Fix a bug in nfs_fscache_release_page()
On Sat, 2010-03-06 at 15:26 +0100, Patch from Trond Myklebust wrote:
From: Trond Myklebust trond.mykleb...@netapp.com
Not having an fscache cookie is perfectly valid if the user didn't mount
with the fscache option.
This patch fixes http://bugzilla.kernel.org/show_bug.cgi?id=15234
Signed-off-by: Trond Myklebust trond.mykleb...@netapp.com
Acked-by: David Howells dhowe...@redhat.com
Cc: sta...@kernel.org
fs/nfs/fscache.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
---
http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=2c1740098c708b465e87637b237feb2fd98f129a
diff --git a/fs/nfs/fscache.c b/fs/nfs/fscache.c
index fa58800..237874f 100644
--- a/fs/nfs/fscache.c
+++ b/fs/nfs/fscache.c
@@ -354,12 +354,11 @@ void nfs_fscache_reset_inode_cookie(struct inode *inode)
*/
int nfs_fscache_release_page(struct page *page, gfp_t gfp)
{
- struct nfs_inode *nfsi = NFS_I(page-mapping-host);
- struct fscache_cookie *cookie = nfsi-fscache;
-
- BUG_ON(!cookie);
-
if (PageFsCache(page)) {
+ struct nfs_inode *nfsi = NFS_I(page-mapping-host);
+ struct fscache_cookie *cookie = nfsi-fscache;
+
+ BUG_ON(!cookie);
dfprintk(FSCACHE, NFS: fscache releasepage (0x%p/0x%p/0x%p)\n,
cookie, page, nfsi);
Err Why are we receiving this email? This changeset is already
committed upstream in Linus' tree and has nothing to do with V4L/DVB.
Trond
--
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: [PATCH] firedtv: add parameter to fake ca_system_ids in CA_INFO
Stefan Richter wrote:
Mauro Carvalho Chehab wrote:
Stefan Richter wrote:
The Digital Everywhere firmware have the shortcoming that ca_info_enq and
ca_info are not supported. This means that we can never retrieve the correct
ca_system_id to present in the CI message CA_INFO. Currently the driver uses
the application id retrieved using app_info_req and app_info, but this id
only match the correct ca_system_id as given in ca_info in some cases.
This patch adds a parameter to the driver in order for the user to override
what will be returned in the CA_INFO CI message. Up to four ca_system_ids
can
be specified.
This is needed for users with CAMs that have different manufacturer id and
ca_system_id and that uses applications that take this into account, like
MythTV.
This seems an ugly workaround. The better seems to patch MythTV to accept a
different
CAM.
Ugly it is, for sure. Can't comment on application-level solutions; if
thats the proper layer at which to address this, then that would be
preferable of course.
From the report, this seems to be a requirement at application level. So, the
fix should
be there.
Henrik, is there any reason why not patching MythTV?
+static int num_fake_ca_system_ids;
...
+ for (i = 0; i num_fake_ca_system_ids; i++) {
+ app_info[4 + i * 2] =
+ (fake_ca_system_ids[i] 8) 0xff;
...
NAK. If someone put an arbitrary high value for num_fake_ca_system_id's, it
will write outside
the app_info array space, as the num_fake_ca_system_ids is not validated
against the size
of app_info.
That's what I thought at first look at the patch too, but then I noticed
that inlcude/linux/moduleparam.h and kernel/params.c properly track
kparam_arry.max = ARRAY_SIZE(array).
http://lxr.linux.no/#linux+v2.6.33/include/linux/moduleparam.h#L62
http://lxr.linux.no/#linux+v2.6.33/include/linux/moduleparam.h#L213
http://lxr.linux.no/#linux+v2.6.33/kernel/params.c#L351
http://lxr.linux.no/#linux+v2.6.33/kernel/params.c#L296
So no danger here.
Also, it makes no sense a negative value for this parameter.
I already posted an updated version of the patch which correctly defines
num_fake_ca_system_ids as an unsigned long.
Ok. As app_info is char [256] (from ca_info::msg field), and kernel module
avoids
the size of the array to be bigger than 4 (the sizeof the array), that's should
be ok.
--
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: [PATCH] firedtv: add parameter to fake ca_system_ids in CA_INFO
Stefan Richter wrote: Stefan Richter wrote: I already posted an updated version of the patch which correctly defines num_fake_ca_system_ids as an unsigned long. err, unsigned int of course, as http://patchwork.kernel.org/patch/82912/. Ah, ok. This is one of the things that Patchwork doesn't handle nice: it doesn't show any hint that a patch might be superseded by a newer one. -- 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: [git:v4l-dvb/master] futex_lock_pi() key refcnt fix
Why is linuxtv sending crap like this? -- 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: [git:v4l-dvb/master] futex_lock_pi() key refcnt fix
Peter Zijlstra wrote: Why is linuxtv sending crap like this? -- 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 Sorry! There's an post update hook script that sends an email to the patch author/SOB's for the new patches added at v4l-dvb git tree. Unfortunately, the git mailbomb script is doing something wrong: it is handling badly all the upstream patches that were merged back on it. I'll need to figure out a way for it to exclude patches that got merged from the normal posts. For now, I've stopped the exim process at the server. -- 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
Tevii S464 PCI DVB-S/S2 tuner
Hello Matthias, I'd like to ask you, or anyone else who is also familiar with the new TeVii's and their Linux support, about the new S464 tuner. I have an excellent experience with old S460, it's the most stable DVB-S2 card I ever had. I want to build a 5 card sat. back-end (most PCI slots I found on any motherboard) and I'm looking for other cx88 alternatives from TeVii. V4L sources suggest the new S464 is basically the same HW, except for the new M88DS3000 demodulator. I think you're probably even better person to ask about their performance in Linux. Does S464 work without issues (voltage, 22kHz, DiSEqC, signal monitoring, S2)? Old S460 never froze on me, it's 100% stable, quick to lock, no reboots required and the sensitivity was OK - you see why I'm excited about the new S464. Can you tell me what's new and better about S464? Is it ready for prime time in Linux? BTW, I must comment on your company's attitude towards Linux - proper driver sources, official support, that's not what we're used to from other manufacturers. Well done! Best wishes, -- David Kubicek -- 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: [git:v4l-dvb/master] sysfs: sysfs_sd_setattr set iattrs unconditionally
On Sat, Mar 06, 2010 at 05:06:55PM +0100, Jean Delvare wrote: Err, what's happening here? I can't see any chmod call in any V4L or DVB driver, so why would this patch matter there? And we will get this fix through Linus' tree anyway, so why bother at all? I'm puzzled. I'm confused too, I got a bunch of these, for patches that seem to be in Linus's tree already. Did a script go haywire? greg k-h -- 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: [git:v4l-dvb/master] sysfs: sysfs_sd_setattr set iattrs unconditionally
Greg KH wrote: On Sat, Mar 06, 2010 at 05:06:55PM +0100, Jean Delvare wrote: Err, what's happening here? I can't see any chmod call in any V4L or DVB driver, so why would this patch matter there? And we will get this fix through Linus' tree anyway, so why bother at all? I'm puzzled. I'm confused too, I got a bunch of these, for patches that seem to be in Linus's tree already. Did a script go haywire? Sorry! There's an post receive hook script that sends an email to the patch author/SOB's for the new patches added at v4l-dvb git tree. Unfortunately, the git mailbomb script did something wrong: it handled badly all the upstream patches that were merged back on git. I'll need to figure out a way for it to exclude patches that got merged from the normal posts. For now, I've disabled it and removed the patches that were on the queue. -- 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: [linuxtv-commits] [git:v4l-dvb/master] ecryptfs: don't ignore return value from lock_rename
Andrew,
Patch from Erez Zadok wrote:
From: Erez Zadok e...@cs.sunysb.edu
Signed-off-by: Erez Zadok e...@cs.sunysb.edu
Cc: Dustin Kirkland kirkl...@canonical.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Al Viro v...@zeniv.linux.org.uk
Signed-off-by: Tyler Hicks tyhi...@linux.vnet.ibm.com
Sorry for all those crappy messages!
Please discard all messages you received today from linuxtv-commits. Due to an
error at
the post-receive hook I wrote, linuxtv server tried to send a message for every
commit
from 2.6.32-rc5 to 2.6.33, when I merged back from your tree.
After noticing the problem, I've stopped the exim and dropped all such messages
from
the server queue, but several messages were already sent.
I've disabled the hook for now, until I find a way to properly handle merged
patches on it.
Sorry for the inconvenience.
Mauro.
fs/ecryptfs/inode.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
---
http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=0d132f7364694da8f7cafd49e2fc2721b73e96e4
diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
index 5726d7a..764dc77 100644
--- a/fs/ecryptfs/inode.c
+++ b/fs/ecryptfs/inode.c
@@ -614,6 +614,7 @@ ecryptfs_rename(struct inode *old_dir, struct dentry
*old_dentry,
struct dentry *lower_new_dentry;
struct dentry *lower_old_dir_dentry;
struct dentry *lower_new_dir_dentry;
+ struct dentry *trap = NULL;
lower_old_dentry = ecryptfs_dentry_to_lower(old_dentry);
lower_new_dentry = ecryptfs_dentry_to_lower(new_dentry);
@@ -621,7 +622,17 @@ ecryptfs_rename(struct inode *old_dir, struct dentry
*old_dentry,
dget(lower_new_dentry);
lower_old_dir_dentry = dget_parent(lower_old_dentry);
lower_new_dir_dentry = dget_parent(lower_new_dentry);
- lock_rename(lower_old_dir_dentry, lower_new_dir_dentry);
+ trap = lock_rename(lower_old_dir_dentry, lower_new_dir_dentry);
+ /* source should not be ancestor of target */
+ if (trap == lower_old_dentry) {
+ rc = -EINVAL;
+ goto out_lock;
+ }
+ /* target should not be ancestor of source */
+ if (trap == lower_new_dentry) {
+ rc = -ENOTEMPTY;
+ goto out_lock;
+ }
rc = vfs_rename(lower_old_dir_dentry-d_inode, lower_old_dentry,
lower_new_dir_dentry-d_inode, lower_new_dentry);
if (rc)
___
linuxtv-commits mailing list
linuxtv-comm...@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-commits
--
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: [git:v4l-dvb/master] Input: lifebook - add another Lifebook DMI signature
Guys,
Please fix your scripts, While it is useful to know if you applied
something to your tree that might affect input I am not really interested
in patches that are coming from mainline.
Thanks.
On Sat, Mar 06, 2010 at 03:27:59PM +0100, Patch from Jon Dodgson wrote:
From: Jon Dodgson crayzee...@gmail.com
There are many many ways one can capitalize Lifebook B Series...
Signed-off-by: Jon Dodgson crayzee...@gmail.com
Signed-off-by: Dmitry Torokhov d...@mail.ru
drivers/input/mouse/lifebook.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
---
http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=57b5e2ae5b5f6b687ef2c644b1cb06bd217cdbe7
diff --git a/drivers/input/mouse/lifebook.c b/drivers/input/mouse/lifebook.c
index 6d7aa10..7c1d7d4 100644
--- a/drivers/input/mouse/lifebook.c
+++ b/drivers/input/mouse/lifebook.c
@@ -53,6 +53,12 @@ static const struct dmi_system_id __initconst
lifebook_dmi_table[] = {
{
/* LifeBook B */
.matches = {
+ DMI_MATCH(DMI_PRODUCT_NAME, Lifebook B Series),
+ },
+ },
+ {
+ /* LifeBook B */
+ .matches = {
DMI_MATCH(DMI_PRODUCT_NAME, LifeBook B Series),
},
},
--
Dmitry
--
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: [git:v4l-dvb/master] Input: lifebook - add another Lifebook DMI signature
Dmitry Torokhov wrote: Guys, Please fix your scripts, While it is useful to know if you applied something to your tree that might affect input I am not really interested in patches that are coming from mainline. Sorry! I've disabled the script for now and removed the patches that were still at the queue. 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: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-tscheck
Hello Mauro, On Wed, 2010-02-24 at 02:33 -0300, Mauro Carvalho Chehab wrote: Please pull change: http://udev.netup.ru/hg/v4l-dvb-aospan-tscheck/rev/0fdeb662c7f6 Allow to enable TS continuity and TEI check on loaded module. Current dvb_demux_tscheck processing doesn't allow to enable check on loaded module. dvb_demux_tscheck can be enabled only when loading module ( dvb_dmx_init should be called to enable dvb_demux_tscheck ). This patch fix this issue. NACK. It is not safe to use vmalloc at dvb_dmx_swfilter_packet(), as this function can be called during interrupt time, and vmalloc can sleep. ok, you are right. I have modified this patch. Please check it again: http://udev.netup.ru/hg/v4l-dvb-aospan-tscheck/rev/3d42e560c88d in this patch cnt_storage always allocated and used only when dvb_demux_tscheck assigned. Is this acceptable ? Thanks. -- Abylai Ospan aos...@netup.ru NetUP Inc. -- 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
[PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-get_frontend
Mauro, Please pull change: http://udev.netup.ru/hg/v4l-dvb-aospan-get_frontend 1. configurable IRQ from CAM. IRQ from CAM disabled by default. In some environment enabled IRQ can cause of machine freeze. 2. get_frontend for STV0900 realized. Thanks. -- Abylai Ospan aos...@netup.ru NetUP Inc. signature.asc Description: This is a digitally signed message part
Re: [git:v4l-dvb/master] ARM: Update mach-types
On Sat, Mar 06, 2010 at 03:25:36PM +0100, Patch from Russell King wrote: From: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Err, why am I getting these emails? Surely you're not re-committing my commits? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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: DM1105: could not attach frontend 195d:1105
Igor M. Liplianin skrev: On 5 марта 2010 00:16:07 Hendrik Skarpeid wrote: Igor M. Liplianin skrev: On 3 марта 2010 18:42:42 Hendrik Skarpeid wrote: Igor M. Liplianin wrote: Now to find GPIO's for LNB power control and ... watch TV :) Yep. No succesful tuning at the moment. There might also be an issue with the reset signal and writing to GPIOCTR, as the module at the moment loads succesfully only once. As far as I can make out, the LNB power control is probably GPIO 16 and 17, not sure which is which, and how they work. GPIO15 is wired to tuner #reset New patch to test No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2721 - Release Date: 03/03/10 20:34:00 modprobe si21xx debug=1 produces this output when scanning. [ 2187.998349] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x02 [ 2187.998353] si21xx: si21xx_set_frontend : FE_SET_FRONTEND [ 2187.999881] si21xx: si21xx_setacquire [ 2187.999884] si21xx: si21xx_set_symbolrate : srate = 2750 [ 2188.022645] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x01 [ 2188.054350] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x02 [ 2188.054355] si21xx: si21xx_set_frontend : FE_SET_FRONTEND [ 2188.055875] si21xx: si21xx_setacquire [ 2188.055879] si21xx: si21xx_set_symbolrate : srate = 2750 [ 2188.110359] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x02 [ 2188.110366] si21xx: si21xx_set_frontend : FE_SET_FRONTEND [ 2188.111885] si21xx: si21xx_setacquire [ 2188.111889] si21xx: si21xx_set_symbolrate : srate = 2750 [ 2188.166350] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x02 [ 2188.166354] si21xx: si21xx_set_frontend : FE_SET_FRONTEND Since the tuner at hand uses a Si2109 chip, VSTATUS 0x01 and 0x02 would indicate that blind scanning is used. Blind scanning is a 2109/2110 specific function, and may not very usable since we always use initial tuning files anyway. 2109/10 also supports the legacy scanning method which is supported by Si2107708. Is the use of blind scanning intentional? Yes, of course, it's intentional. Why not? User has freedom to make little errors in channels.conf file. Also the chip didn't support DVB-S2. And last, has who si2107/08 ? My chip is si2109. I agree, it's best to use the hardware features. I was worried that I may be getting bad i2c data. If I understand you correctly, you have a working Si2109 frontend driver? Here's what I'm getting: Added a few printouts to si21xx.c u8 signal = si21_readreg(state, ANALOG_AGC_POWER_LEVEL_REG); dprintk(%s : FE_READ_STATUS : AGC_POWER: 0x%02x\n, __func__, signal); si21_readregs(state, LOCK_STATUS_REG_1, regs_read, 0x02); reg_read = 0; for (i = 0; i 7; ++i) reg_read |= ((regs_read[0] i) 0x01) (6 - i); lock = ((reg_read 0x7f) | (regs_read[1] 0x80)); dprintk(%s : FE_READ_STATUS : VSTATUS: 0x%02x\n, __func__, lock); dprintk(%s : FE_READ_REGS : REGS[0]: 0x%02x\n, __func__, regs_read[0]); dprintk(%s : FE_READ_REGS : REGS[1]: 0x%02x\n, __func__, regs_read[1]); hend...@iptv:~$ scan -a 1 Sirius-5.0E [72933.818871] si21xx: si21xx_set_symbolrate : srate = 2750 [72933.900276] si21xx: si21_read_status : FE_READ_STATUS : AGC_POWER: 0x20 [72933.908807] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x02 [72933.908812] si21xx: si21_read_status : FE_READ_REGS : REGS[0]: 0x20 [72933.908815] si21xx: si21_read_status : FE_READ_REGS : REGS[1]: 0x00 [72933.908827] si21xx: si21xx_set_frontend : FE_SET_FRONTEND [72933.914962] si21xx: si21xx_setacquire [72933.914967] si21xx: si21xx_set_symbolrate : srate = 2750 [72933.949370] si21xx: si21_read_status : FE_READ_STATUS : AGC_POWER: 0x21 [72933.957877] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x01 [72933.957882] si21xx: si21_read_status : FE_READ_REGS : REGS[0]: 0xc0 [72933.957885] si21xx: si21_read_status : FE_READ_REGS : REGS[1]: 0x60 [72933.996316] si21xx: si21_read_status : FE_READ_STATUS : AGC_POWER: 0x20 [72934.004959] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x02 [72934.004964] si21xx: si21_read_status : FE_READ_REGS : REGS[0]: 0x20 [72934.004968] si21xx: si21_read_status : FE_READ_REGS : REGS[1]: 0x00 So, we have signal and sometimes we are getting carrier also. What worries me most is the FE_READ_REGS : REGS[1]: 0x60 According to the datasheet this register 0x10 Lock status 2, is RCVL 0 0 0 0 0 BSDA BSDO so 0x60 would seem meaningless. Same results using szap. hend...@iptv:~$ szap -a 1 -r -n 170 reading channels from file '/home/hendrik/.szap/channels.conf' zapping to 170 'NRK1;NRK': sat 0, frequency = 12015 MHz V, symbolrate 2750, vpid = 0x0200, apid = 0x0280 sid = 0x0240 using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' status 01 | signal c600 |
Re: Gspca USB driver zc3xx and STV06xx probe the same device ..
2010/3/4 Hans de Goede hdego...@redhat.com:
Hi,
On 03/04/2010 12:36 PM, Erik Andrén wrote:
2010/3/4 Hans de Goedehdego...@redhat.com:
Hi,
On 03/03/2010 02:17 PM, Erik Andrén wrote:
2010/3/3 Gabriel Cnix.or@googlemail.com:
Hello,
I own a QuickCam Messanger webcam.. I didn't used it in ages but today
I plugged it in..
( Device 002: ID 046d:08da Logitech, Inc. QuickCam Messanger )
Now zc3xx and stv06xx are starting both to probe the device .. In
2.6.33 that result in a not working webcam.
( rmmod both modprobe zc3xx one seems to fix that )
On current git head zc3xx works fine even when both are probing the
device.
Also I noticed stv06xx fails anyway for my webcam with this error:
[ 360.910243] STV06xx: Configuring camera
[ 360.910244] STV06xx: st6422 sensor detected
[ 360.910245] STV06xx: Initializing camera
[ 361.161948] STV06xx: probe of 6-1:1.0 failed with error -32
[ 361.161976] usbcore: registered new interface driver STV06xx
[ 361.161978] STV06xx: registered
.
Next thing is stv06xx tells it is an st6422 sensor and does not work
with it while zc3xx tells it is an HV7131R(c) sensor and works fine
with it.
What is right ?
Hans,
As you added support for the st6422 sensor to the stv06xx subdriver I
imagine you best know what's going on.
I took the USB-ID in question from the out of tree v4l1 driver I was
basing
my
st6422 work on. Looking at the other ID's (which are very close together)
and
combining that with this bug report, I think it is safe to say that the
USB-ID
in question should be removed from the stv06xx driver.
Erik will you handle this, or shall I ?
Either way is fine by me.
I can try to do it tonight.
If you could take care of this that would be great!
Thanks,
Hans
Sorry for delaying this, real life came in the way.
I'm pasting in a patch that removes the usb id.
I'm also attaching it as an attachment as gmail probably will stomp on
the inline version.
Gabriel, could you please apply and test this patch and verify that it
works as intended, i. e. the stv06xx driver _doesn't_ bind to your
camera but the zx3xx driver instead does.
If it works as intended could you please reply to this mail with a
tested-by: your name email tag.
Best regards,
Erik
From 6f40494d48c5641326168115a96659581cea6273 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Erik=20Andr=C3=A9n?= erik.and...@gmail.com
Date: Sat, 6 Mar 2010 20:34:51 +0100
Subject: [PATCH 1/1] gspca-stv06xx: Remove the 046d:08da usb id from
linking to the stv06xx driver
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
The 046d:08da usb id shouldn't be associated with the stv06xx driver
as they're not compatible with each other.
This fixes a bug where Quickcam Messenger cams fail to use its proper
driver (gspca-zc3xx), rendering the camera inoperable.
Signed-off-by: Erik Andrén erik.and...@gmail.com
---
drivers/media/video/gspca/stv06xx/stv06xx.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/gspca/stv06xx/stv06xx.c
b/drivers/media/video/gspca/stv06xx/stv06xx.c
index de823ed..b1f7e28 100644
--- a/drivers/media/video/gspca/stv06xx/stv06xx.c
+++ b/drivers/media/video/gspca/stv06xx/stv06xx.c
@@ -497,8 +497,6 @@ static const __devinitdata struct usb_device_id
device_table[] = {
{USB_DEVICE(0x046D, 0x08F5), .driver_info = BRIDGE_ST6422 },
/* QuickCam Messenger (new) */
{USB_DEVICE(0x046D, 0x08F6), .driver_info = BRIDGE_ST6422 },
- /* QuickCam Messenger (new) */
- {USB_DEVICE(0x046D, 0x08DA), .driver_info = BRIDGE_ST6422 },
{}
};
MODULE_DEVICE_TABLE(usb, device_table);
--
1.6.3.3
0001-gspca-stv06xx-Remove-the-046d-08da-usb-id-from-linki.patch
Description: Binary data
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Mar 6 19:00:21 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14392:72846c99c0f7 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.17-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.17-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK spec: OK sparse (linux-2.6.33): ERRORS linux-2.6.16.62-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.7-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.62-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.7-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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
Re: Invalid module format
On Sat, 6 Mar 2010, Mauro Carvalho Chehab wrote: Randy Dunlap wrote: On 03/05/10 16:51, VDR User wrote: On Fri, Mar 5, 2010 at 4:39 PM, Theodore Kilgore kilg...@banach.math.auburn.edu wrote: This is to report the good news that none of the above suspicions have panned out. I still do not know the exact cause of the problem, but a local compile and install of the 2.6.33 kernel did solve the problem. Hence, it does seem that the most likely origin of the problem is somewhere in the Slackware-current tree and the solution does not otherwise concern anyone on this list and does not need to be pursued here. I experienced the same problem and posted a new thread about it with the subject Problem with v4l tree and kernel 2.6.33. I'm a debian user as well so apparently whatever is causing this is not specific to debian or slackware. Even though you've got it working now, the source of the problem should be investigated. -- It's been several years since I last saw this error and I don't recall what caused it then. The message Invalid module format comes from either of modprobe and/or insmod when the kernel returns ENOEXEC to a module (load) syscall. Sometimes the kernel produces more explanatory messages sometimes not. If there are no more explanatory messages, then kernel/module.c can be built with DEBUGP producing more output (and then that new kernel would have to be loaded). Can one of you provide a kernel config file for a kernel/modprobe combination that produces this message? Some of the CONFIG_MODULE* config symbols could have relevance here also. I suspect that it may be related to this: # Select 32 or 64 bit config 64BIT bool 64-bit kernel if ARCH = x86 default ARCH = x86_64 ---help--- Say yes to build a 64-bit kernel - formerly known as x86_64 Say no to build a 32-bit kernel - formerly known as i386 With 2.6.33, it is now possible to compile a 32 bits kernel on a 64 bits machine without needing to pass make ARCH=i386 or to use cross-compilation. Maybe you're running a 32bits kernel, and you've compiled the out-of-tree modules with 64bits or vice-versa. My suggestion is that you should try to force the compilation wit the proper ARCH with something like: make distclean make ARCH=`uname -i` make ARCH=`uname -i` install -- Cheers, Mauro Mauro, I do not know where this leads, but here is a second answer with another piece of information. I mentioned yesterday that I have at this point two kernels, called 2.6.33-smp and 2.6.33-my. The 2.6.33-smp is the stock Slackware-current kernel, and the 2.6.33-my is locally compiled, with somewhat different config parameters. Each of these has its module tree, independent of the other. By which I mean that I have a module tree lib/modules/2.6.33-smp associated with kernel 2.6.33-smp and another module tree lib/modules/2/6/33-my associated with kernel 2.6.33-my I started out, of course, by installing the gspca modules in lib/modules/2.6.33-smp and thereby I presumably over-wrote things in lib/modules/2.6.33-smp/kernel/drivers/media which were present in the 2.6.33-smp module package from the distro. Now, today I did a reinstallation of the 2.6.33-smp modules tree and booted with 2.6.33-smp. I did *not* do anything to change the what was there. For example, I did not install anything from any gspca mercurial tree. No, only what comes with the distro kernel's modules is there. Now, here is what happens under these circumstances: r...@khayyam:/lib/modules/2.6.33-smp/kernel# modprobe gspca_main WARNING: Error inserting v4l1_compat (/lib/modules/2.6.33-smp/kernel/drivers/media/video/v4l1-compat.ko): Invalid module format WARNING: Error inserting videodev (/lib/modules/2.6.33-smp/kernel/drivers/media/video/videodev.ko): Invalid module format FATAL: Error inserting gspca_main (/lib/modules/2.6.33-smp/kernel/drivers/media/video/gspca/gspca_main.ko): Invalid module format r...@khayyam:/lib/modules/2.6.33-smp/kernel# In other words, the same error message as yesterday. But this time the module I was trying to load up was not created by me, but instead it was the one obtained from the distro kernel's modules. Strangely, though, some of the other modules which came with the distro kernel _do_ work. Some of them are essential for running the machine, and they are doing just fine. Theodore Kilgore -- 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: Help with RTL2832U DVB-T dongle (LeadTek WinFast DTV Dongle Mini)
Jan Slaninka wrote: Hi, I'd like to ask for a support with getting LeadTek WindFast DTV Dongle mini running on Linux. So far I was able to fetch latest v4l-dvb from HG, and successfully compiled module dvb_usb_rtl2832u found in 090730_RTL2832U_LINUX_Ver1.1.rar From Ubuntu etc Webforums? Not linuxtv.org or OSS code, missing license, so considered *Realtek proprietary* as default license by (c) law. Ask the maintainers to ask Realtek if they like to have it GPL'd so we can add, improve and maintain it. Do not distribute patches for it over this list or forums until license status is cleared. but with no luck. The box says the dongle's TV Tuner is Infineon 396 No such Infineon Tuner http://www.infineon.com/cms/en/product/channel.html?channel=ff80808112ab681d0112ab6b9bb708b9 must be other device You've seen, possibly EEPROM/Regulator. and Demodulator is RTL2832U. Is there any chance with this one? Any hints appreciated. Thanks, Jan Bus 002 Device 009: ID 0413:6a03 Leadtek Research, Inc. Add this USB-ID to the driver and try your luck. If the frontend tuner is not detected automatically, assign it manually in the source code. y tom -- 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: [git:v4l-dvb/master] af_key: fix netns ops ordering on module load/unload
On Sat, Mar 06, 2010 at 03:27:06PM +0100, Patch from Alexey Dobriyan wrote: From: Alexey Dobriyan adobri...@gmail.com 1. After sock_register() returns, it's possible to create sockets, even if module still not initialized fully (blame generic module code for that!) 2. Consequently, pfkey_create() can be called with pfkey_net_id still not initialized which will BUG_ON in net_generic(): kernel BUG at include/net/netns/generic.h:43! 3. During netns shutdown, netns ops should be unregistered after key manager unregistered because key manager calls can be triggered from xfrm_user module: general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC pfkey_broadcast+0x111/0x210 [af_key] pfkey_send_notify+0x16a/0x300 [af_key] km_state_notify+0x41/0x70 xfrm_flush_sa+0x75/0x90 [xfrm_user] 4. Unregister netns ops after socket ops just in case and for symmetry. Reported by Luca Tettamanti. Signed-off-by: Alexey Dobriyan adobri...@gmail.com Tested-by: Luca Tettamanti kronos...@gmail.com Signed-off-by: Eric Dumazet eric.duma...@gmail.com Signed-off-by: David S. Miller da...@davemloft.net What this has to do with DVB? -- 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
[HG PULL] http://linuxtv.org/hg/~awalls/ivtv-changes
Mauro, Please pull from http://linuxtv.org/hg/~awalls/ivtv-changes for the following 3 changesets: 01/03: ivtv: Combine capture start delays into a single delay http://linuxtv.org/hg/~awalls/ivtv-changes?cmd=changeset;node=2599940a43e4 02/03: ivtv: Really stop capture on device close http://linuxtv.org/hg/~awalls/ivtv-changes?cmd=changeset;node=a10b7a7b96cf 03/03: cx2341x: Remove temporal filter control restriction http://linuxtv.org/hg/~awalls/ivtv-changes?cmd=changeset;node=45aee2790190 cx2341x.c | 14 -- ivtv/ivtv-streams.c |7 +-- 2 files changed, 5 insertions(+), 16 deletions(-) Ian Armstrong managed to track down the source of some intermittent undesirable video effects when starting captures in ivtv. Although patch 01/03 is trivial and authored by me, Ian and Martin's testing was the real work that determined what had to be done. Thanks, 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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK
Hello Hans, Hans Verkuil wrote: This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Mar 6 19:00:21 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14392:72846c99c0f7 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 [...] linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-armv5-dm365: ERRORS I was interested in what these errors could be so I checked the http://www.xs4all.nl/~hverkuil/logs/Saturday.log file. Unfortunately this log file does not contain more. So I also checked the detailed log files at http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 * linux-2.6.33-armv5-dm365.log and * linux-2.6.32.6-armv5-dm365.log Sat Mar 6 19:03:59 CET 2010 make -C /home/hans/work/build/v4l-dvb-master/v4l make[1]: Entering directory `/home/hans/work/build/v4l-dvb-master/v4l' scripts/make_makefile.pl ./scripts/make_kconfig.pl /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6 /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6 Updating/Creating .config File not found: /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6/.config at ./scripts/make_kconfig.pl line 32, IN line 4. Preparing to compile for kernel version 2.6.32 File not found: /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6/.config at ./scripts/make_kconfig.pl line 32, IN line 4. Preparing to compile for kernel version 2.6.32 make[1]: Leaving directory `/home/hans/work/build/v4l-dvb-master/v4l' make[1]: Entering directory `/home/hans/work/build/v4l-dvb-master/v4l' ./scripts/make_kconfig.pl /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6 /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6 Updating/Creating .config File not found: /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6/.config at ./scripts/make_kconfig.pl line 32, IN line 4. Preparing to compile for kernel version 2.6.32 File not found: /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6/.config at ./scripts/make_kconfig.pl line 32, IN line 4. Preparing to compile for kernel version 2.6.32 make[1]: *** No rule to make target `.myconfig', needed by `config-compat.h'. Stop. make[1]: Leaving directory `/home/hans/work/build/v4l-dvb-master/v4l' make: *** [all] Error 2 Sat Mar 6 19:03:59 CET 2010 I recommend to add the lines which contain the message File not found to the generated http://www.xs4all.nl/~hverkuil/logs/Saturday.log log file. By the way, what could be the problem here? Regards, Márton Németh -- 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] gspca cpia1: make local functions static
From: Márton Németh nm...@freemail.hu
Make the local functions static. Note that the function command_setlights() is
currently not called from anywhere.
This will remove the following sparse warnings (see make C=1):
* symbol 'command_setformat' was not declared. Should it be static?
* symbol 'command_setcolourparams' was not declared. Should it be static?
* symbol 'command_setapcor' was not declared. Should it be static?
* symbol 'command_setvloffset' was not declared. Should it be static?
* symbol 'command_setexposure' was not declared. Should it be static?
* symbol 'command_setcolourbalance' was not declared. Should it be static?
* symbol 'command_setcompressiontarget' was not declared. Should it be static?
* symbol 'command_setyuvtresh' was not declared. Should it be static?
* symbol 'command_setcompressionparams' was not declared. Should it be static?
* symbol 'command_setcompression' was not declared. Should it be static?
* symbol 'command_setsensorfps' was not declared. Should it be static?
* symbol 'command_setflickerctrl' was not declared. Should it be static?
* symbol 'command_setecptiming' was not declared. Should it be static?
* symbol 'command_pause' was not declared. Should it be static?
* symbol 'command_resume' was not declared. Should it be static?
* symbol 'command_setlights' was not declared. Should it be static?
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r e50bb36f881c linux/drivers/media/video/gspca/cpia1.c
--- a/linux/drivers/media/video/gspca/cpia1.c Sat Mar 06 22:29:29 2010 -0300
+++ b/linux/drivers/media/video/gspca/cpia1.c Sun Mar 07 07:32:57 2010 +0100
@@ -861,7 +861,7 @@
return do_command(gspca_dev, CPIA_COMMAND_GetExposure, 0, 0, 0, 0);
}
-int command_setformat(struct gspca_dev *gspca_dev)
+static int command_setformat(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
int ret;
@@ -878,7 +878,7 @@
sd-params.roi.rowStart, sd-params.roi.rowEnd);
}
-int command_setcolourparams(struct gspca_dev *gspca_dev)
+static int command_setcolourparams(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
return do_command(gspca_dev, CPIA_COMMAND_SetColourParams,
@@ -887,7 +887,7 @@
sd-params.colourParams.saturation, 0);
}
-int command_setapcor(struct gspca_dev *gspca_dev)
+static int command_setapcor(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
return do_command(gspca_dev, CPIA_COMMAND_SetApcor,
@@ -897,7 +897,7 @@
sd-params.apcor.gain8);
}
-int command_setvloffset(struct gspca_dev *gspca_dev)
+static int command_setvloffset(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
return do_command(gspca_dev, CPIA_COMMAND_SetVLOffset,
@@ -907,7 +907,7 @@
sd-params.vlOffset.gain8);
}
-int command_setexposure(struct gspca_dev *gspca_dev)
+static int command_setexposure(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
int ret;
@@ -943,7 +943,7 @@
return ret;
}
-int command_setcolourbalance(struct gspca_dev *gspca_dev)
+static int command_setcolourbalance(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
@@ -973,7 +973,7 @@
return -EINVAL;
}
-int command_setcompressiontarget(struct gspca_dev *gspca_dev)
+static int command_setcompressiontarget(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
@@ -983,7 +983,7 @@
sd-params.compressionTarget.targetQ, 0);
}
-int command_setyuvtresh(struct gspca_dev *gspca_dev)
+static int command_setyuvtresh(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
@@ -992,7 +992,7 @@
sd-params.yuvThreshold.uvThreshold, 0, 0);
}
-int command_setcompressionparams(struct gspca_dev *gspca_dev)
+static int command_setcompressionparams(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
@@ -1009,7 +1009,7 @@
sd-params.compressionParams.decimationThreshMod);
}
-int command_setcompression(struct gspca_dev *gspca_dev)
+static int command_setcompression(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
@@ -1018,7 +1018,7 @@
sd-params.compression.decimation, 0, 0);
}
-int command_setsensorfps(struct gspca_dev *gspca_dev)
+static int command_setsensorfps(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
@@ -1027,7 +1027,7 @@
sd-params.sensorFps.baserate, 0, 0);
}
-int command_setflickerctrl(struct gspca_dev *gspca_dev)
+static int command_setflickerctrl(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
@@ -1038,7 +1038,7 @@
0);
}
-int
Re: Help with RTL2832U DVB-T dongle (LeadTek WinFast DTV Dongle Mini)
Antti has been working on drivers for the RTL283x. http://linuxtv.org/hg/~anttip/rtl2831u or http://linuxtv.org/hg/~anttip/qt1010/ If you have more information on the RTL2832, I'd be happy to add it at: http://www.linuxtv.org/wiki/index.php/Rtl2831_devices Jan Slaninka wrote: Hi, I'd like to ask for a support with getting LeadTek WindFast DTV Dongle mini running on Linux. So far I was able to fetch latest v4l-dvb from HG, and successfully compiled module dvb_usb_rtl2832u found in 090730_RTL2832U_LINUX_Ver1.1.rar but with no luck. The box says the dongle's TV Tuner is Infineon 396 and Demodulator is RTL2832U. Is there any chance with this one? Any hints appreciated. Thanks, Jan lsmod: Module Size Used by dvb_usb_rtl2832u 94445 0 dvb_usb18655 1 dvb_usb_rtl2832u dmesg output: [ 9283.804050] usb 2-1: new high speed USB device using ehci_hcd and address 9 [ 9283.930504] usb 2-1: New USB device found, idVendor=0413, idProduct=6a03 [ 9283.930507] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 9283.930510] usb 2-1: Product: usbtv [ 9283.930512] usb 2-1: Manufacturer: realtek [ 9283.930610] usb 2-1: configuration #1 chosen from 1 choice lsusb: Bus 002 Device 009: ID 0413:6a03 Leadtek Research, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0413 Leadtek Research, Inc. idProduct 0x6a03 bcdDevice1.00 iManufacturer 1 realtek iProduct2 usbtv iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 USB2.0-BulkIso bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 5 Bulk-In, Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 2 Device Status: 0x (Bus Powered) -- 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
