compile error media-build on 4.15 because of 'device_get_match_data'
I tried to compile media-build on Ubuntu 18.04. (gcc 7.3.0) with Kernel 4.15 and get this error: /home/martin/media_build/v4l/video-i2c.c: In function 'video_i2c_probe': /home/martin/media_build/v4l/video-i2c.c:456:16: error: implicit declaration of function 'device_get_match_data'; did you mean 'of_device_get_match_data'? [-Werror=implicit-function-declaration] data->chip = device_get_match_data(>dev); ^ of_device_get_match_data /home/martin/media_build/v4l/video-i2c.c:456:14: warning: assignment makes pointer from integer without a cast [-Wint-conversion] data->chip = device_get_match_data(>dev); ^ cc1: some warnings being treated as errors scripts/Makefile.build:339: recipe for target '/home/martin/media_build/v4l/video-i2c.o' failed make[3]: *** [/home/martin/media_build/v4l/video-i2c.o] Error 1 Makefile:1552: recipe for target '_module_/home/martin/media_build/v4l' failed make[2]: *** [_module_/home/martin/media_build/v4l] Error 2 make[2]: Leaving directory '/usr/src/linux-headers-4.15.0-20-generic' Makefile:51: recipe for target 'default' failed make[1]: *** [default] Error 2 make[1]: Verzeichnis „/home/martin/media_build/v4l“ wird verlassen Makefile:26: recipe for target 'all' failed make: *** [all] Error 2 build failed at ./build line 526 I hope it is possible to integrate a patch for Kernel 4.15
media_build: how can I test older drivers?
To find the responsible patch for a regression, I need to test older drivers. (1, 3 or 6 months ago) How can I do this with media_build? I don't really understand how the build script works. It seems that it doesn't use the current media_tree.git, but loads instead a driver snapshot (http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2) which is at the moment from March 9. Can I simply change the name of the link for the bz2-package in linux/Makefile? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/4] ivtv: implement new decoder command ioctls.
Hi Hans,
I am not sure if I understand this right. You wrote:
Comments are added on how to convert the legacy ioctls to standard V4L2 API
in applications. Perhaps these legacy ioctls in ivtv can even be removed in a
few years time.
But the patch looks for me as if the currently used ioctls shall be removed
now, which would immidiately break existing applications.
This is an example of the currently used code:
void cPvr350Device::DecoderStop(int blank)
{
struct video_command cmd;
memset(cmd, 0, sizeof(cmd));
cmd.cmd = VIDEO_CMD_STOP;
if (blank) {
cmd.flags = VIDEO_CMD_STOP_TO_BLACK |
VIDEO_CMD_STOP_IMMEDIATELY;
} else { //show last frame instead of a black screen
cmd.flags = VIDEO_CMD_STOP_IMMEDIATELY;
}
if (IOCTL(fd_out, VIDEO_COMMAND, cmd) 0) {
log(pvrERROR, pvr350: VIDEO_CMD_STOP %s error=%d:%s,
blank ? (blank) : , errno, strerror(errno));
}
}
As far as I know my pvr350-Plugin for vdr is the only application which uses
the hardware decoder of the PVR350 (mythtv has dropped support some years
ago). There are only a few users left in time of HDTV.
I don't really understand why it is necessary to do this changes.
I suggest to increase the ivtv driver version number when implementing the
changes. The application (which must be backward compatible) should be able to
determine which ioctl it has to use.
It would be much better if the ivtv driver would continue to support the old
ioctl for the few years we still have any PVR350 user.
Greets,
Martin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/4] ivtv: implement new decoder command ioctls.
I suggest to increase the ivtv driver version number when implementing the changes. The application (which must be backward compatible) should be able to determine which ioctl it has to use. These days the version number of all drivers is the same as the kernel version number, so it is easy to check when new ioctls became available. Does this mean that the ivtv driver version is also 3.3 when somebody uses an older kernel with updated drivers from media_build? I am worried that this might be the case if somebody checks out from the staging/for_v3.3 Branch **before** the patch is merged. It would be much better if the ivtv driver would continue to support the old ioctl for the few years we still have any PVR350 user. Don't worry, I won't be removing anything. good :-) I checked the plugin code and you aren't using VIDEO_GET_EVENT. The VIDEO_GET_EVENT ioctl is the only one I'd really like to get rid of in ivtv in favor of the V4L2 event API. It's only used as far as I can tell in ivtv-ctl and ivtvplay, both ivtv utilities that can easily be changed. Are you perhaps aware of any other userspace applications that use that ioctl? no. I think mythtv used it, but I doubt that the dropped support for the decoder will come back anytime. -- 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
analogue tuners: radio volume much lower than TV volume
My PVR350 (ivtv) and my PVRUSB2 Model 29034 (pvrusb2) have a much lower volume when switching to radio. On the HVR1300 (cx88-blackbird, Philips FMD1216ME tuner) this is no problem; radio has same volume level. The saa7134-based KNC One TV Station DVR (similar tuner: FMD1216MEX) has a very low audio volume on radio, even lower than the ivtv/pvrusb2 devices. Unfortunately it is not possible to set the volume. The radio device doesn't support V4L2_CID_AUDIO_VOLUME, and performing the ioctl on the video device causes a switch back to TV mode. Is there an explanation for this audio volume issue? Does it depend on the tuner type? Should a driver internally sets a higher audio volume for radio mode, or is this against the V4L2 api? -- 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
[regression] DVB cards doesn't work with 2.6.37/ current git
I tried two things: 1.) compile media_build.git for my 2.6.32 Ubuntu Kernel. It compiles, driver loads without errors. [ 8.500109] DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)... [ 8.981263] DVB: registering adapter 1 frontend 0 (Philips TDA10021 DVB-C)... But when I start vdr none of my DVB cards (Cinergy 1200C and Technotrend 1500C) is working. After some time vdr has 100% CPU load. 2.) install a complete 2.6.37 Ubuntu Kernel. Same result as above An Ubuntu 2.6.36-Kernel is working. ??? -- 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
missing Patch in v4l-dvb hg
Hi Douglas, you backported a few ivtv patches from June 2010 to v4l-dvb hg: http://linuxtv.org/hg/v4l- dvb/log/abd3aac6644e/linux/drivers/media/video/ivtv/ivtv-streams.c Unfortunately one patch is missing, which is important for proper function: http://git.linuxtv.org/media_tree.git?a=commit;h=f06b9bd4c62ef93f9467a1432acf2efa84aa3456 Could you please add it? Greets, Martin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
lot of bugs in cx88-blackbird
The HVR1300 driver has several bugs: 1. When executing VIDIOC_S_EXT_CTRLS or VIDIOC_S_FREQUENCY on the mpeg device while the mpeg device is active (capturing), the driver calls blackbird_stop_codec(). This stops the encoder (API call CX2341X_ENC_STOP_CAPTURE). Unfortunately, the encoder gets never restarted after the ioctl is finished. To restart the encoder, we now need to stop capturing and restart reading. But if this is required anyway, the code could be much easier when the driver would simply return EBUSY. I think the bug was introduced in May 2007 (!) with this patch: (V4L/DVB (6828): cx88-blackbird: audio improvements) http://git.linuxtv.org/media_tree.git?a=commitdiff;h=f9e54e0c84da869ad9bc372fb4eab26d558dbfc2 The necessary CX2341X_ENC_START_CAPTURE API command to restart the encoder was moved with this patch from blackbird_initialize_codec() to a new function blackbird_start_codec(), but this new function is not called. For vidioc_s_ext_ctrls the patch (Stop the mpeg encoder when changing parameters ) totally misses a solution to restart the encoder. The different methods to switch channels with mpeg encoder cards have been discussed in the ivtv-devel list lately: http://www.gossamer-threads.com/lists/ivtv/devel/41154 My suggestion is that the driver should return EBUSY for VIDIOC_S_FREQUENCY and all critical settings (standard, bitrate, format, ...) while a capture is in progess. This should happen not only on the mpeg device but also on the analogue device. 2. On this hybrid card, we have an analogue and an mpeg device. As far as I know there is still no application which knows how to handle this. If the User Controls (Brightness, Contrast, Saturation, Hue, Volume) are executed on the analogue device while the mpeg device is active, the result is static on audio+video. We need to stop reading and re-tune the current frequency by executing VIDIOC_S_FREQUENCY on the mpeg device. 3. When executing VIDIOC_S_FREQENCY or any other ioctl on the analogue device, the result is always static video+audio. v4l2-ctl --get-freq still shows the right frequency, but the tuner is obviously on another frequency. 4. If we use VIDIOC_S_STD on the analogue device, a following v4l2-ctl --get- standard (executed on the mpeg device) shows still the previous standard. 5. The default video size for mpeg is 720x480 (which is right for the default standard NTSC-M). If we change the standard to PAL-BG, the size is still 720x480. As far as I remember, the cx2341x does only work properly with height 576 when the video standard is 50Hz. The ivtv driver adjustes this automatically. 6. Setting the video size with VIDIOC_S_FMT for V4L2_BUF_TYPE_VIDEO_CAPTURE works only when executed on the mpeg device. How should an application know this? (for cards with saa7134-empress it is vice versa, VIDIOC_S_FMT works only on the analogue device...) 7. switching from an external input back to TV (input 0) often results in audio static. Re-setting the video standard helps. 8. The external input S-Video has no colour although an Y/C signal is supplied. 9. reading from mpeg device fails randomly with Input/output error. Even a driver reload is not sufficient - I have to reboot my machine to get it working again. 10. vidioc_s_ext_ctrls only supports V4L2_CTRL_CLASS_MPEG, but not V4L2_CTRL_CLASS_USER. The driver should internally pass these to vidioc_s_ctrl instead of returning EINVAL. 11. When switching from input Television to Input Composite1 , then switching to a radio channel and switching back to Composite 1, the video comes from Composite1 but the audio from Television (previous TV channel). Directly switching from Television to radio and then to Composite1 has no problems. I am not a driver developer and can't fix this myself. But I could do testings and hope there is a developer who is willing to have a look at these problems. Greets, Martin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION] saa7134 + ir
Am Dienstag, 15. Juni 2010, um 03:39:24 schrieb Dmitri Belimov: Hi Martin This is not only a problem with saa7134, but also with other drivers like budget-ci. The bug was also present in 2.6.35-rc1 I see this bug with 2.6.33 and fresh hg. There have been several reports here in the list since a few weeks: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/20198 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/19904 There is already a similar patch like yours (see link in first of my links), but it still hasn't gone into the v4l-dvb hg. (Although there have been frequently other -less important- patches been merged ...) Greets, Martin With my best regards, Dmitry. it should be fixed now. Douglas merged this patch today: http://linuxtv.org/hg/v4l-dvb/rev/3d7eaf0239ab Greets, Martin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION] saa7134 + ir
This is not only a problem with saa7134, but also with other drivers like budget-ci. The bug was also present in 2.6.35-rc1 There have been several reports here in the list since a few weeks: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/20198 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/19904 There is already a similar patch like yours (see link in first of my links), but it still hasn't gone into the v4l-dvb hg. (Although there have been frequently other -less important- patches been merged ...) Greets, Martin -- 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: 2.6.35-rc1 fails to boot: OOPS in ir_register_class
It's sad that this bug has gone into 2.6.35-rc1. I already reported it on 24.05.2010: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/19564/ Unfortunately it didn't get any attention, which makes me a little bit depressive... What is the right way to report bugs if code is still in linux-next, but not in a release candidate? Should I make an entry in https://bugzilla.kernel.org/? Or ist this list the right place to report it? Greets, Martin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kernel oops with current hg (ir-sysfs.c ?)
I guess it is a similar problem like the one that was solved a few months ago with this patch: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/14232 I compiled the current v4l-dvb hg against the 2.6.32 Ubuntu 10.04 kernel May 24 13:30:22 ubuntuvdr1 kernel: [5.629408] DVB: registering new adapter (TT-Budget C-1501 PCI) May 24 13:30:22 ubuntuvdr1 kernel: [5.646949] tda9887 3-0043: i2c i/o error: rc == -5 (should be 4) May 24 13:30:22 ubuntuvdr1 kernel: [5.649823] tda9887 3-0043: i2c i/o error: rc == -5 (should be 4) May 24 13:30:22 ubuntuvdr1 kernel: [5.666028] adapter has MAC addr = 00:d0:5c:c6:5a:11 May 24 13:30:22 ubuntuvdr1 kernel: [5.692518] Registered IR keymap rc-tt-1500 May 24 13:30:22 ubuntuvdr1 kernel: [5.692545] BUG: unable to handle kernel NULL pointer dereference at (null) May 24 13:30:22 ubuntuvdr1 kernel: [5.692554] IP: [f825bd7e] ir_register_class+0x3e/0x190 [ir_core] May 24 13:30:22 ubuntuvdr1 kernel: [5.692566] *pde = May 24 13:30:22 ubuntuvdr1 kernel: [5.692571] Oops: [#1] SMP May 24 13:30:22 ubuntuvdr1 kernel: [5.692575] last sysfs file: /sys/module/ir_core/initstate May 24 13:30:22 ubuntuvdr1 kernel: [5.692580] Modules linked in: rc_tt_1500 tda10021 snd_hda_codec_realtek tuner_simple tuner_types tda9887 tda8290 tuner msp3400 snd_hda_intel$ May 24 13:30:22 ubuntuvdr1 kernel: [5.692659] May 24 13:30:22 ubuntuvdr1 kernel: [5.692663] Pid: 375, comm: modprobe Not tainted (2.6.32-22-generic #33-Ubuntu) M56S-S3 May 24 13:30:22 ubuntuvdr1 kernel: [5.692669] EIP: 0060:[f825bd7e] EFLAGS: 00010246 CPU: 0 May 24 13:30:22 ubuntuvdr1 kernel: [5.692677] EIP is at ir_register_class+0x3e/0x190 [ir_core] May 24 13:30:22 ubuntuvdr1 kernel: [5.692681] EAX: EBX: f6375000 ECX: EDX: 0100 May 24 13:30:22 ubuntuvdr1 kernel: [5.692686] ESI: f4fa6000 EDI: EBP: f61d5d78 ESP: f61d5d4c May 24 13:30:22 ubuntuvdr1 kernel: [5.692691] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 May 24 13:30:22 ubuntuvdr1 kernel: [5.692697] Process modprobe (pid: 375, ti=f61d4000 task=f61b6680 task.ti=f61d4000) May 24 13:30:22 ubuntuvdr1 kernel: [5.692704] Stack: May 24 13:30:22 ubuntuvdr1 kernel: [5.692707] 0246 f825ba47 c24054e0 f825ba47 001d5d64 0128 f4fa6000 003f May 24 13:30:22 ubuntuvdr1 kernel: [5.692717] 0 faee9068 0027 f4fa6000 f61d5db0 f825bb7c 009f f8ce32ef May 24 13:30:22 ubuntuvdr1 kernel: [5.692728] 0 c0588f82 f825cc11 0296 f637513c f6375120 f6375000 f6827000 f4fa6000 May 24 13:30:22 ubuntuvdr1 kernel: [5.692741] Call Trace: May 24 13:30:22 ubuntuvdr1 kernel: [5.692750] [f825ba47] ? __ir_input_register+0x167/0x350 [ir_core] May 24 13:30:22 ubuntuvdr1 kernel: [5.692759] [f825ba47] ? __ir_input_register+0x167/0x350 [ir_core] May 24 13:30:22 ubuntuvdr1 kernel: [5.692769] [f825bb7c] ? __ir_input_register+0x29c/0x350 [ir_core] May 24 13:30:22 ubuntuvdr1 kernel: [5.692779] [c0588f82] ? printk+0x1d/0x23 May 24 13:30:22 ubuntuvdr1 kernel: [5.692789] [f8ce1153] ? budget_ci_attach+0x193/0xd80 [budget_ci] May 24 13:30:22 ubuntuvdr1 kernel: [5.692800] [f81ffeac] ? saa7146_init_one+0x7dc/0x860 [saa7146] May 24 13:30:22 ubuntuvdr1 kernel: [5.692811] [c01078d0] ? dma_generic_alloc_coherent+0x0/0xc0 May 24 13:30:22 ubuntuvdr1 kernel: [5.692821] [c0363883] ? local_pci_probe+0x13/0x20 May 24 13:30:22 ubuntuvdr1 kernel: [5.692827] [c0364688] ? pci_device_probe+0x68/0x90 May 24 13:30:22 ubuntuvdr1 kernel: [5.692835] [c03e688d] ? really_probe+0x4d/0x140 May 24 13:30:22 ubuntuvdr1 kernel: [5.692843] [c03ed19e] ? pm_runtime_barrier+0x4e/0xc0 May 24 13:30:22 ubuntuvdr1 kernel: [5.692850] [c03e69bc] ? driver_probe_device+0x3c/0x60 May 24 13:30:22 ubuntuvdr1 kernel: [5.692857] [c03e6a61] ? __driver_attach+0x81/0x90 May 24 13:30:22 ubuntuvdr1 kernel: [5.692864] [c03e5ea3] ? bus_for_each_dev+0x53/0x80 May 24 13:30:22 ubuntuvdr1 kernel: [5.692871] [c03e675e] ? driver_attach+0x1e/0x20 May 24 13:30:22 ubuntuvdr1 kernel: [5.692877] [c03e69e0] ? __driver_attach+0x0/0x90 May 24 13:30:22 ubuntuvdr1 kernel: [5.692884] [c03e6125] ? bus_add_driver+0xd5/0x280 May 24 13:30:22 ubuntuvdr1 kernel: [5.692890] [c03645c0] ? pci_device_remove+0x0/0x40 May 24 13:30:22 ubuntuvdr1 kernel: [5.692897] [c03e6d5a] ? driver_register+0x6a/0x130 May 24 13:30:22 ubuntuvdr1 kernel: [5.692903] [c03648c5] ? __pci_register_driver+0x45/0xb0 May 24 13:30:22 ubuntuvdr1 kernel: [5.692913] [f81fed63] ? saa7146_register_extension+0x53/0x90 [saa7146] May 24 13:30:22 ubuntuvdr1 kernel: [5.692923] [f8ce700d] ? budget_ci_init+0xd/0xf [budget_ci] May 24 13:30:22 ubuntuvdr1 kernel: [5.692929] [c0101131] ? do_one_initcall+0x31/0x190 May 24 13:30:22 ubuntuvdr1 kernel: [5.692937] [f8ce7000] ? budget_ci_init+0x0/0xf [budget_ci] May 24
Re: [PATCH] TT CT-3650 DVB-C support
Hi Guy, great news! Does it also work with QAM256? Hope the patch becomes accepted. And maybe anybody can add support for the CI later. Greets, Martin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ivtv-devel] PVR150 Tinny/fuzzy audio w/ patch?
Am Donnerstag, 31. Dezember 2009 20:40:15 schrieb Andy Walls: On Thu, 2009-12-31 at 14:26 -0500, Andy Walls wrote: On Thu, 2009-12-31 at 18:15 +0100, Martin Dauskardt wrote: Some corrections to errors: My preferences in summary, is that not matter what the digitizer chip: My preferences are, in summary, that no matter what the digitizer chip: a. I'd like to keep the audio clocks always up to avoid tinny audio. b. I'd also like to inhibit the video clock and add the delay after ^^^ refine re-enabling the digitizer to avoid the *potential* for a hung machine. A value smaller than 300 ms should work, but a value smaller than 40 ms may not work, if my hypothesis is correct. c. I do not care to much about the delay after disbaling the video clock, only that it is empirically long enough. Thanks for taking the time to test and comment. Regards, Andy Regards, Andy I tested various sleep values: http://home.arcor-online.de/martin.dauskardt/digitizer_msleep.xls It seems that we only need a total delay of 300ms between the previous actions in ivtv-streams.c and the start of the capture. This also secures that we don't see disturbance from a previous frequency switch. This happens with smaller sleep values: http://home.arcor-online.de/martin.dauskardt/channelswitch.mpg and can lead to the infamous flickering problem (http://www.gossamer- threads.com/lists/ivtv/devel/32970) . The current driver has this problem only with cx23415 (PVR350), not cx23416. My preference is: -let it how it is (300 ms sleep before the firmware call) or -split the 300ms to 150 and 150 Greets, Martin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IR: Fix sysfs attributes declaration
I can confirm this problem. Without this patch (thanks, Francesco!) I get a kernel stack trace when loading the media drivers: http://home.arcor-online.de/martin.dauskardt/trace1.jpg http://home.arcor-online.de/martin.dauskardt/trace2.jpg (An older v4l-dvb hg snapshot from December 5th wotks fine without patch.) I am also using 2.6.32 and have two DVB and two v4l2 cards in my machine. Greets, Martin Dauskardt -- 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: [ivtv-devel] PVR150 Tinny/fuzzy audio w/ patch?
Hi everybody,
first test results from me:
As expected, the double ivtv_msleep_timeout(300, 1); in ivtv-streams.c
increases the time for stopping/starting a stream. I removed the first call
and it still works fine.
@ Mike:
Previously I suggested to add a msleep(300) in state_eval_decoder_run
(pvrusb2-hdw.c), after calling pvr2_decoder_enable(hdw,!0).
With the change from Andy I now have again sporadic black screens with my
saa7115-based PVRUSB2. So I moved the sleep directly into static int
pvr2_decoder_enable:
--- v4l-dvb-bugfix-7753cdcebd28-orig/v4l-dvb-
bugfix-7753cdcebd28/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c
2009-12-24
17:06:08.0 +0100
+++ v4l-dvb-bugfix-7753cdcebd28-patched/v4l-dvb-
bugfix-7753cdcebd28/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c
2009-12-31
17:19:22.836251706 +0100
@@ -1716,6 +1716,7 @@
(enablefl ? on : off));
v4l2_device_call_all(hdw-v4l2_dev, 0, video, s_stream, enablefl);
v4l2_device_call_all(hdw-v4l2_dev, 0, audio, s_stream, enablefl);
+ if (enablefl != 0) msleep(300);
if (hdw-decoder_client_id) {
/* We get here if the encoder has been noticed. Otherwise
we'll issue a warning to the user (which should
Funny- this seems to work, no more black screens appeared.
The remaining questions are in my opinion:
1.)
What is Hans opinion about the changes, especially the move of the 300ms sleep
from after disabling the digitizer to after enabling it ?
2.)
Do we want to keep disabling the digitizer during the
CX2341X_ENC_INITIALIZE_INPUT call in case the digitizer is a cx25840x ?
It seems to be necessary only for the saa7115.
Note: The cx88-blackbird-driver does also no disabling/enabling of the
digitizer (cx2388x) when doing this firmware call.
3.)
Does Andys Patch solve the tinny audio problem for Argus (who originally
posted the problem and a different solution in the ivtv-devel list). I add him
in cc.
Greets and Happy New Year
Martin
PS:
Readers on the ivtv-devel ML list will miss previous postings (the list was
down a few days). Please have a look in
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/14151
and
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/14155
--
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: [ivtv-devel] PVR150 Tinny/fuzzy audio w/ patch?
Hi everybody and Merry Christmas,
Andy Walls wrote:
I have a version of the change for the ivtv/PVR-150 tinny audio fix at
http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix
http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix/rev/7753cdcebd28
It separates out the enable/disable of audio video streaming from each
other for the cx25840 module. Then the ivtv driver can set them
independently to avoid both the unpredictable PCI hang and the tinny
audio in a very generic way. Please test when you can.
@ Andy:
now we have a second 300ms delay in ivtv-streams.c
2.6/* Initialize Digitizer for Capture */
2.7 + /* Avoid tinny audio problem - ensure audio clocks are
going */
2.8 + v4l2_subdev_call(itv-sd_audio, audio, s_stream, 1);
2.9 + /* Avoid unpredictable PCI bus hang - disable video
clocks */
2.10v4l2_subdev_call(itv-sd_video, video, s_stream, 0);
2.11ivtv_msleep_timeout(300, 1);
2.12ivtv_vapi(itv, CX2341X_ENC_INITIALIZE_INPUT, 0);
2.13v4l2_subdev_call(itv-sd_video, video, s_stream, 1);
2.14 + ivtv_msleep_timeout(300, 1);
This would increase the time for channel switching (using encoder stop/start)
noticeable. My suggestion was to move the 300ms sleep at the point after the
stream is re-enabled, so we don't need the first msleep.
I have not tested your code, hope I can do this during the next days.
Mike,
I had to add another subdev call to pvrusb2 to get the same end result
of s_stream calls to the cx25840 module.
@ Mike:
do you remember my posting in the pvrusb2 list about sporadic black screen
after starting a stream? We had the same problem in ivtv, and the 300ms sleep
after disabling the digitizer solved the problem.
I implemented this in a similary way in the pvrusb2 driver and the problem
never appeared again:
--- v4l-dvb-309f16461cf4-orig/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c
2009-12-05 13:34:21.0 +0100
+++ v4l-dvb-309f16461cf4-patched/linux/drivers/media/video/pvrusb2/pvrusb2-
hdw.c 2009-12-24 22:42:49.746899065 +0100
@@ -4689,6 +4689,7 @@
del_timer_sync(hdw-quiescent_timer);
if (hdw-flag_decoder_missed) return 0;
if (pvr2_decoder_enable(hdw,!0) 0) return 0;
+ msleep(300);
hdw-state_decoder_quiescent = 0;
hdw-state_decoder_run = !0;
}
My initial idea was to avoid disabling/enabling the digitizer for devices with
cx2584x-digitizer. Channel changing (using encoder stop/start) with a PVR150
and HVR1900 took always about a second longer than with saa7115-based devices.
Without disabling/enabling the digitizer around the
CX2341X_ENC_INITIALIZE_INPUT call it speeds up noticeable.
So this is the alternate patch for the pvrusb2 driver (similar code for ivtv
was in my last posting which Andy had in his mail):
--- v4l-dvb-309f16461cf4-orig/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c
2009-12-05 13:34:21.0 +0100
+++ v4l-dvb-309f16461cf4-patched/linux/drivers/media/video/pvrusb2/pvrusb2-
hdw.c 2009-12-24 22:48:03.481899379 +0100
@@ -4646,9 +4646,9 @@
!hdw-state_pipeline_pause
hdw-state_pathway_ok) return 0;
}
- if (!hdw-flag_decoder_missed) {
- pvr2_decoder_enable(hdw,0);
- }
+if (hdw-decoder_client_id != PVR2_CLIENT_ID_CX25840 !hdw-
flag_decoder_missed) {
+ pvr2_decoder_enable(hdw,0);
+}
hdw-state_decoder_quiescent = 0;
hdw-state_decoder_run = 0;
/* paranoia - solve race if timer just completed */
@@ -4688,7 +4688,10 @@
!hdw-state_encoder_ok) return 0;
del_timer_sync(hdw-quiescent_timer);
if (hdw-flag_decoder_missed) return 0;
- if (pvr2_decoder_enable(hdw,!0) 0) return 0;
+if (hdw-decoder_client_id != PVR2_CLIENT_ID_CX25840) {
+ if (pvr2_decoder_enable(hdw,!0) 0) return 0;
+msleep(300);
+}
hdw-state_decoder_quiescent = 0;
hdw-state_decoder_run = !0;
}
It works fine with a HVR 1900, but should be tested with a PVRUSB2 model
24xxx.
Greets,
Martin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] tuner-simple, tveeprom: Add support for the FQ1216LME MK3
Am Samstag, 6. Juni 2009 03:59:41 schrieb Andy Walls: Hi, This is version 2 of the patch that: 1. adds explicit support for the FQ1216LME MK3 2. points the tveeprom module to the FQ1216LME MK3 entry for EEPROMs claiming FQ1216LME MK3 and MK5. 3. refactors some code in simple_post_tune() because I needed to set the Auxillary Byte, as did TUNER_LG_TDVS_H06XF, so I could set the TUA6030 TOP to external AGC per the datasheet. The patch no longer twiddles the CP bit nor polls the FL bit for the FQ1216LME. That will be something for another patch. Any other comments? Hi Andy, I have tested this with a current v4l-dvb hg and kernel 2.6.29 with my PVR 150 (FQ1216LME MK5). It works like using tuner type 38, but unfortunately it does not solve the problem of ocassionally loosing audio. This happens even on the video inputs! I need to do further testings with older drivers/kernels to verify if this may be an issue of the new i2c stuff. Testing is very difficult, because sometimes it works for an hour and more, maybe depending on the temperature or the moon phase. The problem reminds me a little bit on this: http://www.gossamer-threads.com/lists/ivtv/users/39029 This is what dmesg says: [ 1864.639391] ivtv: Start initialization, version 1.4.1 [ 1864.639484] ivtv0: Initializing card 0 [ 1864.639489] ivtv0: Autodetected Hauppauge card (cx23416 based) [ 1864.641281] ivtv :01:09.0: PCI INT A - Link[APC4] - GSI 19 (level, low) - IRQ 19 [ 1864.694693] tveeprom 0-0050: Hauppauge model 26709, rev F0C1, serial# 9585403 [ 1864.694697] tveeprom 0-0050: tuner model is Philips FQ1216LME MK5 (idx 121, type 80) [ 1864.694700] tveeprom 0-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) (eeprom 0x74) [ 1864.694703] tveeprom 0-0050: audio processor is CX25843 (idx 37) [ 1864.694705] tveeprom 0-0050: decoder processor is CX25843 (idx 30) [ 1864.694707] tveeprom 0-0050: has no radio [ 1864.694709] ivtv0: Autodetected Hauppauge WinTV PVR-150 [ 1864.704531] cx25840 0-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #0) [ 1864.723533] tuner 0-0043: chip found @ 0x86 (ivtv i2c driver #0) [ 1864.723613] tda9887 0-0043: creating new instance [ 1864.723615] tda9887 0-0043: tda988[5/6/7] found [ 1864.730824] tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0) [ 1864.741408] wm8775 0-001b: chip found @ 0x36 (ivtv i2c driver #0) [ 1864.749596] tuner-simple 0-0061: creating new instance [ 1864.749599] tuner-simple 0-0061: type set to 80 (Philips FQ1216LME MK3 PAL/SECAM w/active loopthrough) [ 1864.752114] IRQ 19/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs [ 1864.753099] ivtv0: Registered device video0 for encoder MPG (4096 kB) [ 1864.756347] ivtv0: Registered device video32 for encoder YUV (2048 kB) [ 1864.760023] ivtv0: Registered device vbi1 for encoder VBI (1024 kB) [ 1864.764195] ivtv0: Registered device video24 for encoder PCM (320 kB) [ 1864.764199] ivtv0: Initialized card: Hauppauge WinTV PVR-150 [ 1864.770863] ivtv: End initialization [ 1864.797718] usbcore: registered new interface driver pvrusb2 [ 1864.797727] pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner [ 1864.797729] pvrusb2: Debug mask is 31 (0x1f) [ 1864.843601] saa7146: register extension 'budget_ci dvb'. [ 1864.862564] saa7146: register extension 'budget dvb'. [ 1864.891936] b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully [ 1865.423084] lirc_serial: auto-detected active low receiver [ 1865.423089] lirc_dev: lirc_register_driver: sample_rate: 0 [ 1865.424882] lirc_serial $Revision: 5.100 $ registered [ 1871.259020] ivtv :01:09.0: firmware: requesting v4l-cx2341x-enc.fw [ 1871.298034] ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes) [ 1871.498142] ivtv0: Encoder revision: 0x02060039 [ 1871.514028] cx25840 0-0044: firmware: requesting v4l-cx25840.fw [ 1874.755988] cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382 bytes) [ 4426.500017] Clocksource tsc unstable (delta = -62502716 ns) Greets, Martin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ivtv-devel] tveeprom cannot autodetect tuner! (FQ1216LME MK5)
I should add that the picture quality is with all tested tuner types worse than with my PVR250/350. I don't know if a PVR150 is in generally worse than a PVR250. I can't call it really noisy, but in german I would say the picture is a little bit grobkörnig. It really needs a temporal filter setting of value 8 or more, while my other PVR cards have a nice quality even with value 0. I will test whatever you guys want me to test :-) But I am not a programmer, so I need detailled instructions what to patch. My next step will be testing an older v4l2 with an 2.6.27 kernel to see if the audio problem still exists. -- 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: [ivtv-devel] tveeprom cannot autodetect tuner! (FQ1216LME MK5)
#define TUNER_PHILIPS_FQ1216ME 24 /* you must actively select B/G/D/K, I, L, L` */ #define TUNER_PHILIPS_FQ1216AME_MK4 56 /* Hauppauge PVR-150 PAL */ #define TUNER_PHILIPS_FM1216ME_MK3 38 #define TUNER_PHILIPS_FMD1216ME_MK3 63 #define TUNER_PHILIPS_FMD1216MEX_MK378 #define TUNER_PHILIPS_FM1216MK5 79 Could the user try one of those, starting with the FQ1216 tuner numbers (24 and 56), to see if one of them works? For the FQ1261LME MK3, tveeprom has the FM1216ME_MK3 tuner number (38). I have this card now at home for testing. First results: #define TUNER_PHILIPS_FQ1216ME 24 /* you must actively select B/G/D/K, I, L, Result: only static #define TUNER_PHILIPS_FM1216ME_MK3 38 result: picture + sound o.k. #define TUNER_PHILIPS_FQ1216AME_MK4 56 /* Hauppauge PVR-150 PAL */ result: picture o.k., but no sound #define TUNER_PHILIPS_FMD1216ME_MK3 63 result: picture + sound o.k. #define TUNER_PHILIPS_FMD1216MEX_MK378 result: picture + sound o.k. #define TUNER_PHILIPS_FM1216MK5 79 result: picture o.k. , but audio disappears every few seconds (for about 1-2 seconds, then comes back) tuner type 63 and 79 are Hybrid tuners. This is fore sure an analogue-only tuner. The sticker says Multi-PAL, and according to VIDIOC_ENUMSTD it supports PAL, PAL-BG and PAL-H. So I think 38 is right. Any suggestions for further tests? -- 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: [ivtv-devel] tveeprom cannot autodetect tuner! (FQ1216LME MK5)
Am Montag, 25. Mai 2009 21:34:43 schrieb Martin Dauskardt: #define TUNER_PHILIPS_FM1216MK5 79 result: picture o.k. , but audio disappears every few seconds (for about 1-2 seconds, then comes back) correction: This is not a problem of tuner type 79. It happens also with tuner type 38. Sometimes the audio is also muted after the start of the application. Only switching to another input and back brings the audio back. I am beginning to wonder if this problem may be related to a similar problem with the PVRUSB2: http://www.isely.net/pipermail/pvrusb2/2009-May/002331.html If there is a problem with the new v4l2 sub-device mechanism, it seems to be more specific to some devices than to others. With my PVR350 I didn't notice such problems - although I remember that in **very** rare cases the audio fails after a channel switch. Greets, Martin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ivtv-devel] tveeprom cannot autodetect tuner! (FQ1216LME MK5)
Hi Andy,
Martin,
I don't see tuner type 81 in the list in tuners.h. I do see:
#define TUNER_PHILIPS_FQ1216ME 24 /* you must actively select
B/G/D/K, I, L, L` */
#define TUNER_PHILIPS_FQ1216AME_MK4 56 /* Hauppauge PVR-150 PAL */
#define TUNER_PHILIPS_FM1216ME_MK3 38
#define TUNER_PHILIPS_FMD1216ME_MK3 63
#define TUNER_PHILIPS_FMD1216MEX_MK3 78
#define TUNER_PHILIPS_FM1216MK5 79
ah, sorry. I looked into hauppauge_tuner[] from tveeprom.c and also misread
the internal number 80 as 81:
/* 80-89 */
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FQ1216LME MK3},
Could the user try one of those, starting with the FQ1216 tuner numbers
(24 and 56), to see if one of them works? For the FQ1261LME MK3,
tveeprom has the FM1216ME_MK3 tuner number (38).
I hope to get in contact with him this weekend. There is another problems with
the application which must be solved before, but I am sure we will found out
the right tuner type at the end.
Greets,
Martin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
