Re: cx23885 - regression between 4.17.x and 4.18.x

[Vincent McIntyre]

On Thu, Sep 13, 2018 at 06:39:57PM +0100, David R wrote:
> Hi
> 
> Just a heads up. I'm having to revert cx23885-core.c to the 4.17 version
> to obtain stability with my old AMD Phenom/ASUS M4A785TD and Hauppauge
> WinTV-HVR-5525. The latest code drops out and refuses to return video
> streams in hours or a few days max. The 4.17 version is fine and stable
> over weeks/months.
> 
> 04:00.0 Multimedia video controller: Conexant Systems, Inc. CX23887/8
> PCIe Broadcast Audio and Video Decoder with 3D Comb (rev 04)
>     Subsystem: Hauppauge computer works Inc. Device f038
>     Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR+ FastB2B- DisINTx-
>     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> SERR-      Latency: 0, Cache Line Size: 64 bytes
>     Interrupt: pin A routed to IRQ 17
>     Region 0: Memory at fe80 (64-bit, non-prefetchable) [size=2M]
>     Capabilities: 
>     Kernel driver in use: cx23885

Interesting. cx88 also seems to have regressed.
Are you able to give a git commit range for what works & doesn't work?

I asked Adam to try building the modules with media-build
but have not heard anything further.

Date: Sat, 8 Sep 2018 20:49:22 -0400
From: Adam Stylinski 
To: linux-media@vger.kernel.org
Subject: 4.18 regression

Hello,

I haven't done a thorough bisection of kernel revisions, but moving from 
kernel 4.17.19
to 4.18.6 results in mythtv being unable to tune in any channel with a pic 
hdtv 5500
tuner (cx88 based device with an LG frontend). I get an error back from the 
channel
scanner about not being able to measure signal strength and getting back an 
error unknown
(errno 254).

I was able to use dvbtools with get-atsc to get a channel, but I don't 
think any of the
forward error correction was applied to it.

Let me know if you need more details.

Vince

Re: more build failures

[Vincent McIntyre]

On Sat, Dec 16, 2017 at 09:30:46AM -0200, Mauro Carvalho Chehab wrote:
> 
> Just pushed two patches to media build, in order to address those
> issues. Here, it is now compiling fine with Kernel 4.4.59.
> 

Yep, working again. Thank you for taking the time to sort this out.

Regards
Vince

Re: more build failures

[Vincent McIntyre]

On Fri, Dec 15, 2017 at 11:41:13PM +1100, Vincent McIntyre wrote:
> 
> ...
> 
> $ make allyesconfig
> make -C /home/me/git/clones/media_build/v4l allyesconfig
> make[1]: Entering directory '/home/me/git/clones/media_build/v4l'
> No version yet, using 4.4.0-103-generic
> make[2]: Entering directory '/home/me/git/clones/media_build/linux'
> Syncing with dir ../media/
> Applying patches for kernel 4.4.0-103-generic
> patch -s -f -N -p1 -i ../backports/api_version.patch
> patch -s -f -N -p1 -i ../backports/pr_fmt.patch
> patch -s -f -N -p1 -i ../backports/debug.patch
> patch -s -f -N -p1 -i ../backports/drx39xxj.patch
> patch -s -f -N -p1 -i ../backports/v4.14_compiler_h.patch
> patch -s -f -N -p1 -i ../backports/v4.14_saa7146_timer_cast.patch
> patch -s -f -N -p1 -i ../backports/v4.14_module_param_call.patch
> patch -s -f -N -p1 -i ../backports/v4.12_revert_solo6x10_copykerneluser.patch
> patch -s -f -N -p1 -i ../backports/v4.10_sched_signal.patch
> 1 out of 1 hunk FAILED
> The text leading up to this was:
> --
> |diff --git a/drivers/staging/media/lirc/lirc_zilog.c 
> b/drivers/staging/media/lirc/lirc_zilog.c
> |index 015e41bd036e..fd61081b47d9 100644
> |--- a/drivers/staging/media/lirc/lirc_zilog.c
> |+++ b/drivers/staging/media/lirc/lirc_zilog.c
> --
> No file to patch.  Skipping patch.
> 1 out of 1 hunk ignored
> Makefile:130: recipe for target 'apply_patches' failed
> make[2]: *** [apply_patches] Error 1
> make[2]: Leaving directory '/home/me/git/clones/media_build/linux'
> Makefile:374: recipe for target 'allyesconfig' failed
> make[1]: *** [allyesconfig] Error 2
> make[1]: Leaving directory '/home/me/git/clones/media_build/v4l'
> Makefile:26: recipe for target 'allyesconfig' failed
> make: *** [allyesconfig] Error 2
> can't select all drivers at ./build line 525
> + status=29
> + date
> Friday 15 December  23:29:17 AEDT 2017
> + [ 0 = 29 ]

I managed to get past the failure above with this change

 - media: rc: move ir-lirc-codec.c contents into lirc_dev.c
   media: lirc: remove last remnants of lirc kapi
 - Sean removed lirc_zilog.c, so it no longer needs patching

--- a/backports/v4.10_sched_signal.patch
+++ b/backports/v4.10_sched_signal.patch
@@ -195,19 +195,6 @@ index 0e8025b7b4dd..8c59d4f53200 100644
  #include 
  #include 
  #include 
-diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
-index db1e7b70c998..fc03068e22b5 100644
 a/drivers/media/rc/lirc_dev.c
-+++ b/drivers/media/rc/lirc_dev.c
-@@ -18,7 +18,7 @@
- #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
- 
- #include 
--#include 
-+#include 
- #include 
- #include 
- #include 
 diff --git a/drivers/media/usb/cpia2/cpia2_core.c 
b/drivers/media/usb/cpia2/cpia2_core.c
 index 0efba0da0a45..5d8aa65ab40b 100644
 --- a/drivers/media/usb/cpia2/cpia2_core.c
@@ -246,19 +233,6 @@ index 0b5c43f7e020..36bd904946bd 100644
  #include 
  #include 
  
-diff --git a/drivers/staging/media/lirc/lirc_zilog.c 
b/drivers/staging/media/lirc/lirc_zilog.c
-index 015e41bd036e..fd61081b47d9 100644
 a/drivers/staging/media/lirc/lirc_zilog.c
-+++ b/drivers/staging/media/lirc/lirc_zilog.c
-@@ -42,7 +42,7 @@
- #include 
- #include 
- #include 
--#include 
-+#include 
- #include 
- #include 
- #include 


However it falls over later in a way I don't think I can help with.

...
  CC [M]  /home/me/git/clones/media_build/v4l/pvrusb2-i2c-core.o
  CC [M]  /home/me/git/clones/media_build/v4l/pvrusb2-audio.o
  CC [M]  /home/me/git/clones/media_build/v4l/pvrusb2-encoder.o
  CC [M]  /home/me/git/clones/media_build/v4l/pvrusb2-video-v4l.o
  CC [M]  /home/me/git/clones/media_build/v4l/pvrusb2-eeprom.o
  CC [M]  /home/me/git/clones/media_build/v4l/pvrusb2-main.o
  CC [M]  /home/me/git/clones/media_build/v4l/pvrusb2-hdw.o
/home/me/git/clones/media_build/v4l/pvrusb2-hdw.c: In function 
'pvr2_send_request_ex':
/home/me/git/clones/media_build/v4l/pvrusb2-hdw.c:3651:7: error: implicit 
declaration of function 'usb_urb_ep_type_check' 
[-Werror=implicit-function-declaration]
   if (usb_urb_ep_type_check(hdw->ctl_write_urb)) {
   ^
cc1: some warnings being treated as errors
scripts/Makefile.build:258: recipe for target 
'/home/me/git/clones/media_build/v4l/pvrusb2-hdw.o' failed
make[3]: *** [/home/me/git/clones/media_build/v4l/pvrusb2-hdw.o] Error 1
Makefile:1423: recipe for target '_module_/home/me/git/clones/media_build/v4l' 
failed
make[2]: *** [_module_/home/me/git/clones/media_build/v4l] Error 2
make[2]: Leaving directory '/usr/src/linux-headers-4.4.0-103-generic'
Makefile:51: recipe for target 'default' failed
make[1]: *** [default] Error 2
make[1]: Leaving directory '/home/me/git/clones/media_build/v4l'
Makefile:26: recipe for target 'all' failed
make: *** [all] Error 2

Cheers
Vince

more build failures

[Vincent McIntyre]

Hi,

Don't get me wrong, I appreciate the vast amount of work going on here.
Just letting you know what I'm seeing.

+ date
Friday 15 December  23:28:52 AEDT 2017
+ uname -a
Linux ubuntu 4.4.0-103-generic #126-Ubuntu SMP Mon Dec 4 16:23:28 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux
+ cat /proc/version_signature
Ubuntu 4.4.0-103.126-generic 4.4.98

...

+ git --no-pager log -1
commit 4058fea6b2507661d66af5298c048d7c55338f42
Author: Jasmin Jessich 
Date:   Tue Dec 12 12:49:01 2017 -0500

fixup v3.13_ddbridge_pcimsi.patch

Required after the ddbridge 0.9.32 bump in media_tree.

Signed-off-by: Jasmin Jessich 
Signed-off-by: Daniel Scheller 

...

+ git --no-pager log -1
commit 0393e735649dc41358adb7b603bd57dad1ed3260
Author: Laurent Pinchart 
Date:   Tue Oct 17 13:15:54 2017 -0400

media: uvcvideo: Stream error events carry no data

According to the UVC specification, stream error events carry no data.
Fix a buffer overflow (that should be harmless given data alignment)
when reporting the stream error event by removing the data byte from the
message.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 

...

$ make allyesconfig
make -C /home/me/git/clones/media_build/v4l allyesconfig
make[1]: Entering directory '/home/me/git/clones/media_build/v4l'
No version yet, using 4.4.0-103-generic
make[2]: Entering directory '/home/me/git/clones/media_build/linux'
Syncing with dir ../media/
Applying patches for kernel 4.4.0-103-generic
patch -s -f -N -p1 -i ../backports/api_version.patch
patch -s -f -N -p1 -i ../backports/pr_fmt.patch
patch -s -f -N -p1 -i ../backports/debug.patch
patch -s -f -N -p1 -i ../backports/drx39xxj.patch
patch -s -f -N -p1 -i ../backports/v4.14_compiler_h.patch
patch -s -f -N -p1 -i ../backports/v4.14_saa7146_timer_cast.patch
patch -s -f -N -p1 -i ../backports/v4.14_module_param_call.patch
patch -s -f -N -p1 -i ../backports/v4.12_revert_solo6x10_copykerneluser.patch
patch -s -f -N -p1 -i ../backports/v4.10_sched_signal.patch
1 out of 1 hunk FAILED
The text leading up to this was:
--
|diff --git a/drivers/staging/media/lirc/lirc_zilog.c 
b/drivers/staging/media/lirc/lirc_zilog.c
|index 015e41bd036e..fd61081b47d9 100644
|--- a/drivers/staging/media/lirc/lirc_zilog.c
|+++ b/drivers/staging/media/lirc/lirc_zilog.c
--
No file to patch.  Skipping patch.
1 out of 1 hunk ignored
Makefile:130: recipe for target 'apply_patches' failed
make[2]: *** [apply_patches] Error 1
make[2]: Leaving directory '/home/me/git/clones/media_build/linux'
Makefile:374: recipe for target 'allyesconfig' failed
make[1]: *** [allyesconfig] Error 2
make[1]: Leaving directory '/home/me/git/clones/media_build/v4l'
Makefile:26: recipe for target 'allyesconfig' failed
make: *** [allyesconfig] Error 2
can't select all drivers at ./build line 525
+ status=29
+ date
Friday 15 December  23:29:17 AEDT 2017
+ [ 0 = 29 ]

Re: [PATCH] build: Added missing timer_setup_on_stack

[Vincent McIntyre]

On Sat, Dec 09, 2017 at 09:00:18AM +0100, Hans Verkuil wrote:
> I misapplied a pr_fmt patch. It's now fixed.
> 

Indeed, the build goes fine now. Thank you both again.
Cheers
Vince

Re: [PATCH] build: Added missing timer_setup_on_stack

[Vincent McIntyre]

On Fri, Dec 08, 2017 at 10:12:05PM +0100, Hans Verkuil wrote:
...
> 
> I've applied all your patches. Thank you very much for working on this.
> 
> Let's see what the result of the nightly build will be.
> 
> In general reverting kernel patches to make a driver compile is something of a
> last resort. It tends to be painful to maintain in the long run, at least, 
> that's
> been my experience.
> 

Hi,

thanks both for your work on this. Not quite there yet however.

$ make allyesconfig
make -C /home/me/git/clones/media_build/v4l allyesconfig
make[1]: Entering directory '/home/me/git/clones/media_build/v4l'
No version yet, using 4.4.0-103-generic
make[2]: Entering directory '/home/me/git/clones/media_build/linux'
Syncing with dir ../media/
Applying patches for kernel 4.4.0-103-generic
patch -s -f -N -p1 -i ../backports/api_version.patch
patch -s -f -N -p1 -i ../backports/pr_fmt.patch
1 out of 1 hunk FAILED
Makefile:130: recipe for target 'apply_patches' failed
make[2]: *** [apply_patches] Error 1
make[2]: Leaving directory '/home/me/git/clones/media_build/linux'
Makefile:374: recipe for target 'allyesconfig' failed
make[1]: *** [allyesconfig] Error 2
make[1]: Leaving directory '/home/me/git/clones/media_build/v4l'
Makefile:26: recipe for target 'allyesconfig' failed
make: *** [allyesconfig] Error 2
can't select all drivers at ./build line 525
+ status=29

FWIW I also get the same failure on a 4.10 machine:
+ cat /proc/version_signature
Ubuntu 4.10.0-38.42~16.04.1-generic 4.10.17

I will have a look to see if I can spot this one.
Cheers
Vince

build failure on ubuntu 16.04 LTS

[Vincent McIntyre]

Hi,

the build has been broken for over a week for me.
Possibly my checkout is out of date??
I am using the normal build --main-git method.

Setup details:

+ date
Wednesday 6 December  21:25:28 AEDT 2017
+ uname -a
Linux ubuntu 4.4.0-101-generic #124-Ubuntu SMP Fri Nov 10 18:29:59 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux
+ cat /proc/version_signature
Ubuntu 4.4.0-101.124-generic 4.4.95

+ git --no-pager log -1
commit 320b9b80ebbf318a67a9479c18a0e4be244c8409
Author: Hans Verkuil 
Date:   Tue Nov 28 08:48:04 2017 +0100

Update backports/pr_fmt.patch

Signed-off-by: Hans Verkuil 

+ cd media
+ git --no-pager log -1
commit 781b045baefdabf7e0bc9f33672ca830d3db9f27
Author: Sakari Ailus 
Date:   Wed Nov 1 05:40:58 2017 -0400

media: imx274: Fix error handling, add MAINTAINERS entry

Add the missing MAINTAINERS entry for imx274, fix error handling in driver
probe and unregister the correct control handler in driver remove.

Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 


This is the build failure
...

Created default (all yes) .config file
./scripts/fix_kconfig.pl
make[1]: Leaving directory '/home/me/git/clones/media_build/v4l'
$ make
make -C /home/me/git/clones/media_build/v4l
make[1]: Entering directory '/home/me/git/clones/media_build/v4l'
scripts/make_makefile.pl
./scripts/make_myconfig.pl
perl scripts/make_config_compat.pl /lib/modules/4.4.0-101-generic/build 
./.myconfig ./config-compat.h
creating symbolic links...
Kernel build directory is /lib/modules/4.4.0-101-generic/build
make -C ../linux apply_patches
make[2]: Entering directory '/home/me/git/clones/media_build/linux'
Syncing with dir ../media/
Patches for 4.4.0-101-generic already applied.
make[2]: Leaving directory '/home/me/git/clones/media_build/linux'
make -C /lib/modules/4.4.0-101-generic/build 
SUBDIRS=/home/me/git/clones/media_build/v4l  modules
make[2]: Entering directory '/usr/src/linux-headers-4.4.0-101-generic'
  CC [M]  /home/me/git/clones/media_build/v4l/msp3400-driver.o
In file included from include/linux/compiler.h:56:0,
 from include/asm-generic/bug.h:4,
 from ./arch/x86/include/asm/bug.h:35,
 from include/linux/bug.h:4,
 from include/linux/mmdebug.h:4,
 from /home/me/git/clones/media_build/v4l/config-compat.h:12,
 from /home/me/git/clones/media_build/v4l/compat.h:10,
 from :0:
/home/me/git/clones/media_build/v4l/../linux/include/linux/compiler-gcc.h:3:2: 
error: #error "Please don't include  directly, include 
 instead."
 #error "Please don't include  directly, include 
 instead."
  ^
scripts/Makefile.build:258: recipe for target 
'/home/me/git/clones/media_build/v4l/msp3400-driver.o' failed
make[3]: *** [/home/me/git/clones/media_build/v4l/msp3400-driver.o] Error 1
Makefile:1423: recipe for target '_module_/home/me/git/clones/media_build/v4l' 
failed
make[2]: *** [_module_/home/me/git/clones/media_build/v4l] Error 2
make[2]: Leaving directory '/usr/src/linux-headers-4.4.0-101-generic'
Makefile:51: recipe for target 'default' failed
make[1]: *** [default] Error 2
make[1]: Leaving directory '/home/me/git/clones/media_build/v4l'
Makefile:26: recipe for target 'all' failed
make: *** [all] Error 2
build failed at ./build line 526
+ status=29

I'm struggling to follow the depedency chain here so I thought I'd better ask.

ubuntu(master)$ grep -r compiler-gcc.h|grep -F '#include'

media/include/linux/compiler_types.h:#include 
media/tools/include/linux/compiler.h:#include 

Cheers
Vince

Re: broken build against 4.4.0

[Vincent McIntyre]

On Sun, Nov 05, 2017 at 01:55:22PM +0100, Jasmin J. wrote:
> Hello Vincent!
> 
> > can someone take a look please?
> Well, Matthias may have fixed that (I didn't try).
> 
> See:
>   https://www.mail-archive.com/linux-media@vger.kernel.org/msg121610.html
> 
> Maybe you need that also:
>   https://www.mail-archive.com/linux-media@vger.kernel.org/msg121625.html
> 

It seems Hans applied this a couple of hours ago - thank you Hans!
The build completes just fine now.

Cheers
Vince

broken build against 4.4.0

[Vincent McIntyre]

Hi,
can someone take a look please?

+ uname -a
Linux ubuntu 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux
+ cat /proc/version_signature
Ubuntu 4.4.0-97.120-generic 4.4.87

This was with a fresh clone,

+ git --no-pager log -1
commit c93534951f5d66bef7f17f16293acf2be346b726
Author: Jasmin Jessich 
Date:   Sat Oct 14 01:41:32 2017 +0200

build: Fixed patches for Kernel 2.6.35

Signed-off-by: Jasmin Jessich 
Signed-off-by: Hans Verkuil 

...

make[2]: Leaving directory '/home/me/git/clones/media_build/linux'
make -C /lib/modules/4.4.0-97-generic/build 
SUBDIRS=/home/me/git/clones/media_buildmodules
make[2]: Entering directory '/usr/src/linux-headers-4.4.0-97-generic'
  CC [M]  /home/me/git/clones/media_build/v4l/msp3400-driver.o
  CC [M]  /home/me/git/clones/media_build/v4l/msp3400-kthreads.o
  LD [M]  /home/me/git/clones/media_build/v4l/msp3400.o
  CC [M]  /home/me/git/clones/media_build/v4l/smiapp-core.o
  CC [M]  /home/me/git/clones/media_build/v4l/smiapp-regs.o
  CC [M]  /home/me/git/clones/media_build/v4l/smiapp-quirk.o
  CC [M]  /home/me/git/clones/media_build/v4l/smiapp-limits.o
  LD [M]  /home/me/git/clones/media_build/v4l/smiapp.o
  CC [M]  /home/me/git/clones/media_build/v4l/et8ek8_mode.o
  CC [M]  /home/me/git/clones/media_build/v4l/et8ek8_driver.o
  LD [M]  /home/me/git/clones/media_build/v4l/et8ek8.o
  CC [M]  /home/me/git/clones/media_build/v4l/cx25840-core.o
  CC [M]  /home/me/git/clones/media_build/v4l/cx25840-audio.o
  CC [M]  /home/me/git/clones/media_build/v4l/cx25840-firmware.o
  CC [M]  /home/me/git/clones/media_build/v4l/cx25840-vbi.o
  CC [M]  /home/me/git/clones/media_build/v4l/cx25840-ir.o
  LD [M]  /home/me/git/clones/media_build/v4l/cx25840.o
  CC [M]  /home/me/git/clones/media_build/v4l/m5mols_core.o
  CC [M]  /home/me/git/clones/media_build/v4l/m5mols_controls.o
  CC [M]  /home/me/git/clones/media_build/v4l/m5mols_capture.o
  LD [M]  /home/me/git/clones/media_build/v4l/m5mols.o
  CC [M]  /home/me/git/clones/media_build/v4l/imx074.o
  CC [M]  /home/me/git/clones/media_build/v4l/mt9m001.o
  CC [M]  /home/me/git/clones/media_build/v4l/mt9t031.o
  CC [M]  /home/me/git/clones/media_build/v4l/mt9t112.o
  CC [M]  /home/me/git/clones/media_build/v4l/mt9v022.o
  CC [M]  /home/me/git/clones/media_build/v4l/ov5642.o
  CC [M]  /home/me/git/clones/media_build/v4l/ov772x.o
  CC [M]  /home/me/git/clones/media_build/v4l/ov9640.o
  CC [M]  /home/me/git/clones/media_build/v4l/ov9740.o
  CC [M]  /home/me/git/clones/media_build/v4l/rj54n1cb0c.o
  CC [M]  /home/me/git/clones/media_build/v4l/tw9910.o
  CC [M]  /home/me/git/clones/media_build/v4l/aptina-pll.o
  CC [M]  /home/me/git/clones/media_build/v4l/tvaudio.o
/home/me/git/clones/media_build/v4l/tvaudio.c: In function 'chip_thread_wake':
/home/me/git/clones/media_build/v4l/tvaudio.c:305:27: error: implicit 
declaration of function 'from_timer' [-Werror=implicit-function-declaration]
  struct CHIPSTATE *chip = from_timer(chip, t, wt);
   ^
/home/me/git/clones/media_build/v4l/tvaudio.c:305:47: error: 'wt' undeclared 
(first use in this function)
  struct CHIPSTATE *chip = from_timer(chip, t, wt);
   ^
/home/me/git/clones/media_build/v4l/tvaudio.c:305:47: note: each undeclared 
identifier is reported only once for each function it appears in
/home/me/git/clones/media_build/v4l/tvaudio.c: In function 'tvaudio_probe':
/home/me/git/clones/media_build/v4l/tvaudio.c:1998:2: error: implicit 
declaration of function 'timer_setup' [-Werror=implicit-function-declaration]
  timer_setup(>wt, chip_thread_wake, 0);
  ^
cc1: some warnings being treated as errors
scripts/Makefile.build:264: recipe for target 
'/home/me/git/clones/media_build/v4l/o.o' failed
make[3]: *** [/home/me/git/clones/media_build/v4l/tvaudio.o] Error 1
Makefile:1423: recipe for target '_module_/home/me/git/clones/media_build/v4l' 
fail
make[2]: *** [_module_/home/me/git/clones/media_build/v4l] Error 2
make[2]: Leaving directory '/usr/src/linux-headers-4.4.0-97-generic'
Makefile:51: recipe for target 'default' failed
make[1]: *** [default] Error 2
make[1]: Leaving directory '/home/me/git/clones/media_build/v4l'
Makefile:26: recipe for target 'all' failed
make: *** [all] Error 2
build failed at ./build line 526

Re: [progress]: dvb_usb_rtl28xxu not tuning "Leadtek Winfast DTV2000 DS PLUS TV"

[Vincent McIntyre]

On Tue, Sep 26, 2017 at 02:32:26PM +1000, Eyal Lebedinsky wrote:
> 
> While the problem persists, I managed to find a way around it for now.
> 
> I changed the antenna input.
> 
> Originally I used a powered splitter to feed all the tuners, and it worked
> well with the out-of-kernel driver. This driver does not build or work with
> a more modern kernel so I shifted to using dvb_usb_rtl28xxu which fails to
> tune.
> 
> The new wiring splits (passive) the antenna in two, feeds one side directly
> to the two "Leadtek Winfast DTV2000 DS PLUS TV" cards (through another passive
> 2-way) and the other side goes to the old powered splitter that feeds a few
> USB tuners.
> 
> Now all tuners are happy. It seems that the "Leadtek Winfast DTV2000 DS PLUS 
> TV"
> cannot handle the amplified input while the USB tuners require it.
> 
> I hope that there is a way to set a profile in dvb_usb_rtl28xxu to attenuate
> the input to an acceptable level thus unravelling the antenna cables rat-nest.

Glad you had some success.

I did some more rummaging in v4l-utils. It may help you to know about
dvb-fe-tool, which gives information about the frontend device
(eg /dev/dvb/adapter0/frontend0). In particular you can monitor the
s/n as you make changes:

 # dvb-fe-tool --femon -a 0  #here doing adapter0/frontend0

It displays info about the signal quality and the carrier/noise (C/N) ratio,
which might help any investigation of where the driver fails to cope as
you change what you are feeding it.

I noticed your dvbv5-scan showed C/N around 20dB but the manpage shows
'good signal' with C/N of 36dB which suggests the device should be
expected to deal with higher signal levels.

Once you figured out the signal level, did a dvbv5-scan work with no
errors? In the example you showed I saw the channels getting 'lock'
but then some kind of error occurred.

Regards
Vince

Re: f26: dvb_usb_rtl28xxu not tuning "Leadtek Winfast DTV2000 DS PLUS TV"

[Vincent McIntyre]

On Mon, Sep 25, 2017 at 10:16:23AM +1000, Eyal Lebedinsky wrote:

> >Turn on debug printing for the modules of interest
> ># echo 'module rtl2832 +p' > /sys/kernel/debug/dynamic_debug/control
> ># echo 'module dvb_usb_rtl28xxu +p' > /sys/kernel/debug/dynamic_debug/control
> 
> Have done this. Attached are the messages from a (failed) scandvb that fails 
> for all multiplexes.
> 
> The messages at the end continued at a high rate after the test finished 
> (until I disabled debug
> with '-p') and there was no user of the tuners. Maybe IR RC is active?
 
This looks like progress, now we can see more of the rather odd behaviour.

The tuned frequency does not progress monotonically,
but wanders up and down the band.
 Frequency  Delta
 21916
 18484  -3432
 19184700
 19116-68
 17784  -1332
 18416632
 17716   -700
 19150   1434
 18450   -700
 19184734
 19116-68
 17750  -1366
 21950   4200
 18484  -3466
 19150666
 17784  -1366
 18416632
 19184768
 19116-68
 17716  -1400
 19150   1434
 18450   -700
 17750   -700
 17784 34
 17716-68

The bandwidth and inversion type seem to be set correctly, at least.

Also:
 - every instance of if_frequency=0 pset_iffreq=
   shows the same numbers - zero. Surely that can't be right.
 - there seems to be no correlation at all between the AGC level
   (automatic gain control, I assume) and the 'cnr raw' which I'm
   guessing is some measure of the signal level.

I don't know where to start with decoding the rtl28xxu_ctrl_msg
I'm afraid. It's quite possible the remote control is active.
You can run
   ir-keytable -v
to show which remotes the system knows about.

We might get more clues to rub together from looking at where
scandvb falls over, if you run it under 'strace'
  strace -t -s 2048 -o ./scandvb.strace scandvb 
This will show the system calls being made. The -t will add timestamps
to the output that could be correlated with the dmesg output.

I'm curious - did you try scandvb with one of your other tuners?

I'm actually not familiar with scandvb, I can't find a program
with that name in the ubuntu repositories.
What I've used before is dvbv5-scan, which is part of:
 git://linuxtv.org/v4l-utils.git

That repo also includes the v4l2-compliance tool,
which might be useful here. Something like:
 ./v4l2-compliance -d /dev/dvb/adapter3 -a -T -v
What I am not sure about is whether the tuner needs to be
'zapped' to a nice strong TV channel before you can use this.

Anyway, hope some of these ideas are helpful.
Cheers
Vince

Re: f26: dvb_usb_rtl28xxu not tuning "Leadtek Winfast DTV2000 DS PLUS TV"

[Vincent McIntyre]

On Sat, Sep 23, 2017 at 10:48:34PM +1000, Eyal Lebedinsky wrote:
> On 18/09/17 14:26, Eyal Lebedinsky wrote:
> >I have just upgraded to f24. I am now using the standard dvb_usb_rtl28xxu fe
> 
> I have upgraded to f26 and this driver still fails to tune the "Leadtek 
> Winfast DTV2000 DS PLUS TV".
> 
> >which logs messages suggesting all is well (I get the /dev/dvb/adapter? etc.)
> >but I get no channels tuned when I run mythfrontend or scandvb.
> >
> >Is anyone using this combination?
> >Is this the correct way to use this tuner?
> 
> Is this the wrong list? If so then please suggest a more suitable one.

It's the right list. The problem is nobody seems to care.
I have one of these too, I was able to get it tune at one time
but there were some problems that I never ended up running down.

I was planning to dig it out and have a play with it again.

Just to confirm - you're building the media_build git tree on f26
and those drivers are the ones that are not working, yes?
If not, you need to try that to get any help here.
Have a look at https://git.linuxtv.org/media_build.git/about/
and let me know if you need further help with that.

It may be possible to get the driver into debug mode and get more
information logged. I'm not sure this will work but give it a go.

First set up the dynamic debug filesystem (may already be there)
# cat >> /etc/fstab
debugfs /sys/kernel/debug debugfs defaults 0 0
^D
# mount -av

Turn on debug printing for the modules of interest
# echo 'module rtl2832 +p' > /sys/kernel/debug/dynamic_debug/control
# echo 'module dvb_usb_rtl28xxu +p' > /sys/kernel/debug/dynamic_debug/control


Vince

Re: [media_build] regression at 3a17e11 "update v4.10_sched_signal.patch"

[Vincent McIntyre]

On Thu, Jun 08, 2017 at 04:42:30PM +0200, Hans Verkuil wrote:
> On 08/06/17 15:28, Vincent McIntyre wrote:
> > I managed to find the failing patch, not sure what the fix is.
> > 
> > $ cd linux/
> > $ patch -f -N -p1 -i ../backports/v4.10_sched_signal.patch
> > patching file drivers/media/dvb-core/dvb_ca_en50221.c
> > Hunk #1 succeeded at 35 (offset 1 line).
> > patching file drivers/media/dvb-core/dvb_demux.c
> > Hunk #1 succeeded at 20 with fuzz 1 (offset 1 line).
> > patching file drivers/media/dvb-core/dvb_frontend.c
> > Hunk #1 succeeded at 30 (offset 1 line).
> > patching file drivers/media/pci/cx18/cx18-driver.h
> > patching file drivers/media/pci/ivtv/ivtv-driver.c
> > patching file drivers/media/pci/ivtv/ivtv-driver.h
> > Hunk #1 succeeded at 39 (offset 1 line).
> > patching file drivers/media/pci/pt1/pt1.c
> > patching file drivers/media/pci/pt3/pt3.c
> > patching file drivers/media/pci/solo6x10/solo6x10-i2c.c
> > patching file drivers/media/pci/zoran/zoran_device.c
> > patching file drivers/media/platform/vivid/vivid-radio-rx.c
> > patching file drivers/media/platform/vivid/vivid-radio-tx.c
> > patching file drivers/media/rc/lirc_dev.c
> > Hunk #1 FAILED at 18.
> > 1 out of 1 hunk FAILED -- saving rejects to file 
> > drivers/media/rc/lirc_dev.c.rej
> > patching file drivers/media/usb/cpia2/cpia2_core.c
> > patching file drivers/media/usb/gspca/cpia1.c
> > Hunk #1 succeeded at 28 (offset 1 line).
> > patching file drivers/media/v4l2-core/videobuf-dma-sg.c
> > patching file drivers/staging/media/lirc/lirc_zilog.c
> > patching file include/media/v4l2-ioctl.h
> > 
> > $ cat drivers/media/rc/lirc_dev.c.rej
> > --- drivers/media/rc/lirc_dev.c
> > +++ drivers/media/rc/lirc_dev.c
> > @@ -18,7 +18,7 @@
> >  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >  
> >  #include 
> > -#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > 
> 
> Odd, it applies cleanly here.
> 
> But don't bother, the media_build totally broke after the latest round of
> commits to the master. We're looking into that, but it might take a bit
> of time before it is resolved.
> 

Just to follow up on this.
The build still fell over during patching if I ran
   build --main-git --depth 1 -v 1
but did not if I ran
   build -v 1
(which causes the tarball to download instead)

This suggests an inconsistency between the two,
which is surprising and likely unintended.

I poked around a bit and found that the media subdir
was out of date and the build script was not updating it;
--depth 1 appears to suppress that.

Once I did a manual update, the patching succeeded.
I'll try to work out a patch so 'build' avoids this issue in future.

Vince

[patch] [media_build] make check_git() give more information in verbose mode (resend)

[Vincent McIntyre]

While debugging another issue I found this change helpful.
Original send Date: Thu, 1 Jun 2017 20:44:27 +1000



Make check_git() give more information in verbose mode.

Signed-off-by: Vincent McIntyre <vincent.mcint...@gmail.com>
---
 build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/build b/build
index d7f51c2..4457a73 100755
--- a/build
+++ b/build
@@ -303,12 +303,13 @@ sub check_git($$)
my $cmd = shift;
my $remote = shift;
 
-   print "\$ git --git-dir media/.git $cmd\n" if ($level);
+   print "\$ git --git-dir media/.git $cmd (checking for '$remote')\n" if 
($level);
open IN, "git --git-dir media/.git $cmd|" or die "can't run git 
--git-dir media/.git $cmd";
while () {
return 1 if (m/^[\*]*\s*($remote)\n$/);
}
close IN;
+   print "check failed\n" if ($level);
return 0;
 }
 
-- 
2.7.4


- End forwarded message -

[patch] [media_build] small cleanup of build script (resend)

[Vincent McIntyre]

Original send date: Thu, 1 Jun 2017 20:12:32 +1000

Introduce a function to help tracing of system() calls

While debugging a recent issue I wanted more complete information
about the sequencence of events in a series of calls like
  system("foo") or die("BAR")
Adding this helper did that and cleaned things up a little.

Signed-off-by: Vincent McIntyre <vincent.mcint...@gmail.com>
---
 build | 81 +++
 1 file changed, 47 insertions(+), 34 deletions(-)

diff --git a/build b/build
index 4457a73..38ffd4f 100755
--- a/build
+++ b/build
@@ -342,6 +342,19 @@ sub which($)
return undef;
 }
 
