Re: [REGRESSION] saa7134 + ir
Am Dienstag, 15. Juni 2010, um 03:39:24 schrieb Dmitri Belimov: > Hi Martin > > > This is not only a problem with saa7134, but also with other drivers > > like budget-ci. The bug was also present in 2.6.35-rc1 > > I see this bug with 2.6.33 and fresh hg. > > > There have been several reports here in the list since a few weeks: > > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/20198 > > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/19904 > > > > There is already a similar patch like yours (see link in first of my > > links), but it still hasn't gone into the v4l-dvb hg. (Although there > > have been frequently other -less important- patches been merged ...) > > > > Greets, > > Martin > > > > With my best regards, Dmitry. > it should be fixed now. Douglas merged this patch today: http://linuxtv.org/hg/v4l-dvb/rev/3d7eaf0239ab Greets, Martin -- 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] Add 12 bit RAW Bayer Pattern pixel format support in V4L2
Zhang, Xiaolin wrote:
> From 54079deb89764a9399c95098e4c3830c88d24a5c Mon Sep 17 00:00:00 2001
> From: Xiaolin Zhang
> Date: Tue, 18 May 2010 18:02:24 +0800
> Subject: [PATCH] Add 12 bit RAW Bayer Pattern pixel format support.
Hi Xiaolin,
> Signed-off-by: Xiaolin Zhang
> ---
> Documentation/DocBook/v4l/videodev2.h.xml | 10 +-
> include/linux/videodev2.h |4
> 2 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/DocBook/v4l/videodev2.h.xml
> b/Documentation/DocBook/v4l/videodev2.h.xml
> index 0683259..649ef9e 100644
> --- a/Documentation/DocBook/v4l/videodev2.h.xml
> +++ b/Documentation/DocBook/v4l/videodev2.h.xml
> @@ -330,7 +330,15 @@ struct linkend="v4l2-pix-format">v4l2_pix_format {
> #define V4L2_PIX_FMT_SBGGR8
> v4l2_fourcc('B', 'A', '8', '1') /* 8 BGBG.. GRGR.. */
> #define V4L2_PIX_FMT_SGBRG8
> v4l2_fourcc('G', 'B', 'R', 'G') /* 8 GBGB.. RGRG.. */
> #define V4L2_PIX_FMT_SGRBG8
> v4l2_fourcc('G', 'R', 'B', 'G') /* 8 GRGR.. BGBG.. */
> -#define V4L2_PIX_FMT_SGRBG10
> v4l2_fourcc('B', 'A', '1', '0') /* 10bit raw bayer */
> +#define V4L2_PIX_FMT_SRGGB8
> v4l2_fourcc('R', 'G', 'G', 'B') /* 8 RGRG.. GBGB.. */
> +#define V4L2_PIX_FMT_SBGGR10
> v4l2_fourcc('B', 'G', '1', '0') /* 10 BGBG.. GRGR.. */
> +#define V4L2_PIX_FMT_SGBRG10
> v4l2_fourcc('G', 'B', '1', '0') /* 10 GBGB.. RGRG.. */
> +#define V4L2_PIX_FMT_SGRBG10
> v4l2_fourcc('B', 'A', '1', '0') /* 10 GRGR.. BGBG.. */
> +#define V4L2_PIX_FMT_SRGGB10
> v4l2_fourcc('R', 'G', '1', '0') /* 10 RGRG.. GBGB.. */
> +#define V4L2_PIX_FMT_SBGGR12
> v4l2_fourcc('B', 'G', '1', '2') /* 12 BGBG.. GRGR.. */
> +#define V4L2_PIX_FMT_SGBRG12
> v4l2_fourcc('G', 'B', '1', '2') /* 12 GBGB.. RGRG.. */
> +#define V4L2_PIX_FMT_SGRBG12
> v4l2_fourcc('B', 'A', '1', '2') /* 12 GRGR.. BGBG.. */
> +#define V4L2_PIX_FMT_SRGGB12
> v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */
> /* 10bit raw bayer DPCM compressed to 8 bits */
> #define linkend="V4L2-PIX-FMT-SGRBG10DPCM8">V4L2_PIX_FMT_SGRBG10DPCM8
> v4l2_fourcc('B', 'D', '1', '0')
> /*
How about arranging the 12 bit modes after the 10 bit ones?
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 3793d16..202092a 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -335,6 +335,10 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_SGBRG10 v4l2_fourcc('G', 'B', '1', '0') /* 10 GBGB..
> RGRG.. */
> #define V4L2_PIX_FMT_SGRBG10 v4l2_fourcc('B', 'A', '1', '0') /* 10 GRGR..
> BGBG.. */
> #define V4L2_PIX_FMT_SRGGB10 v4l2_fourcc('R', 'G', '1', '0') /* 10 RGRG..
> GBGB.. */
> +#define V4L2_PIX_FMT_SBGGR12 v4l2_fourcc('B', 'G', '1', '2') /* 12 BGBG..
> GRGR.. */
> +#define V4L2_PIX_FMT_SGBRG12 v4l2_fourcc('G', 'B', '1', '2') /* 12 GBGB..
> RGRG.. */
> +#define V4L2_PIX_FMT_SGRBG12 v4l2_fourcc('B', 'A', '1', '2') /* 12 GRGR..
> BGBG.. */
> +#define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG..
> GBGB.. */
> /* 10bit raw bayer DPCM compressed to 8 bits */
> #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> /*
Same here.
Regards,
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.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 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 10:29 PM, Peter Stuge wrote: Justin P. Mattock wrote: *baffled* Why did you think that would work? transmit_cmd()s signature has 4 parameters. I have no manual in front of me. Did a quick google, but came up with (no hits) info on what that function does. grep showed too many entries to really see why/what this is. Check out the tool cscope. (Or kscope, if you prefer a GUI.) //Peter thanks for this tool.. I think this is what I need.. running around not knowing what/where the manual is for a call is a bit daunting. I'll give this a look. Thanks for this.. Justin P. Mattock -- 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 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
On 06/14/2010 10:16 PM, Mauro Carvalho Chehab wrote: Em 14-06-2010 23:26, Justin P. Mattock escreveu: not sure if this is correct or not for fixing this warning: CC [M] drivers/media/common/tuners/tuner-simple.o drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' set but not used Signed-off-by: Justin P. Mattock --- drivers/media/common/tuners/tuner-simple.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/common/tuners/tuner-simple.c b/drivers/media/common/tuners/tuner-simple.c index 8abbcc5..4465b99 100644 --- a/drivers/media/common/tuners/tuner-simple.c +++ b/drivers/media/common/tuners/tuner-simple.c @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, struct tuner_simple_priv *priv = fe->tuner_priv; u8 config, cb; u16 div; - struct tunertype *tun; u8 buffer[4]; int rc, IFPCoff, i; enum param_type desired_type; struct tuner_params *t_params; - tun = priv->tun; - + Why are you adding an extra blank line here? Except for that, the patch looks sane. /* IFPCoff = Video Intermediate Frequency - Vif: 940 =16*58.75 NTSC/J (Japan) 732 =16*45.75 M/N STD o.k. resent this.. I ended up doing a git reset do make sure things dont get funky etc.. Justin P. Mattock -- 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 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
On 06/14/2010 10:16 PM, Mauro Carvalho Chehab wrote: Em 14-06-2010 23:26, Justin P. Mattock escreveu: not sure if this is correct or not for fixing this warning: CC [M] drivers/media/common/tuners/tuner-simple.o drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' set but not used Signed-off-by: Justin P. Mattock --- drivers/media/common/tuners/tuner-simple.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/common/tuners/tuner-simple.c b/drivers/media/common/tuners/tuner-simple.c index 8abbcc5..4465b99 100644 --- a/drivers/media/common/tuners/tuner-simple.c +++ b/drivers/media/common/tuners/tuner-simple.c @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, struct tuner_simple_priv *priv = fe->tuner_priv; u8 config, cb; u16 div; - struct tunertype *tun; u8 buffer[4]; int rc, IFPCoff, i; enum param_type desired_type; struct tuner_params *t_params; - tun = priv->tun; - + Why are you adding an extra blank line here? Except for that, the patch looks sane. I think I was doing something wrong when creating these patches. i.g. I just hightlight the code then move the cursor highlight all the way to the right before pressing "x". normally would be o.k. but for some reason seems to be doing this. found if I highlight left to ; (or the end of the code I want to delete) then git commit creates the patch properly. /* IFPCoff = Video Intermediate Frequency - Vif: 940 =16*58.75 NTSC/J (Japan) 732 =16*45.75 M/N STD I'll resend this. Thanks for having a look. Justin P. Mattock -- 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 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
Justin P. Mattock wrote: > > *baffled* Why did you think that would work? transmit_cmd()s signature > > has 4 parameters. > > I have no manual in front of me. Did a quick google, but came up with > (no hits) info on what that function does. grep showed too many entries > to really see why/what this is. Check out the tool cscope. (Or kscope, if you prefer a GUI.) //Peter -- 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 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
Em 14-06-2010 23:26, Justin P. Mattock escreveu: > not sure if this is correct or not for > fixing this warning: > CC [M] drivers/media/common/tuners/tuner-simple.o > drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': > drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' > set but not used > > Signed-off-by: Justin P. Mattock > > --- > drivers/media/common/tuners/tuner-simple.c |4 +--- > 1 files changed, 1 insertions(+), 3 deletions(-) > > diff --git a/drivers/media/common/tuners/tuner-simple.c > b/drivers/media/common/tuners/tuner-simple.c > index 8abbcc5..4465b99 100644 > --- a/drivers/media/common/tuners/tuner-simple.c > +++ b/drivers/media/common/tuners/tuner-simple.c > @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, > struct tuner_simple_priv *priv = fe->tuner_priv; > u8 config, cb; > u16 div; > - struct tunertype *tun; > u8 buffer[4]; > int rc, IFPCoff, i; > enum param_type desired_type; > struct tuner_params *t_params; > > - tun = priv->tun; > - > + Why are you adding an extra blank line here? Except for that, the patch looks sane. > /* IFPCoff = Video Intermediate Frequency - Vif: > 940 =16*58.75 NTSC/J (Japan) > 732 =16*45.75 M/N STD -- 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 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 08:49 PM, valdis.kletni...@vt.edu wrote:
On Mon, 14 Jun 2010 19:12:31 PDT, "Justin P. Mattock" said:
what I tried was this:
if (!rc)
printk("test"\n")
and everything looked good,
but as a soon as I changed
rc = transmit_cmd(chip,&tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
"attempting to determine the timeouts");
to this:
rc = transmit_cmd(chip,&tpm_cmd, TPM_INTERNAL_RESULT_SIZE);
if (!rc)
printk("attempting to determine the timeouts\n");
*baffled* Why did you think that would work? transmit_cmd()s signature
has 4 parameters.
I have no manual in front of me. Did a quick google, but came up with
(no hits) info on what that function does. grep showed too many entries
to really see why/what this is. So I kind of just scrambled with this one.
Justin P. Mattock
--
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 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On Mon, 14 Jun 2010 19:12:31 PDT, "Justin P. Mattock" said:
> what I tried was this:
>
> if (!rc)
> printk("test"\n")
>
> and everything looked good,
> but as a soon as I changed
>
> rc = transmit_cmd(chip,&tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
> "attempting to determine the timeouts");
>
> to this:
>
> rc = transmit_cmd(chip,&tpm_cmd, TPM_INTERNAL_RESULT_SIZE);
>
> if (!rc)
> printk("attempting to determine the timeouts\n");
*baffled* Why did you think that would work? transmit_cmd()s signature
has 4 parameters.
pgp7x2ph53HxQ.pgp
Description: PGP signature
Re: [PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 05:13 PM, valdis.kletni...@vt.edu wrote:
On Mon, 14 Jun 2010 13:26:44 PDT, "Justin P. Mattock" said:
Im getting this warning when compiling:
CC drivers/char/tpm/tpm.o
drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt':
drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used
The below patch gets rid of the warning,
but I'm not sure if it's the best solution.
rc = transmit_cmd(chip,&tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
"attempting to determine the timeouts");
+ if (!rc)
+ rc = 0;
}
Good thing that's a void function. ;)
Unless transmit_cmd() is marked 'must_check', maybe losing the 'rc =' would
be a better solution?
what I tried was this:
if (!rc)
printk("test"\n")
and everything looked good,
but as a soon as I changed
rc = transmit_cmd(chip,&tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
"attempting to determine the timeouts");
to this:
rc = transmit_cmd(chip,&tpm_cmd, TPM_INTERNAL_RESULT_SIZE);
if (!rc)
printk("attempting to determine the timeouts\n");
I error out with transmit_cmd not having enough
functions to it.. so I just added the rc = 0;
and went on to the next.
Justin P. Mattock
--
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: [REGRESSION] saa7134 + ir
Hi Martin > This is not only a problem with saa7134, but also with other drivers > like budget-ci. The bug was also present in 2.6.35-rc1 I see this bug with 2.6.33 and fresh hg. > There have been several reports here in the list since a few weeks: > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/20198 > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/19904 > > There is already a similar patch like yours (see link in first of my > links), but it still hasn't gone into the v4l-dvb hg. (Although there > have been frequently other -less important- patches been merged ...) > > Greets, > Martin > With my best regards, 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: [PATCH 2/8]bluetooth/hci_ldisc.c Fix warning: variable 'tty' set but not used
Hi Justin, * Justin P. Mattock [2010-06-14 13:26:42 -0700]: > Im getting this while building: > CC [M] drivers/bluetooth/hci_ldisc.o > drivers/bluetooth/hci_ldisc.c: In function 'hci_uart_send_frame': > drivers/bluetooth/hci_ldisc.c:213:21: warning: variable 'tty' set but not used > > the below fixed it for me, but am not sure if > it's correct. The fix is correct, you just need to fix the trailing whitespace problem and resend it. Also we use "Bluetooth:" as part of the commit message on the bluetooth subsystem. For example: "Bluetooth: Remove set but not used varible 'tty' Or something like that. -- Gustavo F. Padovan http://padovan.org -- 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 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On Mon, 14 Jun 2010 13:26:44 PDT, "Justin P. Mattock" said: > Im getting this warning when compiling: > CC drivers/char/tpm/tpm.o > drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt': > drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used > > The below patch gets rid of the warning, > but I'm not sure if it's the best solution. > rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, > "attempting to determine the timeouts"); > + if (!rc) > + rc = 0; > } Good thing that's a void function. ;) Unless transmit_cmd() is marked 'must_check', maybe losing the 'rc =' would be a better solution? pgp5OZccJj29w.pgp Description: PGP signature
[PATCH -next] vivi: fix depends again
From: Randy Dunlap My previous patch to depend on FONTS was not sufficient since FONTS is boolean. VIDEO_VIVI needs to depend on a tristate so that it won't be enabled as =y when framebuffer is built as modular, so modify it to depend on the same symbols that FONTS depends on, which are FRAMEBUFFER_CONSOLE || STI_CONSOLE. Fixes this build error when VIDEO_VIVI=y and FRAMEBUFFER_CONSOLE=m: vivi.c:(.init.text+0x7205): undefined reference to `find_font' Signed-off-by: Randy Dunlap --- drivers/media/video/Kconfig |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- linux-next-20100614.orig/drivers/media/video/Kconfig +++ linux-next-20100614/drivers/media/video/Kconfig @@ -559,7 +559,8 @@ config VIDEO_DAVINCI_VPIF config VIDEO_VIVI tristate "Virtual Video Driver" - depends on VIDEO_DEV && VIDEO_V4L2 && !SPARC32 && !SPARC64 && FONTS + depends on VIDEO_DEV && VIDEO_V4L2 && !SPARC32 && !SPARC64 + depends on (FRAMEBUFFER_CONSOLE || STI_CONSOLE) && FONTS select FONT_8x16 select VIDEOBUF_VMALLOC default n -- 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 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 04:07 PM, Stefan Richter wrote: On 14 Jun, Justin P. Mattock wrote: On 06/14/2010 02:47 PM, Edward Shishkin wrote: Whitespaces should be removed. I recommend quilt package for managing patches: "quilt refresh --strip-trailing-whitespace" is your friend.. o.k. I resent this.. fixed the whitespace(hopefully) and add your Acked to it. as for quilt I'll have to look into that.. (using a lfs system, so if the sourcecode is easy to deal with(build), then it's a good but if it becomes a nightmare maybe not!!). Since you appear to generate the patches with git, you can use "git diff --check [...]" for some basic whitespace checks (additions of trailing space, additions of space before tab). For more extensive checks, try "git diff [...] | scripts/checkpatch.pl -". Check this before you commit. If you committed already, "git commit --amend [-a] [...]" lets you alter the very last commit of course. Thanks for the info on this, copied it down in my book of commands... Justin P. Mattock -- 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 1/8]reiserfs:stree.c Fix variable set but not used.
On 14 Jun, Justin P. Mattock wrote: > On 06/14/2010 02:47 PM, Edward Shishkin wrote: >> Whitespaces should be removed. >> I recommend quilt package for managing patches: >> "quilt refresh --strip-trailing-whitespace" is your friend.. > > o.k. I resent this.. fixed the whitespace(hopefully) > and add your Acked to it. > as for quilt I'll have to look into that.. > (using a lfs system, so if the sourcecode is easy > to deal with(build), then it's a good but if it becomes > a nightmare maybe not!!). Since you appear to generate the patches with git, you can use "git diff --check [...]" for some basic whitespace checks (additions of trailing space, additions of space before tab). For more extensive checks, try "git diff [...] | scripts/checkpatch.pl -". Check this before you commit. If you committed already, "git commit --amend [-a] [...]" lets you alter the very last commit of course. -- 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 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 02:47 PM, Edward Shishkin wrote: Justin P. Mattock wrote: On 06/14/2010 02:05 PM, Edward Shishkin wrote: Justin P. Mattock wrote: Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock Acked-by: Edward Shishkin o.k.!! what about the whitespace issue? Whitespaces should be removed. I recommend quilt package for managing patches: "quilt refresh --strip-trailing-whitespace" is your friend.. Thanks, Edward. o.k. I resent this.. fixed the whitespace(hopefully) and add your Acked to it. as for quilt I'll have to look into that.. (using a lfs system, so if the sourcecode is easy to deal with(build), then it's a good but if it becomes a nightmare maybe not!!). Justin P. Mattock -- 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 1/8]reiserfs:stree.c Fix variable set but not used.
Justin P. Mattock wrote: On 06/14/2010 02:05 PM, Edward Shishkin wrote: Justin P. Mattock wrote: Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock Acked-by: Edward Shishkin o.k.!! what about the whitespace issue? Whitespaces should be removed. I recommend quilt package for managing patches: "quilt refresh --strip-trailing-whitespace" is your friend.. Thanks, Edward. from what I remember I did notice the "+" that git does when making patches like this but given some many of these warnings I just did a quick workaround or however then figured to worry later on that. --- fs/reiserfs/stree.c | 7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c index 313d39d..73086ad 100644 --- a/fs/reiserfs/stree.c +++ b/fs/reiserfs/stree.c @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key, /* Key to s struct buffer_head *bh; struct path_element *last_element; int node_level, retval; - int right_neighbor_of_leaf_node; int fs_gen; struct buffer_head *reada_bh[SEARCH_BY_KEY_READA]; b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA]; @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key, /* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key, /* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + /* repeat search from the root */ continue; } -- 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 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
On 06/14/2010 01:53 PM, Jean Delvare wrote:
Hi Justin,
On Mon, 14 Jun 2010 13:26:46 -0700, Justin P. Mattock wrote:
could be a right solution, could be wrong
here is the warning:
CC drivers/i2c/i2c-core.o
drivers/i2c/i2c-core.c: In function 'i2c_register_adapter':
drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used
Signed-off-by: Justin P. Mattock
---
drivers/i2c/i2c-core.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 1cca263..79c6c26 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
mutex_lock(&core_lock);
dummy = bus_for_each_drv(&i2c_bus_type, NULL, adap,
__process_new_adapter);
+ if(!dummy)
+ dummy = 0;
One word: scripts/checkpatch.pl
In other news, the above is just plain wrong. First we force people to
read the result of bus_for_each_drv() and then when they do and don't
need the value, gcc complains, so we add one more layer of useless
code, which developers and possibly tools will later wonder and
complain about? I can easily imagine that a static code analyzer would
spot the above code as being a potential bug.
Let's stop this madness now please.
Either __must_check goes away from bus_for_each_drv() and from every
other function which raises this problem, or we must disable that new
type of warning gcc 4.6.0 generates. Depends which warnings we value
more, as we can't sanely have both.
That is the crux of the whole thing. Putting in crap to get rid of the
__must_check warning someone obviously wanted to provoke is just plain
wrong.
I don't know what the answer is, but in addition to your suggestion of
removing the __must_check, you might try:
BUG_ON(dummy != WHAT_IT_SHOULD_BE);
or
if (dummy != WHAT_IT_SHOULD_BE)
panic("nice message here);
or
static inline void i_really_know_what_i_am_doing(int arg)
{
/*
* Trick the compiler because we don't want to
* handle error conditions.
*/
return;
}
.
.
.
i_really_know_what_i_am_doing(dummy);
David Daney
--
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 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 02:05 PM, Edward Shishkin wrote: Justin P. Mattock wrote: Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock Acked-by: Edward Shishkin o.k.!! what about the whitespace issue? from what I remember I did notice the "+" that git does when making patches like this but given some many of these warnings I just did a quick workaround or however then figured to worry later on that. --- fs/reiserfs/stree.c | 7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c index 313d39d..73086ad 100644 --- a/fs/reiserfs/stree.c +++ b/fs/reiserfs/stree.c @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key, /* Key to s struct buffer_head *bh; struct path_element *last_element; int node_level, retval; - int right_neighbor_of_leaf_node; int fs_gen; struct buffer_head *reada_bh[SEARCH_BY_KEY_READA]; b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA]; @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key, /* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key, /* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + /* repeat search from the root */ continue; } -- 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 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 01:48 PM, Nick Bowler wrote: On 13:26 Mon 14 Jun , Justin P. Mattock wrote: @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + This hunk introduces whitespace on the empty line, which is not cool. I can resend!!(biggest problem is working through these warnings) /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + Here, too. Most of the patches in this series have similar issues. main thing now(for me atleast)is, is this actual dead code or what? if not then something else needs to be done, if yes then I guess I can resend this, with out the whitespace issue. Justin P. Mattock -- 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 1/8]reiserfs:stree.c Fix variable set but not used.
Justin P. Mattock wrote: Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock Acked-by: Edward Shishkin --- fs/reiserfs/stree.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c index 313d39d..73086ad 100644 --- a/fs/reiserfs/stree.c +++ b/fs/reiserfs/stree.c @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s struct buffer_head *bh; struct path_element *last_element; int node_level, retval; - int right_neighbor_of_leaf_node; int fs_gen; struct buffer_head *reada_bh[SEARCH_BY_KEY_READA]; b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA]; @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + /* repeat search from the root */ continue; } -- 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 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
On 06/14/2010 01:53 PM, Jean Delvare wrote: Hi Justin, On Mon, 14 Jun 2010 13:26:46 -0700, Justin P. Mattock wrote: could be a right solution, could be wrong here is the warning: CC drivers/i2c/i2c-core.o drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used Signed-off-by: Justin P. Mattock --- drivers/i2c/i2c-core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 1cca263..79c6c26 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) mutex_lock(&core_lock); dummy = bus_for_each_drv(&i2c_bus_type, NULL, adap, __process_new_adapter); + if(!dummy) + dummy = 0; One word: scripts/checkpatch.pl it was this, and/or just take the code out (since I'm a newbie) In other news, the above is just plain wrong. First we force people to read the result of bus_for_each_drv() and then when they do and don't need the value, gcc complains, so we add one more layer of useless code, which developers and possibly tools will later wonder and complain about? I can easily imagine that a static code analyzer would spot the above code as being a potential bug. Let's stop this madness now please. your telling me!! I haven't even compiled all the way through the kernel yet.(lots of warnings) Either __must_check goes away from bus_for_each_drv() and from every other function which raises this problem, or we must disable that new type of warning gcc 4.6.0 generates. Depends which warnings we value more, as we can't sanely have both. mutex_unlock(&core_lock); return 0; up to you guys.. best thing now is deciphering what and what not is an actual issue. Justin P. Mattock -- 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 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
Hi Justin, On Mon, 14 Jun 2010 13:26:46 -0700, Justin P. Mattock wrote: > could be a right solution, could be wrong > here is the warning: > CC drivers/i2c/i2c-core.o > drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': > drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used > > Signed-off-by: Justin P. Mattock > > --- > drivers/i2c/i2c-core.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c > index 1cca263..79c6c26 100644 > --- a/drivers/i2c/i2c-core.c > +++ b/drivers/i2c/i2c-core.c > @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) > mutex_lock(&core_lock); > dummy = bus_for_each_drv(&i2c_bus_type, NULL, adap, >__process_new_adapter); > + if(!dummy) > + dummy = 0; One word: scripts/checkpatch.pl In other news, the above is just plain wrong. First we force people to read the result of bus_for_each_drv() and then when they do and don't need the value, gcc complains, so we add one more layer of useless code, which developers and possibly tools will later wonder and complain about? I can easily imagine that a static code analyzer would spot the above code as being a potential bug. Let's stop this madness now please. Either __must_check goes away from bus_for_each_drv() and from every other function which raises this problem, or we must disable that new type of warning gcc 4.6.0 generates. Depends which warnings we value more, as we can't sanely have both. > mutex_unlock(&core_lock); > > return 0; -- 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
[PATCH] gspca_pac7302: add Genius iSlim 310
From: Márton Németh
Add Genius iSlim 310 webcam to the supported list of the PAC7302 driver.
For more information see
http://linuxtv.org/wiki/index.php/PixArt_PAC7301/PAC7302 .
Signed-off-by: Márton Németh
---
diff --git a/Documentation/video4linux/gspca.txt
b/Documentation/video4linux/gspca.txt
index f13eb03..f9b9d32 100644
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt
@@ -253,6 +253,7 @@ pac7302 093a:2620 Apollo AC-905
pac7302093a:2621 PAC731x
pac7302093a:2622 Genius Eye 312
pac7302093a:2624 PAC7302
+pac7302093a:2625 Genius iSlim 310
pac7302093a:2626 Labtec 2200
pac7302093a:2628 Genius iLook 300
pac7302093a:2629 Genious iSlim 300
diff --git a/drivers/media/video/gspca/pac7302.c
b/drivers/media/video/gspca/pac7302.c
index 2a68220..7c0f265 100644
--- a/drivers/media/video/gspca/pac7302.c
+++ b/drivers/media/video/gspca/pac7302.c
@@ -1200,6 +1200,7 @@ static const struct usb_device_id device_table[]
__devinitconst = {
{USB_DEVICE(0x093a, 0x2621)},
{USB_DEVICE(0x093a, 0x2622), .driver_info = FL_VFLIP},
{USB_DEVICE(0x093a, 0x2624), .driver_info = FL_VFLIP},
+ {USB_DEVICE(0x093a, 0x2625)},
{USB_DEVICE(0x093a, 0x2626)},
{USB_DEVICE(0x093a, 0x2628)},
{USB_DEVICE(0x093a, 0x2629), .driver_info = FL_VFLIP},
--
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 1/8]reiserfs:stree.c Fix variable set but not used.
On 13:26 Mon 14 Jun , Justin P. Mattock wrote: > @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct > cpu_key *key, /* Key to s > > pathrelse(search_path); > > - right_neighbor_of_leaf_node = 0; > - > + This hunk introduces whitespace on the empty line, which is not cool. > /* With each iteration of this loop we search through the items in the > current node, and calculate the next current node(next path element) > for the next iteration of this loop.. */ > @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct > cpu_key *key, /* Key to s > starting from the root. */ > block_number = SB_ROOT_BLOCK(sb); > expected_level = -1; > - right_neighbor_of_leaf_node = 0; > - > + Here, too. Most of the patches in this series have similar issues. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.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
[PATCH 2/8]bluetooth/hci_ldisc.c Fix warning: variable 'tty' set but not used
Im getting this while building:
CC [M] drivers/bluetooth/hci_ldisc.o
drivers/bluetooth/hci_ldisc.c: In function 'hci_uart_send_frame':
drivers/bluetooth/hci_ldisc.c:213:21: warning: variable 'tty' set but not used
the below fixed it for me, but am not sure if
it's correct.
Signed-off-by: Justin P. Mattock
---
drivers/bluetooth/hci_ldisc.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 76a1abb..f693dfe 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -210,7 +210,6 @@ static int hci_uart_close(struct hci_dev *hdev)
static int hci_uart_send_frame(struct sk_buff *skb)
{
struct hci_dev* hdev = (struct hci_dev *) skb->dev;
- struct tty_struct *tty;
struct hci_uart *hu;
if (!hdev) {
@@ -222,8 +221,7 @@ static int hci_uart_send_frame(struct sk_buff *skb)
return -EBUSY;
hu = (struct hci_uart *) hdev->driver_data;
- tty = hu->tty;
-
+
BT_DBG("%s: type %d len %d", hdev->name, bt_cb(skb)->pkt_type,
skb->len);
hu->proto->enqueue(hu, skb);
--
1.7.1.rc1.21.gf3bd6
--
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 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
Im getting this warning when compiling: CC drivers/char/tpm/tpm.o drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt': drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used The below patch gets rid of the warning, but I'm not sure if it's the best solution. Signed-off-by: Justin P. Mattock --- drivers/char/tpm/tpm.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c index 05ad4a1..3d685dc 100644 --- a/drivers/char/tpm/tpm.c +++ b/drivers/char/tpm/tpm.c @@ -514,6 +514,8 @@ void tpm_gen_interrupt(struct tpm_chip *chip) rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, "attempting to determine the timeouts"); + if (!rc) + rc = 0; } EXPORT_SYMBOL_GPL(tpm_gen_interrupt); -- 1.7.1.rc1.21.gf3bd6 -- 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 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
could be a right solution, could be wrong here is the warning: CC drivers/i2c/i2c-core.o drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used Signed-off-by: Justin P. Mattock --- drivers/i2c/i2c-core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 1cca263..79c6c26 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) mutex_lock(&core_lock); dummy = bus_for_each_drv(&i2c_bus_type, NULL, adap, __process_new_adapter); + if(!dummy) + dummy = 0; mutex_unlock(&core_lock); return 0; -- 1.7.1.rc1.21.gf3bd6 -- 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 3/8]char/hpet.c Fix variable 'hpet' set but not used
The below fixes this warning:
drivers/char/hpet.c: In function 'hpet_ioctl_common':
drivers/char/hpet.c:559:23: warning: variable 'hpet' set but not used
please have a look.
Signed-off-by: Justin P. Mattock
---
drivers/char/hpet.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index a0a1829..7932858 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -556,7 +556,6 @@ static int
hpet_ioctl_common(struct hpet_dev *devp, int cmd, unsigned long arg, int
kernel)
{
struct hpet_timer __iomem *timer;
- struct hpet __iomem *hpet;
struct hpets *hpetp;
int err;
unsigned long v;
@@ -568,7 +567,6 @@ hpet_ioctl_common(struct hpet_dev *devp, int cmd, unsigned
long arg, int kernel)
case HPET_DPI:
case HPET_IRQFREQ:
timer = devp->hd_timer;
- hpet = devp->hd_hpet;
hpetp = devp->hd_hpets;
break;
case HPET_IE_ON:
--
1.7.1.rc1.21.gf3bd6
--
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 1/8]reiserfs:stree.c Fix variable set but not used.
Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock --- fs/reiserfs/stree.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c index 313d39d..73086ad 100644 --- a/fs/reiserfs/stree.c +++ b/fs/reiserfs/stree.c @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s struct buffer_head *bh; struct path_element *last_element; int node_level, retval; - int right_neighbor_of_leaf_node; int fs_gen; struct buffer_head *reada_bh[SEARCH_BY_KEY_READA]; b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA]; @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + /* repeat search from the root */ continue; } -- 1.7.1.rc1.21.gf3bd6 -- 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 7/8]ieee1394/sdp2 Fix warning: variable 'unit_characteristics' set but not used
Temporary fix until something is resolved to fix the below warning: CC [M] drivers/ieee1394/sbp2.o drivers/ieee1394/sbp2.c: In function 'sbp2_parse_unit_directory': drivers/ieee1394/sbp2.c:1353:6: warning: variable 'unit_characteristics' set but not used Signed-off-by: Justin P. Mattock --- drivers/ieee1394/sbp2.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/ieee1394/sbp2.c b/drivers/ieee1394/sbp2.c index 4565cb5..fcf8bd5 100644 --- a/drivers/ieee1394/sbp2.c +++ b/drivers/ieee1394/sbp2.c @@ -1356,6 +1356,8 @@ static void sbp2_parse_unit_directory(struct sbp2_lu *lu, management_agent_addr = 0; unit_characteristics = 0; + if (!unit_characteristics) + unit_characteristics = 0; firmware_revision = SBP2_ROM_VALUE_MISSING; model = ud->flags & UNIT_DIRECTORY_MODEL_ID ? ud->model_id : SBP2_ROM_VALUE_MISSING; -- 1.7.1.rc1.21.gf3bd6 -- 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 5/8]drm:drm_gem Fix warning: variable 'dev' set but not used
Probably not even a fix for this warning: CC [M] drivers/gpu/drm/drm_gem.o drivers/gpu/drm/drm_gem.c: In function 'drm_gem_handle_delete': drivers/gpu/drm/drm_gem.c:188:21: warning: variable 'dev' set but not used Signed-off-by: Justin P. Mattock --- drivers/gpu/drm/drm_gem.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 33dad3f..e8180c9 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -206,6 +206,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle) return -EINVAL; } dev = obj->dev; + if (!dev) + dev = 0; /* Release reference and decrement refcount. */ idr_remove(&filp->object_idr, handle); -- 1.7.1.rc1.21.gf3bd6 -- 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 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
not sure if this is correct or not for fixing this warning: CC [M] drivers/media/common/tuners/tuner-simple.o drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' set but not used Signed-off-by: Justin P. Mattock --- drivers/media/common/tuners/tuner-simple.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/common/tuners/tuner-simple.c b/drivers/media/common/tuners/tuner-simple.c index 8abbcc5..4465b99 100644 --- a/drivers/media/common/tuners/tuner-simple.c +++ b/drivers/media/common/tuners/tuner-simple.c @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, struct tuner_simple_priv *priv = fe->tuner_priv; u8 config, cb; u16 div; - struct tunertype *tun; u8 buffer[4]; int rc, IFPCoff, i; enum param_type desired_type; struct tuner_params *t_params; - tun = priv->tun; - + /* IFPCoff = Video Intermediate Frequency - Vif: 940 =16*58.75 NTSC/J (Japan) 732 =16*45.75 M/N STD -- 1.7.1.rc1.21.gf3bd6 -- 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 0/8] Fix gcc 4.6.0 set but not used warning messages.
First and foremost, I must thank anybody taking the time to even look at these(I know you people have better things to be doing). And secondly here is my try at trying to fix some of the warning messages spammed by gcc 4.6.0 when building the kernel. Some of them I removed, and some of them I just shut off. Note: Removing the code does seem like a good approach(if it's actually dead), but if not then something needs to be fixed. As for shutting off the code to shutup gcc does seem like a temporary fix, but would rather have a warning message, than see it get lost in the sands of time. In any case Thanks for taking the time, and hopefully we can get fixes for all of this mess generated by gcc.. Justin P. Mattock -- 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
Problems with Technisat Skystar HD S2 USB and VDR
Dear Group, i have a Technisat Skystar USB HD S2 Box working in my VDR. But when tuning to channels in the lowband e.g. "Das Erste HD" or "TVP Info" it seems that the driver gets no lock. Jun 14 22:07:23 proykon vdr: [24686] TS buffer on device 1 thread started (pid=24245, tid=24686) .. Jun 14 22:07:30 proykon kernel: [115652.858425] stb6100_set_frequency: Frequency=1023000 Jun 14 22:07:30 proykon kernel: [115652.894298] stb6100_get_frequency: Frequency=1022994 Jun 14 22:07:30 proykon kernel: [115652.935547] stb6100_get_bandwidth: Bandwidth=5200 Jun 14 22:07:31 proykon kernel: [115653.915758] stb6100_set_bandwidth: Bandwidth=5161 Jun 14 22:07:31 proykon kernel: [115653.951506] stb6100_get_bandwidth: Bandwidth=5200 Jun 14 22:07:31 proykon kernel: [115654.030503] stb6100_get_bandwidth: Bandwidth=5200 Jun 14 22:07:31 proykon kernel: [115654.162495] stb6100_set_frequency: Frequency=1023000 Jun 14 22:07:31 proykon kernel: [115654.198120] stb6100_get_frequency: Frequency=1022994 Jun 14 22:07:31 proykon kernel: [115654.239870] stb6100_get_bandwidth: Bandwidth=5200 Jun 14 22:07:32 proykon vdr: [24251] frontend 0/0 timed out while tuning to channel 673, tp 110773 Jun 14 22:07:32 proykon kernel: [115655.135586] stb6100_set_bandwidth: Bandwidth=5161 Jun 14 22:07:32 proykon kernel: [115655.171083] stb6100_get_bandwidth: Bandwidth=5200 . Linux proykon 2.6.34 #2 SMP Wed Jun 2 21:49:57 CEST 2010 i686 GNU/Linux I use the DVB driver of the repository s2-liplianin Does anybody know such a problem? Regards Martin Berndaner -- 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
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:Mon Jun 14 19:00:11 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14977:23492745405c git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 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.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS 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.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS 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 linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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: genius islim 310 webcam test
On Mon, 14 Jun 2010 16:58:15 +0200 Németh Márton wrote: > Hi Jean-Francois, I got this report about a working Genius iSlim 310 > webcam. Maybe it would be a good idea to add the device 0x093a:0x2625 > in pac7302.c. Should I send a patch for you? Hi Németh, OK for the patch. Don't forget to add the webcam in the file Documentation/video4linux/gspca.txt. Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: [Bug #15589] 2.6.34-rc1: Badness at fs/proc/generic.c:316
On Mon, Jun 14, 2010 at 12:39 AM, Alexey Dobriyan wrote: > On Sun, Jun 13, 2010 at 01:57:40PM -0600, Grant Likely wrote: >> On brief review, they look like completely different issues. I doubt >> the second patch will fix the flexcop-pci issue. > > It will, see how name wht slashes propagated by request_irq() I think we've crossed wires. By second patch I mean the patch that changes OF code. That change has absolutely no bearing on the flexcop-pci driver. The patch to the flexcop-pci driver looks correct to me, but it is completely unrelated to the OF badness. g. -- 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: genius islim 310 webcam test
Hi Sergei, thanks for the report.
Hi Jean-Francois, I got this report about a working Genius iSlim 310
webcam. Maybe it would be a good idea to add the device 0x093a:0x2625
in pac7302.c. Should I send a patch for you?
Regards,
Márton Németh
Krivchikov Sergei wrote:
> Hi! All works.
> From: http://forum.ubuntu.ru/index.php?topic=9767.msg717310#msg717310
> and
> http://stemp.wordpress.com/2009/11/03/karmic-get-the-latest-drivers-for-gspca-uvc-usbvideo-and-other/
>
> |1. sudo aptitude install mercurial build-essential linux-headers
> libncurses5-dev
> ||2. hg clone http://linuxtv.org/hg/v4l-dvb/
> ||3. cd v4l-dvb
> 4. Add to | v4l-dvb/linux/drivers/media/video/gspca/pac7302.c in section
>
> /* -- module initialisation -- */
> static const struct usb_device_id device_table[] __devinitconst = {
> {USB_DEVICE(0x06f8, 0x3009)},
> {USB_DEVICE(0x093a, 0x2620)},
> {USB_DEVICE(0x093a, 0x2621)},
> {USB_DEVICE(0x093a, 0x2622), .driver_info = FL_VFLIP},
>
> {USB_DEVICE(0x093a, 0x2624), .driver_info = FL_VFLIP},
> * {USB_DEVICE(0x093a, 0x2625)}*,
> {USB_DEVICE(0x093a, 0x2626)},
> {USB_DEVICE(0x093a, 0x2628)},
> {USB_DEVICE(0x093a, 0x2629), .driver_info = FL_VFLIP},
>
> {USB_DEVICE(0x093a, 0x262a)},
> {USB_DEVICE(0x093a, 0x262c)},
> {}
> };
>
>
>
> |5. sudo cp /boot/config-`uname -r` v4l/.config|
> |6. sudo make menuconfig|
> Set in "Multimedia Support -> Video Capture adapters -> V4L USB
> devices -> GSPCA -> pac7302.c and Uncheck all other devices if you want.
> |7. make
> 8. sudo make install|
>
>
> Thanks!
--
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: Problem with em28xx card, PAL and teletext
On Sun, Jun 13, 2010 at 11:21 PM, Eugeniy Meshcheryakov wrote: > Thanks, that patch fixes the shifting problem, all the pixels are in the > right place. Ok, I'll issue a PULL request to get that upstream. Thanks for testing. >> In the meantime though, >> you can work around the issue by cropping out the lines with the >> following command: >> >> /usr/bin/mplayer -vo xv,x11 tv:// -tv >> driver=v4l2:device=/dev/video0:norm=PAL:width=720:height=576:input=1 >> -vf crop=720:572:0:0 > Thanks for the tip. It worked with 640x480. But when I tried to use > 720x576 I got a picture with a lot of noise made of horizontal white > lines. However maybe it is because of damaged USB connector... If you email me a screenshot (preferably off list due to the size), I can probably provide some additional advice. Also please provide the exact mplayer command you used so I can try to reproduce it here. > Also teletext is still unreadable (both with 640x480 and 720x576). Does > mplayer support teletext correctly? And can it work with resolution > 640x480? I don't know how good mplayer's teletext support is. When I did the original work, I did the testing using "mtt", and in fact I had to do it over an SSH link since I didn't have a teletext feed here. It should work at 640x480 though. I would suggest you try it with mtt/tvtime at 720x576 and see if it works. If it does, then we have a starting point to narrow down whether it's an issue with the application, the selected capture resolution, the driver itself, or something strange about the teletext feed itself. Cheers, 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: [Bug #15589] 2.6.34-rc1: Badness at fs/proc/generic.c:316
On Mon, 14 Jun 2010 09:39:48 +0300 Alexey Dobriyan wrote: > On Sun, Jun 13, 2010 at 01:57:40PM -0600, Grant Likely wrote: > > On brief review, they look like completely different issues. I > > doubt the second patch will fix the flexcop-pci issue. > > It will, see how name wht slashes propagated by request_irq() Yes, the latter patch dodges the issue with flexcop driver by simply skipping the directory creation, but both patches should be applied IMO. The former to fix the flexcop driver because we can trivially fix it, the latter to solve problems with any generic bogus firmware. -- Jindrich Makovicka -- 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: Kernel oops with new IR modules
On Sun, 2010-06-13 at 19:55 -0700, Timothy D. Lenz wrote: > I tried to build new drivers from v4l hg for 06/08/10 and when I tried > to load drivers I got a kernel oops. Kernel is 2.6.34 64bit for amd cpu > > http://pastebin.com/7KwJtFJg See: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/20198 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/19904 The Oops appears to be in the same place as the Oops I analyzed in the second link. However, your compiler, like mine, decides to code the comparison against RC_DRIVER_SCANCODE (which is 0) first: 4f: 83 3a 00 cmpl $0x0,(%rdx)<-- Oopsing insn Right about here: http://linuxtv.org/hg/v4l-dvb/file/23492745405c/linux/drivers/media/IR/ir-sysfs.c#l226 As mentioned in the first link, please try the patch found here: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=84b14f181a36eea6591779156ef356f8d198bbfd Regards, Andy > Jun 13 14:35:40 x64VDR kernel: IR JVC protocol handler initialized > Jun 13 14:35:40 x64VDR kernel: IR Sony protocol handler initialized > Jun 13 14:35:40 x64VDR kernel: cx23885_dev_checkrevision() Hardware > revision = 0xb0 > Jun 13 14:35:40 x64VDR kernel: cx23885[0]/0: found at :02:00.0, rev: > 2, irq: 16, latency: 0, mmio: 0xfdc0 > Jun 13 14:35:40 x64VDR kernel: cx23885 :02:00.0: setting latency > timer to 64 > Jun 13 14:35:40 x64VDR kernel: IRQ 16/cx23885[0]: IRQF_DISABLED is not > guaranteed on shared IRQs > Jun 13 14:35:40 x64VDR kernel: Registered IR keymap rc-fusionhdtv-mce > Jun 13 14:35:40 x64VDR kernel: BUG: unable to handle kernel NULL pointer > dereference at (null) > Jun 13 14:35:40 x64VDR kernel: IP: [] > ir_register_class+0x4f/0x15f [ir_core] > Jun 13 14:35:40 x64VDR kernel: PGD 7ebdb067 PUD 7ebd3067 PMD 0 > Jun 13 14:35:40 x64VDR kernel: Oops: [#1] PREEMPT SMP > Jun 13 14:35:40 x64VDR kernel: last sysfs file: > /sys/module/ir_core/initstate > Jun 13 14:35:40 x64VDR kernel: CPU 1 > Jun 13 14:35:40 x64VDR kernel: Modules linked in: rc_fusionhdtv_mce > ir_kbd_i2c(+) ir_sony_decoder ir_jvc_decoder ir_rc6_decoder cx23885 > ir_rc5_decoder cx2341x v4l2_common videobuf_dvb ir_common ir_nec_decoder > ir_core btcx_risc tveeprom lnbp21 stv0299 dvb_ttpci dvb_core saa7146_vv > videodev v4l1_compat v4l2_compat_ioctl32 saa7146 videobuf_dma_sg > videobuf_core ttpci_eeprom powernow_k8 hwmon_vid max6650 snd_intel8x0 > snd_ac97_codec ac97_bus smbfs af_packet snd_hda_codec_analog > snd_hda_intel snd_hda_codec snd_pcm snd_seq snd_timer snd_seq_device snd > sg psmouse amd64_edac_mod k8temp fan soundcore snd_page_alloc > asus_atk0110 i2c_nforce2 thermal processor button > Jun 13 14:35:40 x64VDR kernel: > Jun 13 14:35:40 x64VDR kernel: Pid: 1933, comm: modprobe Not tainted > 2.6.34.20100610.1 #1 M2N-E/System Product Name > Jun 13 14:35:40 x64VDR kernel: RIP: 0010:[] > [] ir_register_class+0x4f/0x15f [ir_core] > Jun 13 14:35:40 x64VDR kernel: RSP: 0018:88007e0abd18 EFLAGS: 00010246 > Jun 13 14:35:40 x64VDR kernel: RAX: RBX: > 88007ee5ec00 RCX: a022ae00 > Jun 13 14:35:40 x64VDR kernel: RDX: RSI: > a022a9d4 RDI: 88007ee5ec00 > Jun 13 14:35:40 x64VDR kernel: RBP: R08: > 004f R09: > Jun 13 14:35:40 x64VDR kernel: R10: R11: > 88007ee28808 R12: a029d060 > Jun 13 14:35:40 x64VDR kernel: R13: 88007ee28000 R14: > 0282 R15: a0296aec > Jun 13 14:35:40 x64VDR kernel: FS: 7fdc8355d6f0() > GS:88000170() knlGS: > Jun 13 14:35:40 x64VDR kernel: CS: 0010 DS: ES: CR0: > 8005003b > Jun 13 14:35:40 x64VDR kernel: CR2: CR3: > 7ebd1000 CR4: 06e0 > Jun 13 14:35:40 x64VDR kernel: DR0: DR1: > DR2: > Jun 13 14:35:40 x64VDR kernel: DR3: DR6: > 0ff0 DR7: 0400 > Jun 13 14:35:40 x64VDR kernel: Process modprobe (pid: 1933, threadinfo > 88007e0aa000, task 88007e22a280) > Jun 13 14:35:40 x64VDR kernel: Stack: > Jun 13 14:35:40 x64VDR kernel: 88007ee28000 88007ee5ec00 > 88007ee28000 a029d060 > Jun 13 14:35:40 x64VDR kernel: <0> 002d a022960a > 0001 > Jun 13 14:35:40 x64VDR kernel: <0> 88007ee5ee20 88007ee5edf8 > 88007e0aa000 88007d815600 > Jun 13 14:35:40 x64VDR kernel: Call Trace: > Jun 13 14:35:40 x64VDR kernel: [] ? > __ir_input_register+0x243/0x2e7 [ir_core] > Jun 13 14:35:40 x64VDR kernel: [] ? > ir_probe+0x37f/0x448 [ir_kbd_i2c] > Jun 13 14:35:40 x64VDR kernel: [] ? > ir_probe+0x0/0x448 [ir_kbd_i2c] > Jun 13 14:35:40 x64VDR kernel: [] ? > i2c_device_probe+0xb0/0xe6 > Jun 13 14:35:40 x64VDR kernel: [] ? > driver_sysfs_add+0x42/0x69 > Jun 13 14:35:40 x64VDR kernel: [] ? > driver_pro
Re: [OT] preferred video apps?
On 01.05.2010 03:48, Mauro Carvalho Chehab wrote: > Randy Dunlap wrote: > >> Hi, >> >> Sorry for a non-kernel question, but I'd like to get some suggestions >> on video recording and editing software, please. >> >> If it matters, this is mostly for recording & editing sports events >> (matches). >> >> Reply privately if you prefer ... >> > Please, _do_not_ reply privately ;) > > We should build a relation of the userspace applications we need to care when > testing for regressions, so, this is not OT. It would be nice to hear what are > the preferred open source applications. > > From my side, those are the applications I use: > analog: xawtv 3, xawtv 4, tvtime, mencoder, ffmpeg > > Only mencoder and ffmpeg can record - but xawtv (and xdtv) call them. > gstreamer can record too :) A few examples: stream to screen: gst-launch v4l2src ! xvimagesink capture 1 image gst-launch v4l2src num-buffers=1 ! jpegenc ! filesink location="test.jpeg" stream to screen and capture video (-e is needed to terminate video on ctrl-c) gst-launch -e v4l2src ! tee name=t ! queue ! xvimagesink t. ! ffenc_mpeg4 ! avimux ! filesink location="video.avi" same as before, but select resolution and framerate gst-launch -e v4l2src ! "video/x-raw-yuv,width=320,height=240,framerate=(fraction)15/1" ! tee name=t ! queue ! xvimagesink t. ! ffenc_mpeg4 ! avimux ! filesink location="video.avi" (see man gst-launch-0.10 for more examples) Stefan > On digital side, I use kaffeine, gnutv and vlc. Kaffeine and gnutv can > record. > Not sure about vlc. > > mplayer is capable of working with both analog and digital (and, by > consequence, > mencoder). > > Although I don't use, mythtv and vdr are also very popular applications. > AFAIK, > both have record support. > > -- 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: Attempting to use 2 KWorld PlusTV Dual DVB-T PCI tuners
Ah, looks like it was a PCI slot thing, moved the second card into a different slot and all seems to be working well. Sorry for the noise, Martyn On Wed, 09 Jun 2010 12:08:25 +0100, Martyn Welch wrote: > Hi, > > I'm attempting to use 2 (I believe identical) KWorld PlusTV Dual DVB-T PCI > tuners in my system. I have downloaded the firmware and at boot can see the > cards being (nearly) successfully detected. It seems that both turners are > being detected on one card, but only one on the second. > > I haven't had much time to test the cards and I'm afraid I'm not near the > box to be able to provide the boot log at the moment. Looking through the > code I can see "static struct dvb_usb_device_properties > af9015_properties[3];" here: > > http://lxr.linux.no/#linux+v2.6.32/drivers/media/dvb/dvb-usb/af9015.c#L43 > > Which suggests to me that it's only going to be able to register 3 tuners > (or is it 3 cards?), is that the case? > > Martyn -- 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