+sub run($$)
+{
+   my $cmd = shift;
+   my $err = shift;
+   $err = '' unless defined($err);
+
+   my ($pkg,$filename,$line) = caller;
+
+   print "\$ $cmd\n" if ($level);
+   system($cmd) == 0
+   or die($err . " at $filename line $line\n");
+}
+
 ##
 # Main
 ##
@@ -406,11 +419,11 @@ if (@git == 2) {
if (!$local) {
print "Getting the latest Kernel tree. This will take 
some time\n";
if ($depth) {
-   system("git clone --origin '$rname/$git[1]' 
git://linuxtv.org/media_tree.git media $depth") == 0
-   or die "Can't clone from the upstream 
tree";
+   run("git clone --origin '$rname/$git[1]' 
git://linuxtv.org/media_tree.git media $depth",
+   "Can't clone from the upstream tree");
} else {
-   system("git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git media $depth") 
== 0
-   or die "Can't clone from the upstream 
tree";
+   run("git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git media $depth",
+   "Can't clone from the upstream tree");
}
system('git --git-dir media/.git config format.cc 
"Linux Media Mailing List <linux-media@vger.kernel.org>"');
system('git --git-dir media/.git config format.signoff 
true');
@@ -419,56 +432,54 @@ if (@git == 2) {
} else {
if ($workdir ne "") {
print "Creating a new workdir from $git[0] at 
media\n";
-   system("git new-workdir $git[0] media") == 0
-   or die "Can't create a new workdir";
+   run("git new-workdir $git[0] media",
+   "Can't create a new workdir");
} else {
print "Creating a new clone\n";
-   system("git clone -l $git[0] media $depth") == 0
-   or die "Can't create a new clone";
+   run("git clone -l $git[0] media $depth",
+   "Can't create a new clone");
}
}
} elsif ($workdir eq "") {
if (check_git("remote", "$rname/$git[1]")) {
-   system("git --git-dir media/.git remote update 
'$rname/$git[1]'") == 0
-   or die "Can't update from the upstream tree";
+   run("git --git-dir media/.git remote update 
'$rname/$git[1]'",
+   "Can't update from the upstream tree");
} else {
-   system("git --git-dir media/.git remote update origin") 
== 0
-   or die "Can't update from the upstream tree";
+   run("git --git-dir media/.git remote update origin",
+   "Can't update from the upstream tree");
}
}
 
if ($workdir eq "") {
if (!check_git("remote", "$name")) {
print "adding remote $name to track $git[0]\n";
-   printf "\$ git --git-dir media/.git remote add $name 
$git[0]\n" if ($level);
-   system ("git --git-dir media/.git remote add $name 
$git[0]") == 0
-   or die "Can't create remote $name";
+   run("git --git-dir media/.git remote add $name $git[0]",
+  

[patch] [media_build] Small fix to build script (resend)

[Vincent McIntyre]

This seems to have fallen on the floor...
Original send date: Thu, 1 Jun 2017 19:43:43 +1000

Avoid going splat if --depth is not given

Commit 6b4a9c5 indroduced the --depth parameter to limit the commit history
pulled by when cloning, giving a nice speedup. But in the process it broke
running without the --depth parameter. The first invocation of
'./build --main-git' works fine, but the second falls over like so:

  fatal: No such remote or remote group: media_tree/master
  Can't update from the upstream tree at ./build line 430.

The fix is to check whether that remote has been defined before trying
to update from it.

Signed-off-by: Vincent McIntyre <vincent.mcint...@gmail.com>
---
 build | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/build b/build
index a4cd38e..d7f51c2 100755
--- a/build
+++ b/build
@@ -427,8 +427,13 @@ if (@git == 2) {
}
}
} elsif ($workdir eq "") {
-   system("git --git-dir media/.git remote update 
'$rname/$git[1]'") == 0
-   or die "Can't update from the upstream tree";
+   if (check_git("remote", "$rname/$git[1]")) {
+   system("git --git-dir media/.git remote update 
'$rname/$git[1]'") == 0
+   or die "Can't update from the upstream tree";
+   } else {
+   system("git --git-dir media/.git remote update origin") 
== 0
+   or die "Can't update from the upstream tree";
+   }
}
 
if ($workdir eq "") {

Re: [media_build] regression at 3a17e11 "update v4.10_sched_signal.patch"

[Vincent McIntyre]

> 
> $ cat drivers/media/rc/lirc_dev.c.rej
> --- drivers/media/rc/lirc_dev.c
> +++ drivers/media/rc/lirc_dev.c
> @@ -18,7 +18,7 @@
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>  
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> 

A bit of staring brings this to light:

The file that is being patched has extra lines relative to the patch

 18 #undef pr_fmt
 19 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 20 
 21 #include 
**   22 #include 
 23 #include 
**   24 #include 
 25 #include 
 26 #include 
 27 #include 
 28 #include 
 29 #include 
 30 #include 

This hunk applies cleanly, and seems to match up with recent kernel
code (eg
   174cd4b1e5fbd0d74c68cf3a74f5bd4923485512
   sched/headers: Prepare to move signal wakeup & sigpending methods
from  into )

@@ -20,7 +20,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 

HTH
Vince

Re: [media_build] regression at 3a17e11 "update v4.10_sched_signal.patch"

[Vincent McIntyre]

I managed to find the failing patch, not sure what the fix is.

$ cd linux/
$ patch -f -N -p1 -i ../backports/v4.10_sched_signal.patch
patching file drivers/media/dvb-core/dvb_ca_en50221.c
Hunk #1 succeeded at 35 (offset 1 line).
patching file drivers/media/dvb-core/dvb_demux.c
Hunk #1 succeeded at 20 with fuzz 1 (offset 1 line).
patching file drivers/media/dvb-core/dvb_frontend.c
Hunk #1 succeeded at 30 (offset 1 line).
patching file drivers/media/pci/cx18/cx18-driver.h
patching file drivers/media/pci/ivtv/ivtv-driver.c
patching file drivers/media/pci/ivtv/ivtv-driver.h
Hunk #1 succeeded at 39 (offset 1 line).
patching file drivers/media/pci/pt1/pt1.c
patching file drivers/media/pci/pt3/pt3.c
patching file drivers/media/pci/solo6x10/solo6x10-i2c.c
patching file drivers/media/pci/zoran/zoran_device.c
patching file drivers/media/platform/vivid/vivid-radio-rx.c
patching file drivers/media/platform/vivid/vivid-radio-tx.c
patching file drivers/media/rc/lirc_dev.c
Hunk #1 FAILED at 18.
1 out of 1 hunk FAILED -- saving rejects to file drivers/media/rc/lirc_dev.c.rej
patching file drivers/media/usb/cpia2/cpia2_core.c
patching file drivers/media/usb/gspca/cpia1.c
Hunk #1 succeeded at 28 (offset 1 line).
patching file drivers/media/v4l2-core/videobuf-dma-sg.c
patching file drivers/staging/media/lirc/lirc_zilog.c
patching file include/media/v4l2-ioctl.h

$ cat drivers/media/rc/lirc_dev.c.rej
--- drivers/media/rc/lirc_dev.c
+++ drivers/media/rc/lirc_dev.c
@@ -18,7 +18,7 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 

[media_build] regression at 3a17e11 "update v4.10_sched_signal.patch"

[Vincent McIntyre]

Hi

I think the build was broken by this commit.

  3a17e11 "update v4.10_sched_signal.patch"

It's been fun learning about git bisect.

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"

The build script falls over on these kernels, in the same way

 4.4.0-77-generic x86_64
 4.8.0-53-generic x86_64


$ ./build --main-git --depth 1 -v 1
...
**
* Start building *
* **
* $ make allyesconfig
* make -C /home/me/git/clones/media_build/v4l allyesconfig
* make[1]: Entering directory '/home/me/git/clones/media_build/v4l'
* make[2]: Entering directory '/home/me/git/clones/media_build/linux'
* Syncing with dir ../media/
* Applying patches for kernel 4.4.0-77-generic
* patch -s -f -N -p1 -i ../backports/api_version.patch
* patch -s -f -N -p1 -i ../backports/pr_fmt.patch
* patch -s -f -N -p1 -i ../backports/debug.patch
* patch -s -f -N -p1 -i ../backports/drx39xxj.patch
* patch -s -f -N -p1 -i ../backports/v4.10_sched_signal.patch
* 1 out of 1 hunk FAILED
* Makefile:137: recipe for target 'apply_patches' failed
* make[2]: *** [apply_patches] Error 1
* make[2]: Leaving directory '/home/me/git/clones/media_build/linux'
* Makefile:383: recipe for target 'allyesconfig' failed
* make[1]: *** [allyesconfig] Error 2
* make[1]: Leaving directory '/home/me/git/clones/media_build/v4l'
* Makefile:26: recipe for target 'allyesconfig' failed
* make: *** [allyesconfig] Error 2
* can't select all drivers at ./build.new line 521
*

Hopefully this of some use to someone
Vince

Re: Unknown symbol put_vaddr_frames when using media_build

[Vincent McIntyre]

On Wed, Jun 07, 2017 at 08:12:01PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 7 Jun 2017 22:17:50 +0200
> Matthias Schwarzott  escreveu:
> 
> > Am 07.06.2017 um 20:23 schrieb Mauro Carvalho Chehab:
> > > Em Tue, 9 May 2017 06:56:25 +0200
> > > Matthias Schwarzott  escreveu:
> > >   
> > >> Hi!
> > >>
> > >> Whenever I compile the media drivers using media_build against a recent
> > >> kernel, I get this message when loading them:
> > >>
> > >> [5.848537] media: Linux media interface: v0.10
> > >> [5.881440] Linux video capture interface: v2.00
> > >> [5.881441] WARNING: You are using an experimental version of the
> > >> media stack.
> > >> ...
> > >> [6.166390] videobuf2_memops: Unknown symbol put_vaddr_frames (err 0)
> > >> [6.166394] videobuf2_memops: Unknown symbol get_vaddr_frames (err 0)
> > >> [6.166396] videobuf2_memops: Unknown symbol frame_vector_destroy 
> > >> (err 0)
> > >> [6.166398] videobuf2_memops: Unknown symbol frame_vector_create (err 
> > >> 0)
> > >>
> > >> That means I am not able to load any drivers being based on
> > >> videobuf2_memops without manual actions.
> > >>
> > >> I used kernel 4.11.0, but it does not matter which kernel version
> > >> exactly is used.
> > >>
> > >> My solution for that has been to modify mm/Kconfig of my kernel like
> > >> this and then enable FRAME_VECTOR in .config  
> > > 
> > > Well, if you build your Kernel with VB2 compiled, you'll have it.
> > >   
> > Sure.
> > 
> > So my question is:
> > How good do the kernel origin vb2 and the media_build vb2 play together?
> > 
> > Will modprobe always choose the media_build one?
> > Or will "make install" just overwrite the original file?
> 
> make install *should* overwrite the old one. If not, then there's a problem
> at the media-build makefile [1].
> 

There is a problem. make install has been broken for at least a week,
see the thread "media_build: fails to install"

The reason is that scripts/make_makefile.pl aborts

make[1]: Entering directory '/home/me/git/clones/media_build/v4l'
scripts/make_makefile.pl
Can't handle includes! In 
../linux/drivers/staging/media/atomisp/pci/atomisp2/css2400/Makefile at
scripts/  make_makefile.pl line 109,  line 4.

is because that css2400/Makefile includes another:

$ cat ../linux/drivers/staging/media/atomisp/pci/atomisp2/css2400/Makefile

ccflags-y += -DISP2400B0
ISP2400B0 := y

include $(srctree)/$(src)/../Makefile.common

The abort of scripts/make_makefile.pl means that the v4l/Makefile
does not get completely written out, in particular the rules for
making the 'media-install' target.

I am not sure how to fix this. The make_makefile.pl deliberately
falls over when given an include to deal with, so there must be
some other mechanism in the media_build framework that handles
this kind of thing. But I am not aware of it. 

Vince

Re: Build fails Ubuntu 17.04 / "error: implicit declaration of function"

[Vincent McIntyre]

On Tue, May 30, 2017 at 09:35:03PM +0200, Karl Wallin wrote:
> Hi!
> 
> Sorry for not replying earlier, work.
> I came so far as to download the patches (via n00bishly pasting the
> actual content of the .patch-files into .patch-files since my git
> cherry-pick command didn't work) but then after trying to apply them I
> got a prompt with specifying the path of the file and didn't research
> that further.
> 
> I downloaded the latest release from GIT and now it actually builds!!! :D :D
> 
> However it does not install :(
> 
> "root@nuc-d54250wyk:/home/ubuntu/media_build# make install
> make -C /home/ubuntu/media_build/v4l install
> make[1]: Entering directory '/home/ubuntu/media_build/v4l'
> make[1]: *** No rule to make target 'media-install', needed by 'install'.  
> Stop.
> make[1]: Leaving directory '/home/ubuntu/media_build/v4l'
> Makefile:15: recipe for target 'install' failed
> make: *** [install] Error 2"
> 
> I've gone into "v4l" and looked for a "media-install" file but haven't
> found any.
> 
> Perhaps this is something I've misunderstood and easy to fix so I
> finally can install it?


This was also noticed by Olli Salonen (see thread "media_build: fails
to install"). I note there what the problem is but I don't know how
to fix it.

Vince

Re: media_build: fails to install

[Vincent McIntyre]

On Wed, May 31, 2017 at 03:57:04AM +0300, Olli Salonen wrote:
> It seems that I'm able to build the media_build correctly on Ubuntu
> 16.04.2 with kernel 4.8, but make install fails:
> 
> ~/src/media_build$ sudo make install
> make -C /home/olli/src/media_build/v4l install
> make[1]: Entering directory '/home/olli/src/media_build/v4l'
> make[1]: *** No rule to make target 'media-install', needed by 'install'.  
> Stop.
> make[1]: Leaving directory '/home/olli/src/media_build/v4l'
> Makefile:15: recipe for target 'install' failed
> make: *** [install] Error 2
> 

I can confirm this issue.

The reason is that scripts/make_makefile.pl aborts

make[1]: Entering directory '/home/me/git/clones/media_build/v4l'^M
scripts/make_makefile.pl^M  
Can't handle includes! In 
../linux/drivers/staging/media/atomisp/pci/atomisp2/css2400/Makefile at 
scripts/  make_makefile.pl line 109,  line 4.^M

because that css2400/Makefile includes another:

$ cat ../linux/drivers/staging/media/atomisp/pci/atomisp2/css2400/Makefile

ccflags-y += -DISP2400B0
ISP2400B0 := y

include $(srctree)/$(src)/../Makefile.common

The abort of scripts/make_makefile.pl means that the v4l/Makefile
does not get completely written out, in particular the rules for
making the 'media-install' target.

I am not sure how to fix this. The make_makefile.pl deliberately
falls over when given an include to deal with, so there must be
some other mechanism in the media_build framework that handles
this kind of thing. But I am not aware of it. Hans, help pretty please?

Vince

[PATCH] build: make check_git() give more information in verbose mode

[Vincent McIntyre]

While debugging another issue I found this change helpful.

Signed-off-by: Vincent McIntyre <vincent.mcint...@gmail.com>
---
 build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/build b/build
index d7f51c2..4457a73 100755
--- a/build
+++ b/build
@@ -303,12 +303,13 @@ sub check_git($$)
my $cmd = shift;
my $remote = shift;
 
-   print "\$ git --git-dir media/.git $cmd\n" if ($level);
+   print "\$ git --git-dir media/.git $cmd (checking for '$remote')\n" if 
($level);
open IN, "git --git-dir media/.git $cmd|" or die "can't run git 
--git-dir media/.git $cmd";
while () {
return 1 if (m/^[\*]*\s*($remote)\n$/);
}
close IN;
+   print "check failed\n" if ($level);
return 0;
 }
 
-- 
2.7.4

[PATCH] small cleanup of build script

[Vincent McIntyre]

Introduce a function for better tracing of system() calls

While debugging a recent issue I wanted more complete information
about the sequencence of events in a series of
system("foo") or die("BAR") calls.
Adding this helper did that and cleaned things up a little.

Signed-off-by: Vincent McIntyre <vincent.mcint...@gmail.com>
---
 build | 81 +++
 1 file changed, 47 insertions(+), 34 deletions(-)

diff --git a/build b/build
index 4457a73..38ffd4f 100755
--- a/build
+++ b/build
@@ -342,6 +342,19 @@ sub which($)
return undef;
 }
 
+sub run($$)
+{
+   my $cmd = shift;
+   my $err = shift;
+   $err = '' unless defined($err);
+
+   my ($pkg,$filename,$line) = caller;
+
+   print "\$ $cmd\n" if ($level);
+   system ($cmd) == 0
+   or die($err . " at $filename line $line\n");
+}
+
 ##
 # Main
 ##
@@ -406,11 +419,11 @@ if (@git == 2) {
if (!$local) {
print "Getting the latest Kernel tree. This will take 
some time\n";
if ($depth) {
-   system("git clone --origin '$rname/$git[1]' 
git://linuxtv.org/media_tree.git media $depth") == 0
-   or die "Can't clone from the upstream 
tree";
+   run("git clone --origin '$rname/$git[1]' 
git://linuxtv.org/media_tree.git media $depth",
+   "Can't clone from the upstream tree");
} else {
-   system("git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git media $depth") 
== 0
-   or die "Can't clone from the upstream 
tree";
+   run("git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git media $depth",
+   "Can't clone from the upstream tree");
}
system('git --git-dir media/.git config format.cc 
"Linux Media Mailing List <linux-media@vger.kernel.org>"');
system('git --git-dir media/.git config format.signoff 
true');
@@ -419,56 +432,54 @@ if (@git == 2) {
} else {
if ($workdir ne "") {
print "Creating a new workdir from $git[0] at 
media\n";
-   system("git new-workdir $git[0] media") == 0
-   or die "Can't create a new workdir";
+   run("git new-workdir $git[0] media",
+   "Can't create a new workdir");
} else {
print "Creating a new clone\n";
-   system("git clone -l $git[0] media $depth") == 0
-   or die "Can't create a new clone";
+   run("git clone -l $git[0] media $depth",
+   "Can't create a new clone");
}
}
} elsif ($workdir eq "") {
if (check_git("remote", "$rname/$git[1]")) {
-   system("git --git-dir media/.git remote update 
'$rname/$git[1]'") == 0
-   or die "Can't update from the upstream tree";
+   run("git --git-dir media/.git remote update 
'$rname/$git[1]'",
+   "Can't update from the upstream tree");
} else {
-   system("git --git-dir media/.git remote update origin") 
== 0
-   or die "Can't update from the upstream tree";
+   run("git --git-dir media/.git remote update origin",
+   "Can't update from the upstream tree");
}
}
 
if ($workdir eq "") {
if (!check_git("remote", "$name")) {
print "adding remote $name to track $git[0]\n";
-   printf "\$ git --git-dir media/.git remote add $name 
$git[0]\n" if ($level);
-   system ("git --git-dir media/.git remote add $name 
$git[0]") == 0
-   or die "Can't create remote $name";
+   run("git --git-dir media/.git remote add $name $git[0]",
+   "Can't create remote $name");

[PATCH] Small fix to build script

[Vincent McIntyre]

Avoid going splat if --depth is not given

Commit 6b4a9c5 indroduced the --depth parameter to limit the commit history
pulled by when cloning, giving a nice speedup. But in the process it broke
running without the --depth parameter. The first invocation of
'./build --main-git' works fine, but the second falls over like so:

  fatal: No such remote or remote group: media_tree/master
  Can't update from the upstream tree at ./build line 430.

The fix is to check whether that remote has been defined before trying
to update from it.

Signed-off-by: Vincent McIntyre <vincent.mcint...@gmail.com>
---
 build | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/build b/build
index a4cd38e..d7f51c2 100755
--- a/build
+++ b/build
@@ -427,8 +427,13 @@ if (@git == 2) {
}
}
} elsif ($workdir eq "") {
-   system("git --git-dir media/.git remote update 
'$rname/$git[1]'") == 0
-   or die "Can't update from the upstream tree";
+   if (check_git("remote", "$rname/$git[1]")) {
+   system("git --git-dir media/.git remote update 
'$rname/$git[1]'") == 0
+   or die "Can't update from the upstream tree";
+   } else {
+   system("git --git-dir media/.git remote update origin") 
== 0
+   or die "Can't update from the upstream tree";
+   }
}
 
if ($workdir eq "") {
-- 
2.7.4

Re: [PATCH 0/3] Fix failure of media_build build script

[Vincent McIntyre]

Before sending I ran one-more-test... which failed.
Will respin and try again later.

Vince

[PATCH 0/3] Fix failure of media_build build script

[Vincent McIntyre]

Hi

I was trying to run build --main-git without the --depth option and
it went splat. The attached series fixes my problem, possibly not
entirely correctly for all cases, in the first patch. The other two
patches are small cleanups that should make things more legible.

Vincent McIntyre (3):
  Use a better name for the upstream remote.
  Add a helper to simplify all the system-or-die calls
  Convert remaining system-or-die calls

 build | 76 +++
 1 file changed, 44 insertions(+), 32 deletions(-)

-- 
2.7.4

Re: Build fails Ubuntu 17.04 / "error: implicit declaration of function"

[Vincent McIntyre]

I saw this too, ([regression] Build failure on ubuntu 16.04 LTS)

857313e51006ff51524579bcd8808b70f9a80812
media: utilize new cdev_device_add helper function

introduced these in March this year. More backport patches are needed.

[regression] Build failure on ubuntu 16.04 LTS

[Vincent McIntyre]

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"

$ uname -a
Linux testbox 4.8.0-53-generic #56~16.04.1-Ubuntu SMP Tue May 16
01:18:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ git remote -v
origin  git://linuxtv.org/media_build.git (fetch)
origin  git://linuxtv.org/media_build.git (push)

$ git log -1
commit c8dfc17d6d049d79497c78737625f6ea3b08c456
Author: Hans Verkuil 
Date:   Mon May 22 09:11:11 2017 +0200

Don't build atomisp crap

Signed-off-by: Hans Verkuil 

The attached log file has the failure. This build was done with a
fresh git clone.  I did a quick grep of the tree and the only place I
find cec_devnode_register is in the module that fails to build,
cec-core.c.

Any advice welcome.
Vince
**
* Start building *
**
make -C /home/me/git/clones/media_build/v4l allyesconfig
make[1]: Entering directory '/home/me/git/clones/media_build/v4l'
No version yet, using 4.8.0-53-generic
make[2]: Entering directory '/home/me/git/clones/media_build/linux'
Syncing with dir ../media/
Applying patches for kernel 4.8.0-53-generic
patch -s -f -N -p1 -i ../backports/api_version.patch
patch -s -f -N -p1 -i ../backports/pr_fmt.patch
patch -s -f -N -p1 -i ../backports/debug.patch
patch -s -f -N -p1 -i ../backports/drx39xxj.patch
patch -s -f -N -p1 -i ../backports/v4.10_sched_signal.patch
patch -s -f -N -p1 -i ../backports/v4.10_fault_page.patch
patch -s -f -N -p1 -i ../backports/v4.10_refcount.patch
patch -s -f -N -p1 -i ../backports/v4.9_mm_address.patch
patch -s -f -N -p1 -i ../backports/v4.9_dvb_net_max_mtu.patch
patch -s -f -N -p1 -i ../backports/v4.9_ktime_cleanups.patch
patch -s -f -N -p1 -i ../backports/v4.8_user_pages_flag.patch
Patched drivers/media/dvb-core/dvbdev.c
Patched drivers/media/v4l2-core/v4l2-dev.c
Patched drivers/media/rc/rc-main.c
Syncing with dir ../media/
make[2]: Leaving directory '/home/me/git/clones/media_build/linux'
./scripts/make_kconfig.pl /lib/modules/4.8.0-53-generic/build /lib/modules/4.8.0-53-generic/build 1
Preparing to compile for kernel version 4.8.0

***WARNING:*** You do not have the full kernel sources installed.
This does not prevent you from building the v4l-dvb tree if you have the
kernel headers, but the full kernel source may be required in order to use
make menuconfig / xconfig / qconfig.

If you are experiencing problems building the v4l-dvb tree, please try
building against a vanilla kernel before reporting a bug.

Vanilla kernels are available at http://kernel.org.
On most distros, this will compile a newly downloaded kernel:

cp /boot/config-`uname -r` /.config
cd 
make all modules_install install

Please see your distro's web site for instructions to build a new kernel.

WARNING: This is the V4L/DVB backport tree, with experimental drivers
 backported to run on legacy kernels from the development tree at:
http://git.linuxtv.org/media-tree.git.
 It is generally safe to use it for testing a new driver or
 feature, but its usage on production environments is risky.
 Don't use it in production. You've been warned.
INTEL_ATOMISP: Requires at least kernel 9.255.255
Created default (all yes) .config file
./scripts/fix_kconfig.pl
make[1]: Leaving directory '/home/me/git/clones/media_build/v4l'
make -C /home/me/git/clones/media_build/v4l 
make[1]: Entering directory '/home/me/git/clones/media_build/v4l'
scripts/make_makefile.pl
Can't handle includes! In ../linux/drivers/staging/media/atomisp/pci/atomisp2/css2400/Makefile at scripts/make_makefile.pl line 109,  line 4.
./scripts/make_myconfig.pl
perl scripts/make_config_compat.pl /lib/modules/4.8.0-53-generic/build ./.myconfig ./config-compat.h
creating symbolic links...
make -C firmware prep
make[2]: Entering directory '/home/me/git/clones/media_build/v4l/firmware'
make[2]: Leaving directory '/home/me/git/clones/media_build/v4l/firmware'
make -C firmware
make[2]: Entering directory '/home/me/git/clones/media_build/v4l/firmware'
  CC  ihex2fw
Generating vicam/firmware.fw
Generating ttusb-budget/dspbootcode.bin
Generating cpia2/stv0672_vp4.bin
Generating av7110/bootcode.bin
make[2]: Leaving directory '/home/me/git/clones/media_build/v4l/firmware'
Kernel build directory is /lib/modules/4.8.0-53-generic/build
make -C ../linux apply_patches
make[2]: Entering directory '/home/me/git/clones/media_build/linux'
Syncing with dir ../media/
Patches for 4.8.0-53-generic already applied.
make[2]: Leaving directory '/home/me/git/clones/media_build/linux'
make -C /lib/modules/4.8.0-53-generic/build SUBDIRS=/home/me/git/clones/media_build/v4l  modules
make[2]: Entering directory '/usr/src/linux-headers-4.8.0-53-generic'
  CC [M]  /home/me/git/clones/media_build/v4l/cec-core.o
/home/me/git/clones/media_build/v4l/cec-core.c: In function 'cec_devnode_register':
/home/me/git/clones/media_build/v4l/cec-core.c:142:8: error: implicit 

Re: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

On 3/1/17, Sean Young  wrote:
>
> Sorry Vincent, but are you sure you're running the patch with the
> & 0xff mask? That should have solved it.
>

er, no. Some kind of build issue. Once I applied your media_build
patch and then the latest kernel patch you sent, this is what the test
run looks like.

# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event5) with:
Driver imon, table rc-imon-mce
Supported protocols: rc-6
Enabled protocols: rc-6
Name: iMON Remote (15c2:ffdc)
bus: 3, vendor/product: 15c2:ffdc, version: 0x
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc1/ (/dev/input/event15) with:
Driver dvb_usb_cxusb, table rc-dvico-mce
Supported protocols: nec
Enabled protocols:
Name: IR-receiver inside an USB DVB re
bus: 3, vendor/product: 0fe9:db78, version: 0x827b
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc2/ (/dev/input/event16) with:
Driver dvb_usb_af9035, table rc-empty
Supported protocols: nec
Enabled protocols:
Name: Leadtek WinFast DTV Dongle Dual
bus: 3, vendor/product: 0413:6a05, version: 0x0200
Repeat delay = 500 ms, repeat period = 125 ms

# ir-keytable -r -t -d /dev/input/event15
scancode 0x0101 = KEY_RECORD (0xa7)
scancode 0x0102 = KEY_TV (0x179)
scancode 0x0103 = KEY_0 (0x0b)
scancode 0x0105 = KEY_VOLUMEDOWN (0x72)
scancode 0x0107 = KEY_4 (0x05)
scancode 0x0109 = KEY_CHANNELDOWN (0x193)
scancode 0x010a = KEY_EPG (0x16d)
scancode 0x010b = KEY_1 (0x02)
scancode 0x010d = KEY_STOP (0x80)
scancode 0x010e = KEY_MP3 (0x187)
scancode 0x010f = KEY_PREVIOUSSONG (0xa5)
scancode 0x0111 = KEY_CHANNELUP (0x192)
scancode 0x0112 = KEY_NEXTSONG (0xa3)
scancode 0x0113 = KEY_ANGLE (0x173)
scancode 0x0115 = KEY_VOLUMEUP (0x73)
scancode 0x0116 = KEY_SETUP (0x8d)
scancode 0x0117 = KEY_2 (0x03)
scancode 0x0119 = KEY_OPEN (0x86)
scancode 0x011a = KEY_DVD (0x185)
scancode 0x011b = KEY_3 (0x04)
scancode 0x011e = KEY_FAVORITES (0x16c)
scancode 0x011f = KEY_ZOOM (0x174)
scancode 0x0142 = KEY_ENTER (0x1c)
scancode 0x0143 = KEY_REWIND (0xa8)
scancode 0x0146 = KEY_POWER2 (0x164)
scancode 0x0147 = KEY_PLAYPAUSE (0xa4)
scancode 0x0148 = KEY_7 (0x08)
scancode 0x0149 = KEY_BACK (0x9e)
scancode 0x014c = KEY_8 (0x09)
scancode 0x014d = KEY_MENU (0x8b)
scancode 0x014e = KEY_POWER (0x74)
scancode 0x014f = KEY_FASTFORWARD (0xd0)
scancode 0x0150 = KEY_5 (0x06)
scancode 0x0151 = KEY_UP (0x67)
scancode 0x0152 = KEY_CAMERA (0xd4)
scancode 0x0153 = KEY_DOWN (0x6c)
scancode 0x0154 = KEY_6 (0x07)
scancode 0x0155 = KEY_TAB (0x0f)
scancode 0x0157 = KEY_MUTE (0x71)
scancode 0x0158 = KEY_9 (0x0a)
scancode 0x0159 = KEY_INFO (0x166)
scancode 0x015a = KEY_TUNER (0x182)
scancode 0x015b = KEY_LEFT (0x69)
scancode 0x015e = KEY_OK (0x160)
scancode 0x015f = KEY_RIGHT (0x6a)
Enabled protocols: unknown other rc-5 sanyo mce-kbd rc-6 sharp xmp
Testing events. Please, press CTRL-C to abort.
 # 1
1488461383.614660: event type EV_MSC(0x04): scancode = 0x10b
1488461383.614660: event type EV_KEY(0x01) key_down: KEY_1(0x0002)
1488461383.614660: event type EV_SYN(0x00).
1488461383.865435: event type EV_KEY(0x01) key_up: KEY_1(0x0002)
1488461383.865435: event type EV_SYN(0x00).
 # 2
1488461394.150608: event type EV_MSC(0x04): scancode = 0x117
1488461394.150608: event type EV_KEY(0x01) key_down: KEY_2(0x0003)
1488461394.150608: event type EV_SYN(0x00).
1488461394.401431: event type EV_KEY(0x01) key_up: KEY_2(0x0003)
1488461394.401431: event type EV_SYN(0x00).
 # 8
1488461400.870636: event type EV_MSC(0x04): scancode = 0x14c
1488461400.870636: event type EV_KEY(0x01) key_down: KEY_8(0x0009)
1488461400.870636: event type EV_SYN(0x00).
1488461401.121430: event type EV_KEY(0x01) key_up: KEY_8(0x0009)
1488461401.121430: event type EV_SYN(0x00).
 # 9
1488461409.598593: event type EV_MSC(0x04): scancode = 0x158
1488461409.598593: event type EV_KEY(0x01) key_down: KEY_9(0x000a)
1488461409.598593: event type EV_SYN(0x00).
1488461409.849430: event type EV_KEY(0x01) key_up: KEY_9(0x000a)
1488461409.849430: event type EV_SYN(0x00).
 # vol_dn
1488461418.530615: event type EV_MSC(0x04): scancode = 0x105
1488461418.530615: event type EV_KEY(0x01) key_down: KEY_VOLUMEDOWN(0x0072)
1488461418.530615: event type EV_SYN(0x00).
1488461418.781443: event type EV_KEY(0x01) key_up: KEY_VOLUMEDOWN(0x0072)
1488461418.781443: event type EV_SYN(0x00).
 # vol_up
1488461428.490659: event type EV_MSC(0x04): scancode = 0x115
1488461428.490659: event type EV_KEY(0x01) key_down: KEY_VOLUMEUP(0x0073)
1488461428.490659: event type EV_SYN(0x00).
1488461428.741432: event type EV_KEY(0x01) key_up: KEY_VOLUMEUP(0x0073)
1488461428.741432: event type EV_SYN(0x00).
 # down arrow
1488461441.650689: event type EV_MSC(0x04): scancode = 0x153
1488461441.650689: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
1488461441.650689: event type EV_SYN(0x00).
1488461441.901433: event type EV_KEY(0x01) key_up: 

Re: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

On 2/22/17, Sean Young  wrote:

> So it's still using the old keymap. I've attached a new one.

That works, thanks.

>>   # vol down
>> 1487676637.746348: event type EV_MSC(0x04): scancode = 0x0105
>> 1487676637.746348: event type EV_SYN(0x00).
>>   # vol up
>> 1487676642.746321: event type EV_MSC(0x04): scancode = 0x0115
>> 1487676642.746321: event type EV_SYN(0x00).
>
> Oops, that's a bug. 0x should be 0x. I've attached a new version of
> the patch which should fix that.
>

I am still getting the high bits set. I checked the code and the patch
was correctly applied,
I see where you are applying a 0xff mask to the ircode values.


Test run:
# Found /sys/class/rc/rc0/ (/dev/input/event5) with:
Driver imon, table rc-imon-mce
Supported protocols: rc-6
Enabled protocols: rc-6
Name: iMON Remote (15c2:ffdc)
bus: 3, vendor/product: 15c2:ffdc, version: 0x
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc1/ (/dev/input/event15) with:
Driver dvb_usb_cxusb, table rc-dvico-mce
Supported protocols: nec
Enabled protocols:
Name: IR-receiver inside an USB DVB re
bus: 3, vendor/product: 0fe9:db78, version: 0x827b
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc2/ (/dev/input/event16) with:
Driver dvb_usb_af9035, table rc-empty
Supported protocols: nec
Enabled protocols:
Name: Leadtek WinFast DTV Dongle Dual
bus: 3, vendor/product: 0413:6a05, version: 0x0200
Repeat delay = 500 ms, repeat period = 125 ms

#  ir-keytable -r -t -d /dev/input/event15
scancode 0x0101 = KEY_RECORD (0xa7)
scancode 0x0102 = KEY_TV (0x179)
scancode 0x0103 = KEY_0 (0x0b)
scancode 0x0105 = KEY_VOLUMEDOWN (0x72)
scancode 0x0107 = KEY_4 (0x05)
scancode 0x0109 = KEY_CHANNELDOWN (0x193)
scancode 0x010a = KEY_EPG (0x16d)
scancode 0x010b = KEY_1 (0x02)
scancode 0x010d = KEY_STOP (0x80)
scancode 0x010e = KEY_MP3 (0x187)
scancode 0x010f = KEY_PREVIOUSSONG (0xa5)
scancode 0x0111 = KEY_CHANNELUP (0x192)
scancode 0x0112 = KEY_NEXTSONG (0xa3)
scancode 0x0113 = KEY_ANGLE (0x173)
scancode 0x0115 = KEY_VOLUMEUP (0x73)
scancode 0x0116 = KEY_SETUP (0x8d)
scancode 0x0117 = KEY_2 (0x03)
scancode 0x0119 = KEY_OPEN (0x86)
scancode 0x011a = KEY_DVD (0x185)
scancode 0x011b = KEY_3 (0x04)
scancode 0x011e = KEY_FAVORITES (0x16c)
scancode 0x011f = KEY_ZOOM (0x174)
scancode 0x0142 = KEY_ENTER (0x1c)
scancode 0x0143 = KEY_REWIND (0xa8)
scancode 0x0146 = KEY_POWER2 (0x164)
scancode 0x0147 = KEY_PLAYPAUSE (0xa4)
scancode 0x0148 = KEY_7 (0x08)
scancode 0x0149 = KEY_BACK (0x9e)
scancode 0x014c = KEY_8 (0x09)
scancode 0x014d = KEY_MENU (0x8b)
scancode 0x014e = KEY_POWER (0x74)
scancode 0x014f = KEY_FASTFORWARD (0xd0)
scancode 0x0150 = KEY_5 (0x06)
scancode 0x0151 = KEY_UP (0x67)
scancode 0x0152 = KEY_CAMERA (0xd4)
scancode 0x0153 = KEY_DOWN (0x6c)
scancode 0x0154 = KEY_6 (0x07)
scancode 0x0155 = KEY_TAB (0x0f)
scancode 0x0157 = KEY_MUTE (0x71)
scancode 0x0158 = KEY_9 (0x0a)
scancode 0x0159 = KEY_INFO (0x166)
scancode 0x015a = KEY_TUNER (0x182)
scancode 0x015b = KEY_LEFT (0x69)
scancode 0x015e = KEY_OK (0x160)
scancode 0x015f = KEY_RIGHT (0x6a)
Enabled protocols: other jvc sony nec sanyo mce-kbd rc-6 sharp xmp
Testing events. Please, press CTRL-C to abort.
 # '1'
1487948112.709532: event type EV_MSC(0x04): scancode = 0x010b
1487948112.709532: event type EV_SYN(0x00).
 # '2'
1487948137.229455: event type EV_MSC(0x04): scancode = 0x0117
1487948137.229455: event type EV_SYN(0x00).
 # '8'
1487948233.341489: event type EV_MSC(0x04): scancode = 0x014c
1487948233.341489: event type EV_SYN(0x00).
 # '9'
1487948248.417547: event type EV_MSC(0x04): scancode = 0x0158
1487948248.417547: event type EV_SYN(0x00).
 # volume_down
1487948270.537497: event type EV_MSC(0x04): scancode = 0x0105
1487948270.537497: event type EV_SYN(0x00).
 # volume_up
1487948464.425435: event type EV_MSC(0x04): scancode = 0x0115
1487948464.425435: event type EV_SYN(0x00).

Cheers
Vince

Re: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

On 2/21/17, Sean Young  wrote:
> Hi Vincent,
>
...
>
> On the cxusb the protocol is now nec, and that is the only protocol it
> supports, you can't change it.
>

doh! ok well that's all good then.

>> $ sudo cat /sys/class/rc/rc1/protocols
>> nec
>> $ sudo sh
>> # echo "+rc-5 +nec +rc-6 +jvc +sony +rc-5-sz +sanyo +sharp +xmp" >
>> /sys/class/rc/rc1/protocols
>> bash: echo: write error: Invalid argument
>> # cat  /sys/class/rc/rc1/protocols
>> nec
>> In kern.log I got:
>> kernel: [ 2293.491534] rc_core: Normal protocol change requested
>> kernel: [ 2293.491538] rc_core: Protocol switching not supported
>>
>> # echo "+nec" > /sys/class/rc/rc1/protocols
>> bash: echo: write error: Invalid argument
>> kernel: [ 2390.832476] rc_core: Normal protocol change requested
>> kernel: [ 2390.832481] rc_core: Protocol switching not supported
>
> That is expected. Does the the keymap actually work?
>
> ir-keytable -r -t

Kind of important information, yes. Answer: not sure. I can see it
receiving something but none of the keys I pressed caused any reaction
on the application (mythtv)

# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event5) with:
Driver imon, table rc-imon-mce
Supported protocols: rc-6
Enabled protocols: rc-6
Name: iMON Remote (15c2:ffdc)
bus: 3, vendor/product: 15c2:ffdc, version: 0x
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc1/ (/dev/input/event11) with:
Driver dvb_usb_cxusb, table rc-dvico-mce
Supported protocols: nec
Enabled protocols:
Name: IR-receiver inside an USB DVB re
bus: 3, vendor/product: 0fe9:db78, version: 0x827b
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc2/ (/dev/input/event16) with:
Driver dvb_usb_af9035, table rc-empty
Supported protocols: nec
Enabled protocols:
Name: Leadtek WinFast DTV Dongle Dual
bus: 3, vendor/product: 0413:6a05, version: 0x0200
Repeat delay = 500 ms, repeat period = 125 ms

# ir-keytable -r -t -d /dev/input/event11
scancode 0xfe01 = KEY_R (0x13)
scancode 0xfe02 = KEY_TV (0x179)
scancode 0xfe03 = KEY_0 (0x0b)
scancode 0xfe05 = KEY_VOLUMEDOWN (0x72)
scancode 0xfe07 = KEY_4 (0x05)
scancode 0xfe09 = KEY_CHANNELDOWN (0x193)
scancode 0xfe0a = KEY_EPG (0x16d)
scancode 0xfe0b = KEY_1 (0x02)
scancode 0xfe0d = KEY_ESC (0x01)
scancode 0xfe0e = KEY_MP3 (0x187)
scancode 0xfe0f = KEY_PREVIOUSSONG (0xa5)
scancode 0xfe11 = KEY_CHANNELUP (0x192)
scancode 0xfe12 = KEY_NEXTSONG (0xa3)
scancode 0xfe13 = KEY_ANGLE (0x173)
scancode 0xfe15 = KEY_VOLUMEUP (0x73)
scancode 0xfe16 = KEY_SETUP (0x8d)
scancode 0xfe17 = KEY_2 (0x03)
scancode 0xfe19 = KEY_OPEN (0x86)
scancode 0xfe1a = KEY_DVD (0x185)
scancode 0xfe1b = KEY_3 (0x04)
scancode 0xfe1e = KEY_FAVORITES (0x16c)
scancode 0xfe1f = KEY_ZOOM (0x174)
scancode 0xfe42 = KEY_ENTER (0x1c)
scancode 0xfe43 = KEY_REWIND (0xa8)
scancode 0xfe46 = KEY_POWER2 (0x164)
scancode 0xfe47 = KEY_P (0x19)
scancode 0xfe48 = KEY_7 (0x08)
scancode 0xfe49 = KEY_ESC (0x01)
scancode 0xfe4c = KEY_8 (0x09)
scancode 0xfe4d = KEY_M (0x32)
scancode 0xfe4e = KEY_POWER (0x74)
scancode 0xfe4f = KEY_FASTFORWARD (0xd0)
scancode 0xfe50 = KEY_5 (0x06)
scancode 0xfe51 = KEY_UP (0x67)
scancode 0xfe52 = KEY_CAMERA (0xd4)
scancode 0xfe53 = KEY_DOWN (0x6c)
scancode 0xfe54 = KEY_6 (0x07)
scancode 0xfe55 = KEY_TAB (0x0f)
scancode 0xfe57 = KEY_MUTE (0x71)
scancode 0xfe58 = KEY_9 (0x0a)
scancode 0xfe59 = KEY_INFO (0x166)
scancode 0xfe5a = KEY_TUNER (0x182)
scancode 0xfe5b = KEY_LEFT (0x69)
scancode 0xfe5e = KEY_ENTER (0x1c)
scancode 0xfe5f = KEY_RIGHT (0x6a)
Enabled protocols: other sony nec sanyo mce-kbd rc-6 sharp xmp
Testing events. Please, press CTRL-C to abort.
  # pressed '1' key
1487676458.742329: event type EV_MSC(0x04): scancode = 0x010b
1487676458.742329: event type EV_SYN(0x00).
  # '2'
1487676481.742284: event type EV_MSC(0x04): scancode = 0x0117
1487676481.742284: event type EV_SYN(0x00).
  # '8'
1487676504.842250: event type EV_MSC(0x04): scancode = 0x014c
1487676504.842250: event type EV_SYN(0x00).
  # '9'
1487676506.542243: event type EV_MSC(0x04): scancode = 0x0158
1487676506.542243: event type EV_SYN(0x00).
  # right-arrow
1487676551.942312: event type EV_MSC(0x04): scancode = 0x015f
1487676551.942312: event type EV_SYN(0x00).
  # vol down
1487676637.746348: event type EV_MSC(0x04): scancode = 0x0105
1487676637.746348: event type EV_SYN(0x00).
  # vol up
1487676642.746321: event type EV_MSC(0x04): scancode = 0x0115
1487676642.746321: event type EV_SYN(0x00).

# cat /sys/class/rc/rc1/protocols
nec

All the above was done with the system booted with this in /etc/rc.local
/usr/bin/ir-keytable -s rc1 -c
/usr/bin/ir-keytable -s rc1 -w /etc/rc_keymaps/dvico-remote

After I disabled the rc.local script and rebooted:
# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event10) with:
Driver imon, table rc-imon-mce
Supported 

Fwd: [regression] dvb_usb_cxusb (was Re: ir-keytable: infinite loops, segfaults)

[Vincent McIntyre]

Hi list

I missed you in the cc: field...

-- Forwarded message --
From: Vincent McIntyre <vincent.mcint...@gmail.com>
Date: Thu, 16 Feb 2017 23:51:05 +1100
Subject: Re: [regression] dvb_usb_cxusb (was Re: ir-keytable: infinite
loops, segfaults)
To: Sean Young <s...@mess.org>

On 2/16/17, Sean Young <s...@mess.org> wrote:
>
> The problem is that DVB_USB_CXUSB Kconfig has this line:
> select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT
> The make_kconfig.pl script transforms this into a dependency, but
> DVB_SI2168 is only available when compiling against kernel 4.7 or later.
> I think only one select line needs to match, so I created this patch.
>
> Please apply this patch against media_build, you might need to do make
> clean before building again.

Awsome - build is working again, thank you. See the other thread for
my progress report.

> Thanks,
>
> Sean
>
>
> From: Sean Young <s...@mess.org>
> Date: Wed, 15 Feb 2017 14:58:00 +
> Subject: [PATCH] only one select Kconfig needs to match

Tested-by: vincent.mcint...@gmail.com

> ---
>  v4l/scripts/make_kconfig.pl | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/v4l/scripts/make_kconfig.pl b/v4l/scripts/make_kconfig.pl
> index ba8c134..a11f820 100755
> --- a/v4l/scripts/make_kconfig.pl
> +++ b/v4l/scripts/make_kconfig.pl
> @@ -169,6 +169,7 @@ sub depends($$)
>   push @{$depends{$key}}, $deps;
>  }
>
> +my %selectdepends = ();
>  sub selects($$$)
>  {
>   my $key = shift;
> @@ -181,7 +182,7 @@ sub selects($$$)
>   # Transform "select X if Y" into "depends on !Y || X"
>   $select = "!($if) || ($select)";
>   }
> - push @{$depends{$key}}, $select;
> + push @{$selectdepends{$key}}, $select;
>  }
>
>  # Needs:
> @@ -228,6 +229,23 @@ sub checkdeps()
>   return 0;
>   }
>   }
> + my $selectdeps = $selectdepends{$key};
> + if ($selectdeps) {
> + my $found = 0;
> + foreach (@$selectdeps) {
> + next if($_ eq '');
> + if (eval(toperl($_))) {
> + $found = 1;
> + last;
> + }
> + }
> + if ($found == 0) {
> + print "Disabling $key, select dependency '$_' 
> not met\n" if $debug;
> + $allconfig{$key} = 0;
> + return 0;
> + }
> + }
> +
>   return 1;
>   }
>
> --
> 2.7.4

Vince

Re: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

The dmesg...


dmesg.txt.gz
Description: GNU Zip compressed data

Re: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

Hi again

after you kindly fixed media_build for me I applied the nec protocol
patch and tried again.

$ sudo ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event5) with:
Driver imon, table rc-imon-mce
Supported protocols: rc-6
Enabled protocols: rc-6
Name: iMON Remote (15c2:ffdc)
bus: 3, vendor/product: 15c2:ffdc, version: 0x
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc1/ (/dev/input/event11) with:
Driver dvb_usb_cxusb, table rc-dvico-mce
Supported protocols: nec
Enabled protocols:
Name: IR-receiver inside an USB DVB re
bus: 3, vendor/product: 0fe9:db78, version: 0x827b
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc2/ (/dev/input/event16) with:
Driver dvb_usb_af9035, table rc-empty
Supported protocols: nec
Enabled protocols:
Name: Leadtek WinFast DTV Dongle Dual
bus: 3, vendor/product: 0413:6a05, version: 0x0200
Repeat delay = 500 ms, repeat period = 125 ms

$ sudo ir-keytable -v --sysdev rc1
Found device /sys/class/rc/rc0/
Found device /sys/class/rc/rc1/
Found device /sys/class/rc/rc2/
Input sysfs node is /sys/class/rc/rc0/input8/
Event sysfs node is /sys/class/rc/rc0/input8/event5/
Parsing uevent /sys/class/rc/rc0/input8/event5/uevent
/sys/class/rc/rc0/input8/event5/uevent uevent MAJOR=13
/sys/class/rc/rc0/input8/event5/uevent uevent MINOR=69
/sys/class/rc/rc0/input8/event5/uevent uevent DEVNAME=input/event5
Parsing uevent /sys/class/rc/rc0/uevent
/sys/class/rc/rc0/uevent uevent NAME=rc-imon-mce
/sys/class/rc/rc0/uevent uevent DRV_NAME=imon
input device is /dev/input/event5
/sys/class/rc/rc0/protocols protocol rc-6 (enabled)
Found /sys/class/rc/rc0/ (/dev/input/event5) with:
Driver imon, table rc-imon-mce
Supported protocols: rc-6
Enabled protocols: rc-6
Name: iMON Remote (15c2:ffdc)
bus: 3, vendor/product: 15c2:ffdc, version: 0x
Repeat delay = 500 ms, repeat period = 125 ms
Input sysfs node is /sys/class/rc/rc1/input17/
Event sysfs node is /sys/class/rc/rc1/input17/event11/
Parsing uevent /sys/class/rc/rc1/input17/event11/uevent
/sys/class/rc/rc1/input17/event11/uevent uevent MAJOR=13
/sys/class/rc/rc1/input17/event11/uevent uevent MINOR=75
/sys/class/rc/rc1/input17/event11/uevent uevent DEVNAME=input/event11
Parsing uevent /sys/class/rc/rc1/uevent
/sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce
/sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb
input device is /dev/input/event11
/sys/class/rc/rc1/protocols protocol nec (disabled)
Found /sys/class/rc/rc1/ (/dev/input/event11) with:
Driver dvb_usb_cxusb, table rc-dvico-mce
Supported protocols: nec
Enabled protocols:
Name: IR-receiver inside an USB DVB re
bus: 3, vendor/product: 0fe9:db78, version: 0x827b
Repeat delay = 500 ms, repeat period = 125 ms
Input sysfs node is /sys/class/rc/rc2/input19/
Event sysfs node is /sys/class/rc/rc2/input19/event16/
Parsing uevent /sys/class/rc/rc2/input19/event16/uevent
/sys/class/rc/rc2/input19/event16/uevent uevent MAJOR=13
/sys/class/rc/rc2/input19/event16/uevent uevent MINOR=80
/sys/class/rc/rc2/input19/event16/uevent uevent DEVNAME=input/event16
Parsing uevent /sys/class/rc/rc2/uevent
/sys/class/rc/rc2/uevent uevent NAME=rc-empty
/sys/class/rc/rc2/uevent uevent DRV_NAME=dvb_usb_af9035
input device is /dev/input/event16
/sys/class/rc/rc2/protocols protocol nec (disabled)
Found /sys/class/rc/rc2/ (/dev/input/event16) with:
Driver dvb_usb_af9035, table rc-empty
Supported protocols: nec
Enabled protocols:
Name: Leadtek WinFast DTV Dongle Dual
bus: 3, vendor/product: 0413:6a05, version: 0x0200
Repeat delay = 500 ms, repeat period = 125 ms

So only rc0 has any protocols enabled. Let's try to enable nec on rc1

$ sudo /usr/bin/ir-keytable -s rc1 -c
Old keytable cleared
$ sudo /usr/bin/ir-keytable -s rc1 -w /etc/rc_keymaps/dvico-remote
Read dvico_mce table
Wrote 45 keycode(s) to driver
Invalid protocols selected
Couldn't change the IR protocols
$ sudo /usr/bin/ir-keytable -s rc1 -p nec -v
Found device /sys/class/rc/rc0/
Found device /sys/class/rc/rc1/
Found device /sys/class/rc/rc2/
Input sysfs node is /sys/class/rc/rc1/input17/
Event sysfs node is /sys/class/rc/rc1/input17/event11/
Parsing uevent /sys/class/rc/rc1/input17/event11/uevent
/sys/class/rc/rc1/input17/event11/uevent uevent MAJOR=13
/sys/class/rc/rc1/input17/event11/uevent uevent MINOR=75
/sys/class/rc/rc1/input17/event11/uevent uevent DEVNAME=input/event11
Parsing uevent /sys/class/rc/rc1/uevent
/sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce
/sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb
input device is /dev/input/event11
/sys/class/rc/rc1/protocols protocol nec (disabled)
Opening /dev/input/event11
Input Protocol version: 0x00010001
/sys/class/rc/rc1//protocols: Invalid argument
Couldn't change the IR 

Re: [regression] dvb_usb_cxusb (was Re: ir-keytable: infinite loops, segfaults)

[Vincent McIntyre]

ping?

My media_build tree is updated as far as:
$ git log -1
commit 0721d4bde661c71cd4e41de37afb24b0694c65a3
Author: Hans Verkuil <hans.verk...@cisco.com>
Date:   Mon Nov 21 13:17:19 2016 +0100

Only use Makefile.mm if frame_vector.c is present.

Signed-off-by: Hans Verkuil <hans.verk...@cisco.com>

> On Wed, Feb 08, 2017 at 10:30:30PM +1100, Vincent McIntyre wrote:
>> Hi
>>
>> I have been working with Sean on figuring out the protocol used by a
>> dvico remote.
>> I thought the patch he sent was at fault but I backed it out and tried
>> again.
>>
>> I've attached a full dmesg but the core of it is when dvb_usb_cxusb
>> tries to load:
>>
>> [7.858907] WARNING: You are using an experimental version of the
>> media stack.
>> As the driver is backported to an older kernel, it doesn't
>> offer
>> enough quality for its usage in production.
>> Use it with care.
>>Latest git patches (needed if you report a bug to
>> linux-media@vger.kernel.org):
>> 47b037a0512d9f8675ec2693bed46c8ea6a884ab [media]
>> v4l2-async: failing functions shouldn't have side effects
>> 79a2eda80c6dab79790c308d9f50ecd2e5021ba3 [media]
>> mantis_dvb: fix some error codes in mantis_dvb_init()
>> c2987aaf0c9c2bcb0d4c5902d61473d9aa018a3d [media]
>> exynos-gsc: Avoid spamming the log on VIDIOC_TRY_FMT
>> [7.861968] dvb_usb_af9035 1-4:1.0: prechip_version=83
>> chip_version=02 chip_type=9135
>> [7.887476] dvb_usb_cxusb: disagrees about version of symbol
>> dvb_usb_generic_rw
>> [7.887477] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_rw (err -22)
>

[regression] dvb_usb_cxusb (was Re: ir-keytable: infinite loops, segfaults)

[Vincent McIntyre]

Hi

I have been working with Sean on figuring out the protocol used by a
dvico remote.
I thought the patch he sent was at fault but I backed it out and tried again.

I've attached a full dmesg but the core of it is when dvb_usb_cxusb
tries to load:

[7.858907] WARNING: You are using an experimental version of the
media stack.
As the driver is backported to an older kernel, it doesn't offer
enough quality for its usage in production.
Use it with care.
   Latest git patches (needed if you report a bug to
linux-media@vger.kernel.org):
47b037a0512d9f8675ec2693bed46c8ea6a884ab [media]
v4l2-async: failing functions shouldn't have side effects
79a2eda80c6dab79790c308d9f50ecd2e5021ba3 [media]
mantis_dvb: fix some error codes in mantis_dvb_init()
c2987aaf0c9c2bcb0d4c5902d61473d9aa018a3d [media]
exynos-gsc: Avoid spamming the log on VIDIOC_TRY_FMT
[7.861968] dvb_usb_af9035 1-4:1.0: prechip_version=83
chip_version=02 chip_type=9135
[7.887476] dvb_usb_cxusb: disagrees about version of symbol
dvb_usb_generic_rw
[7.887477] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_rw (err -22)
[7.887499] dvb_usb_cxusb: disagrees about version of symbol rc_keydown
[7.887500] dvb_usb_cxusb: Unknown symbol rc_keydown (err -22)
[7.887507] dvb_usb_cxusb: disagrees about version of symbol
dib0070_wbd_offset
[7.887508] dvb_usb_cxusb: Unknown symbol dib0070_wbd_offset (err -22)
[7.887513] dvb_usb_cxusb: disagrees about version of symbol
dvb_usb_device_init
[7.887514] dvb_usb_cxusb: Unknown symbol dvb_usb_device_init (err -22)
[7.887518] dvb_usb_cxusb: disagrees about version of symbol
dvb_usb_generic_write
[7.887519] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_write (err -22)
[7.900099] usb 1-4: dvb_usb_v2: found a 'Leadtek WinFast DTV
Dongle Dual' in cold state
[7.900768] usb 1-4: dvb_usb_v2: downloading firmware from file
'dvb-usb-it9135-02.fw'
[8.124533] input: HDA NVidia HDMI/DP,pcm=3 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input14
[8.124616] input: HDA NVidia HDMI/DP,pcm=7 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input15
[8.124690] input: HDA NVidia HDMI/DP,pcm=8 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input16
[8.124763] input: HDA NVidia HDMI/DP,pcm=9 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input17
[8.144601] dvb_usb_cxusb: disagrees about version of symbol
dvb_usb_generic_rw
[8.144603] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_rw (err -22)
[8.144638] dvb_usb_cxusb: disagrees about version of symbol rc_keydown
[8.144639] dvb_usb_cxusb: Unknown symbol rc_keydown (err -22)
[8.144648] dvb_usb_cxusb: disagrees about version of symbol
dib0070_wbd_offset
[8.144649] dvb_usb_cxusb: Unknown symbol dib0070_wbd_offset (err -22)
[8.144654] dvb_usb_cxusb: disagrees about version of symbol
dvb_usb_device_init
[8.144655] dvb_usb_cxusb: Unknown symbol dvb_usb_device_init (err -22)
[8.144659] dvb_usb_cxusb: disagrees about version of symbol
dvb_usb_generic_write
[8.144660] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_write (err -22)


Vince
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.4.0-59-generic (buildd@lgw01-11) (gcc version 
5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #80-Ubuntu SMP Fri Jan 6 
17:47:47 UTC 2017 (Ubuntu 4.4.0-59.80-generic 4.4.35)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-59-generic 
root=UUID=420e8415-6799-4f8e-bb39-7d9077271ea6 ro
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'lazy' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009ebff] usable
[0.00] BIOS-e820: [mem 0x0009ec00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7ed12fff] usable
[0.00] BIOS-e820: [mem 0x7ed13000-0x7ed14fff] reserved
[0.00] BIOS-e820: [mem 0x7ed15000-0x7ee2dfff] usable
[0.00] BIOS-e820: [mem 0x7ee2e000-0x7eee4fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7eee5000-0x7eee8fff] usable
[0.00] BIOS-e820: [mem 0x7eee9000-0x7eef2fff] ACPI data
[0.00] BIOS-e820: [mem 0x7eef3000-0x7eef3fff] usable
[0.00] BIOS-e820: [mem 0x7eef4000-0x7eefefff] ACPI data
[0.00] BIOS-e820: [mem 0x7eeff000-0x7eef] usable
[0.00] 

Re: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

I tried your patch, after disabling the custom keymap file I had put
in. Unfortunately the remote isn't working at all. When the relevant
modules get loaded I see this in dmesg


[7.838223] media: Linux media interface: v0.10
[7.840484] WARNING: You are using an experimental version of the
media stack.
As the driver is backported to an older kernel, it doesn't offer
enough quality for its usage in production.
Use it with care.
   Latest git patches (needed if you report a bug to
linux-media@vger.kernel.org):
47b037a0512d9f8675ec2693bed46c8ea6a884ab [media]
v4l2-async: failing functions shouldn't have side effects
79a2eda80c6dab79790c308d9f50ecd2e5021ba3 [media]
mantis_dvb: fix some error codes in mantis_dvb_init()
c2987aaf0c9c2bcb0d4c5902d61473d9aa018a3d [media]
exynos-gsc: Avoid spamming the log on VIDIOC_TRY_FMT
[7.843667] dvb_usb_cxusb: disagrees about version of symbol
dvb_usb_generic_rw
[7.843669] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_rw (err -22)
[7.843692] dvb_usb_cxusb: disagrees about version of symbol rc_keydown
[7.843693] dvb_usb_cxusb: Unknown symbol rc_keydown (err -22)
[7.843701] dvb_usb_cxusb: disagrees about version of symbol
dib0070_wbd_offset
[7.843702] dvb_usb_cxusb: Unknown symbol dib0070_wbd_offset (err -22)
[7.843707] dvb_usb_cxusb: disagrees about version of symbol
dvb_usb_device_init
[7.843708] dvb_usb_cxusb: Unknown symbol dvb_usb_device_init (err -22)
[7.843712] dvb_usb_cxusb: disagrees about version of symbol
dvb_usb_generic_write
[7.843713] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_write (err -22)
[8.089033] dvb_usb_cxusb: disagrees about version of symbol
dvb_usb_generic_rw
[8.089035] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_rw (err -22)
[8.089068] dvb_usb_cxusb: disagrees about version of symbol rc_keydown
[8.089070] dvb_usb_cxusb: Unknown symbol rc_keydown (err -22)
[8.089079] dvb_usb_cxusb: disagrees about version of symbol
dib0070_wbd_offset
[8.089080] dvb_usb_cxusb: Unknown symbol dib0070_wbd_offset (err -22)
[8.089085] dvb_usb_cxusb: disagrees about version of symbol
dvb_usb_device_init
[8.089086] dvb_usb_cxusb: Unknown symbol dvb_usb_device_init (err -22)
[8.089090] dvb_usb_cxusb: disagrees about version of symbol
dvb_usb_generic_write
[8.089091] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_write (err -22)

A manual modprobe gives this:

# modprobe -v dvb_usb_cxusb
insmod 
/lib/modules/4.4.0-59-generic/kernel/drivers/media/usb/dvb-usb/dvb-usb-cxusb.ko
modprobe: ERROR: could not insert 'dvb_usb_cxusb': Invalid argument
# dmesg

[  547.365417] dvb_usb_cxusb: disagrees about version of symbol
dvb_usb_generic_rw
[  547.365422] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_rw (err -22)
[  547.365461] dvb_usb_cxusb: disagrees about version of symbol rc_keydown
[  547.365463] dvb_usb_cxusb: Unknown symbol rc_keydown (err -22)
[  547.365475] dvb_usb_cxusb: disagrees about version of symbol
dib0070_wbd_offset
[  547.365477] dvb_usb_cxusb: Unknown symbol dib0070_wbd_offset (err -22)
[  547.365484] dvb_usb_cxusb: disagrees about version of symbol
dvb_usb_device_init
[  547.365486] dvb_usb_cxusb: Unknown symbol dvb_usb_device_init (err -22)
[  547.365493] dvb_usb_cxusb: disagrees about version of symbol
dvb_usb_generic_write
[  547.365495] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_write (err -22)

I was able to modprobe the rc-dvico-mce module, there was nothing in
dmesg afterward though.

Cheers
Vince
--
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: Failure of ./build

[Vincent McIntyre]

Hi Bill

with this patch I can get past the errors you are seeing. Those errors
are happening because recent changes in the mainline kernel have not
been reflected in the backport patches directory.

[Patch] remove unneeded pr_fmt patches

Recently  (bbdba43f) the pr_fmt macro was removed from ivtvfb.c, and
some lirc driver
files in staging were removed entirely (2933974c..f41003a23a). Update
pr_fmt.patch
to reflect those changes.
Signed-off-by: vincent.mcint...@gmail.com.

diff --git a/backports/pr_fmt.patch b/backports/pr_fmt.patch
index edb56f5..3f374cc 100644
--- a/backports/pr_fmt.patch
+++ b/backports/pr_fmt.patch
@@ -322,18 +322,6 @@ index adcd09b..49382d3 100644
  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

  #include "cx25821-video.h"
-diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
-index 8b95eef..ce1cd12 100644
 a/drivers/media/pci/ivtv/ivtvfb.c
-+++ b/drivers/media/pci/ivtv/ivtvfb.c
-@@ -38,6 +38,7 @@
- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
-  */
-
-+#undef pr_fmt
- #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
- #include 
 diff --git a/drivers/media/pci/saa7134/saa7134.h
b/drivers/media/pci/saa7134/saa7134.h
 index 3849083..957d000 100644
 --- a/drivers/media/pci/saa7134/saa7134.h
@@ -1270,42 +1258,6 @@ index 5f7254d..8606ced 100644
  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

  #include 
-diff --git a/drivers/staging/media/lirc/lirc_bt829.c
b/drivers/staging/media/lirc/lirc_bt829.c
-index 44f5655..a45dd88 100644
 a/drivers/staging/media/lirc/lirc_bt829.c
-+++ b/drivers/staging/media/lirc/lirc_bt829.c
-@@ -18,6 +18,7 @@
-  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-
-+#undef pr_fmt
- #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
- #include 
-diff --git a/drivers/staging/media/lirc/lirc_imon.c
b/drivers/staging/media/lirc/lirc_imon.c
-index a183e68..adad0cd 100644
 a/drivers/staging/media/lirc/lirc_imon.c
-+++ b/drivers/staging/media/lirc/lirc_imon.c
-@@ -20,6 +20,7 @@
-  *   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-  */
-
-+#undef pr_fmt
- #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
- #include 
-diff --git a/drivers/staging/media/lirc/lirc_parallel.c
b/drivers/staging/media/lirc/lirc_parallel.c
-index 3906ac6..b554d48 100644
 a/drivers/staging/media/lirc/lirc_parallel.c
-+++ b/drivers/staging/media/lirc/lirc_parallel.c
-@@ -22,6 +22,7 @@
-  *
-  */
-
-+#undef pr_fmt
- #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
- /*** Includes ***/
 diff --git a/drivers/staging/media/lirc/lirc_sasem.c
b/drivers/staging/media/lirc/lirc_sasem.c
 index b080fde..baa93b9 100644
 --- a/drivers/staging/media/lirc/lirc_sasem.c



However - when I apply the above, the build still falls over, at:

  CC [M]  /home/me/git/clones/media_build/v4l/lgdt3306a.o
/home/me/git/clones/media_build/v4l/lgdt3306a.c: In function 'lgdt3306a_select':
/home/me/git/clones/media_build/v4l/lgdt3306a.c:2140:30: error:
implicit declaration of function 'i2c_mux_priv'
[-Werror=implicit-function-declaration]
  struct i2c_client *client = i2c_mux_priv(muxc);
  ^
/home/me/git/clones/media_build/v4l/lgdt3306a.c:2140:30: warning:
initialization makes pointer from integer without a cast
[-Wint-conversion]
/home/me/git/clones/media_build/v4l/lgdt3306a.c: In function
'lgdt3306a_deselect':
/home/me/git/clones/media_build/v4l/lgdt3306a.c:2148:30: warning:
initialization makes pointer from integer without a cast
[-Wint-conversion]
  struct i2c_client *client = i2c_mux_priv(muxc);
  ^
/home/me/git/clones/media_build/v4l/lgdt3306a.c: In function 'lgdt3306a_probe':
/home/me/git/clones/media_build/v4l/lgdt3306a.c:2182:16: error:
implicit declaration of function 'i2c_mux_alloc'
[-Werror=implicit-function-declaration]
  state->muxc = i2c_mux_alloc(client->adapter, >dev,
^
/home/me/git/clones/media_build/v4l/lgdt3306a.c:2183:13: error:
'I2C_MUX_LOCKED' undeclared (first use in this function)
   1, 0, I2C_MUX_LOCKED,
 ^
/home/me/git/clones/media_build/v4l/lgdt3306a.c:2183:13: note: each
undeclared identifier is reported only once for each function it
appears in
/home/me/git/clones/media_build/v4l/lgdt3306a.c:2189:13: error:
dereferencing pointer to incomplete type 'struct i2c_mux_core'
  state->muxc->priv = client;
 ^
/home/me/git/clones/media_build/v4l/lgdt3306a.c:2190:8: error:
implicit declaration of function 'i2c_mux_add_adapter'
[-Werror=implicit-function-declaration]
  ret = i2c_mux_add_adapter(state->muxc, 0, 0, 0);
^
/home/me/git/clones/media_build/v4l/lgdt3306a.c: In function 'lgdt3306a_remove':
/home/me/git/clones/media_build/v4l/lgdt3306a.c:2214:2: error:
implicit declaration of function 'i2c_mux_del_adapters'
[-Werror=implicit-function-declaration]
  i2c_mux_del_adapters(state->muxc);
  ^
cc1: some warnings being treated as errors
scripts/Makefile.build:264: recipe for target

Re: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

Hey there

On 11/30/16, Vincent McIntyre <vincent.mcint...@gmail.com> wrote:
> On Sun, Nov 27, 2016 at 07:35:10PM +, Sean Young wrote:
>>
>> > I wanted to mention that the IR protocol is still showing as unknown.
>> > Is there anything that can be done to sort that out?
>>
>> It would be nice if that could be sorted out, although that would be
>> a separate patch.
>>
>> So all we know right now is what scancode the IR receiver hardware
>> produces but we have no idea what IR protocol is being used. In order to
>> figure this out we need a recording of the IR the remote sends, for which
>> a different IR receiver is needed. Neither your imon nor your
>> dvb_usb_af9035 can do this, something like a mce usb IR receiver would
>> be best. Do you have access to one? One with an IR emitter would be
>> best.
>>
>> So with that we can have a recording of the IR the remote sends, and
>> with the emitter we can see which IR protocols the IR receiver
>> understands.
>
> Haven't been able to find anything suitable. I would order something
> but I won't be able to follow up for several weeks.
> I'll ask on the myth list to see if anyone is up for trying this.
>

I bought one of these, but I am not sure how to make the recording:

# lsusb -d 1934:5168 -v

Bus 008 Device 003: ID 1934:5168 Feature Integration Technology Inc.
(Fintek) F71610A or F71612A Consumer Infrared Receiver/Transceiver
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize016
  idVendor   0x1934 Feature Integration Technology Inc. (Fintek)
  idProduct  0x5168 F71610A or F71612A Consumer Infrared
Receiver/Transceiver
  bcdDevice0.01
  iManufacturer   1 FINTEK
  iProduct2 eHome Infrared Transceiver
  iSerial 3 88636562727801
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   32
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval   1
Device Status: 0x
  (Bus Powered)


# ir-keytable -v
Found device /sys/class/rc/rc0/
Found device /sys/class/rc/rc1/
Found device /sys/class/rc/rc2/
Found device /sys/class/rc/rc3/  < the new device
Input sysfs node is /sys/class/rc/rc0/input8/
Event sysfs node is /sys/class/rc/rc0/input8/event5/
Parsing uevent /sys/class/rc/rc0/input8/event5/uevent
/sys/class/rc/rc0/input8/event5/uevent uevent MAJOR=13
/sys/class/rc/rc0/input8/event5/uevent uevent MINOR=69
/sys/class/rc/rc0/input8/event5/uevent uevent DEVNAME=input/event5
Parsing uevent /sys/class/rc/rc0/uevent
/sys/class/rc/rc0/uevent uevent NAME=rc-imon-mce
/sys/class/rc/rc0/uevent uevent DRV_NAME=imon
input device is /dev/input/event5
/sys/class/rc/rc0/protocols protocol rc-6 (enabled)
Found /sys/class/rc/rc0/ (/dev/input/event5) with:
Driver imon, table rc-imon-mce
Supported protocols: rc-6
Enabled protocols: rc-6
Name: iMON Remote (15c2:ffdc)
bus: 3, vendor/product: 15c2:ffdc, version: 0x
Repeat delay = 500 ms, repeat period = 125 ms
Input sysfs node is /sys/class/rc/rc1/input18/
Event sysfs node is /sys/class/rc/rc1/input18/event15/
Parsing uevent /sys/class/rc/rc1/input18/event15/uevent
/sys/class/rc/rc1/input18/event15/uevent uevent MAJOR=13
/sys/class/rc/rc1/input18/event15/uevent uevent MINOR=79
/sys/class/rc/rc1/input18/event15/uevent ue

Re: Mysterious regression in dvb driver

[Vincent McIntyre]

On Mon, Jan 23, 2017 at 12:21:35PM +, Dreamcat4 wrote:
> Hi again,
> 
> Installed Antergos (arch) linux today, and its still same issues. That
> is with an even newer 4.8 kernel. No HD channels, I2C error in dmesg,
> CRC error during w_scan tuning. (when its tuning the HD channels).
> 
> So I'm hesitant to report it as a bug under ubuntu bug reporter. Since
> its not just limited to debian-based distros.
> 
> My main question is whats actually all the files on the disk /
> filesystem that are involved? If not in the kernel. Then I could go
> back and grab them all from ubuntu 14.04 (works), to try in 14.10
> (time of first breakage). Replacing one file at a time.
> 
> Wheras... if it is in the kernel then what else was added later on
> that broke this? And why is the newer 4.2 updated kernel in the old
> 14.04 (+.3) still working then? Just doesn't add up / make sense to
> me.
> 
> I would be very grateful if anyone here could please shed some more
> light on the matter.

If it is a cross-distro breakage then probably the kernel bugzilla
might be the right place to file an issue. However you should first
spend a little time to clarify exactly where the issue is occurring.

First, can you find the usb-id or pci-id for the device, as well as
the marketing name. It's important for others to be able to identify
the device unambiguously. dmesg from a working kernel should show this.
Once you have that, run lspci -vvv or lsusb -v for that device and
save the output.

Next I suggest making a list of the kernels you have tried and whether
the device is working or not with that kernel. You want the most detailed
version number you can find, from the kernel package name or changelog.
The release date for the packages would probably be helpful too.

Then you should look for the latest working and earliest non-working
version. Since you are using distro kernels, which will have many
differences from the one published by kernel.org, it may be worth trying
to find the git repository and the git tag that matches the kernels on
either side of the break. This will allow easy diffing of the code.
The changelog for the kernel package should have dates and perhaps even
git commit ids that will help with that quest. If you get stuck on this
just post your results so far, someone may be able to help.

It might also be useful to capture dmesg logs for those two (working/
nonworking) versions so you can look for the place where things go awry.

HTH
Vince
--
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: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

On Sun, Nov 27, 2016 at 07:35:10PM +, Sean Young wrote:
>  
> > I wanted to mention that the IR protocol is still showing as unknown.
> > Is there anything that can be done to sort that out?
> 
> It would be nice if that could be sorted out, although that would be 
> a separate patch.
> 
> So all we know right now is what scancode the IR receiver hardware
> produces but we have no idea what IR protocol is being used. In order to
> figure this out we need a recording of the IR the remote sends, for which
> a different IR receiver is needed. Neither your imon nor your 
> dvb_usb_af9035 can do this, something like a mce usb IR receiver would
> be best. Do you have access to one? One with an IR emitter would be
> best.
> 
> So with that we can have a recording of the IR the remote sends, and
> with the emitter we can see which IR protocols the IR receiver 
> understands.

Haven't been able to find anything suitable. I would order something
but I won't be able to follow up for several weeks.
I'll ask on the myth list to see if anyone is up for trying this.

Thanks again for your help with this
Vince
--
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: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

On Sun, Nov 27, 2016 at 07:35:10PM +, Sean Young wrote:
> > The application I am trying to use it with is the mythtv frontend.  I
> > am doing the keycode munging from an SSH session while myth is still
> > running on the main screen. I didn't think this would matter (since it
> > worked for KEY_OK->KEY_ENTER) but perhaps it does. Obviously
> > ir-keytable -t intercepts the scancodes when it is running, but when I
> > kill it myth responds normally to some keys, but not all.
> 
> X and keycodes is a bit messy. You might need xmodmap mappings. You
> can check them xev. I don't know much about this, I'm afraid. What
> linux distribution, version and keyboard layout are you using? I could
> try and see if I can reproduce/fix this.

I mostly figured this out but something weird happens with the most
significant bit (see my follow-on email). FWIW, this is on ubuntu 16.04
with their standard kernel (4.4) and a bog-standard US english layout.


> > I wanted to mention that the IR protocol is still showing as unknown.
> > Is there anything that can be done to sort that out?
> 
> It would be nice if that could be sorted out, although that would be 
> a separate patch.

That's fine. For the current patch, please feel free to add my
Tested-By: vincent.mcint...@gmail.com

> So all we know right now is what scancode the IR receiver hardware
> produces but we have no idea what IR protocol is being used. In
> order to figure this out we need a recording of the IR the remote
> sends, for which a different IR receiver is needed. Neither your
> imon nor your dvb_usb_af9035 can do this, something like a mce usb
> IR receiver would be best. Do you have access to one? One with an IR
> emitter would be best.
> 
> So with that we can have a recording of the IR the remote sends, and
> with the emitter we can see which IR protocols the IR receiver
> understands.
> 

I'll poke around to see if I can find something, will take a few days.
Thanks again for your interest in this.
Vince
--
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: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

>>
>> However when you try to use the new mapping in some application then
>> it does not work?
>
> That's correct. ir-keytable seems to be doing the right thing, mapping
> the scancode to the input-event-codes.h key code I asked it to.
>
> The application I am trying to use it with is the mythtv frontend.  I
> am doing the keycode munging from an SSH session while myth is still
> running on the main screen. I didn't think this would matter (since it
> worked for KEY_OK->KEY_ENTER) but perhaps it does. Obviously
> ir-keytable -t intercepts the scancodes when it is running, but when I
> kill it myth responds normally to some keys, but not all.

It turned out that that I had to restart X to make it notice the updated keymap.
After that, the modfied keymap I set up is mostly working.

There is still a bit of a mystery. As I understand it, X should notice
key codes less than 255 (0xff). But it seems to be ignoring KEY_STOP
(code 128, 0x80) and any key codes higher than that but less than 255.
ir-keytable -t shows the right codes.

Vince
--
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 media_build install

[Vincent McIntyre]

Hi list,

I sent a patch for this issue, could someone take a look?

http://www.mail-archive.com/linux-media@vger.kernel.org/msg105340.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: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

On 11/25/16, Sean Young  wrote:
>
> So if I understand you correctly, if you change the keymap, like you
> changed 0xfe47 to KEY_PAUSE, then "ir-keytable -s rc1 -t" show you the
> correct (new) key? So as far as ir-keytable is concerned, everything
> works?
>
> However when you try to use the new mapping in some application then
> it does not work?

That's correct. ir-keytable seems to be doing the right thing, mapping
the scancode to the input-event-codes.h key code I asked it to.

The application I am trying to use it with is the mythtv frontend.  I
am doing the keycode munging from an SSH session while myth is still
running on the main screen. I didn't think this would matter (since it
worked for KEY_OK->KEY_ENTER) but perhaps it does. Obviously
ir-keytable -t intercepts the scancodes when it is running, but when I
kill it myth responds normally to some keys, but not all.



I wanted to mention that the IR protocol is still showing as unknown.
Is there anything that can be done to sort that out?

Vince
--
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: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

On Wed, Nov 23, 2016 at 10:34:19PM +, Sean Young wrote:
> > Not sure why Driver is (null), dvb_usb_cxusb is loaded.
> 
> That's a mistake, I've fixed that now.

Ah. I see the added module_name struct members.

> > I tried -t and it generated events constantly, before I could press
> > any keys.
> > # ir-keytable -s rc1 -t
> > Testing events. Please, press CTRL-C to abort.
> > 1479903007.535509: event type EV_MSC(0x04): scancode = 0x00
> > 1479903007.535509: event type EV_SYN(0x00).
> > 1479903007.635521: event type EV_MSC(0x04): scancode = 0x00
> 
> That's also been fixed.
> 

yep, works nicely.

Things are looking much better!
As shown below I am able to clear a keytable and put in a fresh one.
Having a bit of trouble with key remapping.
I guess we still have to work out the protocol in use.

Test details:
# ir-keytable -v
Found device /sys/class/rc/rc0/
Found device /sys/class/rc/rc1/
Found device /sys/class/rc/rc2/
Input sysfs node is /sys/class/rc/rc0/input8/
Event sysfs node is /sys/class/rc/rc0/input8/event5/
Parsing uevent /sys/class/rc/rc0/input8/event5/uevent
/sys/class/rc/rc0/input8/event5/uevent uevent MAJOR=13
/sys/class/rc/rc0/input8/event5/uevent uevent MINOR=69
/sys/class/rc/rc0/input8/event5/uevent uevent DEVNAME=input/event5
Parsing uevent /sys/class/rc/rc0/uevent
/sys/class/rc/rc0/uevent uevent NAME=rc-imon-mce
/sys/class/rc/rc0/uevent uevent DRV_NAME=imon
input device is /dev/input/event5
/sys/class/rc/rc0/protocols protocol rc-6 (enabled)
Found /sys/class/rc/rc0/ (/dev/input/event5) with:
Driver imon, table rc-imon-mce
Supported protocols: rc-6 
Enabled protocols: rc-6 
Name: iMON Remote (15c2:ffdc)
bus: 3, vendor/product: 15c2:ffdc, version: 0x
Input sysfs node is /sys/class/rc/rc1/input18/
Event sysfs node is /sys/class/rc/rc1/input18/event15/
Parsing uevent /sys/class/rc/rc1/input18/event15/uevent
/sys/class/rc/rc1/input18/event15/uevent uevent MAJOR=13
/sys/class/rc/rc1/input18/event15/uevent uevent MINOR=79
/sys/class/rc/rc1/input18/event15/uevent uevent DEVNAME=input/event15
Parsing uevent /sys/class/rc/rc1/uevent
/sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce
/sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb
input device is /dev/input/event15
/sys/class/rc/rc1/protocols protocol unknown (disabled)
Found /sys/class/rc/rc1/ (/dev/input/event15) with:
Driver dvb_usb_cxusb, table rc-dvico-mce
Supported protocols: unknown 
Enabled protocols: 
Name: IR-receiver inside an USB DVB re
bus: 3, vendor/product: 0fe9:db78, version: 0x827b
Input sysfs node is /sys/class/rc/rc2/input19/
Event sysfs node is /sys/class/rc/rc2/input19/event16/
Parsing uevent /sys/class/rc/rc2/input19/event16/uevent
/sys/class/rc/rc2/input19/event16/uevent uevent MAJOR=13
/sys/class/rc/rc2/input19/event16/uevent uevent MINOR=80
/sys/class/rc/rc2/input19/event16/uevent uevent DEVNAME=input/event16
Parsing uevent /sys/class/rc/rc2/uevent
/sys/class/rc/rc2/uevent uevent NAME=rc-empty
/sys/class/rc/rc2/uevent uevent DRV_NAME=dvb_usb_af9035
input device is /dev/input/event16
/sys/class/rc/rc2/protocols protocol nec (disabled)
Found /sys/class/rc/rc2/ (/dev/input/event16) with:
Driver dvb_usb_af9035, table rc-empty
Supported protocols: nec 
Enabled protocols: 
Name: Leadtek WinFast DTV Dongle Dual
bus: 3, vendor/product: 0413:6a05, version: 0x0200
Repeat delay = 500 ms, repeat period = 125 ms
Repeat delay = 500 ms, repeat period = 125 ms
Repeat delay = 500 ms, repeat period = 125 ms

# ir-keytable -r -v -s rc1
Found device /sys/class/rc/rc0/
Found device /sys/class/rc/rc1/
Found device /sys/class/rc/rc2/
Input sysfs node is /sys/class/rc/rc1/input18/
Event sysfs node is /sys/class/rc/rc1/input18/event15/
Parsing uevent /sys/class/rc/rc1/input18/event15/uevent
/sys/class/rc/rc1/input18/event15/uevent uevent MAJOR=13
/sys/class/rc/rc1/input18/event15/uevent uevent MINOR=79
/sys/class/rc/rc1/input18/event15/uevent uevent DEVNAME=input/event15
Parsing uevent /sys/class/rc/rc1/uevent
/sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce
/sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb
input device is /dev/input/event15
/sys/class/rc/rc1/protocols protocol unknown (disabled)
Opening /dev/input/event15
Input Protocol version: 0x00010001
Enabled protocols: 
scancode 0xfe01 = KEY_RECORD (0xa7)
scancode 0xfe02 = KEY_TV (0x179)
scancode 0xfe03 = KEY_0 (0x0b)
scancode 0xfe05 = KEY_VOLUMEDOWN (0x72)
scancode 0xfe07 = KEY_4 (0x05)
scancode 0xfe09 = KEY_CHANNELDOWN (0x193)
scancode 0xfe0a = KEY_EPG (0x16d)
scancode 0xfe0b = KEY_1 (0x02)
scancode 0xfe0d = KEY_STOP (0x80)
scancode 0xfe0e = KEY_MP3 (0x187)
scancode 0xfe0f = KEY_PREVIOUSSONG (0xa5)
scancode 0xfe11 = KEY_CHANNELUP (0x192)
scancode 0xfe12 = KEY_NEXTSONG (0xa3)
scancode 0xfe13 = KEY_ANGLE (0x173)
scancode 0xfe15 = KEY_VOLUMEUP (0x73)
scancode 0xfe16 = KEY_SETUP (0x8d)
scancode 0xfe17 = KEY_2 (0x03)
scancode 0xfe19 = 

Re: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

On Tue, Nov 22, 2016 at 09:20:44AM +, Sean Young wrote:
> > Thanks for this. I have got it to build within the media_build setup
> > but will need to find some windows in the schedule for testing. More
> > in a couple of days. Are there specific things you would like me to
> > test?
> 
> You should have an rc device for the IR receiver in the dvb device; does
> it continue to work and can you clear/load a new keymap with ir-keytable,
> and does it work after that.
> 
> A "Tested-by" would be great if it all works of course.

Time for some initial results. Good start, not quite there yet.

Nov 23 23:04:56 kernel: Registered IR keymap rc-dvico-mce
Nov 23 23:04:56 kernel: input: IR-receiver inside an USB DVB receiver as 
/devices/pci:00
Nov 23 23:04:56 kernel: rc rc1: IR-receiver inside an USB DVB receiver as 
/devices/pci:0
Nov 23 23:04:56 kernel: dvb-usb: schedule remote query interval to 100 msecs.
Nov 23 23:04:56 kernel: dvb-usb: DViCO FusionHDTV DVB-T Dual Digital 4 
successfully initiali
Nov 23 23:04:56 kernel: dvb-usb: found a 'DViCO FusionHDTV DVB-T Dual Digital 
4' in warm sta
Nov 23 23:04:56 kernel: dvb-usb: will pass the complete MPEG2 transport stream 
to the softwa
Nov 23 23:04:56 kernel: dvbdev: DVB: registering new adapter (DViCO FusionHDTV 
DVB-T Dual Di
Nov 23 23:04:56 kernel: usb 3-2: media controller created
Nov 23 23:04:56 kernel: dvbdev: dvb_create_media_entity: media entity 
'dvb-demux' registered
Nov 23 23:04:56 kernel: cxusb: No IR receiver detected on this device.
Nov 23 23:04:56 kernel: usb 3-2: DVB: registering adapter 1 frontend 0 (Zarlink 
ZL10353 DVB-
Nov 23 23:04:56 kernel: dvbdev: dvb_create_media_entity: media entity 'Zarlink 
ZL10353 DVB-T
Nov 23 23:04:56 kernel: xc2028 5-0061: creating new instance
Nov 23 23:04:56 kernel: xc2028 5-0061: type set to XCeive xc2028/xc3028 tuner
Nov 23 23:04:56 kernel: xc2028 5-0061: Loading 80 firmware images from 
xc3028-v27.fw, type: 
Nov 23 23:04:56 kernel: dvb-usb: DViCO FusionHDTV DVB-T Dual Digital 4 
successfully initiali
Nov 23 23:04:56 kernel: usbcore: registered new interface driver dvb_usb_cxusb

# lsmod |grep rc
rc_dvico_mce   16384  0
rc_imon_mce16384  0
rc_core32768  11 
imon,dvb_usb,winbond_cir,dvb_usb_cxusb,rc_imon_mce,rc_dvico_mce,dvb_usb_v2,dvb_usb_af9035
libcrc32c  16384  1 raid456
crc_itu_t  16384  1 firewire_core

# lsmod |grep cxu
dvb_usb_cxusb  77824  2
dib007020480  1 dvb_usb_cxusb
dvb_usb32768  1 dvb_usb_cxusb
rc_core32768  11 
imon,dvb_usb,winbond_cir,dvb_usb_cxusb,rc_imon_mce,rc_dvico_mce,dvb_usb_v2,dvb_usb_af9035


# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event5) with:
Driver imon, table rc-imon-mce
Supported protocols: rc-6 
Enabled protocols: rc-6 
Name: iMON Remote (15c2:ffdc)
bus: 3, vendor/product: 15c2:ffdc, version: 0x
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc1/ (/dev/input/event15) with:
Driver (null), table rc-dvico-mce
Supported protocols: unknown 
Enabled protocols: 
Name: IR-receiver inside an USB DVB re
bus: 3, vendor/product: 0fe9:db78, version: 0x827b
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc2/ (/dev/input/event16) with:
Driver dvb_usb_af9035, table rc-empty
Supported protocols: nec 
Enabled protocols: 
Name: Leadtek WinFast DTV Dongle Dual
bus: 3, vendor/product: 0413:6a05, version: 0x0200
Repeat delay = 500 ms, repeat period = 125 ms

Not sure why Driver is (null), dvb_usb_cxusb is loaded.

# ir-keytable -s rc1 -r -v
Found device /sys/class/rc/rc0/
Found device /sys/class/rc/rc1/
Found device /sys/class/rc/rc2/
Input sysfs node is /sys/class/rc/rc1/input18/
Event sysfs node is /sys/class/rc/rc1/input18/event15/
Parsing uevent /sys/class/rc/rc1/input18/event15/uevent
/sys/class/rc/rc1/input18/event15/uevent uevent MAJOR=13
/sys/class/rc/rc1/input18/event15/uevent uevent MINOR=79
/sys/class/rc/rc1/input18/event15/uevent uevent DEVNAME=input/event15
Parsing uevent /sys/class/rc/rc1/uevent
/sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce
input device is /dev/input/event15
/sys/class/rc/rc1/protocols protocol unknown (disabled)
Opening /dev/input/event15
Input Protocol version: 0x00010001
scancode 0xfe01 = KEY_RECORD (0xa7)
scancode 0xfe02 = KEY_TV (0x179)
scancode 0xfe03 = KEY_0 (0x0b)
scancode 0xfe05 = KEY_VOLUMEDOWN (0x72)
scancode 0xfe07 = KEY_4 (0x05)
scancode 0xfe09 = KEY_CHANNELDOWN (0x193)
scancode 0xfe0a = KEY_EPG (0x16d)
scancode 0xfe0b = KEY_1 (0x02)
scancode 0xfe0d = KEY_STOP (0x80)
scancode 0xfe0e = KEY_MP3 (0x187)
scancode 0xfe0f = KEY_PREVIOUSSONG (0xa5)
scancode 0xfe11 = KEY_CHANNELUP (0x192)
scancode 0xfe12 = KEY_NEXTSONG (0xa3)
scancode 0xfe13 = KEY_ANGLE (0x173)
scancode 0xfe15 = KEY_VOLUMEUP (0x73)
scancode 0xfe16 = KEY_SETUP (0x8d)
scancode 0xfe17 = KEY_2 (0x03)
scancode 0xfe19 = KEY_OPEN (0x86)
scancode 0xfe1a = 

[patch] fix 'make install'

[Vincent McIntyre]

Recent work on handling the case of no frame_vector.c in the kernel
seems to have ended up breaking the 'make install' target. The patch
below makes it work again for me, on ubuntu 16.04 LTS, amd64,
kernel 4.4.
Without it, I get this behavior:
moake -C /home/me/media_build/v4l install
make[1]: Entering directory '/home/me/media_build/v4l'
make[1]: *** No rule to make target 'mm-install', needed by 'install'.  Stop.
make[1]: Leaving directory '/home/me/media_build/v4l'
Makefile:15: recipe for target 'install' failed
make: *** [install] Error 2


diff --git a/v4l/Makefile b/v4l/Makefile
index 28e8fb7..74a2633 100644
--- a/v4l/Makefile
+++ b/v4l/Makefile
@@ -210,8 +210,14 @@ all:: default
 
 #
 # installation invocation rules
-
-modules_install install:: mm-install media-install firmware_install
+INSTALLDEPS :=
+ifeq ($(makefile-mm),1)
+INSTALLDEPS += mm-install
+endif
+ifeq ($(makefile-media),1)
+INSTALLDEPS += media-install
+endif
+modules_install install:: $(INSTALLDEPS) firmware_install
 
 remove rminstall:: media-rminstall
 
Vince
--
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: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

On 11/21/16, Sean Young  wrote:
>>
>> Ah. Here we have a problem. The device (/dev/input/event15)
>> doesn't have a corresponding rcX node, see ir-keytable output below.
>> I had it explained to me like this:
>
> As I said you would need to use a raw IR receiver which has rc-core support
> to determine the protocol, so never mind. Please can you try this patch:
>
> I don't have the hardware to test this so your input would be appreciated.
>

Thanks for this. I have got it to build within the media_build setup
but will need to find some windows in the schedule for testing. More
in a couple of days. Are there specific things you would like me to
test?

Vince
--
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: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

On Fri, Nov 18, 2016 at 05:40:34PM +, Sean Young wrote:
> 
> At the moment it's not easy to determine what protocol an remote uses;
> I would like to change that but for now, the following is probably
> the easiest way.
> 
> cd /sys/class/rc/rc1 # replace rc1 with your receiver
> for i in $( protocols; done
> echo 3 > /sys/module/rc_core/parameters/debug
> journal -f -k
> 
> Protocol numbers are defined in enum rc_type, see include/media/rc-map.h

I tried this with the rc1 device as a test. I get this odd result:
# cat protocols
nec
# echo '+nec' > protocols
bash: echo: write error: Invalid argument

and ir-keytable still shows no protocols enabled
# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event5) with:
Driver imon, table rc-imon-mce
Supported protocols: rc-6 
Enabled protocols: rc-6 
Name: iMON Remote (15c2:ffdc)
bus: 3, vendor/product: 15c2:ffdc, version: 0x
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc1/ (/dev/input/event16) with:
Driver dvb_usb_af9035, table rc-empty
Supported protocols: nec 
Enabled protocols: 
Name: Leadtek WinFast DTV Dongle Dual
bus: 3, vendor/product: 0413:6a05, version: 0x0200
Repeat delay = 500 ms, repeat period = 125 ms

I messed around some more with ir-keytable and got more segfaults
if I try to use the -d argument.

# ir-keytable -d /dev/input/event16 -p NEC -p RC6 -w 
/lib/udev/rc_keymaps/rc6_mce 
Read rc6_mce table
Wrote 63 keycode(s) to driver
Segmentation fault (core dumped)

-s at least doesn't segfault, but doesn't advance the cause.

# ir-keytable -s rc1 -p NEC -p RC6 -w /lib/udev/rc_keymaps/rc6_mce 
Read rc6_mce table
Wrote 63 keycode(s) to driver
/sys/class/rc/rc1//protocols: Invalid argument
Couldn't change the IR protocols


# ir-keytable -s rc1 -p NEC -w /lib/udev/rc_keymaps/winfast
Read winfast table
Wrote 56 keycode(s) to driver
/sys/class/rc/rc1//protocols: Invalid argument
Couldn't change the IR protocols

Vince
--
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: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

On Fri, Nov 18, 2016 at 05:40:34PM +, Sean Young wrote:
> > 
> > # ir-keytable
> > Found /sys/class/rc/rce0/ (/dev/input/event5) with:
> > Driver imon, table rc-imon-mce
> > Supported protocols: rc-6 
> > Enabled protocols: rc-6 
> > Name: iMON Remote (15c2:ffdc)
> > bus: 3, vendor/product: 15c2:ffdc, version: 0x
> > Repeat delay = 500 ms, repeat period = 125 ms
> > Found /sys/class/rc/rc1/ (/dev/input/event16) with:
> > Driver dvb_usb_af9035, table rc-empty
> > Supported protocols: nec 
> > Enabled protocols: 
> > Name: Leadtek WinFamst DTV Dongle Dual
> > bus: 3, vendor/product: 0413:6a05, version: 0x0200
> > Repeat delay = 500 mss, repeat period = 125 ms

So I checked on the ir receivers and found the rc1 device ir receiver
was indeed blocked (haven't checked rc0 properly, time is short)

I tested it with evtest and the remote that comes with the device

# evtest /dev/input/event16
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x413 product 0x6a05 version 0x200
Input device name: "Leadtek WinFast DTV Dongle Dual"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
Event code 28 (KEY_ENTER)
Event code 103 (KEY_UP)
Event code 105 (KEY_LEFT)
Event code 106 (KEY_RIGHT)
Event code 108 (KEY_DOWN)
Event code 111 (KEY_DELETE)
Event code 113 (KEY_MUTE)
Event code 114 (KEY_VOLUMEDOWN)
Event code 115 (KEY_VOLUMEUP)
Event code 119 (KEY_PAUSE)
Event code 128 (KEY_STOP)
Event code 142 (KEY_SLEEP)
Event code 152 (KEY_SCREENLOCK)
Event code 161 (KEY_EJECTCD)
Event code 164 (KEY_PLAYPAUSE)
Event code 167 (KEY_RECORD)
Event code 168 (KEY_REWIND)
Event code 174 (KEY_EXIT)
Event code 207 (KEY_PLAY)
Event code 208 (KEY_FASTFORWARD)
Event code 210 (KEY_PRINT)
Event code 212 (KEY_CAMERA)
Event code 224 (KEY_BRIGHTNESSDOWN)
Event code 225 (KEY_BRIGHTNESSUP)
Event code 226 (KEY_MEDIA)
Event code 352 (KEY_OK)
Event code 356 (KEY_POWER2)
Event code 358 (KEY_INFO)
Event code 365 (KEY_EPG)
Event code 366 (KEY_PVR)
Event code 368 (KEY_LANGUAGE)
Event code 369 (KEY_TITLE)
Event code 370 (KEY_SUBTITLE)
Event code 372 (KEY_ZOOM)
Event code 373 (KEY_MODE)
Event code 377 (KEY_TV)
Event code 385 (KEY_RADIO)
Event code 386 (KEY_TUNER)
Event code 387 (KEY_PLAYER)
Event code 389 (KEY_DVD)
Event code 392 (KEY_AUDIO)
Event code 393 (KEY_VIDEO)
Event code 398 (KEY_RED)
Event code 399 (KEY_GREEN)
Event code 400 (KEY_YELLOW)
Event code 401 (KEY_BLUE)
Event code 402 (KEY_CHANNELUP)
Event code 403 (KEY_CHANNELDOWN)
Event code 407 (KEY_NEXT)
Event code 412 (KEY_PREVIOUS)
Event code 425 (KEY_PRESENTATION)
Event code 512 (KEY_NUMERIC_0)
Event code 513 (KEY_NUMERIC_1)
Event code 514 (KEY_NUMERIC_2)
Event code 515 (KEY_NUMERIC_3)
Event code 516 (KEY_NUMERIC_4)
Event code 517 (KEY_NUMERIC_5)
Event code 518 (KEY_NUMERIC_6)
Event code 519 (KEY_NUMERIC_7)
Event code 520 (KEY_NUMERIC_8)
Event code 521 (KEY_NUMERIC_9)
Event code 522 (KEY_NUMERIC_STAR)
Event code 523 (KEY_NUMERIC_POUND)
  Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN)
Key repeat handling:
  Repeat type 20 (EV_REP)
Repeat code 0 (REP_DELAY)
  Value500
Repeat code 1 (REP_PERIOD)
  Value125
Properties:
Testing ... (interrupt to exit)

Event: time 1479509081.158426, type 4 (EV_MSC), code 4 (MSC_SCAN), value 35a
Event: time 1479509081.158426, -- SYN_REPORT 

Event: time 1479509084.658351, type 4 (EV_MSC), code 4 (MSC_SCAN), value 35e
Event: time 1479509084.658351, -- SYN_REPORT 
^C

I tried to load a keymap but got another segfault

# ir-keytable -p nec -d /dev/input/event16 -w /lib/udev/rc_keymaps/rc6_mce 
Read rc6_mce table
Wrote 63 keycode(s) to driver
Segmentation fault (core dumped)

Can't find a -dbg package so can't give you a useful backtrace
at the moment.

Anyway: trying the same evtest with the dvico remote
evtest /dev/input/event16

Event: time 1479509251.174361, type 4 (EV_MSC), code 4 (MSC_SCAN), value 105
Event: time 1479509251.174361, -- SYN_REPORT 

Event: time 1479509254.174403, type 4 (EV_MSC), code 4 (MSC_SCAN), value 115
Event: time 1479509254.174403, -- SYN_REPORT 

So something is connecting via IR.
Out of time now, more later
Vince
--
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: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

On Fri, Nov 18, 2016 at 05:40:34PM +, Sean Young wrote:
> >  
> > So are you saying that the hex codes in the rc_map_dvico_mce_table
> > struct are invalid (at least in some cases)?
> 
> Most likely the remote produces IR in a standard protocol (e.g. rc5, rc6). 
> If we first get the keymap right then the remote can be used with any 
> IR receiver that can deal with its protocol; conversely, if we know 
> what protocol the IR receiver can receive, and we make it produce the 
> scancodes in the right format, it can then be used with any remote that 
> uses the protocol it understands.
> 
> So at the moment we don't know what protocol it is, and even if it is 
> rc5 then some bit shifting might be needed to make it into a proper
> rc5 scancode (both driver and keymap).
> 
> > How can I tell what protocol is in use?
> > 0x00010001 doesn't mean much to me; I did search the linux source
> > for the code but didn't find any helpful matches.
> 
> At the moment it's not easy to determine what protocol an remote uses;
> I would like to change that but for now, the following is probably
> the easiest way.
> 
> cd /sys/class/rc/rc1 # replace rc1 with your receiver
> for i in $( protocols; done
> echo 3 > /sys/module/rc_core/parameters/debug
> journal -f -k
 
Ah. Here we have a problem. The device (/dev/input/event15)
doesn't have a corresponding rcX node, see ir-keytable output below.
I had it explained to me like this:

  A "HID" device is basically any input device that resembles
  a keyboard or mouse (Human Interface Device). The label may also cover
  things like joysticks, etc. It does /not/ include remotes, so it
  seems, since "remote" can cover a wide variety of input devices.

  Some remotes can emulate fully or partially keyboard keypresses
  which is why they can be treated as HID devices. Of course, not all
  the keys may be mapped correctly or at all.


> Protocol numbers are defined in enum rc_type, see include/media/rc-map.h
> 
> > > Would it be possible to test the remote with another device (say an
> > > usb mce receiver or so) and see what scancodes it sends? Then we can
> > > translate the keymap to a real one and make the cxusb driver send
> > > correct scancodes to rc-core.
> > 
> > Great idea. Do you mean something like [1]?
> 
> Yes, it would be a receiver like that.
> 
> > Or the (presumably generic) receiver that comes with [2]?
> 
> It's not clear what usb receiver it uses.
> 
> > Would a FLIRC work?
> 
> I hadn't heard of flirc, looks like it doesn't have a kernel driver. Maybe
> I'll go and get one. :)
> 
> > Probably dumb question - in this machine I also have
> > an iMon Remote (152c:ffdc)
> > and Leadtek WinFast DTV Dongle Dual
> > Do you think either of those would be helpful?
> > I tried evtest with them and the remote, no responses.
> > 
> > # ir-keytable
> > Found /sys/class/rc/rce0/ (/dev/input/event5) with:
> > Driver imon, table rc-imon-mce
> > Supported protocols: rc-6 
> > Enabled protocols: rc-6 
> > Name: iMON Remote (15c2:ffdc)
> > bus: 3, vendor/product: 15c2:ffdc, version: 0x
> > Repeat delay = 500 ms, repeat period = 125 ms
> > Found /sys/class/rc/rc1/ (/dev/input/event16) with:
> > Driver dvb_usb_af9035, table rc-empty
> > Supported protocols: nec 
> > Enabled protocols: 
> > Name: Leadtek WinFamst DTV Dongle Dual
> > bus: 3, vendor/product: 0413:6a05, version: 0x0200
> > Repeat delay = 500 mss, repeat period = 125 ms
> 
> Looks like it's neither rc6 nor nec then.
> 
> If you don't have the right receiver then all of this a bit academic.
> Maybe it's possible to port to rc-core with the existing scancodes.

I may have given bad information here - I need to check whether the
IR receivers for these devices are properly connected. That might be
why there was no response...

Thanks for your help so far
Vince
--
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: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

On Thu, Nov 17, 2016 at 01:45:26PM +, Sean Young wrote:
> On Wed, Nov 16, 2016 at 09:52:58PM +1100, Vincent McIntyre wrote:
> > I have a fairly old dvico dual digital 4 tuner and remote.
> > There seem to be some issues with support for it, can I help fix them?
> > 
> > I am using ir-keytable 1.10.0-1 on Ubuntu 16.04 LTS,
> > with kernel 4.4.0-47-generic (package version 4.4.0-47-generic)
> > 
> > The remote's keymapping is the one in /lib/udev/rc_keymaps/dvico_mce;
> > kernel support for the device is in media/usb/dvb-usb/cxusb.c.
> > 
> > Mostly it works, in that I get correct keycodes back from evtest
> > and ir-keytable -t. But I want to change some of the keycode mappings
> > and that is not working.
> 
> I suspect the problem here is rc-core is not used and 
> legacy_dvb_usb_setkeycode has a bug (it has several problems).
> 
> It would be nicer if we could move it rc-core, but for that to work
> we need to know what scancodes remote sends (and in what protocol).
> A scancode of 0xfe47 is not a valid RC5 scancode.
 
So are you saying that the hex codes in the rc_map_dvico_mce_table
struct are invalid (at least in some cases)?

How can I tell what protocol is in use?
0x00010001 doesn't mean much to me; I did search the linux source
for the code but didn't find any helpful matches.

> Would it be possible to test the remote with another device (say an
> usb mce receiver or so) and see what scancodes it sends? Then we can
> translate the keymap to a real one and make the cxusb driver send
> correct scancodes to rc-core.

Great idea. Do you mean something like [1]?
Or the (presumably generic) receiver that comes with [2]?
Would a FLIRC work?

Probably dumb question - in this machine I also have
an iMon Remote (152c:ffdc)
and Leadtek WinFast DTV Dongle Dual
Do you think either of those would be helpful?
I tried evtest with them and the remote, no responses.

# ir-keytable
Found /sys/class/rc/rce0/ (/dev/input/event5) with:
Driver imon, table rc-imon-mce
Supported protocols: rc-6 
Enabled protocols: rc-6 
Name: iMON Remote (15c2:ffdc)
bus: 3, vendor/product: 15c2:ffdc, version: 0x
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc1/ (/dev/input/event16) with:
Driver dvb_usb_af9035, table rc-empty
Supported protocols: nec 
Enabled protocols: 
Name: Leadtek WinFamst DTV Dongle Dual
bus: 3, vendor/product: 0413:6a05, version: 0x0200
Repeat delay = 500 mss, repeat period = 125 ms

Thanks
Vince

[1] 
http://www.ebay.com.au/itm/New-HP-USB-MCE-IR-Wireless-Receiver-Windows-7-Vista-/261127073131
[2] https://www.jaycar.com.au/home-theatre-pc-remote-control/p/XC4939

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

ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

Hi,

I have a fairly old dvico dual digital 4 tuner and remote.
There seem to be some issues with support for it, can I help fix them?

I am using ir-keytable 1.10.0-1 on Ubuntu 16.04 LTS,
with kernel 4.4.0-47-generic (package version 4.4.0-47-generic)

The remote's keymapping is the one in /lib/udev/rc_keymaps/dvico_mce;
kernel support for the device is in media/usb/dvb-usb/cxusb.c.

Mostly it works, in that I get correct keycodes back from evtest
and ir-keytable -t. But I want to change some of the keycode mappings
and that is not working.

  # cat >testfile
  0xfe47 KEY_PAUSE
  ^D
  
  # ir-keytable -v -d /dev/input/event15 -w testfile
  Parsing testfile keycode file
  parsing 0xfe47=KEY_PAUSE:   value=119
  Opening /dev/input/event15
  Input Protocol version: 0x00010001
  fe47=0077
  Wrote 1 keycode(s) to driver

So far so good, yes? But evtest still reports the same keycode
for the key I tried to modify.

  # evtest
  
  
  Event: time 1479206112.262746, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), 
value 1
  Event: time 1479206112.262746, -- SYN_REPORT 
  Event: time 1479206112.262760, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), 
value 0
  Event: time 1479206112.262760, -- SYN_REPORT 
 
  # irkeytable -r -d /dev/input/event15 |grep PAUSE
  Enabled protocols: unknown rc-5 sony nec sanyo mce-kbd rc-6 sharp xmp 
  scancode 0xfe02 = KEY_PAUSE (0x77)
  scancode 0xfe47 = KEY_PLAYPAUSE (0xa4)

I thought that I might need to clear and replace the entire table
to get things working. This is where the problems really start.

First trying to clear the table causes an infinite loop.

  # ir-keytable -d /dev/input/event15 -c
  Opening /dev/input/event15
  Input Protocol version: 0x00010001
  Deleting entry 1
  Deleting entry 2
  Deleting entry 3
  Deleting entry 4
  
  Deleting entry 2114689
  Deleting entry 2114690
  ^C

Then I tried to load a modified version of dvico_mce
The whole file was there, with just this change:
--- dvico_mce   2016-11-13 22:50:11.442092350 +1100
+++ testfile2016-11-16 20:46:29.361411631 +1100
@@ -38,7 +38,7 @@
 0xfe03 KEY_0
 0xfe1f KEY_ZOOM
 0xfe43 KEY_REWIND
-0xfe47 KEY_PLAYPAUSE
+0xfe47 KEY_PAUSE
 0xfe4f KEY_FASTFORWARD
 0xfe57 KEY_MUTE
 0xfe0d KEY_STOP

The program seems to parse the modified file ok but then
segaults while reading from the input device.

  # ir-keytable -v -d /dev/input/event15 -w testfile
  Parsing testfile keycode file
  parsing 0xfe02=KEY_TV:  value=377
  parsing 0xfe0e=KEY_MP3: value=391
  parsing 0xfe1a=KEY_DVD: value=389
  parsing 0xfe1e=KEY_FAVORITES:   value=364
  parsing 0xfe16=KEY_SETUP:   value=141
  parsing 0xfe46=KEY_POWER2:  value=356
  parsing 0xfe0a=KEY_EPG: value=365
  parsing 0xfe49=KEY_BACK:value=158
  parsing 0xfe4d=KEY_MENU:value=139
  parsing 0xfe51=KEY_UP:  value=103
  parsing 0xfe5b=KEY_LEFT:value=105
  parsing 0xfe5f=KEY_RIGHT:   value=106
  parsing 0xfe53=KEY_DOWN:value=108
  parsing 0xfe5e=KEY_OK:  value=352
  parsing 0xfe59=KEY_INFO:value=358
  parsing 0xfe55=KEY_TAB: value=15
  parsing 0xfe0f=KEY_PREVIOUSSONG:value=165
  parsing 0xfe12=KEY_NEXTSONG:value=163
  parsing 0xfe42=KEY_ENTER:   value=28
  parsing 0xfe15=KEY_VOLUMEUP:value=115
  parsing 0xfe05=KEY_VOLUMEDOWN:  value=114
  parsing 0xfe11=KEY_CHANNELUP:   value=402
  parsing 0xfe09=KEY_CHANNELDOWN: value=403
  parsing 0xfe52=KEY_CAMERA:  value=212
  parsing 0xfe5a=KEY_TUNER:   value=386
  parsing 0xfe19=KEY_OPEN:value=134
  parsing 0xfe0b=KEY_1:   value=2
  parsing 0xfe17=KEY_2:   value=3
  parsing 0xfe1b=KEY_3:   value=4
  parsing 0xfe07=KEY_4:   value=5
  parsing 0xfe50=KEY_5:   value=6
  parsing 0xfe54=KEY_6:   value=7
  parsing 0xfe48=KEY_7:   value=8
  parsing 0xfe4c=KEY_8:   value=9
  parsing 0xfe58=KEY_9:   value=10
  parsing 0xfe13=KEY_ANGLE:   value=371
  parsing 0xfe03=KEY_0:   value=11
  parsing 0xfe1f=KEY_ZOOM:value=372
  parsing 0xfe43=KEY_REWIND:  value=168
  parsing 0xfe47=KEY_PAUSE:   value=119
  parsing 0xfe4f=KEY_FASTFORWARD: value=208
  parsing 0xfe57=KEY_MUTE:value=113
  parsing 0xfe0d=KEY_STOP:value=128
  parsing 0xfe01=KEY_RECORD:  value=167
  parsing 0xfe4e=KEY_POWER:   value=116
  Read dvico_mce table
  Opening /dev/input/event15
  Input Protocol version: 0x00010001
  fe4e=0074
  fe01=00a7
  fe0d=0080
  fe57=0071
  fe4f=00d0
  fe47=0077
  fe43=00a8
  fe1f=0174
  fe03=000b
  fe13=0173
  fe58=000a
  fe4c=0009
  fe48=0008
  fe54=0007
  fe50=0006
  fe07=0005
  fe1b=0004
  fe17=0003
  fe0b=0002
  fe19=0086
  fe5a=0182
  fe52=00d4
  fe09=0193
  fe11=0192
  fe05=0072
  fe15=0073
  fe42=001c
  fe12=00a3
  fe0f=00a5
  fe55=000f
  fe59=0166
  fe5e=0160
  fe53=006c
  fe5f=006a
  fe5b=0069
  fe51=0067
  fe4d=008b
  fe49=009e
  fe0a=016d
  fe46=0164
  fe16=008d
  fe1e=016c
  fe1a=0185
  

[patch] fix failure when applying backports/debug.patch

[Vincent McIntyre]

Hi,

backports/debug.patch has gotten out of sync with the main tree.
The last patch hunk fails:
...
Applying patches for kernel 3.13.0-57-generic
patch -s -f -N -p1 -i ../backports/api_version.patch
patch -s -f -N -p1 -i ../backports/pr_fmt.patch
patch -s -f -N -p1 -i ../backports/debug.patch
1 out of 1 hunk FAILED
make[2]: *** [apply_patches] Error 1
make[2]: Leaving directory `/home/vjm/git/clones/media_build/linux'
make[1]: *** [allyesconfig] Error 2
make[1]: Leaving directory `/home/vjm/git/clones/media_build/v4l'
make: *** [allyesconfig] Error 2
can't select all drivers at ./build line 490, IN line 4.



This happens because this change removed the #define DEBUG line

commit 890024ad144902bfa637f23b94b396701a88ed88
Author: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
Date:   Fri Jul 3 16:11:41 2015 -0300

[media] stk1160: Reduce driver verbosity

These messages are not really informational, and just makes the driver's
output too verbose. This commit changes some messages to a debug level,
removes a really useless driver loaded message and finally undefines
the DEBUG macro.

Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com


$ git diff e3e30f63389a319ca45161b07eb74e60f1e7ea20 
890024ad144902bfa637f23b94b396701a88ed88 drivers/media/usb/stk1160/stk1160.h
diff --git a/drivers/media/usb/stk1160/stk1160.h
b/drivers/media/usb/stk1160/stk1160.h
index 3922a6c..72cc8e8 100644
--- a/drivers/media/usb/stk1160/stk1160.h
+++ b/drivers/media/usb/stk1160/stk1160.h
@@ -58,7 +58,6 @@
  * new drivers should use.
  *
  */
-#define DEBUG
 #ifdef DEBUG
 #define stk1160_dbg(fmt, args...) \
printk(KERN_DEBUG stk1160:  fmt,  ## args)


The following should fix the issue

diff --git a/backports/debug.patch b/backports/debug.patch
index a222783..cbd9526 100644
--- a/backports/debug.patch
+++ b/backports/debug.patch
@@ -35,7 +35,7 @@ index fb2acc5..8edffcb 100644
  #endif

 diff --git a/drivers/media/usb/stk1160/stk1160.h
b/drivers/media/usb/stk1160/stk1160.h
-index abdea48..2eed017 100644
+index 72cc8e8..323e5d7 100644
 --- a/drivers/media/usb/stk1160/stk1160.h
 +++ b/drivers/media/usb/stk1160/stk1160.h
 @@ -58,6 +58,7 @@
@@ -43,6 +43,6 @@ index abdea48..2eed017 100644
   *
   */
 +#undef DEBUG
- #define DEBUG
  #ifdef DEBUG
  #define stk1160_dbg(fmt, args...) \
+   printk(KERN_DEBUG stk1160:  fmt,  ## args)


--
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: rtl28xx Leadtek

[Vincent McIntyre]

On Sat, May 16, 2015 at 04:37:47PM +1000, Eyal Lebedinsky wrote:
 On 16/05/15 13:23, Vincent McIntyre wrote:
 Hi,
 
 I have been trying to get support going for a
 Leadtek WinFast DTV2000DS Plus (usbid 0413:6f12)
 
 In case it matters here, I have these cards and am using the driver
 built from
   git clone git://linuxtv.org/media_build.git
   git clone g...@github.com:jaredquinn/DVB-Realtek-RTL2832U.git
 
 I get rather reliable tuning with hardly any of the old problems of
 zero length recordings of fails to tune  some channels.
 
 I run old fedora 19 though, and things may have deteriorated since?
 Last time I needed to build was Jan 31 for kernel 3.14.27-100.fc19.x86_64.
 Is this driver included with the kernel these days?

Thanks for your reply Eyal.
There is certainly an in-kernel driver, which I am trying to use.
I don't know what relation it has to the github code, which looks
to have useful information on registers and other magic numbers
that might be needed for proper operation.

Antti, would you care to comment on whether the github code
linked above is useful at all for your work on the realtek drivers?

Cheers
Vince
--
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]: v4l-utils/util/dvb add -C to manpages

[Vincent McIntyre]

Hi
I noticed the -C option was in the help from the -? option
but not in the manpages.
Cheers
Vince

diff --git a/utils/dvb/dvbv5-scan.1.in b/utils/dvb/dvbv5-scan.1.in
index 08e3163..8016185 100644
--- a/utils/dvb/dvbv5-scan.1.in
+++ b/utils/dvb/dvbv5-scan.1.in
@@ -35,6 +35,9 @@ Force dvbv5\-scan to use DVBv3 only.
 \fB\-a\fR, \fB\-\-adapter\fR=\fIadapter#\fR
 Use the given adapter. Default value: 0.
 .TP
+\fB\-C\fR, \fB\-\-cc\fR=\fIcountry_code\fR
+Use the default parameters for the given country code.
+.TP
 \fB\-d\fR, \fB\-\-demux\fR=\fIdemux#\fR
 Use the given demux. Default value: 0.
 .TP
diff --git a/utils/dvb/dvbv5-zap.1.in b/utils/dvb/dvbv5-zap.1.in
index adfcaac..2e471e6 100644
--- a/utils/dvb/dvbv5-zap.1.in
+++ b/utils/dvb/dvbv5-zap.1.in
@@ -40,6 +40,9 @@ Use the given adapter. Default value: 0.
 Select a different audio Packet ID (PID).
 The default is to use the first audio PID found at the \fBchannel-name-file\fR.
 .TP
+\fB\-C\fR, \fB\-\-cc\fR=\fIcountry_code\fR
+Use the default parameters for the given country code.
+.TP
 \fB\-d\fR, \fB\-\-demux\fR=\fIdemux#\fR
 Use the given demux. Default value: 0.
 .TP
--
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

issue with videobuf2-dma-sg.ko

[Vincent McIntyre]

Hi

I am trying to load the cx23885 module. It fails to load and I get this in 
dmesg;

  [  433.506983] videobuf2_dma_sg: Unknown symbol dma_buf_export (err 0)

I wrote a small script to load each of the dependencies one at a time,
which shows pretty clearly the problem is videobuf2-dma-sg.ko.

I am up to date with the media_tree:
  $ git log |head
  commit 59366d3bbae4f67ae3b3a32696faa0798cef1b67
  Author: Hans Verkuil hans.verk...@cisco.com
  Date:   Sat May 2 10:41:49 2015 +0200

  v4l/compat.h: fix compiler warning

  In file included from command-line:0:0:
  v4l/compat.h:1605:11: warning: 'struct device_node' declared inside 
parameter list
 u64 *out_values, size_t sz)
  ^

Can anyone point out how to fix this?
What other information would be useful?
Cheers
Vince

System details

  $ uname -a
  Linux ubuntu 3.13.0-51-generic #84-Ubuntu SMP Wed Apr 15 12:11:46 UTC 2015 
i686 i686 i686 GNU/Linux
  
  $ sudo sh load.sh
  videobuf2_core 3
  videodev 2
  rc_core 1
  altera_ci 0
  modprobe -v altera_ci
  insmod 
/lib/modules/3.13.0-51-generic/kernel/drivers/media/pci/cx23885/altera-ci.ko
  v4l2_common 2
  snd_pcm 4
  snd 17
  tveeprom 0
  modprobe -v tveeprom
  insmod /lib/modules/3.13.0-51-generic/kernel/drivers/media/common/tveeprom.ko
  cx2341x 0
  modprobe -v cx2341x
  insmod /lib/modules/3.13.0-51-generic/kernel/drivers/media/common/cx2341x.ko
  videobuf2_dma_sg 0
  modprobe -v videobuf2_dma_sg
  insmod 
/lib/modules/3.13.0-51-generic/kernel/drivers/media/v4l2-core/videobuf2-dma-sg.ko
  modprobe: ERROR: could not insert 'videobuf2_dma_sg': Unknown symbol in 
module, or unknown parameter (see dmesg)
  videobuf2_dvb 0
  modprobe -v videobuf2_dvb
  insmod 
/lib/modules/3.13.0-51-generic/kernel/drivers/media/v4l2-core/videobuf2-dvb.ko
  dvb_core 2
  tda18271 0
  modprobe -v tda18271
  insmod /lib/modules/3.13.0-51-generic/kernel/drivers/media/tuners/tda18271.ko
  altera_stapl 0
  modprobe -v altera_stapl
  insmod 
/lib/modules/3.13.0-51-generic/kernel/drivers/misc/altera-stapl/altera-stapl.ko
  cx23885 0
  modprobe -v cx23885
  insmod 
/lib/modules/3.13.0-51-generic/kernel/drivers/media/v4l2-core/videobuf2-dma-sg.ko
  modprobe: ERROR: could not insert 'cx23885': Unknown symbol in module, or 
unknown parameter (see dmesg)
  
  $ dmesg|tail
  [   38.177893] nvidia :01:00.0: irq 43 for MSI/MSI-X
  [   39.350957] init: plymouth-upstart-bridge main process ended, respawning
  [   39.390535] init: plymouth-upstart-bridge main process (1381) terminated 
with status 1
  [   39.390563] init: plymouth-upstart-bridge main process ended, respawning
  [   56.994291] audit_printk_skb: 123 callbacks suppressed
  [   56.994298] type=1400 audit(1430633192.185:74): apparmor=STATUS 
operation=profile_replace profile=unconfined 
name=/usr/lib/cups/backend/cups-pdf pid=2295 comm=apparmor_parser
  [   56.994310] type=1400 audit(1430633192.185:75): apparmor=STATUS 
operation=profile_replace profile=unconfined name=/usr/sbin/cupsd 
pid=2295 comm=apparmor_parser
  [   56.994991] type=1400 audit(1430633192.185:76): apparmor=STATUS 
operation=profile_replace profile=unconfined name=/usr/sbin/cupsd 
pid=2295 comm=apparmor_parser
  [  122.119702] videobuf2_dma_sg: Unknown symbol dma_buf_export (err 0)
  [  122.243021] videobuf2_dma_sg: Unknown symbol dma_buf_export (err 0)
  
  
  
  $ cat load.sh
  #!/bin/sh
  for m in videobuf2_core videodev rc_core altera_ci v4l2_common snd_pcm snd 
tveeprom cx2341x videobuf2_dma_sg videobuf2_dvb dvb_core tda18271 altera_stapl 
cx23885
  do
  n=`lsmod|grep -F $m -c`
  echo $m $n
  [ $n -eq 0 ] || continue
  echo modprobe -v $m
  modprobe -v $m
  done
  
--
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: issue with videobuf2-dma-sg.ko

[Vincent McIntyre]

On Sun, May 03, 2015 at 10:45:37AM +0200, Hans Verkuil wrote:
 Hi Vince,
 
 On 05/03/2015 09:14 AM, Vincent McIntyre wrote:
  Hi
  
  I am trying to load the cx23885 module. It fails to load and I get this in 
  dmesg;
  
[  433.506983] videobuf2_dma_sg: Unknown symbol dma_buf_export (err 0)
  
 
 Try again, I've hopefully fixed this problem. You need to do a git pull from 
 the
 media_build.git repo and that should solve it.
 
 Let me know if you run into problems.
 

That was quick work!
I rebuilt and the module is loading fine again, dmesg attached.
Thanks Hans
Vince



dmesg.txt.gz
Description: application/gunzip

Re: [PATCH] [media] rtl28xxu: add [0413:6f12] WinFast DTV2000 DS Plus

[Vincent McIntyre]

On Mon, Mar 09, 2015 at 03:19:01PM +1000, Christian Dale wrote:
 Add Leadtek WinFast DTV2000DS Plus device based on Realtek RTL2832U.
 
 I have not tested the remote, but it is the Y04G0051 model.
 

Thanks for doing this Christian. I have one of these cards also, 0x6f12.
I wrote the same patch some time ago and it is not working for me.
Can you give a few details of what kernel you tested on etc?

I am testing on ubuntu 14.04 LTS
[0.00] Linux version 3.13.0-45-generic (buildd@kissel) (gcc
version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #74-Ubuntu SMP Tue Jan 13
19:37:48 UTC 2015 (Ubuntu 3.13.0-45.74-generic 3.13.11-ckt13)


The symptom I have is when I try to tune with 'scan'
from dvb-apps, the program wedges and I get this in dmesg:
[  163.138982] fc0013: fc0013_set_params: failed: -22
[  164.246233] fc0013: fc0013_set_params: failed: -22
[  165.167758] fc0013: fc0013_set_params: failed: -22
[  166.250280] fc0013: fc0013_set_params: failed: -22
[  167.196580] fc0013: fc0013_set_params: failed: -22
[  168.286208] fc0013: fc0013_set_params: failed: -22
...

kind regards
Vince
--
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: Mygica T230 DVB-T/T2/C Ubuntu 14.04 (kernel 3.13.0-45) using media_build

[Vincent McIntyre]

On 2/23/15, Vincent McIntyre vincent.mcint...@gmail.com wrote:
 I saw this too, while working with Antti on adding support for
 another rtl* device.


I should add how I triggered this
 - build --main-git, make install, halt
 - cold-boot, check modules loaded ok, check /dev/dvb/adapter* exist
 - try to tune with dvb-apps 'scan' and adapter0/tuner0. This is where
the oops occurred.

Vince
--
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: Mygica T230 DVB-T/T2/C Ubuntu 14.04 (kernel 3.13.0-45) using media_build

[Vincent McIntyre]

I saw this too, while working with Antti on adding support for 
another rtl2832-based DVB card.

The kernel version
[0.00] Linux version 3.13.0-45-generic (buildd@kissel) (gcc version 
4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #74-Ubuntu SMP Tue Jan 13 19:37:48 UTC 2015 
(Ubuntu 3.13.0-45.74-generic 3.13.11-ckt13)


This is what dmesg contained:

[  247.897962] BUG: unable to handle kernel NULL pointer dereference at 0008
[  247.897971] IP: [f84f62f4] media_entity_pipeline_start+0x24/0x350 [media]
[  247.897982] *pdpt = 1c70f001 *pde = 
[  247.897988] Oops:  [#1] SMP
[  247.897992] Modules linked in: gpio_ich nvidia(POX) snd_hda_codec_hdmi bnep 
ir_lirc_codec(OX) rfcomm ir_xmp_decoder(OX) lirc_dev(OX) ir_sony_decoder(OX) 
ir_sharp_decoder(OX) ir_sanyo_decoder(OX) ir_rc6_decoder(OX) ir_rc5_decoder(OX) 
ir_nec_decoder(OX) ir_mce_kbd_decoder(OX) ir_jvc_decoder(OX) bluetooth 
rtl2832_sdr(OX) videobuf2_vmalloc(OX) snd_hda_intel videobuf2_memops(OX) 
snd_intel8x0 snd_ac97_codec snd_hda_codec videobuf2_core(OX) ac97_bus snd_hwdep 
v4l2_common(OX) snd_pcm videodev(OX) snd_page_alloc fc0013(OX) snd_seq_midi 
snd_seq_midi_event rtl2832(OX) snd_rawmidi i2c_mux snd_seq dvb_usb_rtl28xxu(OX) 
dvb_usb_v2(OX) dvb_core(OX) rc_core(OX) snd_seq_device media(OX) snd_timer 
dcdbas snd serio_raw drm soundcore lpc_ich shpchp ppdev parport_pc lp mac_hid 
parport hid_generic tg3 usbhid psmouse ptp e1000 pps_core pata_acpi floppy hid
[  247.898043] CPU: 0 PID: 2967 Comm: kdvb-ad-0-fe-0 Tainted: POX 
3.13.0-45-generic #74-Ubuntu
[  247.898046] Hardware name: Dell Inc. OptiPlex GX280/0DG476, 
BIOS A07 11/29/2005
[  247.898049] task: e5e9db00 ti: dbb8 task.ti: dbb8
[  247.898052] EIP: 0060:[f84f62f4] EFLAGS: 00010286 CPU: 0
[  247.898058] EIP is at media_entity_pipeline_start+0x24/0x350 [media]
[  247.898061] EAX:  EBX: e0b26280 ECX: f7b8a580 EDX: f6aac614
[  247.898063] ESI: f6aac400 EDI:  EBP: dbb81f08 ESP: dbb81e30
[  247.898066]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  247.898069] CR0: 8005003b CR2: 0008 CR3: 1c70e000 CR4: 07f0
[  247.898072] Stack:
[  247.898074]  f7b8a5c8 0001 0006  b7de1fcc 0039  
0001
[  247.898081]   f7b8a5c8 0001  dbb81eb4 c1089ef6 dbb81eb8 
c108c7c9
[  247.898086]   f7b8a580 f7b8a5c8 f7b8a580 f261ea00 e5e9db00 dbb81eac 
c108a44a
[  247.898093] Call Trace:
[  247.898102]  [c1089ef6] ? dequeue_task_fair+0x416/0x7c0
[  247.898106]  [c108c7c9] ? enqueue_task_fair+0x5d9/0x7e0
[  247.898110]  [c108a44a] ? check_preempt_wakeup+0x1aa/0x250
[  247.898115]  [c1087b21] ? set_next_entity+0xb1/0xe0
[  247.898120]  [c100ed20] ? __switch_to+0xb0/0x340
[  247.898126]  [c1658fc8] ? __schedule+0x358/0x770
[  247.898130]  [c1082c60] ? try_to_wake_up+0x150/0x240
[  247.898143]  [f8763121] dvb_frontend_thread+0x331/0x9a0 [dvb_core]
[  247.898154]  [f8763121] ? dvb_frontend_thread+0x331/0x9a0 [dvb_core]
[  247.898158]  [c1082dc0] ? default_wake_function+0x10/0x20
[  247.898162]  [c1090f57] ? __wake_up_common+0x47/0x70
[  247.898166]  [c1090f9f] ? __wake_up_locked+0x1f/0x30
[  247.898177]  [f8762df0] ? dvb_frontend_ioctl_legacy.isra.8+0xc20/0xc20 
[dvb_core]
[  247.898182]  [c10751d1] kthread+0xa1/0xc0
[  247.898187]  [c1663b37] ret_from_kernel_thread+0x1b/0x28
[  247.898191]  [c1075130] ? kthread_create_on_node+0x140/0x140
[  247.898193] Code: 90 90 90 90 90 90 90 57 8d 7c 24 08 83 e4 f8 ff 77 fc 55 
89 e5 57 56 53 81 ec cc 00 00 00 3e 8d 74 26 00 89 c7 89 85 48 ff ff ff 8b 40 
08 89 95 50 ff ff ff 89 85 60 ff ff ff 05 44 02 00
00 89
[  247.898229] EIP: [f84f62f4] media_entity_pipeline_start+0x24/0x350 [media] 
SS:ESP 0068:dbb81e30
[  247.898236] CR2: 0008
[  247.898241] ---[ end trace 800df23615d3c02a ]---


The git commit for the media_build tree at the time I compiled
everything was

commit  c40e87b410c9ed170e2ae6ca2aeef06a44621b20 
Add writel_relaxed supportHEADmaster
Signed-off-by: Hans Verkuil hans.verk...@cisco.com

HTH
Vince

--
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: build failure on ubuntu 14.04.1 LTS

[Vincent McIntyre]

On Mon, Jan 19, 2015 at 01:45:44PM +0100, Hans Verkuil wrote:
 On 01/19/2015 01:32 PM, Vincent McIntyre wrote:
  Hi
  
  I am seeing build failures since 11 January.
  A build I did on 22 December worked fine.
  My build procedure and the error are shown below.
 
 I've just updated media_build to stop compiling the smiapp driver for kernels
  3.20. So if you do 'git pull' in your media_build directory and try again
 it should work.

I can confirm that it does work now.
Thanks for the quick turnaround, much appreciated.
Vince
--
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

build failure on ubuntu 14.04.1 LTS

[Vincent McIntyre]

Hi

I am seeing build failures since 11 January.
A build I did on 22 December worked fine.
My build procedure and the error are shown below.

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION=Ubuntu 14.04.1 LTS
$ uname -a
Linux ubuntu 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:30:01 UTC 2014 i686 
i686 i686 GNU/Linux
$ make distclean
$ rm v4l/.config
$ git pull
$ git log |head
commit de98549b53c938b44f578833fe8440b92f4a8c64
Author: Hans Verkuil hans.verk...@cisco.com
Date:   Mon Jan 12 10:53:27 2015 +0100

Update v3.11_dev_groups.patch

Signed-off-by: Hans Verkuil hans.verk...@cisco.com

commit 3886d538f89948d49b652465e0d52e6e9a7329ab
Author: Hans Verkuil hans.verk...@cisco.com

$ ./build --main-git
...
  CC [M]  /home/me/git/clones/media_build/v4l/smiapp-core.o
/home/me/git/clones/media_build/v4l/smiapp-core.c: In function 
'smiapp_get_pdata':
/home/me/git/clones/media_build/v4l/smiapp-core.c:3061:3: error: implicit 
declaration of function 'of_read_number' [-Werror=implicit-function-declaration]
   pdata-op_sys_clock[i] = of_read_number(val + i * 2, 2);
   ^
cc1: some warnings being treated as errors
make[3]: *** [/home/me/git/clones/media_build/v4l/smiapp-core.o] Error 1
make[2]: *** [_module_/home/me/git/clones/media_build/v4l] Error 2
make[2]: Leaving directory `/usr/src/linux-headers-3.13.0-37-generic'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/home/me/git/clones/media_build/v4l'
make: *** [all] Error 2
build failed at ./build line 491, IN line 4.

$ grep -ilr implicit-function-declaration . |grep -v o.cmd
./media/tools/thermal/tmon/Makefile
./media/arch/parisc/math-emu/Makefile
./media/Makefile

It's not clear to me whether this a problem with the media_tree code
or the media_build code.

media/Makefile contains this definition

KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
 -fno-strict-aliasing -fno-common \
 -Werror-implicit-function-declaration \
 -Wno-format-security \
 -std=gnu89

Regards
Vince
--
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] ensure correct install of modules from drivers/{misc,staging}

[Vincent McIntyre]

Hi,

On an ubuntu system the code builds ok but not all modules run properly;
the issue I noticed was the cx23885 module gave these errors when loaded:

[   20.395552] cx23885: disagrees about version of symbol altera_init
[   20.395560] cx23885: Unknown symbol altera_init (err -22)

The cause was that there were two altera-stapl modules in the /lib tree

% find .-type f -name altera_stapl.ko
 ./kernel/drivers/misc/altera-stapl/altera-stapl.ko
 ./kernel/drivers/linux/drivers/misc/altera-stapl/altera-stapl.ko

I traced that back to make_makefile.pl; it was not using the right
directory names for any drivers in drivers/misc or drivers/staging.
For example before the patch this line was being generated:

 n=0;for i in altera-stapl.ko;do if [ -f $i ]; then if [ $n -eq 0 ]; then 
echo -n ../linux/drivers/misc/altera-stapl/: ; install -d 
/lib/modules/3.13.0-35-generic/kernel/drivers/media/../linux/drivers/misc/altera-stapl;
 fi; n=$(($n+1)); if [  $n -eq 4 ]; then echo; echo -n   ; n=1; 
fi; echo -n $i ; install -m 644 -c $i 
/lib/modules/3.13.0-35-generic/kernel/drivers/media/../linux/drivers/misc/altera-stapl;
 fi; done; if [  $n -ne 0 ]; then echo; strip --strip-debug 
/lib/modules/3.13.0-35-generic/kernel/drivers/media/../linux/drivers/misc/altera-stapl/*.ko;
 fi;


after applying this patch the same line is:

 n=0;for i in altera-stapl.ko;do if [ -f $i ]; then if [ $n -eq 0 ]; then 
echo -n ../misc/altera-stapl/: ; install -d 
/lib/modules/3.13.0-35-generic/kernel/drivers/media/../misc/altera-stapl; fi; 
n=$(($n+1)); if [  $n -eq 4 ]; then echo; echo -n   ; n=1; fi; echo 
-n $i ; install -m 644 -c $i 
/lib/modules/3.13.0-35-generic/kernel/drivers/media/../misc/altera-stapl; fi; 
done; if [  $n -ne 0 ]; then echo; strip --strip-debug 
/lib/modules/3.13.0-35-generic/kernel/drivers/media/../misc/altera-stapl/*.ko; 
fi;

This also affects drivers in staging.

The patch is below.

Test system
% cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION=Ubuntu 14.04.1 LTS
% uname -a
Linux ubuntu 3.13.0-25-generic #62-Ubuntu SMP Fri Aug 15 01:58:01 UTC 2014 i686 
i686 i686 GNU/Linux

Vince

[patch] ensure correct install of modules from drivers/{misc,staging}

v4l/scripts/make_mediafile.pl uses the %instdir hash to collate a list
of directories in media_build/linux which contain Makefiles; it uses
this data when constructing a dependency for the Makefile.media target.
It also uses this hash to collate all the individual module names and
generate code which installs the individual modules.
But it gets the installation directory wrong in the case of modules
outside the linux/drivers/media tree.

To fix, do the collation of source locations and conversion into install
locations as separate steps.

signed-off-by: vincent.mcint...@gmail.com

diff --git a/v4l/scripts/make_makefile.pl b/v4l/scripts/make_makefile.pl
index 134f717..6b9ae55 100755
--- a/v4l/scripts/make_makefile.pl
+++ b/v4l/scripts/make_makefile.pl
@@ -2,7 +2,9 @@
 use FileHandle;
 use File::Find;
 
-my %instdir = ();
+my %srcdir  = (); # keys are directory paths (relative to v4l dir),
+  # values are hashes with module file names as their keys
+my %instdir = (); # derived from %srcdir
 
 # Take a Makefile line of the form:
 # obj-X = some_directory/ some_module.o
@@ -12,6 +14,7 @@ my %instdir = ();
 # to install.  Prints the edited line to OUT.
 # Arguments: directory Makefile is in, the objects, original line(s) from
 # Makefile (with newlines intact).
+# Side effects: collates lists of files to install into %srcdir hash
 sub check_line($$$)
 {
my $dir = shift;
@@ -29,11 +32,9 @@ sub check_line($$$)
next;
}
 
-   # It's a file, add it to list of files to install
+   # It's a file, add it to the list of files
s/\.o$/.ko/;
-   my $idir = $dir;
-   $idir =~ s|^../linux/drivers/media/?||;
-   $instdir{$idir}{$_} = 1;
+   $srcdir{$dir}{$_} = 1;
$count++;
}
# Removing any tailling whitespace, just to be neat
@@ -184,7 +185,7 @@ sub removeubuntu($)
my $dest = /lib/modules/\$(KERNELRELEASE)/$udir;
my $filelist;
 
-   while ( my ($dir, $files) = each(%instdir) ) {
+   while ( my ($dir, $files) = each(%srcdir) ) {
$filelist .= ' '. join(' ', keys %$files);
}
while ( my ($dir, $files) = each(%obsolete) ) {
@@ -232,6 +233,15 @@ removeubuntu(/updates/dkms);
 
 print OUT \t\@echo \Installing kernel modules under 
\$(DESTDIR)\$(KDIR26)/:\\n;
 
+# change source dirs (relative to v4l dir)
+# into install dirs  (relative to DESTDIR/KDIR26)
+while (my ($dir, $files) = each %srcdir) {
+   my $idir = $dir;
+   $idir =~ s|\.\./linux/drivers/|../|;
+   $idir =~ s|\.\./media/?||;
+   $instdir{$idir} = $files;
+}
+
 while (my ($dir, $files) = each 

Re: regression: (repost) firmware loading for dvico dual digital 4

[Vincent McIntyre]

Hi Mauro,
thanks for taking the time to look at this.

On Mon, Jun 30, 2014 at 11:56:33AM -0300, Mauro Carvalho Chehab wrote:
 Em Mon, 30 Jun 2014 23:19:46 +1000
 Vincent McIntyre vincent.mcint...@gmail.com escreveu:
 
  Hi,
  
  I am reposting this since it got ignored/missed last time around...
  
  On 5/14/14, Vincent McIntyre vincent.mcint...@gmail.com wrote:
   Hi,
  
   Antti asked me to report this.
  
   I built the latest media_build git on Ubuntu 12.04, with 3.8.0 kernel,
   using './build --main-git'.
   The attached tarball has the relvant info.
  
   Without the media_build modules, firmware loads fine (file dmesg.1)
   Once I build and install the media_build modules, the firmware no
   longer loads. (dmesg.2)
  
   The firmware loading issue appears to have been reported to ubuntu (a
   later kernel, 3.11)  with a possible fix proposed, see
   https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1291459
  
   I can post lspci etc details if people want.
  
  
  An updated version of the tar file is attached.
  
  dmesg.1 is from 3.8.0-38 plus media-build modules and shows the
  firmware loading issue.
  The media-build HEAD revision was
commit e4a8d40f63afa8b0276ea7758d9b4d32e64a964d
Author: Hans Verkuil hans.verk...@cisco.com
Date:   Wed Jun 18 10:27:51 2014 +0200
  
  dmesg.2 is from 3.8.0-42 with the ubuntu-provided modules and does not
  show the issue.
  
  The issue occurs in later ubuntu kernels, 3.11 as noted previously
  and 3.13.0-30.
  
  The OS is ubuntu 12.04 LTS, amd64.
  
  I looked into bisecting this but could not figure out a procedure
  since the 'build' script tries really hard to use the latest
  media-build and kernel sources. It looks like one has to run the
  media-build 'make' against a checkout of the vanilla kernel that
  roughly corresponds in time (or at least is not from a time later than
  the current media-build revision that is checked out).
 
  
  
  Please respond this time
 
 Next time, please add the logs directly at the email, as this makes
 clearer about what's the problem and what driver has the issues.
 

Ok. I wanted to ensure it did not get mangled into unreadability
by the journey through various email systems.

 Anyway, based on this:
 
 [   16.332247] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3), id 
 .
 [   16.344378] cxusb: i2c wr: len=64 is too big!
 
 I suspect that the enclosed patch should fix your issue. Please test. If it
 works, please reply to this email with:
   Tested-by: your name your@email
 

The patch is working for me. My tested-by is inline below.
Test procedure:
- git checkout git://linuxtv.org/media_build.git
- cd media_build
- ./build --main-git
- grep define MAX_XFER_SIZE media/drivers/media/usb/dvb-usb/cxusb.c
#define MAX_XFER_SIZE  64
- vi media/drivers/media/usb/dvb-usb/cxusb.c
- grep define MAX_XFER_SIZE media/drivers/media/usb/dvb-usb/cxusb.c
#define MAX_XFER_SIZE  80
- cd media; make -C ../v4l; cd ..
- sudo make install
- sudo halt
- (after boot) dmesg
- try to tune one of the receivers - works ok
- dmesg

The final dmesg output is inline below.

 Cheers,
 Mauro
 
 -
 
 cxusb: increase buffer lenght to 80 bytes
 
 As reported by Vincent:
   [   16.332247] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3), 
 id .
   [   16.344378] cxusb: i2c wr: len=64 is too big!
 
 64 bytes is too short for firmware load on this device. So, increase it
 to 80 bytes.
 
 Reported-by: Vincent McIntyre vincent.mcint...@gmail.com
 Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com

Tested-by: Vincent McIntyre vincent.mcint...@gmail.com

 
 diff --git a/drivers/media/usb/dvb-usb/cxusb.c 
 b/drivers/media/usb/dvb-usb/cxusb.c
 index 6acde5ee4324..a22726ccca64 100644
 --- a/drivers/media/usb/dvb-usb/cxusb.c
 +++ b/drivers/media/usb/dvb-usb/cxusb.c
 @@ -44,7 +44,7 @@
  #include atbm8830.h
  
  /* Max transfer size done by I2C transfer functions */
 -#define MAX_XFER_SIZE  64
 +#define MAX_XFER_SIZE  80
  
  /* debug */
  static int dvb_usb_cxusb_debug;
 

Final dmesg

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.8.0-38-generic (buildd@lamiak) (gcc version 
4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #56~precise1-Ubuntu SMP Thu Mar 13 
16:22:48 UTC 2014 (Ubuntu 3.8.0-38.56~precise1-generic 3.8.13.19)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-38-generic 
root=UUID=00d24ba0-1c1a-420b-a0de-e811e8a8b90c ro
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009ebff] usable
[0.00] BIOS-e820: [mem 0x0009ec00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem

regression: (repost) firmware loading for dvico dual digital 4

[Vincent McIntyre]

Hi,

I am reposting this since it got ignored/missed last time around...

On 5/14/14, Vincent McIntyre vincent.mcint...@gmail.com wrote:
 Hi,

 Antti asked me to report this.

 I built the latest media_build git on Ubuntu 12.04, with 3.8.0 kernel,
 using './build --main-git'.
 The attached tarball has the relvant info.

 Without the media_build modules, firmware loads fine (file dmesg.1)
 Once I build and install the media_build modules, the firmware no
 longer loads. (dmesg.2)

 The firmware loading issue appears to have been reported to ubuntu (a
 later kernel, 3.11)  with a possible fix proposed, see
 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1291459

 I can post lspci etc details if people want.


An updated version of the tar file is attached.

dmesg.1 is from 3.8.0-38 plus media-build modules and shows the
firmware loading issue.
The media-build HEAD revision was
  commit e4a8d40f63afa8b0276ea7758d9b4d32e64a964d
  Author: Hans Verkuil hans.verk...@cisco.com
  Date:   Wed Jun 18 10:27:51 2014 +0200

dmesg.2 is from 3.8.0-42 with the ubuntu-provided modules and does not
show the issue.

The issue occurs in later ubuntu kernels, 3.11 as noted previously
and 3.13.0-30.

The OS is ubuntu 12.04 LTS, amd64.

I looked into bisecting this but could not figure out a procedure
since the 'build' script tries really hard to use the latest
media-build and kernel sources. It looks like one has to run the
media-build 'make' against a checkout of the vanilla kernel that
roughly corresponds in time (or at least is not from a time later than
the current media-build revision that is checked out).


Please respond this time
Vince


dmesg.tar.xz
Description: Binary data

regression: firmware loading for dvico dual digital 4

[Vincent McIntyre]

Hi,

Antti asked me to report this.

I built the latest media_build git on Ubuntu 12.04, with 3.8.0 kernel,
using './build --main-git'.
The attached tarball has the relvant info.

Without the media_build modules, firmware loads fine (file dmesg.1)
Once I build and install the media_build modules, the firmware no
longer loads. (dmesg.2)

The firmware loading issue appears to have been reported to ubuntu (a
later kernel, 3.11)  with a possible fix proposed, see
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1291459

I can post lspci etc details if people want.

Kind regards
VInce


dmesg.tar.xz
Description: Binary data

[bug]? cx23885 - tries to create duplicate (firmware) filename in sysfs

[Vincent McIntyre]

Hi,

I just noticed this starting to happen - I can't see any sign of it in syslog
before I rebuilt the modules (git commit tags are listed below).
I don't know if this is a backporting issue or a bug in mainline.

The system in question has two dual-tuner cards, one a USB (mounted on
a PCI card)
the other a PCI card. Both use the cx23885 driver. As far as I can see
the PCI card is
where the problem lies - there's no way to distinguish between the two
tuners (I found
this when trying to write some udev rules to generate stably-named symlinks).


% uname -a
Linux ubuntu 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC
2010 i686 GNU/Linux

[4.020062] Latest git patches (needed if you report a bug to
linux-media@vger.kernel.org):
[4.020063]  5e094096b93c9c48b4b90457e83cbca6fc2ff5d4 [media] v1.88
DM04/QQBOX Move remote to use rc_core dvb-usb-remote
[4.020064]  154d70a479c27695a4ad938cc0b14cb91866cf2d [media] Add
missing include guard to header file
[4.020065]  537d9c461e6cbe7a2cc35121f0ee4d48f52753a3 [media]
Inlined functions should be static

The error I see is:

[   34.900554] [ cut here ]
[   34.900561] WARNING: at
/build/buildd/linux-2.6.32/fs/sysfs/dir.c:491
sysfs_add_one+0xa0/0x100()
[   34.900563] Hardware name:
[   34.900565] sysfs: cannot create duplicate filename
'/devices/pci:00/:00:1c.3/:04:00.0/firmware/:04:00.0'
[   34.900567] Modules linked in: ppdev ipt_MASQUERADE iptable_nat
nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack
ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp
kvm_intel kvm snd_hda_codec_realtek snd_hda_intel snd_hda_codec
snd_hwdep snd_pcm_oss fbcon snd_mixer_oss tileblit font snd_pcm
snd_seq_dummy bitblit ir_kbd_i2c tuner_xc2028 softcursor snd_seq_oss
vga16fb snd_seq_midi arc4 vgastate ir_lirc_codec lirc_dev rc_imon_mce
zl10353 snd_rawmidi ir_sony_decoder cx23885 lp i915 snd_seq_midi_event
ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder dvb_usb_cxusb snd_seq
parport cx2341x drm_kms_helper intel_agp videobuf_dma_sg videobuf_dvb
videobuf_core snd_timer snd_seq_device drm i2c_algo_bit video
ir_nec_decoder output v4l2_common snd rtl8180 dib7000p dibx000_common
soundcore agpgart snd_page_alloc videodev mac80211 eeprom_93cx6
dvb_usb btcx_risc imon psmouse dvb_core cfg80211 rc_core tveeprom
serio_raw dib0070 usb_storage raid10 raid456 async_raid6_recov
async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0
ohci1394 multipath ieee1394 ahci e1000e pata_marvell linear
[   34.900653] Pid: 2399, comm: kdvb-ad-2-fe-0 Not tainted
2.6.32-27-generic #49-Ubuntu
[   34.900655] Call Trace:
[   34.900660]  [c014c802] warn_slowpath_common+0x72/0xa0
[   34.900663]  [c02609e0] ? sysfs_add_one+0xa0/0x100
[   34.900666]  [c02609e0] ? sysfs_add_one+0xa0/0x100
[   34.900669]  [c014c87b] warn_slowpath_fmt+0x2b/0x30
[   34.900672]  [c02609e0] sysfs_add_one+0xa0/0x100
[   34.900675]  [c0260a8e] create_dir+0x4e/0x90
[   34.900678]  [c0260b00] sysfs_create_dir+0x30/0x50
[   34.900682]  [c034d642] kobject_add_internal+0x92/0x1d0
[   34.900684]  [c0353846] ? vsnprintf+0x206/0x410
[   34.900687]  [c034d86d] kobject_add_varg+0x2d/0x50
[   34.900692]  [c03e4aeb] ? get_device_parent+0xcb/0x1a0
[   34.900695]  [c034d8ec] kobject_add+0x2c/0x60
[   34.900698]  [c03e5c69] device_add+0x99/0x430
[   34.900701]  [c03ed8d0] ? pm_runtime_init+0xb0/0xc0
[   34.900704]  [c03e6017] device_register+0x17/0x20
[   34.900707]  [c03f098b] fw_register_device+0x14b/0x210
[   34.900710]  [c03f0a7d] fw_setup_device+0x2d/0x100
[   34.900713]  [c03f0c00] _request_firmware+0xb0/0x220
[   34.900715]  [c03f0e17] request_firmware+0x17/0x20
[   34.900722]  [f862317c] generic_set_freq+0x99c/0x18f0 [tuner_xc2028]
[   34.900725]  [c0353daa] ? delay_tsc+0x2a/0x70
[   34.900727]  [c0353d71] ? __const_udelay+0x31/0x40
[   34.900735]  [f858e549] ? i2c_sendbytes+0x169/0x3c0 [cx23885]
[   34.900742]  [f858e810] ? i2c_xfer+0x70/0x140 [cx23885]
[   34.900745]  [c058bde2] ? _cond_resched+0x32/0x50
[   34.900749]  [c0474804] ? i2c_transfer+0x94/0xc0
[   34.900753]  [f8624475] xc2028_set_params+0x195/0x286 [tuner_xc2028]
[   34.900757]  [f83e5c4c] zl10353_set_parameters+0x4ec/0x630 [zl10353]
[   34.900763]  [c058d9bf] ? _spin_lock_irqsave+0x2f/0x50
[   34.900766]  [c015b2ac] ? lock_timer_base+0x2c/0x60
[   34.900777]  [f82b71d5]
dvb_frontend_swzigzag_autotune+0x115/0x300 [dvb_core]
[   34.900785]  [f82b81d1] dvb_frontend_swzigzag+0x261/0x300 [dvb_core]
[   34.900792]  [f82b8a67] dvb_frontend_thread+0x3c7/0x700 [dvb_core]
[   34.900795]  [c058b8ec] ? schedule+0x44c/0x840
[   34.900799]  [c0167b50] ? autoremove_wake_function+0x0/0x50
[   34.900807]  [f82b86a0] ? dvb_frontend_thread+0x0/0x700 [dvb_core]
[   34.900810]  [c01678c4] kthread+0x74/0x80
[   34.900813]  [c0167850] ? kthread+0x0/0x80
[   34.900817]  [c0104087] kernel_thread_helper+0x7/0x10
[   34.900819] ---[ end trace 14130c4e15fe09fe ]---
[   34.900822] kobject_add_internal failed for :04:00.0 

Re: imon: spews to dmesg

[Vincent McIntyre]

I think I have found the source of this.

linux/drivers/media/video/omap3isp/Makefile  contains this:
 ifdef CONFIG_VIDEO_OMAP3_DEBUG
 EXTRA_CFLAGS += -DDEBUG
 endif

but this module is not turned on,nor is the _DEBUG setting for it.
 % grep OMAP3 media_build/v4l/.config
 # CONFIG_VIDEO_OMAP3_DEBUG is not set
 # CONFIG_VIDEO_OMAP3 is not set
 % grep OMAP3 media_build/v4l/.myconfig
 CONFIG_VIDEO_OMAP3_DEBUG := n
 CONFIG_VIDEO_OMAP3   := n

nonetheless:
 % grep DDEBUG media_build/v4l/.imon.o.cmd
...
-fconserve-stack -Idrivers/media/dvb/dvb-core
-Idrivers/media/dvb/dvb-usb -Idrivers/media/dvb/frontends
-Idrivers/media/dvb/dvb-core -Idrivers/media/video
-Idrivers/media/common/tuners -Idrivers/media/dvb/dvb-core
-Idrivers/media/dvb/frontends -Idrivers/media/video
-Idrivers/media/common/tuners -Idrivers/media/dvb/dvb-core
-Idrivers/media/dvb/frontends -DDEBUG -Isound
-Idrivers/staging/cxd2099/ -g
...

Commenting out the three lines above in the omap3isp/Makefile gets rid
of the -DDEBUG
in the .cmd files. It seems to be the only Makefile that sets -DDEBUG
in this way.
Not sure what the real remedy is here.
--
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: Build Failure

[Vincent McIntyre]

On 5/1/11, Colin Minihan colin.mini...@gmail.com wrote:
 On Ubuntu 10.04 attempting to run

 git clone git://linuxtv.org/media_build.git
 cd media_build
 ./check_needs.pl
 make -C linux/ download
 make -C linux/ untar
 make stagingconfig
 make

  results in the following failure
 ...

I see this too (platform details below) but only if I do the 'make
stagingconfig' step
which I don't usually need to. The patch Mauro supplied worked for me;
I just edited
the two files involved and reran 'make' at the point at which the
build had failed.
v4l/config-compat.h had the expected extra #define in it and the build
completed ok.
I haven't tested the resulting module as I don't have the relevant hardware.

Cheers
Vince

platform details:

$ cat /etc/issue
Ubuntu 10.04.2 LTS \n \l
$ uname -a
Linux ubuntu 2.6.32-31-generic #61-Ubuntu SMP Fri Apr 8 18:24:35 UTC
2011 i686 GNU/Linux
$ cat v4l/.version
VERSION=2
PATCHLEVEL:=6
SUBLEVEL:=32
KERNELRELEASE:=2.6.32-31-generic
--
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: imon: spews to dmesg

[Vincent McIntyre]

On 4/20/11, Jarod Wilson ja...@wilsonet.com wrote:


 Those are almost all dev_dbg spew.

Indeed, it seems to come from

retval = send_packet(ictx);
if (retval) {
pr_err(send packet failed!\n);
goto exit;
} else {
dev_dbg(ictx-dev, %s: write %d bytes to LCD\n,
__func__, (int) n_bytes);
}

in imon.c


 The normal way to enable dev_dbg spew is via some debugfs magic:

 http://outer-rim.gnu4u.org/?p=38

 (see also kernel source/Documentation/dynamic-debug-howto.txt)


I don't quite see why this would have happened since I didn't have a
debugfs mounted
during the build or after rebooting to use the new modules, to the
best of my knowledge.

 But I also seem to recall that DEBUG may be getting defined
 somewhere as part of the media_build process, which might be what
 is enabling that spew in your case.

I can't follow the flow in the build system well enough to see for
sure where this would be enabled or not, but some after grepping I
found the following in the file
 /linux/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c
 136-
 137:#define DEBUG 0
 138-static int ttusb_cmd(struct ttusb *ttusb,

All other uses of DEBUG that I can find are #if'ed or #ifdef'ed in the
C code files.

dvb-ttusb-budget.c is being built, but why should the definition there
affect other modules?

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

imon: spews to dmesg

[Vincent McIntyre]

Hi list,

I just (2011-04-19) upgraded to the current media_build with build.sh
 commit bcfdefe9f4538abf12fca1cdb631c80e3d598026
 Author: Mauro Carvalho Chehab mchehab@nehalem.(none)
 Date:   Sun Apr 17 08:21:25 2011 -0300
and hit a problem.

I have an Antec case with an LCD screen. It needs the imon driver.
The LCD screen has been working well using media_build from 2011-01-30.

The imon kernel module now spews this at a high rate:
[   38.532581] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.544545] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.552548] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.560560] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.568546] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.576557] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.584554] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.592558] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.600533] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.608551] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.620024] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.636034] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.652034] imon 9-1:1.0: lcd_write: write 8 bytes to LCD

If I stop LCDd
 # /etc/init.d/LCDd stop
the spew stops.


I'm running on ubuntu 10.04 i386, with lcdproc 0.5.3-0ubuntu2.
$ uname -a
Linux ubuntu  2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC
2010 i686 GNU/Linux
$ modinfo imon
filename:   /lib/modules/2.6.32-27-generic/kernel/drivers/media/rc/imon.ko
license:GPL
version:0.9.2
description:Driver for SoundGraph iMON MultiMedia IR/Display
author: Jarod Wilson ja...@wilsonet.com
srcversion: 268453AC090EFB24F487BE7
alias:  usb:v15C2p0046d*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p0045d*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p0044d*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p0043d*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p0042d*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p0041d*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p0040d*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p003Fd*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p003Ed*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p003Dd*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p003Cd*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p003Bd*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p003Ad*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p0039d*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p0038d*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p0037d*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p0036d*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p0035d*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2p0034d*dc*dsc*dp*ic*isc*ip*
alias:  usb:v15C2pFFDCd*dc*dsc*dp*ic*isc*ip*
depends:rc-core
vermagic:   2.6.32-27-generic SMP mod_unload modversions 586
parm:   debug:Debug messages: 0=no, 1=yes (default: no) (bool)
parm:   display_type:Type of attached display. 0=autodetect,
1=vfd, 2=lcd, 3=vga, 4=none (default: autodetect) (int)
parm:   pad_stabilize:Apply stabilization algorithm to iMON
PAD presses in arrow key mode. 0=disable, 1=enable (default). (int)
parm:   nomouse:Disable mouse input device mode when IR device
is open. 0=don't disable, 1=disable. (default: don't disable) (bool)
parm:   pad_thresh:Threshold at which a pad push registers as
an arrow key in kbd mode (default: 28) (int)

The module load looks normal:
$ dmesg|grep imon
[4.454786] imon 9-1:1.0: imon_probe: found iMON device (15c2:ffdc, intf0)
[4.454794] imon 9-1:1.0: imon_find_endpoints: found IR endpoint
[4.454794] imon 9-1:1.0: imon_find_endpoints: found display endpoint
[4.472053] imon 9-1:1.0: 0xffdc iMON LCD, MCE IR (id 0x9f)
[5.024035] Registered IR keymap rc-imon-mce
[5.024173] imon 9-1:1.0: Configuring IR receiver for MCE protocol
[5.032117] imon 9-1:1.0: Registering iMON display with sysfs
[5.032173] imon 9-1:1.0: iMON device (15c2:ffdc, intf0) on
usb9:2 initialized
[5.032198] usbcore: registered new interface driver imon

Then the display port is opened...
[   38.519700] imon 9-1:1.0: display port opened
[   38.532581] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.544545] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.552548] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.560560] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.568546] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.576557] imon 9-1:1.0: lcd_write: write 8 bytes to LCD
[   38.584554] imon 9-1:1.0: lcd_write: write 8 bytes to LCD

I don't have any load options defined for the imon module.

Can anyone shed light on why the module is spewing to dmesg,
and what should I do to fix it ?

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

Re: [linux-dvb] DVICO HDTV Dual Express2

[Vincent McIntyre]

Hi Nick,

Could you post the output of
  lspci -vvv -nn
for the device in question - you'll also need to give the -s argument,
eg -s 02:00.0
or whatever.

This is so it is clear what chips your example of the card is using -
a given card may be implemented with different chipsets over time
depending on how organised the manufacturer is.

Some kernel output similar to that shown on the wiki page, showing
what happens at boot time, may be useful as well.

I have this card, and it is working reasonably well with recent
media_build code:

$ sudo lspci -vvv -nn -s 04:00.0
04:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
CX23885 PCideo and Audio Decoder [14f1:8852] (rev 02)
Subsystem: DViCO Corporation Device [18ac:db78]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Sping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAborMAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 32
Region 0: Memory at 9000 (64-bit, non-prefetchable) [size=2M]
Capabilities: [40] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
64ns, 1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsuppod-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- Trannd-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
Latenc0 2us, L1 4us
ClockPM- Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommCl
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train-
SlotClk+ DLAct- BWMgmt- ABWMgmt-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] Vital Product Data ?
Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+
Queue=0Enable+
Address: fee0200c  Data: 41c9
Capabilities: [100] Advanced Error Reporting ?
Capabilities: [200] Virtual Channel ?
Kernel driver in use: cx23885
Kernel modules: cx23885
--
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: [linux-dvb] DVICO HDTV Dual Express2

[Vincent McIntyre]

On 4/4/11, Daniel O'Connor dar...@dons.net.au wrote:

 I take it you use both tuners? I find I can only use one otherwise one of
 them hangs whatever app is using it.


I do. I haven't tested very carefully that I can use both tuners at
once successfully but I am pretty sure there have been times when both
have been running. I only use them with mythtv,
unless I am testing something like new v4l modules and in that case I
just use one tuner at a time.

The box has two tuner cards, and this one is usually the second one in
the enumeration.
--
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] Re: media_build: build fails against (ubuntu) 2.6.32 on pvrusb2-debugifc.c

[Vincent McIntyre]

The problem was the new check function was not being called.
Signed-off-by: vincent.mcint...@gmail.com

diff --git a/v4l/scripts/make_config_compat.pl b/v4l/scripts/make_config_compat.
index 438561a..f1dd577 100755
--- a/v4l/scripts/make_config_compat.pl
+++ b/v4l/scripts/make_config_compat.pl
@@ -485,6 +485,7 @@ sub check_other_dependencies()
check_vzalloc();
check_flush_work_sync();
check_autosuspend_delay();
+   check_hex_to_bin()
 }

 # Do the basic rules
--
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

media_build: build fails against (ubuntu) 2.6.32 on pvrusb2-debugifc.c

[Vincent McIntyre]

Hi,

I am building against linux-2.6.32-26-generic from ubuntu, with just
the linux-headers package.

I know there is a big fat warning about doing this but I thought I
should report the issue
because mostly building like this does work.

The build was against a clean checkout of the media_build tree, using build.sh.

The build fails with:
  CC [M]  /home/vjm/git/clones/linuxtv.org/media_build/v4l/pvrusb2-sysfs.o
  CC [M]  /home/vjm/git/clones/linuxtv.org/media_build/v4l/pvrusb2-debugifc.o
/home/vjm/git/clones/linuxtv.org/media_build/v4l/pvrusb2-debugifc.c:
In function 'debugifc_parse_unsigned_number':
/home/vjm/git/clones/linuxtv.org/media_build/v4l/pvrusb2-debugifc.c:108:
error: implicit declaration of function 'hex_to_bin'
make[3]: *** 
[/home/vjm/git/clones/linuxtv.org/media_build/v4l/pvrusb2-debugifc.o]
Error 1

I was able to get the build to complete by hand-editing v4l/config-compat.h
@@ -11,6 +11,8 @@

 #include linux/mmdebug.h

+#define NEED_HEX_TO_BIN 1
+
 #undef CONFIG_VIDEO_SH_VOU
 #undef CONFIG_VIDEO_SH_VOU_MODULE
 #undef CONFIG_MX1_VIDEO

and rerunning make.

After inspecting the relevant commit[1] I'm a bit baffled as to why
this occurred.
It seems as though the header file is not being found correctly,
although it does exist,
at /usr/src/linux-headers-2.6.32-26-generic/include/linux/kernel.h.

 % grep -i hex_to_bin
/usr/src/linux-headers-2.6.32-26-generic/include/linux/kernel.h
 %

I'll poke a bit more into this and hopefully come up with a fix.
Cheers
Vince

[1] 
http://git.linuxtv.org/media_build.git?a=commit;h=2f3b6a700ee9b687b59a1eda8f8336b9aa4c47a6
--
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] addition to v2.6.35_i2c_new_probed_device.patch (was: Re: Debug code in HG repositories)

[Vincent McIntyre]

On 1/13/11, Mauro Carvalho Chehab mche...@redhat.com wrote:

 This seems to be a relatively simple patch, inline below.
 This is against the linux-media tree,  I could not figure out how
 to turn it into a clean patch of
 media_build/backports/v2.6.35_i2c_new_probed_device.patch
 I did look for guidance on how to do this in
 media_build/README.patches  but could not find anything that looked
 relevant.

 Well, there are two ways for doing it:


Thanks for your explanation. I was quite puzzled for some time why I
could not find the commit id in the git log, now I understand why.


 The code now compiles for me but I don't know if it will actually
 work, I don't have the hardware.

 Ok, I did the above procedure, adding your patch to the diff. Please test.


That bit works now (from git, the tarball downloaded by build.sh
hasn't caught up).
Thanks for applying.

However the build now fails on a separate issue, which I'll put in a new thread.

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

media_build: build against 2.6.32 fails on rc-technisat-usb2.c

[Vincent McIntyre]

$ cat /proc/version_signature
Ubuntu 2.6.32-26.47-generic 2.6.32.24+drm33.11

Building from git:
$ cd ~/git/clones/v4l-dvb
$ git log -1
commit aeb13b434d0953050306435cd3134d65547dbcf4
Author: Mauro Carvalho Chehab mche...@redhat.com
Date:   Wed Jan 5 13:31:15 2011 -0200

cx25821: Fix compilation breakage due to BKL dependency
...

$ cd ~/git/clones/new_build
$ git log -1
commit 6da048c31318ddeb9b19d899403a91f4c10e34dc
Author: Vincent McIntyre vincent.mcint...@gmail.com
Date:   Thu Jan 13 10:41:14 2011 -0200

Update it to cover hdpvr-i2c.c

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

Building via make tar DIR=... ; make untar; etc fails at this point:

  CC [M]  /home/vjm/git/clones/linuxtv.org/new_build/v4l/rc-streamzap.o
  CC [M]  /home/vjm/git/clones/linuxtv.org/new_build/v4l/rc-tbs-nec.o
make[4]: *** No rule to make target
`/home/vjm/git/clones/linuxtv.org/new_build/v4l/rc-technisat-usb2.c',
needed by `/home/vjm/git/clones/linuxtv.org/new_build/v4l/rc-technisat-usb2.o'.
 Stop.

I'll take a look but thought I should report this.

Cheers
Vince
--
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] addition to v2.6.35_i2c_new_probed_device.patch (was: Re: Debug code in HG repositories)

[Vincent McIntyre]

On 1/12/11, Mauro Carvalho Chehab mche...@redhat.com wrote:

 which on the face of it suggests
   btty-input.c

already handled, my mistake.

   cx88-input.c
the search string was in a comment

   hdpvr-i2c.c
see below


 I have no time currently to touch on it, since I still have lots of patches
 to
 take a look and submit for the merge window. So, if you have some time,
 could you please prepare and submit a patch fixing it?

This seems to be a relatively simple patch, inline below.
This is against the linux-media tree,  I could not figure out how
to turn it into a clean patch of
media_build/backports/v2.6.35_i2c_new_probed_device.patch
I did look for guidance on how to do this in
media_build/README.patches  but could not find anything that looked
relevant.

The code now compiles for me but I don't know if it will actually
work, I don't have the hardware.

Cheers
Vince

Signed-off-by: Vince McIntyre vincent.mcint...@gmail.com
---
 drivers/media/video/hdpvr/hdpvr-i2c.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c
b/drivers/media/video/hdpvr/hdpvr-i2c.c
index 24966aa..129639a 100644
--- a/drivers/media/video/hdpvr/hdpvr-i2c.c
+++ b/drivers/media/video/hdpvr/hdpvr-i2c.c
@@ -59,7 +59,7 @@ static int hdpvr_new_i2c_ir(struct hdpvr_device
*dev, struct i2c_adapter *adap,
break;
}

-   return i2c_new_probed_device(adap, info, addr_list, NULL) == NULL ?
+   return i2c_new_probed_device(adap, info, addr_list) == NULL ?
   -1 : 0;
 }

-- 
1.7.0.4
From 1b44e5c3b2886224042d9c20649311c231db3ccd Mon Sep 17 00:00:00 2001
From: Vince McIntyre vincent.mcint...@gmail.com
Date: Thu, 13 Jan 2011 15:30:13 +1100
Subject: [PATCH] To compile against 2.6.32, drop extra arg when calling i2c_new_probed_device()

Signed-off-by: Vince McIntyre vincent.mcint...@gmail.com
---
 drivers/media/video/hdpvr/hdpvr-i2c.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c b/drivers/media/video/hdpvr/hdpvr-i2c.c
index 24966aa..129639a 100644
--- a/drivers/media/video/hdpvr/hdpvr-i2c.c
+++ b/drivers/media/video/hdpvr/hdpvr-i2c.c
@@ -59,7 +59,7 @@ static int hdpvr_new_i2c_ir(struct hdpvr_device *dev, struct i2c_adapter *adap,
 		break;
 	}
 
-	return i2c_new_probed_device(adap, info, addr_list, NULL) == NULL ?
+	return i2c_new_probed_device(adap, info, addr_list) == NULL ?
 	   -1 : 0;
 }
 
-- 
1.7.0.4

Re: Debug code in HG repositories

[Vincent McIntyre]

On 1/10/11, Mauro Carvalho Chehab mche...@redhat.com wrote:

 Thanks for your script, but it seems specific to your environment. Could you
 please make it more generic and perhaps patch the existing build.sh script?

I was mainly intending to show how I happen to do this. It's way too complicated
compared to build.sh, which is a really nice solution.

 It would be nice to have some optional parameters there, to make life easier
 for end-users.

I can certainly try to supply some patches but I'm not sure what
parameters you have in mind.
build.sh is such a nice simple method; my script attempts to do
everything via git which is
overkill unless one is actively developing. Perhaps I could rework
into a distinct build_git.sh.

Cheers
Vince
--
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: Debug code in HG repositories

[Vincent McIntyre]

On 1/10/11, Mauro Carvalho Chehab mche...@redhat.com wrote:
 Em 07-01-2011 23:02, Vincent McIntyre escreveu:
 On 1/8/11, Hans Verkuil hverk...@xs4all.nl wrote:

 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
 promote this more. I could add backwards compatibility builds to my daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.


 As an end-user I would be interested in seeing this added, since it
 will allow faster detection of breakage in the older versions. For
 instance building against 2.6.32 fails like this:

   CC [M]  /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o
 /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c: In
 function 'hdpvr_new_i2c_ir':
 /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c:62: error:
 too many arguments to function 'i2c_new_probed_device'
 make[4]: *** [/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o]
 Error 1
 make[3]: *** [_module_/home/vjm/git/clones/linuxtv.org/new_build/v4l]
 Error 2
 make[3]: Leaving directory
 `/usr/src/linux-headers-2.6.32-26-ec297b-generic'
 make[2]: *** [default] Error 2
 make[2]: Leaving directory
 `/home/vjm/git/clones/linuxtv.org/new_build/v4l'
 make[1]: *** [all] Error 2
 make[1]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build'
 make: *** [default] Error 2

 It's unclear that adding this would cause a lot of extra work; the
 patches that need to be applied are quite few - a tribute to the
 design work!

 That's weird. Here, it compiles fine against my 2.6.32 kernel, as there's a
 patch that removes the extra parameter. I'll double check and add a fix
 if I found something wrong.

I think a couple of modules may have been missed;
$ cd media_build
$ grep -rl i2c_new_probed_device v4l | grep -v .o
v4l/cx23885-i2c.c
v4l/bttv-input.c
v4l/cx88-input.c
v4l/ivtv-i2c.c
v4l/hdpvr-i2c.c
v4l/v4l2-common.c
v4l/cx18-i2c.c
v4l/em28xx-cards.c

$ grep +++ backports/v2.6.35_i2c_new_probed_device.patch
+++ b/drivers/media/video/bt8xx/bttv-input.cTue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/cx18/cx18-i2c.c   Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/cx23885/cx23885-i2c.c Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/em28xx/em28xx-cards.c Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/ivtv/ivtv-i2c.c   Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/v4l2-common.c Tue Oct 26 14:17:09 2010 -0200
+++ b/drivers/media/video/ivtv/ivtv-i2c.c   Tue Oct 26 23:18:52 2010 -0200

which on the face of it suggests
  btty-input.c
  cx88-input.c
  hdpvr-i2c.c
need looking at.

I get the same result whether building from a git clone of media-tree
or via media_build/build.sh.

I am building against ubuntu 2.6.32-26-generic aka 2.6.32.24+drm33.11, on i386.
I am using just their kernel-headers package for the build. Usually it works ok.

Cheers
Vince
--
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: difference mchehab/new_build.git to media_build.git ?

[Vincent McIntyre]

 There's no difference. It started out at mchehab/new_build.git, then got
 moved
 to media_build.git, but there's a symlink in place to keep from breaking
 things
 for people who originally checked it out at the old location.

 The move essentially promoted it from something Mauro's tinkering with to
 something generally useful for a wider audience. And its also being worked
 on
 by more people than just Mauro now (myself included).

Thanks for clarifying this. Doesn't this justify a one-line NEWS item?
I can understand not wanting to mention it while still experimental, but now...

Vince
--
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] new_build.git - avoid failing on 'rm' of nonexistent file

[Vincent McIntyre]

While attempting to build recently I have found the 'make distclean'
target fails if 'rm' tries to remove a file that is not there. The
attached patch fixes the issue for me (by using rm -f).
I converted all the other 'rm' calls to 'rm -f' along the way.

Please consider applying this.

Cheers
Vince
diff --git a/linux/Makefile b/linux/Makefile
index 695dcf2..8bbeee8 100644
--- a/linux/Makefile
+++ b/linux/Makefile
@@ -53,7 +52,7 @@ help:
 
 todaytar:
 	@if [ $(DIR) =  ]; then echo make $@ DIR=version; exit -1; fi
-	-rm $(PWD)/$(TODAY_TAR).bz2
+	-rm -f $(PWD)/$(TODAY_TAR).bz2
 	tar cf $(PWD)/$(TODAY_TAR) -C $(DIR) $(TARFILES)
 	-git --git-dir $(DIR)/.git log --pretty=oneline HEAD^1^1^1^1^1^1^1^1..HEAD git_log
 	tar rvf $(PWD)/linux-media.tar git_log
@@ -70,7 +69,7 @@ todaytar:
 
 tar:
 	@if [ $(DIR) =  ]; then echo make $@ DIR=version; exit -1; fi
-	-rm $(PWD)/linux-media.tar.bz2
+	-rm -f $(PWD)/linux-media.tar.bz2
 	tar cf $(PWD)/linux-media.tar -C $(DIR) $(TARFILES)
 	-git --git-dir $(DIR)/.git log --pretty=oneline HEAD^1^1^1^1^1^1^1^1..HEAD git_log
 	tar rvf $(PWD)/linux-media.tar git_log
@@ -97,7 +96,7 @@ dir: clean
 	./use_dir.pl $(DIR)
 
 distclean: clean
-	-rm linux-media.tar.bz2 linux-media.tar.bz2.md5
+	-rm -f linux-media.tar.bz2 linux-media.tar.bz2.md5
 
 apply_patches apply-patches:
 	@if [ -e .linked_dir ]; then ./use_dir.pl --recheck --silent; fi
@@ -131,7 +130,7 @@ apply_patches apply-patches:
 	mv .patches_applied .patches_applied.old; \
 	echo #$$dir  .patches_applied; \
 	cat .patches_applied.old  .patches_applied; \
-	rm .patches_applied.old; \
+	rm -f .patches_applied.old; \
 	if [ -e .linked_dir ]; then ./use_dir.pl --get_patched; fi
 
 unapply_patches unapply-patches:
@@ -141,7 +140,7 @@ unapply_patches unapply-patches:
 		echo patch -s -f -R -p1 -i ../backports/$$i; \
 		patch -s -f -R -p1 -i ../backports/$$i || break; \
 	done; \
-	rm .patches_applied; fi
+	rm -f .patches_applied; fi
 
 download:
 	wget $(LATEST_TAR_MD5) -O linux-media.tar.bz2.md5.tmp

[patch] new_build.git - drop videodev.h

[Vincent McIntyre]

'make tar' fails for me (building against ubuntu 2.6.32) unless I
remove videodev.h from TARFILES.

Is this the correct thing to do here?

diff --git a/linux/Makefile b/linux/Makefile
index 695dcf2..8bbeee8 100644
--- a/linux/Makefile
+++ b/linux/Makefile
@@ -20,7 +20,6 @@ TARDIR += include/media/
 TARDIR += include/linux/dvb/
 TARFILES += include/linux/usb/video.h
 TARFILES += include/linux/i2c-id.h
-TARFILES += include/linux/videodev.h
 TARFILES += include/linux/ivtv.h
 TARFILES += include/linux/mmc/sdio_ids.h
 TARFILES += include/linux/ivtvfb.h

Cheers
Vince
--
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: Debug code in HG repositories

[Vincent McIntyre]

On 1/8/11, Hans Verkuil hverk...@xs4all.nl wrote:

 Have you tried Mauro's media_build tree? I had to use it today to test a
 driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should
 promote this more. I could add backwards compatibility builds to my daily
 build script that uses this in order to check for which kernel versions
 this compiles if there is sufficient interest.


As an end-user I would be interested in seeing this added, since it
will allow faster detection of breakage in the older versions. For
instance building against 2.6.32 fails like this:

  CC [M]  /home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o
/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c: In
function 'hdpvr_new_i2c_ir':
/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.c:62: error:
too many arguments to function 'i2c_new_probed_device'
make[4]: *** [/home/vjm/git/clones/linuxtv.org/new_build/v4l/hdpvr-i2c.o]
Error 1
make[3]: *** [_module_/home/vjm/git/clones/linuxtv.org/new_build/v4l] Error 2
make[3]: Leaving directory `/usr/src/linux-headers-2.6.32-26-ec297b-generic'
make[2]: *** [default] Error 2
make[2]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build/v4l'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/vjm/git/clones/linuxtv.org/new_build'
make: *** [default] Error 2

It's unclear that adding this would cause a lot of extra work; the
patches that need to be applied are quite few - a tribute to the
design work!

For what it's worth, I've attached the shell script I use to pull
updates and do a new build.
Doing the initial setup is well explained by the
linuxtv.org/media_tree.git page,
but this script may be of use to end users wanting to track development.

Cheers
Vince


update-and-build.sh
Description: Bourne shell script

Re: new_build on ubuntu (dvbdev.c)

[Vincent McIntyre]

On 11/15/10, Mauro Carvalho Chehab mauroche...@gmail.com wrote:
...
 I've added several patches for the new-build today, in order to make it
 compile
 against older kernels. I tested compilation here with both RHEL6 (2.6.32)
 and
 Fedora 14 (2.6.35) and compilation is working fine. Didn't test the drivers.
 I'm not sure if the remote controller will properly work with my quick
 backport.

Thanks  for those changes. The build completes now, with only three warnings.
I do have to say CONFIG_DVB_FIREDTV=n, it appears still to be a
problem on ubuntu.

 First dumb question - (I'll try to minimise these)

...
 The patches generally reverse-apply some upstream change. Andy's approach
 could be done via compat.h. I opted to just backport the upstream patch.

 Anyway, there were other problems on it, due to other API changes, and to
 the move of the rc-core from .../IR to .../rc directory.

 I opted to simplify the backports, avoiding to duplicate the same patch on
 several different directories.


I see that now, after some quality time in the backports directory. It
does look simpler.

I think my original problem was that somehow the patch in the
2.6.32_series to remove references to noop_llseek() was not applying
cleanly. No idea why, I flushed the logs I kept.

Thanks all, I'll give the new build a test run as soon as I get a chance.

Cheers
Vince
--
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: new_build on ubuntu (dvbdev.c)

[Vincent McIntyre]

Apologies, I replied off-list.

On 11/14/10, Andy Walls awa...@md.metrocast.net wrote:
 On Sun, 2010-11-14 at 09:08 +1100, Vincent McIntyre wrote:
 Hi,
 I'm trying to build on 2.6.32 (ubuntu lucid i386).

 I followed the instructions for building from git[1]

 Shouldn't you be building from:

   http://git.linuxtv.org/mchehab/new_build.git

 for backward compat builds? (I'm not sure myself.)

Yes, I am using this as described in the README (make tar DIR=foo;
make untar; make).

 noop_llseek() is a newer kernl function that provided a trivial llseek()
 implmenetation for drivers that don't support llseek() but still want to
 provide a successful return code:

 http://lkml.org/lkml/2010/4/9/193
 http://lkml.org/lkml/2010/4/9/184

Thanks for explaining this.

 Is it that an additional backport patch may be needed here?

 Yup.  It looks like you need something.  You'll need a patch to
 implement the trivial noop_llseek() function available in the links
 above.

This is helpful, indeed.

First dumb question - (I'll try to minimise these)

 * Inspection of the patches new_build/backports shows all the patches
are to things in the v4l/ tree
 * Yet the patch you pointed to is to fs/read_write.c and include/linux/fs.h

So my question: should this function be implemented as a patch to
files outside the v4l/ tree
or as additional .c and .h files within the v4l top level. I guess the
latter would then need to be #included in a bunch of v4l files. I'm
mainly unsure of the convention here.

I checked the mkrufky tree mentioned in README.patches but that didn't help.
I also checked the mercurial tree and could not find any backport of
noop_llseek,
but I may have missed something.

The consumers of the function appear to be:
$ find v4l -exec grep -li noop_llseek {} \;
v4l/dvb_frontend.c
v4l/lirc_imon.c
v4l/lirc_dev.c
v4l/lirc_it87.c
v4l/imon.c
v4l/dvb_ca_en50221.c
v4l/dvb_net.c
v4l/dvbdev.c
v4l/lirc_sasem.c
v4l/av7110_av.c
v4l/av7110.c
v4l/av7110_ir.c
v4l/dst_ca.c
v4l/firedtv-ci.c
--
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

new_build on ubuntu (dvbdev.c)

[Vincent McIntyre]

Hi,
I'm trying to build on 2.6.32 (ubuntu lucid i386).

I followed the instructions for building from git[1]
but I get an error I don't understand.

make -C /lib/modules/2.6.32-25-3dbc39-generic/build
SUBDIRS=/home/me/git/clones/linuxtv.org/new_build/v4l  modules
make[3]: Entering directory `/usr/src/linux-headers-2.6.32-25-3dbc39-generic'
  CC [M]  /home/me/git/clones/linuxtv.org/new_build/v4l/tuner-xc2028.o
  CC [M]  /home/me/git/clones/linuxtv.org/new_build/v4l/tuner-simple.o
  CC [M]  /home/me/git/clones/linuxtv.org/new_build/v4l/tuner-types.o
  CC [M]  /home/me/git/clones/linuxtv.org/new_build/v4l/mt20xx.o
...all ok so far...
  CC [M]  /home/me/git/clones/linuxtv.org/new_build/v4l/flexcop-dma.o
/home/me/git/clones/linuxtv.org/new_build/v4l/dvbdev.c:108: error:
'noop_llseek' undeclared here (not in a function)
make[4]: *** [/home/me/git/clones/linuxtv.org/new_build/v4l/dvbdev.o] Error 1
make[3]: *** [_module_/home/me/git/clones/linuxtv.org/new_build/v4l] Error 2
make[3]: Leaving directory `/usr/src/linux-headers-2.6.32-25-3dbc39-generic'
make[2]: *** [default] Error 2
make[2]: Leaving directory `/home/me/git/clones/linuxtv.org/new_build/v4l'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/me/git/clones/linuxtv.org/new_build'
make: *** [default] Error 2

Is it that an additional backport patch may be needed here?

The kernel I am running here is Ubuntu 2.6.32-25.43-generic (2.6.32.21+drm33.7)
with one tiny patch, reverting a bad change to drivers/usb/serial/ftdi_sio.c.

Any advice appreciated.

[1] http://git.linuxtv.org/media_tree.git
--
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] new_build.git - remove bashist equality testing

[Vincent McIntyre]

Hi,

while trying to build this on ubuntu 10.04 (2.6.32-24-generic) I
noticed some of the equality
tests in linux/Makefile are bash-style, not POSIX-style.
The problem I encountered was error messages like:
  ...
  make -C ../linux apply_patches
  make[2]: Entering directory `/home/ltv/git/clones/linuxtv.org/new_build/linux'
  [: 23: v2.6.32: unexpected operator
  cat: .patches_applied: No such file or directory
  [: 23: unexpected operator

Please consider applying the attached patch, which fixes the problem for me.

Cheers
Vince
diff --git a/linux/Makefile b/linux/Makefile
index 563ed17..801081f 100644
--- a/linux/Makefile
+++ b/linux/Makefile
@@ -60,11 +60,11 @@ help:
 	@echo   untar|clean|distclean
 
 todaytar:
-	@if [ $(DIR) ==  ]; then echo make $@ DIR=version; exit -1; fi
+	@if [ $(DIR) =  ]; then echo make $@ DIR=version; exit -1; fi
 	-rm $(PWD)/$(TODAY_TAR).bz2
 	tar cf $(PWD)/$(TODAY_TAR) -C $(DIR) $(TARFILES)
 	for i in $(TARDIR); do \
-		if [ `echo $$i|grep Documentation` ==  ]; then \
+		if [ `echo $$i|grep Documentation` =  ]; then \
 			dir=`(cd $(DIR); find $$i -type f -name *.[ch])`; \
 			dir=$$dir `(cd $(DIR); find $$i -type f -name Makefile)`; \
 			dir=$$dir `(cd $(DIR); find $$i -type f -name Kconfig)`; \
@@ -74,11 +74,11 @@ todaytar:
 		fi; done; bzip2 $(PWD)/$(TODAY_TAR)
 
 tar:
-	@if [ $(DIR) ==  ]; then echo make $@ DIR=version; exit -1; fi
+	@if [ $(DIR) =  ]; then echo make $@ DIR=version; exit -1; fi
 	-rm $(PWD)/linux-media.tar.bz2
 	tar cf $(PWD)/linux-media.tar -C $(DIR) $(TARFILES)
 	for i in $(TARDIR); do \
-		if [ `echo $$i|grep Documentation` ==  ]; then \
+		if [ `echo $$i|grep Documentation` =  ]; then \
 			dir=`(cd $(DIR); find $$i -type f -name *.[ch])`; \
 			dir=$$dir `(cd $(DIR); find $$i -type f -name Makefile)`; \
 			dir=$$dir `(cd $(DIR); find $$i -type f -name Kconfig)`; \
@@ -94,14 +94,14 @@ clean:
 	-rm -rf $(MAINDIRS) .patches_applied
 
 dir: clean
-	@if [ $(DIR) ==  ]; then echo make $@ DIR=version; exit -1; fi
+	@if [ $(DIR) =  ]; then echo make $@ DIR=version; exit -1; fi
 	@echo Searching in $(DIR)/Makefile for kernel version.
 
 	for i in $(TARFILES); do \
 		install -D $(DIR)/$$i $$i; \
 	done
 	for i in $(TARDIR); do \
-		if [ `echo $$i|grep Documentation` ==  ]; then \
+		if [ `echo $$i|grep Documentation` =  ]; then \
 			dir=`(cd $(DIR); find $$i -type f -name *.[ch])`; \
 			dir=$$dir `(cd $(DIR); find $$i -type f -name Makefile)`; \
 			dir=$$dir `(cd $(DIR); find $$i -type f -name Kconfig)`; \
@@ -125,9 +125,9 @@ apply_patches apply-patches:
 		fi; \
 	fi; \
 	if [ $(VER) !=  ]; then dir=v$(VER); fi; \
-	if [ $$dir ==  ]; then echo make $@ VER=version; exit -1; fi; \
+	if [ $$dir =  ]; then echo make $@ VER=version; exit -1; fi; \
 	if [ -e ../backports/$$dir/series ]; then \
-		if [ `cat .patches_applied` == $$dir ]; then \
+		if [ `cat .patches_applied` = $$dir ]; then \
 			echo Patches for $$dir already applied.; exit; \
 		else \
 			$(MAKE) unapply_patches; \

Re: Reception issue: DViCO Fusion HDTV DVB-T Dual Express

[Vincent McIntyre]

I have this card (lspci reports pciid 14f1:8852, subsystem 18ac:db78)
and the Dual Digital 4 (lsusb 0fe9:db78).
I had a few problems similar to this (on Nine in Sydney, particularly)
until Mauro applied
some patches to fix some weirdness in the calculations of the tuning
offsets, a few months ago now. Now they are running reliably. I don't
know if the patches have made it into
mainstream distro kernels yet, but you should have them if you are
building the dvb drivers from the mercurial tree against the kernel
you have.

You may want to try dvbsnoop (http://www.linuxtv.org/wiki/index.php/Dvbsnoop)
to check on the mpeg streams. I haven't used it myself...

See also http://www.linuxtv.org/wiki/index.php/Testing_reception_quality
and http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device.

HTH
Vince

It may also help to load the driver module with the 'debug' option on.
--
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: [OT] preferred video apps?

[vincent . mcintyre]

On 1/05/10 10:48 AM, Mauro Carvalho Chehab wrote:


Please, _do_not_ reply privately ;)



I've found VLC useful for testing reception quality by eye,
though it's not obvious how to force usage of a particular tuner.
I am pretty sure it can record.

Also '{c,s,t}zap' ow w-zap are helpful for quick tests of basic 
functionality like tuning, and with the signaltest.pl script

( http://linuxtv.org/wiki/index.php/Testing_reception_quality)

I use MythTV in 'production' but I find it a bit clumsy for testing with.

Cheers
Vince

--
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: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

[Vincent McIntyre]

 Mauro,

 Resend of my proposed patch attached that reverts tuning regressions with
 my DViCO card, whilst still fixing the original 6Mhz tuning issue.  Please
 merge or let me know how else I should proceed to get this merged.

 Thanks

 -Rob

perhaps the attached notes will help Rob's case here.
I did a few more tests, with just one tuner.
First I changed a cable that I was suspicious of (it was way too long anyway)
but I got no significant improvement.
Then I applied the 'revert2.diff' patch that Rob sent and cold-booted.
I reran the test and got significantly lower BER and UNC values.

There is still something odd going on, in that the UNC seem to get
worse with repeated tunings to the same channel, a few minutes apart
(less than 10min). This might be a
measurement artefact, I don't know. I might try changing the channel
order - that should
test whether the trend of the UNC values is with frequency or order in
the tuning sequence.

Cheers
VInce
2009-12-07

Try signaltest.pl again.

First, with old cable and no code changes
hg identify = c57f47cfb0e8+ tip

tuner 0 is usbid 0fe9:db78
do three consecutive runs to see if things worsen with repeated tuning.

Frequency   Signal  Ber Unc
=   
17750 75.9 %   318.9   376.2
191625000 74.5 %   280.1   904.9
21950 77.0 %   245.2  1862.2
22650 77.0 %   186.4  3525.4
57150 77.1 %   502.9  6161.3
57850 77.2 %   541.1  9128.8

Frequency   Signal  Ber Unc
=   
17750 75.5 %   314.6 11219.2
191625000 74.0 %   384.3 12057.3
21950 76.8 %   118.7 13236.9
22650 76.8 %   173.5 15256.6
57150 77.0 %   472.3 17930.7
57850 77.1 %   550.0 20888.8

Frequency   Signal  Ber Unc
=   
17750 75.4 %   346.0 23052.8
191625000 73.3 %   347.5 24087.7
21950 76.7 %   236.0 25289.0
22650 76.8 %   190.1 27241.0
57150 76.9 %   541.1 29910.0
57850 77.1 %   511.7 32902.1


Now repeat with the 1.5m cable connecting wall socket to splitter.
cold boot the machine
hg identify = c57f47cfb0e8+ tip

dvb0.frontend0: usbid 0fe9:db78

Frequency   Signal  Ber Unc
=   
17750 74.0 %   288.2   784.8
191625000 73.3 %   487.2  1890.9
21950 76.7 %   147.2  3189.8
22650 76.8 %   202.2  5094.7
57150 76.9 %   443.1  7640.6
57850 76.9 %   499.9 10675.3

Frequency   Signal  Ber Unc
=   
17750 73.0 %   330.7 12795.4
191625000 72.6 %   291.8 13844.3
21950 76.7 %   132.5 15005.5
22650 76.8 %   136.2 16928.0
57150 76.9 %   525.2 19480.7
57850 77.0 %   522.7 22361.7

Frequency   Signal  Ber Unc
=   
17750 75.5 %   361.6 24584.2
191625000 73.8 %   480.9 25816.4
21950 76.7 %   143.4 26962.2
22650 76.8 %   187.5 28846.1
57150 77.0 %   468.4 31448.9
57850 77.0 %   547.3 34511.8


Now make the code change. Cold boot.
dvb0.frontend0: usbid 0fe9:db78

Frequency   Signal  Ber Unc
=   
17750 76.5 % 0.0 0.0
191625000 76.9 %   136.8   102.3
21950 76.9 %   297.6   549.0
22650 76.8 %   304.7  1461.4
57150 76.9 %   505.0  3801.0
57850 77.0 %   573.7  6818.6

Frequency   Signal  Ber Unc
=   
17750 76.4 % 0.0  8345.0
191625000 76.8 %   169.7  8476.0
21950 76.7 %   243.8  8967.2
22650 76.9 %   271.6  9904.7
57150 76.9 %   525.9 12097.4
57850 77.1 %   

Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

[Vincent McIntyre]

Hi Rob

would you mind very much posting a patch that implements these two reversions,
so I can try it easily? My hg-fu is somewhat lacking...
I have the same hardware and noticed what I think is the same issue,
just with Channel 9.
Another manifestation is huge BER and nonzero REC in the output from 'tzap'.

Kind regards,
Vince


On 11/26/09, Robert Lowery rglow...@exemail.com.au wrote:
 Hi,

 After fixing up a hang on the DViCO FusionHDTV DVB-T Dual Digital 4 (rev
 1) recently via http://linuxtv.org/hg/v4l-dvb/rev/1c11cb54f24d everything
 appeared to be ok, but I have now noticed certain channels in Australia
 are showing corruption which manifest themselves as blockiness and
 screeching audio.

 I have traced this issue down to
 http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 (Fix offset frequencies for
 DVB @ 6MHz)
 Actually, in addition to the above changeset, I also had to revert
 http://linuxtv.org/hg/v4l-dvb/rev/966ce12c444d (Fix 7 MHz DVB-T)  to get
 things going.  Seems this one might have been an attempt to fix an issue
 introduced by the latter, but for me both must be reverted.

 -Rob


 In this change, the offset used by my card has been changed from 275
 to 225.

 The old code which works used to do something like
 offset = 275
 if (((priv-cur_fw.type  DTV7) 
 (priv-cur_fw.scode_table  (ZARLINK456 | DIBCOM52))) ||
 ((priv-cur_fw.type  DTV78)  freq  47000))
 offset -= 50;

 In Australia, (type  DTV7) == true _BUT_ scode_table == 129 == SCODE,
 so the subtraction is not done.

 The new code which does not work does
 if (priv-cur_fw.type  DTV7)
 offset = 225;
 which appears to be off by 500khz causing the tuning regression for me.

 Could any one please advice why this check against scode_table 
 (ZARLINK456 | DIBCOM52) was removed?

 Thanks

 -Rob



 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
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: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

[Vincent McIntyre]

On 11/26/09, Vincent McIntyre vincent.mcint...@gmail.com wrote:

 Another manifestation is huge BER and nonzero REC in the output from
 'tzap'.
doh! I meant huge BER and nonzero UNC.

Apologies also for the top-post.
--
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: bisected regression in tuner-xc2028 on DVICO dual digital 4

[Vincent McIntyre]

On 11/8/09, Devin Heitmueller dheitmuel...@kernellabs.com wrote:

 I think the next step at this point is for you to definitively find a
 use case that does not work with the latest v4l-dvb tip and Robert's
 patch, and include exactly what kernel you tested with and which board
 is having the problem (including the PCI or USB ID).

 At this point, your description seems a bit vague in terms of what is
 working and what is not.  If you do the additional testing to narrow
 down specifically the failure case you are experiencing, I will see
 what I can do.

I'm trying to be as clear as I can.

We can forget about setups 1 and 2, they no longer have the messages
from the cxusb module that I originally reported, I can tune and run
signal level tests like [1].

I'm now looking at setup 3.
 os: ubuntu karmic i386
 kernel: 2.6.31-14-generic
 v4l modules: hg identify returns 19c0469c02c3+ tip

 If I cold boot, I see no tuning issues at the kernel level. Details
of the test below.

 The failure I was attempting to report is that
 I am unable to tune with dvbscan or w_scan.
 I think it is due to changes in the V4L API with respect to the versions
 of these programs I have installed.

 However I am able to tune with 'tzap'. I'm not entirely sure why tzap works,
 but it does and it shows the v4l tip drivers are ok regarding the
issue originally
 reported.

 There are two further areas I am looking into.
 1. If I *warm* boot the same setup, I see dvb-usb: bulk message failed:
 in dmesg.
 I am working on this still to try to get a clear report for you of when
 and on which device it occurs. It will probably take me a week to get
 back to you.
 2. There may be differences in performance, in that:
 2.6.31-14-generic+v4l+Rob shows worse Bit Error Rates than
 2.6.31-14-generic+Rob
 Again I have some work to do to clarify this.
 It seems likely it is a separate issue from this thread.

 That said, I'm preparing a tree with Robert's patch since I am pretty
 confident at least his particular problem is now addressed.

I can see no obstacle to you going ahead with that. Thanks again.

Cheers
Vince

Test details:
 I tune like this:
   sudo strace -t -ff -F -o tzap.strace /usr/bin/tzap -a 0 -r -c
channels.conf 7 Digital(Seven Network)

 In dmesg I see the firmware being loaded but no other messages:
   [ 1232.684884] usb 3-1: firmware: requesting xc3028-v27.fw
   [ 1232.743698] xc2028 1-0061: Loading 80 firmware images from
xc3028-v27.fw, type: xc2028 firmware, ver 2.7
   [ 1232.756391] xc2028 1-0061: Loading firmware for type=BASE F8MHZ
(3), id .
   [ 1237.332511] xc2028 1-0061: Loading firmware for type=D2633 DTV7
(90), id .
   [ 1237.416510] xc2028 1-0061: Loading SCODE for type=SCODE
HAS_IF_5260 (6000), id .

 I can successfully tune each of the 4 tuners in this way. Each time I
run tzap on
 a tuner I've not used before, dmesg shows the firmware loading ok.


[1] http://linuxtv.org/wiki/index.php/Testing_reception_quality
--
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: bisected regression in tuner-xc2028 on DVICO dual digital 4

[Vincent McIntyre]

Hi Barry,

did you try cold-booting either system?

how are you tuning? mythtv?

Cheers
Vince


On 11/9/09, Barry Williams bazzaw...@gmail.com wrote:
 On Mon, Nov 9, 2009 at 12:22 PM, Devin Heitmueller
 dheitmuel...@kernellabs.com wrote:
 On Sun, Nov 8, 2009 at 8:43 PM, Barry Williams bazzaw...@gmail.com
 wrote:
 Hi Devin
 I tried your tree and I seem to get the same problem on one box I get
 the flood of 'dvb-usb: bulk message failed: -110 (1/0'.
 snip

 Can you please confirm the USB ID of the board you are having the
 problem with (by running lsusb from a terminal window)?

 Thanks,

 Devin
 --


 On the first box I have
 Bus 003 Device 003: ID 0fe9:db98 DVICO
 Bus 003 Device 002: ID 0fe9:db98 DVICO

 on the second
 Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

[Vincent McIntyre]

Hi Devin

 please confirm exactly which of your boards is not working.

Sorry for being unclear.

I have three test setups I am working with, all on the same computer.
1. Ubuntu Hardy, kernel 2.6.24-23-rt and drivers from v4l-dvb tip.
2. Ubuntu Karmic, kernel 2.6.31-14-generic, stock Ubuntu drivers.
3. Ubuntu Karmic, kernel 2.6.31-14-generic, v4l-dvb tip.

Setups 2  3 are the same install, on a separate hard disk from setup 1.
I change between 2  3 by installing the v4l modules or restoring the
ubuntu stuff from backup. (rsync -av --delete).

The computer has two DVB-T cards.

First device is the same as Robert's, I believe. It has two tuners. lsusb gives:
Bus 003 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
(ZL10353+xc2028/xc3028) (initialized)
Bus 003 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
(ZL10353+xc2028/xc3028) (initialized)
I have a 'rev1' version of this board.


Second device is DViCO FusionHDTV Dual Digital Express, a PCIe card
based on cx23885[1] It also has two tuners. lspci gives:
04:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 02)
Subsystem: DViCO Corporation Device [18ac:db78]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at 9000 (64-bit, non-prefetchable) [size=2M]
Capabilities: access denied
Kernel driver in use: cx23885
Kernel modules: cx23885

With Robert's patch compiled in:
 * On setup 1
  I am able to tune both cards and there are no errors from the cxusb module
   or dvb-usb anymore.
   I tested each of the four tuners, by running dvbscan with
appropriate arguments to
   select the right /dev/dvb/adapterN.

   I just realised I should probably revert the patch and check which
tuners show the
   original problem. Before I was taking the default choice (adapter0,
I think) which is
one of lhe Dual Digital 4 tuners.

 * I have yet to test setup 2,
   I have built the patched kernel module but the box is back 'in
production' right now.
   I plan to test tomorrow.

 * On setup 3. I attempted to tune using dvbscan, w_scan and vlc.
   Again, I was not specific about which tuner the applications should use.
   So to answer your question, I think it is the lsusb id 0fe9:db78
that is unable to tune.
   I will check the tuners individually, tomorrow.

   My impression was that the failures were because of API differences
between the
   applications (all provided as part of the ubuntu install) and the
V4L modules. I have
   not tried to build v4l-apps from the mercurial tree.

So, I hope this makes things clearer. Happy to run tests if you have
any time to look at this.

Kind regards
Vince


[1] http://linuxtv.org/wiki/index.php/DViCO_FusionHDTV_DVB-T_Dual_Express

On 11/7/09, Devin Heitmueller dheitmuel...@kernellabs.com wrote:
 Please excuse the top post. This is coming from my phone.

 Vincent, please confirm exactly which of your boards is not working.
 Roberts patch is not a general fix and only applies to his EXACT
 product .

 please provide the pci/usb I'd in question.

 thanks,

 devin

 On 11/6/09, Vincent McIntyre vincent.mcint...@gmail.com wrote:
 I tried this patch, on 2.6.24-23-rt and 2.6.31-14-generic
 .
 On the first, it appears to work fine. Thanks again Rob!

 On the second, while the kernel seems happy I am unable to get any
 applications to tune the card, when I use the latest v4l tree + Rob's
 patch (40705fec2fb2 tip).

  * dvbscan fails with 'unable to query frontend status'

  * vlc is unable to tune as well
 [0x9c2cf50] dvb access error: DVB-T: setting frontend failed (-1):
 Invalid argument
 [0x9c2cf50] dvb access error: DVB-T: tuning failed
 [0xb7400c18] main input error: open of `dvb://frequency=177500' failed:
 (null)


  * w_scan fails a bit more informatively
 w_scan version 20090808 (compiled for DVB API 5.0)
 using settings for AUSTRALIA
 DVB aerial
 DVB-T AU
 frontend_type DVB-T, channellist 3
 output format vdr-1.6
 Info: using DVB adapter auto detection.
 /dev/dvb/adapter0/frontend0 - DVB-T Zarlink ZL10353 DVB-T: good
 :-)
 /dev/dvb/adapter1/frontend0 - DVB-T Zarlink ZL10353 DVB-T: good
 :-)
 /dev/dvb/adapter2/frontend0 - DVB-T Zarlink ZL10353 DVB-T: good
 :-)
 /dev/dvb/adapter3/frontend0 - DVB-T Zarlink ZL10353 DVB-T: good
 :-)
 Using DVB-T frontend (adapter /dev/dvb/adapter0/frontend0)
 -_-_-_-_ Getting frontend capabilities-_-_-_-_
 Using DVB API 5.1
 frontend Zarlink ZL10353 DVB-T supports
 INVERSION_AUTO
 QAM_AUTO
 TRANSMISSION_MODE_AUTO
 GUARD_INTERVAL_AUTO
 HIERARCHY_AUTO
 FEC_AUTO
 -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 Scanning 7MHz frequencies...
 177500: (time: 00:00) set_frontend:1690

Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

[Vincent McIntyre]

I have one of these too.

lsusb:
Bus 003 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
(ZL10353+xc2028/xc3028) (initialized)
Bus 003 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
(ZL10353+xc2028/xc3028) (initialized)

In addition I have a DViCO Dual Digital Express which is a PCIe card
based on Conexant, with the Zarlink frontend.
lspci:
04:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 02)
Subsystem: DViCO Corporation Device [18ac:db78]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at 9000 (64-bit, non-prefetchable) [size=2M]
Capabilities: access denied
Kernel driver in use: cx23885
Kernel modules: cx23885



More detail, including dmesg etc, at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/459523

On 11/6/09, Devin Heitmueller dheitmuel...@kernellabs.com wrote:
 On Thu, Nov 5, 2009 at 12:23 AM, Robert Lowery rglow...@exemail.com.au
 wrote:
 Hi Devin,

 Thanks for your reply.

 I don't think your suggestion to use disable_power_mgmt will work as I
 already tried setting the no_poweroff=1 kernel module without success (and
 even tried recompiling with xc2028_sleep returning 0 immediately, but
 until I stopped the .sleep being set at all in xc2028_dvb_tuner_ops, the
 problem kept happening.

 The only thing that fixed it without code change was to set
 dvb_powerdown_on_sleep=0.

 Looking at the below code from dvb_frontend.c, the only difference I could
 see between setting no_poweroff=1 and not setting .sleep is the latter
 stops i2c_gate_ctrl being called.

        if (dvb_powerdown_on_sleep) {
                if (fe-ops.set_voltage)
                        fe-ops.set_voltage(fe, SEC_VOLTAGE_OFF);
                if (fe-ops.tuner_ops.sleep) {
                        if (fe-ops.i2c_gate_ctrl)
                                fe-ops.i2c_gate_ctrl(fe, 1);
                        fe-ops.tuner_ops.sleep(fe);
                        if (fe-ops.i2c_gate_ctrl)
                                fe-ops.i2c_gate_ctrl(fe, 0);
                }
                if (fe-ops.sleep)
                        fe-ops.sleep(fe);
        }

 I'm not very familiar with this code.  Am I missing something?

 -Rob

 Could you please clarify exactly which card you have (PCI/USB ID)?

 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

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