Re: [PATCH] Add patch to allow compilation on versions 3.5 with CONFIG_OF
Doesn't this produce compiler warnings since the static v4l2_of_parse_* functions are now never called? Those functions are inside the #if 0, so the compiler never sees them. I would patch v4l2-core/Makefile instead to just never compile v4l2-of.o. Because the final Makefile is generated by a script, I didn't think you actually could address it at the make prepare phase. That said, now I see that I could have patched linux/drivers/media/vl2-core/Makefile as you suggested. I don't have time to regenerate/resubmit at this point. Take the patch if you want it, feel free to recreate the patch slightly differently with no discernible benefit, or eventually I will get around to it the next time I'm working on that tree. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes
This looks like a workaround for a userspace bug that would affect all USB audio devices. What period/buffer sizes are xawtv/tvtime trying to use? I have similar concerns, although I don't know what the right solution is. For example, the last time Mauro tweaked the latency in tvtime, it broke support for all cx231xx devices (note that tvtime and xawtv share essentially the same ALSA code): http://git.linuxtv.org/cgit.cgi/tvtime.git/commit/?id=3d58ba563bfcc350c180b59a94cec746ccad6ebe It seems like there is definitely something wrong with the latency/period selection in both applications, but we need some insight from people who are better familiar with the ALSA subsystem for advice on the right way to do low latency audio capture (i.e. properly negotiating minimal latency in a way that works with all devices). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes
The official TV playback application, found on the CD with drivers, captures samples from the card into its buffer, and plays from the other end of the buffer concurrently. If there are, on average for a few seconds, too few samples in the buffer, it means that they are consumed faster than they arrive, and so the SAA chip is told to produce them a bit faster. If they accumulate too much, the SAA chip is told to produce them slower. That's it. Ok. Well, xc5000 (with does the audio sampling) doesn't have it, AFAIKT. The xc5000 tuner used on this TV device doesn't provide any mechanism to control audio PLL. It just sends the audio samples to au0828 via a I2S bus. All the audio control is done by the USB bridge at au0828, and that is pretty much limited. The only control that au0828 accepts is the control of the URB buffers (e. g., number of URB packets and URB size). It's probably worth noting that Mauro's explanation here is incorrect - the xc5000 does *not* put out I2S. It outputs an SIF which is fed to the au8522. The au8522 has the audio decoder, and it's responsible for putting out I2S to the au0828. Hence the xc5000's PLL would have no role here. In fact, you should see the exact same behavior on the A/V input, since the au8522 is responsible for the I2S clock which drives the cs5503 (the 5503 is in slave mode). 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
[PATCH] Add patch to allow compilation on versions 3.5 with CONFIG_OF
Support for Open Firmware was introduced in the V4L2 tree, but it depends on features only found in 3.5+. Add a patch to disable the support for earlier kernels. Tested on Ubuntu 10.04 with kernel 3.2.0-030200-generic (which has CONFIG_OF enabled by default). Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com --- backports/backports.txt | 1 + backports/v3.4_openfirmware.patch | 13 + 2 files changed, 14 insertions(+) create mode 100644 backports/v3.4_openfirmware.patch diff --git a/backports/backports.txt b/backports/backports.txt index 281c263..08908e6 100644 --- a/backports/backports.txt +++ b/backports/backports.txt @@ -43,6 +43,7 @@ add v3.6_i2c_add_mux_adapter.patch [3.4.255] add v3.4_i2c_add_mux_adapter.patch +add v3.4_openfirmware.patch [3.2.255] add v3.2_devnode_uses_mode_t.patch diff --git a/backports/v3.4_openfirmware.patch b/backports/v3.4_openfirmware.patch new file mode 100644 index 000..f0a8d36 --- /dev/null +++ b/backports/v3.4_openfirmware.patch @@ -0,0 +1,13 @@ +--- a/drivers/media/v4l2-core/v4l2-of.c2014-06-11 17:05:02.0 -0700 b/drivers/media/v4l2-core/v4l2-of.c2014-06-11 17:05:34.0 -0700 +@@ -1,3 +1,5 @@ ++/* Depends on symbols not present until kernel 3.5 */ ++#if 0 + /* + * V4L2 OF binding parsing library + * +@@ -142,3 +144,4 @@ + return 0; + } + EXPORT_SYMBOL(v4l2_of_parse_endpoint); ++#endif -- 1.9.1 -- 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: Pinnacle 320cx -- /dev/video ?
According to: http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_T_USB_RC Pinnacle Expresscard 320cx ✔ Yes, in kernel since 2.6.26 2304:022e USB2.0 dvb-usb-dib0700-1.20.fw I've just bought this card and it is correctly recognized and initialized, however it doesn't work. Precisely: tvtime and similar applications say: `no video device' and no /dev/video0 nor similar device files are created. Does the _analog_ part work? Am I missing sth? There is no Linux support for the analog video capture with the dib0700 driver. Hence you will only be able to use that device for digital reception. -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] au0828: fix logic of tuner disconnection
On Tue, May 6, 2014 at 11:58 PM, cb.xi...@samsung.com wrote: From: Changbing Xiong cb.xi...@samsung.com The driver crashed when the tuner was disconnected while restart stream operations are still being performed. Fixed by adding a flag in struct au0828_dvb to indicate whether restart stream operations can be performed. If the stream gets misaligned, the work of restart stream operations are usually scheduled for many times in a row. If tuner is disconnected at this time and some of restart stream operations are still not flushed, then the driver crashed due to accessing the resource which used in restart stream operations has been released. Signed-off-by: Changbing Xiong cb.xi...@samsung.com I haven't yet reviewed the logic in detail, but at a minimum this should really be two patches - one to address the disconnect bug and a second to deal with failure to cancel to the worker thread. Also, you need to pick a name for the variable that is more explanatory than flag. Please resubmit this as two separate patches with flag renamed, and I will then look at the actual implementation to see if it causes any problems. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] drivers/base: add managed token devres interfaces
On Mon, May 5, 2014 at 3:36 PM, Tejun Heo t...@kernel.org wrote: On Mon, May 05, 2014 at 03:30:34PM -0400, Devin Heitmueller wrote: On Mon, May 5, 2014 at 3:26 PM, Tejun Heo t...@kernel.org wrote: As such, please consider the patches nacked and try to find someone who can shepherd the code. Mauro, can you help out here? We actually discussed this proposal at length at the media summit last week. The patches are being pulled pending further internal review being pulled into a tree or being pulled for more work? Sorry, I wasn't clear. They are being pulled for more work. After discussion with the rest of the linux-media developers, it was determined that the patches don't cover all the use cases and the patch submission was premature. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Elgato Eye TV Deluxe V2 supported?
On Fri, Apr 25, 2014 at 2:31 PM, Another Sillyname anothersn...@googlemail.com wrote: I have an Elgato Eye TV V2 USB device USB ID 0fd9:002c which reading here https://github.com/mirrors/linux-2.6/blob/master/drivers/staging/media/as102/as102_usb_drv.h Looks like it should be supported (it looks like Devin wrote some of the code?)..it gets recognised in dmesg and indeed lsusb sees it, but no firmware is loaded (I have the required as102 files in /lib/firmware) and in effect it never 'initialises'. Hi Tony, Sorry, I saw your email yesterday but forgot to reply. The issue is that the as102 is still in staging, so it won't appear in mainline kernels by default. You would need to install the media_build tree, run make menuconfig, enable staging drivers and then enable the as102 bridge. The messages you are seeing in dmesg and lsusb are just the kernel finding the hardware at a USB level - these messages will appear whether there is a driver or not for the actual device. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Elgato Eye TV Deluxe V2 supported?
Is the as102 tree ever likely to go mainline? The only reason it's in staging is because it doesn't meet the coding standards (i.e. whitespace, variable naming, etc). Somebody needs to come along and expend the energy to satisfy the whitespace gods. Seems like a fantastically stupid reason to keep a working driver out of the mainline, but that's just my opinion. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy T XS Firmware (Kernel 3.14.1)
Yes, I am sure. The tuner-xc2028 module even reports FW Version 2.7. Yeah, the firmware image itself looks fine. What I suspect is, that this piece of hardware simply doesn't work with that firmware version. You've got the right blob (that's the only firmware that has ever run on the xc3028a chip). The message you provided which says Device is Xceive 34584 version 8.7, firmware version 1.8 is the value read out of the xc3028 chip after the firmware is loaded. The value isn't read out of the firmware blob. There are really three possibilities here: 1. The xc3028 is being held in reset. They've screwed up the GPIOs in the em28xx driver so many times that I've lost count. If the chip is in reset during the firmware load or when reading the version info, you'll get whatever garbage happened to be in memory when the I2C call was made. Alternatively, the xc3028 gets it's reset line probed between loading the firmware and reading the version (but this is less likely). 2. The xc3028 is not in reset, and the firmware load failed. In this case, for whatever reason the firmware wasn't loaded properly into the chip (for example, due to a bug in the I2C code in the em28xx driver) and the CPU on the 3028 never gets started. Hence when it goes to subsequently read the firmware version back out of the chip, the CPU on the 3028 isn't running so you're getting a garbage value back from the 3028. 3. The firmware loaded properly, but due to some other condition the I2C call to read the firmware version never actually made it to the 3028 and you're getting back whatever garbage value happened to be in the kernel memory that was supposed to be populated with the I2C response. The right way to debug this is probably to put a logic analyzer on the I2C bus and see if the traffic is making it to the xc3028 at all. Would also monitor the reset line with a scope and make sure it's high and watch for it being strobed when it shouldn't be. Of course both of those debugging techniques require hardware. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy T XS Firmware (Kernel 3.14.1)
On Wed, Apr 23, 2014 at 4:34 PM, Daniel Exner d...@dragonslave.de wrote: Hi, (Please keep me in CC as I'm currently not subscribed to this Mailinglist) I happened to inherit one of those DVB-T Sticks ID 0ccd:0043 TerraTec Electronic GmbH Cinergy T XS and of course it isn't working as exspected. So far I extracted the firmware the tuner_xc2028 module was telling me (xc3028-v27.fw) and the module loaded. But no dvb device nodes where created. I tried connecting directly to it using xawtv and that gave me a load of Incorrect readback of firmware version. messages. Then I tried loading the module with debug=1 and now I see: Device is Xceive 34584 version 8.7, firmware version 1.8 So I guess the driver is trying to use the wrong firmware file. I extracted some file named merlinC.rom from the Terratec Windows Drivers that I suspect to contain the firmware. Now I need some help how to verify that and create a usable fw File for the driver. You can get the firmware via the following procedure: http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028#How_to_Obtain_the_Firmware or if you're on Ubuntu it's already packaged in linux-firmware-nonfree. The file itself is 66220 bytes and has an MD5 checksum of 293dc5e915d9a0f74a368f8a2ce3cc10. Note that if you have that file in /lib/firmware, it's entirely possible that the driver is just broken (this happens quite often). The values read back by dmesg are from the device itself, so if the chip wasn't properly initialized fields such as the version will contain garbage values. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 3/3] saa7134: convert to vb2
This was a bit confusing following the previous paragraph. I meant to say that the *saa7134* userptr implementation is not USERPTR at all but PAGE_ALIGNED_USERPTR. A proper USERPTR implementation (like in bttv) can use any malloc()ed pointer as it should, but saa7134 can't as it requires the application to align the pointer to a page boundary, which is non-standard. It's probably worth mentioning at this point that there's a bug in videobuf2_vmalloc() where it forces the buffer provided by userptr mode to be page aligned. This causes issues if you hand it a buffer that isn't actually page aligned, as it writes to an arbitrary offset into the buffer instead of the start of the buffer you provided. I've had the following patch in my private tree for months, but had been hesitant to submit it since I didn't know if it would effect other implementations. I wasn't sure if USERPTR mode required the buffers to be page aligned and I was violating the spec. Devin From: Devin Heitmueller dheitmuel...@kernellabs.com Date: Fri, 17 May 2013 19:53:02 + (-0400) Subject: Fix alignment bug when using VB2 with userptr mode Fix alignment bug when using VB2 with userptr mode If we pass in a USERPTR buffer that isn't page aligned, the driver will align it (and not tell userland). The result is that the driver thinks the video starts in one place while userland thinks it starts in another. This manifests itself as the video being horizontally shifted and there being garbage from the start of the field up to that point. This problem was seen with both the em28xx and uvc drivers when testing on the Davinci platform (where the buffers allocated are not necessarily page aligned). --- diff --git a/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c b/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c index 94efa04..ad7ce7c 100644 --- a/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c +++ b/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c @@ -82,7 +82,7 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx, unsigned long vaddr, return NULL; buf-write = write; - offset = vaddr ~PAGE_MASK; + offset = 0; buf-size = size; -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 3/3] saa7134: convert to vb2
Hi Hans, This makes no sense. The vivi driver uses vb2-vmalloc as well, and that works perfectly fine in userptr mode. Applying this patch breaks vivi userptr mode, so this is a NACK for this patch. Don't misunderstand, I acknowledge the very real possibility that I don't fully understand the underlying problem. And to be clear I wasn't intending to send the patch to this mailing list expecting it to be merged. That said, I reproduced it on the ti81xx platform on both em28xx and uvcvideo, so I was comfortable it wasn't an issue with my em28xx VB2 conversion. I wonder though if this is related to this thread: http://www.spinics.net/lists/linux-media/msg75815.html I suspect that in your case the vb2_get_contig_userptr() function is called which as far as I can tell is the wrong function to call for the vmalloc case since there is absolutely no requirement that user pointers should be physically contiguous for vmalloc drivers. Entirely possible. I hadn't followed that thread previously but will take a look. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge ImpactVCB-e 01385
Anyway, I would recommend that you make a safety copy of your modules first (just in case :-) ), and then move all the newly install modules to the right place. Yeah, I generally recommend that in such cases you just rm -rf /lib/modules/`uname -r`/kernel/drivers/media before running make install, so you know you're in a clean state (make a backup copy first though, just in case). This avoids having to figure out which driver moved and the old version of which didn't get deleted. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: No channels on Hauppauge 950Q
On Sun, Mar 30, 2014 at 12:25 PM, Sunset Machine sunsetmachi...@gmail.com wrote: Today is March 30, 2014 The 950Q is a USB TV Stick. The driver loads, the firmware loads. Various software sees the device but none of them find any channels. I use an antenna for over-the-air HD television in the US. The device works on Windows but not Linux (Debian 7.3, Squeeze). What kernel version are you using? What applications have you tested with? If you have a relatively recent version of the HVR-950q stick with a kernel older than 3.7, then you are likely to have issues with not having some required driver updates for the new tuner chip inside the unit. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: No channels on Hauppauge 950Q
On Sun, Mar 30, 2014 at 3:16 PM, Sunset Machine sunsetmachi...@gmail.com wrote: kernel 3.2.0-4-686-pae and a new 950q Ok. If you own a Revision E1H3 device, then that kernel definitely won't work (the Rev is printed on the back of the stick above the barcode). 3.13-1-686-pae is available in Debian testing. I'll look into it. TVTime, MythTV, Mplayer, Kaffeine, and w_scan. scan would oddly leave the green signal light on when the program finished, as if it were tuned, but reporting 0 channels found. Well TVTime won't do OTA broadcasts since it's digital only. That said, the others should assuming you configured them properly. Definitely check the stick revision and try a much newer kernel. There have been a ton of fixes since 3.2 so it isn't worth even trying to debug on that kernel. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] saa7134: automatic norm detection
Let me explain why I created a new thread. My company is engaged in the monitoring of TV air. All TV channels are recorded 24/7 for further analysis. But some local TV channels change the standard over time (SECAM-PAL, PAL-SECAM). So the recording software must be notified about these changes to set a new standard and record the picture but not the noise. OK, fair enough. This is a perfectly reasonable use case, but since we don't do this with any other devices we probably need to decide whether this really should be the responsibility of the kernel at all, or whether it really should be done in userland. Doing it in userland would be trivial (even just a script which periodically runs QUERYSTD in a loop would accomplish the same thing), and the extra complexity of having a thread combined with the inconsistent behavior with all the other drivers might make it more worthwhile to do it in userland. If it were hooked to an interrupt line on the video decoder, I could certainly see doing it in kernel, but for something like this the loop that checks the standard could just as easily be done in userland. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xc2038/3028 firmware
Hi Frank, I specifically asked for and received permission from Xceive/CrestaTech to make the xc5000 firmware freely redistributable. They were unwilling to entertain that though for the xc2028/3028 as they considered it a long deprecated product. In order to include firmware blobs in linux-firmware, there needs to be an actual license legally permitting redistribution - we don't have that for the 2028/3028. In general CrestaTech have been extremely cooperative with the Linux community, especially in recent years. However in this case they just couldn't justify the effort to do the paperwork for a chip that they stopped shipping years ago. Devin On Fri, Mar 21, 2014 at 1:25 PM, Frank Schäfer fschaefer@googlemail.com wrote: Hi, are there any reasons why the xc2028/3028 firmware files are not included in the linux-firmware tree ? The xc5000 firmware is already there, so it seems Xceive|has nothing against| redistribution of their firmware... ?! Regards, Frank -- 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 -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/79] Add support for ATSC PCTV 80e USB stick
On Mon, Mar 3, 2014 at 5:05 AM, Mauro Carvalho Chehab m.che...@samsung.com wrote: This patch series finally merge a long waited driver, for Micronas/Trident DRX-J ATSC frontends. It is based on a previous work from Devin, who made the original port of the Trident driver and got license to ship the firmware. Latter, it got some attention from Patrick that tried to upstream it. However, this driver had very serious issues, and didn't fit into Linux Kernel code quality standards. So, I made some patches, back in 2012, in order to try helping to get this driver merged, but, as I didn't have the device, and Patrick never sent a final tested version, the patches got hibernated for a long time. Finally, this year, I got one hardware for me, and one for Shuah, as she offered her help to fix suspend/resume issues at the subsystem. This series is a result of this work: the driver got major cleanups, and several relevant bug fixes. The most serious one is that the device was not fully initializing the struct that was enabling the MPEG output. Worse than that, the routine that was setting the MPEG output was also rewriting the default values for a dirty set. The type of output was also wrong: on this board, PCTV 80e is wired for serial MPEG transfer, but the driver was initialized to parallel. All those bugs got fixed, and, at least on my tests with a PCTV 80e model 01134, the device is now properly working. Not sure if all patches will arrive the ML, as there are some very big ones here that could be biger than VGER's max limit for posts. Anyway, all patches can be found at: http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/drx-j-v3 Have fun! Mauro Devin Heitmueller (2): [media] drx-j: add a driver for Trident drx-j frontend [media] drx-j: put under 3-clause BSD license Mauro Carvalho Chehab (74): [media] drx-j: CodingStyle fixes [media] drx-j: Fix compilation and un-comment it [media] drx-j: Fix CodingStyle [media] drx-j: get rid of the typedefs on bsp_i2c.h [media] drx-j: remove the const annotate on HICommand() [media] drx-j: get rid of the integer typedefs [media] drx-j: get rid of the other typedefs at bsp_types.h [media] drx-j: get rid of the bsp*.h headers [media] drx-j: get rid of most of the typedefs [media] drx-j: fix whitespacing on pointer parmameters [media] drx-j: Use checkpatch --fix to solve several issues [media] drx-j: Don't use CamelCase [media] drx-j: do more CodingStyle fixes [media] drx-j: remove the unused tuner_i2c_write_read() function [media] drx-j: Remove a bunch of unused but assigned vars [media] drx-j: Some minor CodingStyle fixes at headers [media] drx-j: make a few functions static [media] drx-j: Get rid of drx39xyj/bsp_tuner.h [media] drx-j: get rid of typedefs in drx_driver.h [media] drx-j: Get rid of typedefs on drxh.h [media] drx-j: a few more CodingStyle fixups [media] drx-j: Don't use buffer if an error occurs [media] drx-j: replace the ugly CHK_ERROR() macro [media] drx-j: don't use parenthesis on return [media] drx-j: Simplify logic expressions [media] drx-j: More CamelCase fixups [media] drx-j: Remove typedefs in drxj.c [media] drx-j: CodingStyle fixups on drxj.c [media] drx-j: Use the Linux error codes [media] drx-j: Replace printk's by pr_foo() [media] drx-j: get rid of some ugly macros [media] drx-j: remove typedefs at drx_driver.c [media] drx-j: remove drxj_options.h [media] drx-j: make checkpatch.pl happy [media] drx-j: remove the useless microcode_size [media] drx-j: Fix release and error path on drx39xxj.c [media] drx-j: Be sure that all allocated data are properly initialized [media] drx-j: dynamically load the firmware [media] drx-j: Split firmware size check from the main routine [media] em28xx: add support for PCTV 80e remote controller [media] drx-j: remove unused code from drx_driver.c [media] drx-j: get rid of its own be??_to_cpu() implementation [media] drx-j: reset the DVB scan configuration at powerup [media] drx-j: Allow standard selection [media] drx-j: Some cleanups at drx_driver.c source [media] drx-j: prepend function names with drx_ at drx_driver.c [media] drx-j: get rid of drx_driver.c [media] drx-j: Avoid any regressions by preserving old behavior [media] drx-j: Remove duplicated firmware upload code [media] drx-j: get rid of drx_ctrl [media] drx-j: get rid of the remaining drx generic functions [media] drx-j: move drx39xxj into drxj.c [media] drx-j: get rid of drxj_ctrl() [media] drx-j: comment or remove unused code [media] drx-j: remove some ugly bindings from drx39xxj_dummy.c [media] drx-j: get rid of tuner dummy get/set frequency [media] drx-j: be sure to use tuner's IF [media] drx-j: avoid calling power_down_foo twice [media] drx-j: call ctrl_set_standard even if a standard is powered [media
Re: V4L2 and frames vs fields
Hi Hans, For field formats where both fields are used the spec is reasonably clear. The v4l2_format height field refers to the full frame height (combining both fields). No dispute here. For the TOP/BOTTOM/ALTERNATE setting the format's height refers to that of the field, not the frame. So the resulting buffer size is still height * bytesperline. What is the assertion based on? Looking at different drivers (and if so, which ones)? Looking at different userland apps (and if so which one)? Somewhere in the spec? Drivers can use several strategies on how to handle this: Some support only one field setting: INTERLACED if height frameheight / 2 and TOP if height = frameheight / 2. In this case the application cannot change the field, it is set by the driver based on the height chosen by the application. So you're saying that an app says I want V4L2_FIELD_INTERLACED with a height of 320x240, and the driver will change the field type to V4L2_FIELD_TOP in the response to the S_FMT call? The reverse is also possible: the driver allows you to change the field but not the height. So INTERLACED will give a height of 576 and TOP a height of 288. If there is a hardware scaler as well, then changing the field setting must not change the format's height, instead the scaler is adjusted. So if the height is 576 and the field is TOP, then the image will be scaled up by a factor of 2. Are you making a general statement about what you think should be the desired behavior, or citing what some particular driver does? If there are limitations in what the scaler can do (say it can only downscale) then it depends on the height which field values are honored. So attempts to set FIELD_TOP if the height is 576 and only a downscaler is available should result in FIELD_INTERLACE and an unchanged height. Only at heights = 288 will the FIELD_TOP setting work. When implementing FIELD_ANY drivers can choose to select FIELD_TOP (or BOTTOM) if the height = frameheight / 2 instead of FIELD_INTERLACED. The description of FIELD_ALTERNATE in the spec has this phrase: Image sizes refer to the frame, not fields. That seems nonsense to me and none of the drivers that support FIELD_ALTERNATE does that. If any of FIELD_TOP, BOTTOM or ALTERNATE is selected the width, height and sizeimage fields all relate to the size of a (possibly scaled) field. I plan on updating the spec, but I'd like to run this by you all to see if I missed anything or got it wrong after all. This all looks like a pretty big mess, so I'm really wondering who is actually using any of this functionality (both on the driver and application side). If we can't find any apps that actually use any of this functionality, and the behavior is undefined in the spec, then it might make sense to decide on what is the right approach and then make the drivers conform rather than trying to figure out what approach is taken by the most drivers and then updating the spec to reflect that. I can appreciate there's a good bit of extra complexity here as a result of how different chipsets implement their video pipeline and scaler. The specific use case *I* care about is that I've got 720x480 NTSC video coming in and I'm rendering it to a small LCD. I want to be able to throw away the bottom field since the LCD is smaller than 240 high and this allows me to not require any deinterlacing (simply rescaling the video to 320x240 using the hardware scaler won't solve the problem since I'll still get interlaced video, just 120 lines of the top field and 120 of the bottom). I suspect at least some of the cases that prompted the creation of these different field formats is similar, while others such as ALTERNATE are a result of really old hardware that cannot report which field it is returning. I also suspect many of the drivers have code that implements support for some of these formats not because somebody needed it but rather because the code was copied from some other driver (and may not even actually work). If nothing else, it would be very helpful if you could make more clear which of the statements you made above are the result of interpretation of the spec, evaluation of some of the current drivers which claim to support these field types, or what you think the correct behavior *should* be independent of how various drivers do it today. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unknown EM2800 video grabber (card=0)
No idea what's going wrong here, but this dmesg output is definitely incomplete. Or maybe you modifed the driver and messed things up ? ;-) My guess is that it's not actually an em28xx device at all (and the doc the user is referring to refers to some device by the manufacturer with the same name). Open it up and send us some hi-res photos of the PCB. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] media/drx39xyj: fix DJH_DEBUG path null pointer dereferences, and compile errors.
On Fri, Feb 28, 2014 at 4:22 PM, Shuah Khan shuah...@samsung.com wrote: This patch series fixes null pointer dereference boot failure as well as compile errors. Seems kind of strange that I wasn't on the CC for this, since I was the original author of all that code (in fact, DJH are my initials). Mauro, did you strip off my authorship when you pulled the patches from my tree? The patches themselves look sane, and I will send a formal Acked-by once I can get in front of a real computer. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/24] xc5000: properly report i2c write failures
On Mon, Feb 10, 2014 at 3:25 AM, Joonyoung Shim dofm...@gmail.com wrote:
As you said, i modified like below patch and it is working well.
Thanks for your advice.
diff --git a/drivers/media/usb/au0828/au0828-cards.c
b/drivers/media/usb/au0828/au0828-cards.c
index 0cb7c28..9936875 100644
--- a/drivers/media/usb/au0828/au0828-cards.c
+++ b/drivers/media/usb/au0828/au0828-cards.c
@@ -108,7 +108,7 @@ struct au0828_board au0828_boards[] = {
.name= DViCO FusionHDTV USB,
.tuner_type = UNSET,
.tuner_addr = ADDR_UNSET,
-.i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
+.i2c_clk_divider = AU0828_I2C_CLK_20KHZ,
},
[AU0828_BOARD_HAUPPAUGE_WOODBURY] = {
.name = Hauppauge Woodbury,
Great. Feel free to submit a patch to the mailing list with your SOB,
and we'll merge that change upstream.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/24] xc5000: properly report i2c write failures
I can't load firmware like error of below link.
https://bugs.launchpad.net/ubuntu/+source/linux-firmware-nonfree/+bug/1263837
This error is related with this patch. This fix is right but above error is
created after this fix
because my device makes WatchDogTimer to 0 when load firmware.
Maybe it will be related with XREG_BUSY register but i can't check it.
I removed this fix, but i have faced at other error with xc5000: PLL not
running after fwload
So i have commented like below.
static const struct xc5000_fw_cfg xc5000a_1_6_114 = {
.name = XC5000A_FIRMWARE,
.size = 12401,
//.pll_reg = 0x806c,
};
Then, xc5000 device works well.
I don't have xc5000 datasheet so i can't debug xc5000 driver anymore.
Hi Joonyoung,
Assuming this is the DViCO FusionHDTV7 device that uses the
au0828/au8522, I suspect that what's happening here is your I2C
controller is not stable. The I2C clock stretching done by the xc5000
often exposed bugs in various bridge drivers and the au0828 was no
exception. I had to work around these hardware bugs in the au0828
driver but I made them specific to the HVR-950q since that was the
only device I could test with.
In other words, the xc5000 is most likely doing exactly what it is
supposed to, and the increased robustness of the tuner driver with
those two patches exposed intermittent I2C failures in au0828 that
were previously being silently discarded (resulting in indeterminate
behavior).
I would recommending looking at the changes in au0828-cards.c for the
HVR-950q and add the code necessary to make them also apply for the
DVICO device, and that should resolve your problems (in particular the
i2c_clk_divider field should be set).
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: au0828 errors and mangled video with Hauppauge 950Q
On Wed, Feb 5, 2014 at 1:05 AM, Connor Behan connor.be...@gmail.com wrote: Ccing Devin. I'm pretty sure the analog side has a problem at the driver level. On most days, one cannot pickup an ATSC signal where I am, so I am trying to capture analog video with a Hauppauge WinTV HVR 950Q. Whether I use Television, Composite or S-Video, I see the same corrupted video such as this: http://imgur.com/c398F4v Looks like insufficient USB bandwidth available to support the 24 MB/second required for uncompressed analog video. Is this on an x86 PC? Or some embedded target such as ARM? If the latter, then the answer is almost certainly that the USB host controller implementation is garbage and cannot handle the throughput. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] e4000: convert DVB tuner to I2C driver model
Hi Antti, My biggest point was to criticize that general resistance of new design models which has been DVB side, not only that simple change but many others too. I am pretty sure the many mistakes are taken when there has not been better alternative available at the time, and later was developed proper solution, which is not still taken into use. Sometimes the simplest looking changes can introduce all sorts of regressions. Just look at the mess that was caused by Mauro's supposedly trivial dynamic stack allocation fixes as a prime example. In principle I don't have any objection to adopting common frameworks. That said, the changes you've proposed do deviate from how the framework currently works, and it might have been more constructive to post an RFC to the mailing list describing your proposed changes to the framework rather than just submitting a patch for a single tuner. In this particular case, your approach does give us some advantages in being able to leverage the I2C framework, but it has costs as well. Specifically my concerns are as follows: 1. Removing the abstraction layer that dvb_attach() provided will make it more difficult to add resource tracking code to handle tuner locking/sharing. To solve those problems would actually require us to later *reintroduce* a layer of abstraction between the bridge and tuner drivers if this patch were accepted as-is. Case in point - in the V4L2 layer, they actually went in the opposite direction - adding the V4L2 subdev framework in order to provide additional abstraction between the bridge and I2C devices. 2. Your approach now makes it the responsibility of the caller to explicitly call request_module(), something that is taken care of today by dvb_attach(). Right now you can't forget to include the dependency since it's taken care of for you - with your change the implementor *can* forget, and the result will be that it will fail *sometimes* based on whether the module happens to already be loaded. In theory your approach would give us a bit more flexibility to have drivers with fewer module dependencies if people are compiling the kernel from scratch for a single tuner, but that's hardly the common use case and it significantly increases the risk of new bugs in failing to specify dependencies. 3. Your change gives no consideration to analog or hybrid tuners. This isn't surprising since you've never worked in that area, but if the model you are proposing is to be applied to all tuners, then we need to fully understand the effects on tuner-core.ko. I have also feeling that these wrong solutions and design models used are one source of problems we have. All the chip I/Os should be modeled in a standard manner to make sure it is possible to interconnect flexible. GPIOs should be implemented as kernel GPIOs. I2C should be implemented as kernel I2C. Clock should be implemented as a kernel clock. Chip power-management should be implement as regulator (or what ever that is). TS interface also should be modeled and implement in a standard manner. Implementing things like that makes it possible to interconnect complex hardware without fearing some small change will break functionality because of some home-brew solution. Sure. Modular design practices are a good thing. Thanks for stating the obvious. Did they also teach you about how refactoring can introduce bugs, especially in instances where there are no unit tests and you cannot exercise all the possible code paths? :-) I am confident that after the above factors are considered/addressed that some variant of this patch can certainly be incorporated upstream, and I look forward to seeing the continued improvement of the codebase while not introducing new regressions. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] e4000: convert DVB tuner to I2C driver model
On Sun, Jan 26, 2014 at 7:16 PM, Antti Palosaari cr...@iki.fi wrote: Driver conversion from proprietary DVB tuner model to more general I2C driver model. Mike should definitely weigh in on this. Eliminating the existing model of using dvb_attach() for tuners is something that needs to be considered carefully, and this course of action should be agreed on by the subsystem maintainers before we start converting drivers. This could be particularly relevant for hybrid tuners where the driver instance is instantiated via tuner-core using dvb_attach() for the analog side. In the meantime, this change makes this driver work differently than every other tuner in the tree. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem getting sensible video out of Hauppauge HVR-1100 composite
On Mon, Jan 20, 2014 at 1:26 PM, Neil Bird gn...@fnxweb.com wrote: But, flip me, it's spewing 800 MB+ for a minute's worth of video. That'd be ~48GB for an hour's TV (the intention is to use this for a MythTV PVR). Am I likely to be able to do anything about that? Even with post-transcoding that's going to be an excessive amount of filing to deal with :-( The device doesn't have an MPEG encoder - you're getting raw uncompressed video. You would either have to buy a different device that has an encoder or do software encoding in real-time to MPEG2 or H.264 if your goal is to store the video. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE EXPERIMENTAL] PCTV 80e driver
On Sun, Jan 19, 2014 at 8:39 AM, Mauro Carvalho Chehab m.che...@samsung.com wrote: It seems that subsequent tuning makes the device worse, reducing the maximum effective packet bandwidth. Btw, this happens with both xHCI and EHCI drivers, so, it is not related to any USB 3.0 issue. I'm pretty sure I saw this and had a patch. I don't recall the exact circumstances under which it happened, but I believe it had to do with stopping and then restarting the streaming on the em28xx too quickly. The state machine inside the em28xx gets confused and you end up getting a misaligned stream (which is why you see hundreds of different PIDs in output from tools such as dvbtraffic). Enabling some demux logs, it is possible to see that there are too many FEC errors: [73514.186880] dvb_dmx_swfilter_packet: 4546 callbacks suppressed [73514.186933] TEI detected. PID=0x17f data1=0xc1 [73514.186965] TEI detected. PID=0x1c68 data1=0xbc [73514.186993] TEI detected. PID=0x17f data1=0xc1 [73514.187022] TEI detected. PID=0x1c68 data1=0xbc [73514.187049] TEI detected. PID=0x17f data1=0xc1 [73514.187080] TEI detected. PID=0x1c68 data1=0xbc [73514.187105] TEI detected. PID=0x17f data1=0xc1 [73514.194878] TEI detected. PID=0x1c68 data1=0xbc [73514.194906] TEI detected. PID=0x17f data1=0xc1 [73514.194927] TEI detected. PID=0x1c68 data1=0xbc [73521.569205] TS speed 402 Kbits/sec Are these actually valid PIDs you're expecting data on? If not, then it could just be the issue I described above. Does the TEI check occur after it has found the SYNC byte? I'm starting to suspect that this could be a hardware issue. It would be good to see if others can use it and tune to several channels. Ah, I didn't work at the remote controller yet. I'll handle it after doing more tests with the DVB functionality. Remote controller support was added. Should be trivial - I added the support for the em2874's RC using that device - the RC support went upstream years ago but not the actual board profile. Probably worth mentioning that while I got signal lock on ATSC, I didn't any significant analysis into the quality of the SNR. It's possible that additional optimization of the frontend is required in order to achieve optimal performance. Also, I didn't do the ClearQAM support yet, although that should be a fairly straightforward exercise (should just be another block in the set_frontend() call which sets the modulation appropriately). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE EXPERIMENTAL] PCTV 80e driver
On Sun, Jan 19, 2014 at 12:32 PM, Mauro Carvalho Chehab m.che...@samsung.com wrote: Em Sun, 19 Jan 2014 11:50:55 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Sun, Jan 19, 2014 at 8:39 AM, Mauro Carvalho Chehab m.che...@samsung.com wrote: It seems that subsequent tuning makes the device worse, reducing the maximum effective packet bandwidth. Btw, this happens with both xHCI and EHCI drivers, so, it is not related to any USB 3.0 issue. I'm pretty sure I saw this and had a patch. I don't recall the exact circumstances under which it happened, but I believe it had to do with stopping and then restarting the streaming on the em28xx too quickly. The state machine inside the em28xx gets confused and you end up getting a misaligned stream (which is why you see hundreds of different PIDs in output from tools such as dvbtraffic). Do you still has your old tree? I'm not seeing it anymore at kernellabs. Yeah, I still have the tree. It's not the HG tree that you saw a couple of years ago - it's on one of my private git trees because it was part of a commercial project. I'll have to dig around and see if I can find it. Enabling some demux logs, it is possible to see that there are too many FEC errors: [73514.186880] dvb_dmx_swfilter_packet: 4546 callbacks suppressed [73514.186933] TEI detected. PID=0x17f data1=0xc1 [73514.186965] TEI detected. PID=0x1c68 data1=0xbc [73514.186993] TEI detected. PID=0x17f data1=0xc1 [73514.187022] TEI detected. PID=0x1c68 data1=0xbc [73514.187049] TEI detected. PID=0x17f data1=0xc1 [73514.187080] TEI detected. PID=0x1c68 data1=0xbc [73514.187105] TEI detected. PID=0x17f data1=0xc1 [73514.194878] TEI detected. PID=0x1c68 data1=0xbc [73514.194906] TEI detected. PID=0x17f data1=0xc1 [73514.194927] TEI detected. PID=0x1c68 data1=0xbc [73521.569205] TS speed 402 Kbits/sec Are these actually valid PIDs you're expecting data on? If not, then it could just be the issue I described above. Does the TEI check occur after it has found the SYNC byte? Yes. it keeps repeating several times, even after finding the SYNC. This patch makes the behavior stable: http://git.linuxtv.org/mchehab/experimental.git/commitdiff/88c9318cbea60d189a9b10cbc4c5a73f8b002336 Even so, the bitstream of my test signal is 19Mbps, while the measured speed with the valid packets is being about 3Mbps. Something is seriously wrong then - I had it delivering all 19 Mbps. Probably worth mentioning that while I got signal lock on ATSC, I didn't any significant analysis into the quality of the SNR. It's possible that additional optimization of the frontend is required in order to achieve optimal performance. It is unlikely to be due to some optimization, as I'm not injecting any errors via the RF generator. Sorry, I wasn't clear. I didn't intend to suggest any RF optimization is causing the issue you're seeing. I was just saying that I didn't do any optimization of the RF path so while it works under ideal signal conditions it may not work as well under more adverse signal conditions. In other words, I did what most of the other LinuxTV developers do - I got a successful signal lock and said good enough. ;-) On that note, it's probably worth mentioning that particular design has an LNA controlled by one of the GPIOs on the DRX-J. So if you're consistently having poor RF performance (especially with a generator), try sticking an attenuator in-line, and/or make sure that the LNA is actually being properly disabled. Btw, I noticed that there are two extra firmwares, that aren't currently used, defined, on your driver, at drxj_mc_vsb.h and drxj_mc_vsbqam.h. Do you remember when those should be used? Or are them just two variants of the main firmware, with support for just VSB and just ClearQAM? I would have to look at the source again to be sure, but if I recall it was just so you could reduce the size of the firmware if you didn't care about the other modulation scheme. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] au8522, au0828: Added demodulator reset
On Sat, Jan 11, 2014 at 5:12 PM, Tim Mester tmes...@ieee.org wrote: My device is the 950q, so it uses the AU8522_DEMODLOCKING method. No devices do tuner locking for digital (it's always the demodulator). That code should really just be ripped out. It does not appear to be an xc5000 issue on the surface. When I originally put the patch together, I removed the return if the frequency was the same, and added the reset_demodulator() call at the end of the set_frontend() function. It seemed to work the same as the patch that I submitted. I'm pretty sure that we accomplish the same thing through the patch I have which reworks the clock management. except for removing the part where the set_frontend() call returns if the freq/modulation are already set. I have not been able to tell that it keeps the au8522 from losing lock, but it allows it to come back. I see this issue about once a every 2-3 weeks on average, which is less frequent than the other issues. If you believe that this issue could result in a xc5000 and au8522 interaction, then I should be able to try out the updated firmware. It will just take some time to know the results. My instinct would be to get you to try that patch series I have in git. I suspect that it will address your issue with no further patches required (we might need the one additional patch to remove the early return in set_frontend, but let's see). The testing of the new firmware can be done in a separate series (the issue it addresses is completely unrelated to the behavior you are seeing). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How can I find out what is the driver for device node '/dev/video11'
On Wed, Jan 8, 2014 at 1:50 PM, m silverstri
michael.j.silvers...@gmail.com wrote:
In linux kernel, a device (e.g. codec) can register as a file (e.g.
/dev/video11).
How can I find out from the code which driver is registered as
'/dev/video11'. i.e. what is the driver will be invoked when I
open('/dev/video11', O_RDWR,0) in my user space code?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
The QUERYCAP ioctl() will tell you the driver name.
http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How can I find out what is the driver for device node '/dev/video11'
On Wed, Jan 8, 2014 at 2:03 PM, m silverstri michael.j.silvers...@gmail.com wrote: Thanks. I don't have the a running hardware. If I can only search within the code space, how can I find out which driver is for '/dev/video11'? Is there a config file which I can look it up? If you don't actually have the hardware platform, then determining it just from the source code is a huge undertaking (unless it's some well known device which happens to always create it at that offset). What is the hardware platform, and what is the capture device? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] au8522, au0828: Added demodulator reset
Hi Tim, On Wed, Jan 8, 2014 at 12:12 AM, Tim Mester tmes...@ieee.org wrote: Commit 2e68a75990011ccd looks interesting. It makes sense to me that if we are gating the clock, and it is possible that we are glitching the clock line, it could put the internal synchronous logic into a bad state. If that happens, it would generally require a reset under a stable clock to get out of that condition. I will give that patch a try an see if it addresses issue 1), mentioned above. Yeah, the whole thing about the clocks not being enabled/disabled in the correct order relative to enabling the sub-blocks did result in some strange cases where sub-block wouldn't reactivate properly, requiring a reset to return it to a working state. It was specifically this issue I was concerned about might be the right fix for the problem you are hitting. Note: you need more than just 2e68a75990011ccd. That is actually an add-on to the real commit that restructures the clock managment: 39c39b0e612b5d35feb00329b527b266df8f7fd2 However, I'm not sure if that will do anything about issue 2). Do you have any insight into that one? Well, I've never been a fan of how the code just does a blind return 0 if the target modulation and frequency are the same as it's in theory already tuned to. Have you tried commenting out just that block and see if it makes a difference? IIRC, the dvb-frontend kernel thread should automatically re-issue a set_frontend() call if the signal lock drops out. As for the underlying problem, I'm not sure. Generally once the signal is locked it continues to work. If you set the xc5000 debug=1 modprobe option, do you see lines in the log that say xc5000: PLL not locked? How reproducible is the issue, and how often does it happen? I've got some newer firmware that might be worth trying which isn't upstream yet (assuming for a moment that it's an xc5000 issue). If you believe you can repro the issue pretty regularly, you and I can work offline to try that out. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] au8522, au0828: Added demodulator reset
On Tue, Jan 7, 2014 at 9:58 AM, Mauro Carvalho Chehab m.che...@samsung.com wrote: Patches 1 and 2 are ok? If so, could you please reply to them with your ack? Sure, no problem. http://git.kernellabs.com/?p=dheitmueller/linuxtv.git;a=shortlog;h=refs/heads/950q_improv I'm not against the hack you've proposed if it's really warranted, but a reset is really a last resort and I'm very concerned it's masking over the real problem. Are you planning to submit the above patches upstream soon? Yeah, I've just been busy and haven't had a chance to send them to the list (except for the last patch on the series, which is customer specific). I've got a couple of others which haven't been pushed and need to be put onto that series before it can be merged. Will definitely be good to get it all upstream before somebody does some refactoring and then a rebase is required. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] au8028: Fix cleanup on kzalloc fail
(dev, 0x60b, 0x01);
+ au0828_start_transport(dev);
start_urb_transfer(dev);
mutex_unlock(dvb-lock);
@@ -375,6 +404,9 @@ static int dvb_register(struct au0828_dev *dev)
/* register network adapter */
dvb_net_init(dvb-adapter, dvb-net, dvb-demux.dmx);
+
+ dvb-start_count = 0;
+ dvb-stop_count = 0;
return 0;
fail_fe_conn:
diff --git a/linux/drivers/media/usb/au0828/au0828.h
b/linux/drivers/media/usb/au0828/au0828.h
index ef1f57f..a00b400 100644
--- a/linux/drivers/media/usb/au0828/au0828.h
+++ b/linux/drivers/media/usb/au0828/au0828.h
@@ -102,6 +102,8 @@ struct au0828_dvb {
struct dmx_frontend fe_mem;
struct dvb_net net;
int feeding;
+ int start_count;
+ int stop_count;
};
enum au0828_stream_state {
--
1.8.1.4
--
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
Acked-by: Devin Heitmueller dheitmuel...@kernellabs.com
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] au0828: Add option to preallocate digital transfer buffers
= 0; i URB_COUNT; i++)
+ kfree(dev-dig_transfer_buffer[i]);
+ }
+
+
}
/* All the DVB attach calls go here, this function get's modified
diff --git a/linux/drivers/media/usb/au0828/au0828.h
b/linux/drivers/media/usb/au0828/au0828.h
index a00b400..5439772 100644
--- a/linux/drivers/media/usb/au0828/au0828.h
+++ b/linux/drivers/media/usb/au0828/au0828.h
@@ -262,6 +262,10 @@ struct au0828_dev {
/* USB / URB Related */
int urb_streaming;
struct urb *urbs[URB_COUNT];
+
+ /* Preallocated transfer digital transfer buffers */
+
+ char *dig_transfer_buffer[URB_COUNT];
};
/* --- */
--
1.8.1.4
--
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
Acked-by: Devin Heitmueller dheitmuel...@kernellabs.com
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] au8522, au0828: Added demodulator reset
On Mon, Jan 6, 2014 at 11:29 PM, Tim Mester ttmest...@gmail.com wrote: The demodulator can get in a state in ATSC mode where just restarting the feed alone does not correct the corrupted stream. The demodulator reset in addition to the feed restart seems to correct the condition. The au8522 driver has been modified so that when set_frontend() is called with the same frequency and modulation mode, the demodulator will be reset. The au0282 drives uses this feature when it attempts to restart the feed. What is the actual corruption that you are seeing? Can you describe it in greater detail? The original fix was specifically related to the internal FIFO on the au0828 where it can get shifted by one or more bits (i.e. the leading byte is no longer 0x47 but 0x47 X). Hence it's an issue unrelated to the actual au8522. I suspect this is actually a different problem which out of dumb luck gets fixed by resetting the chip. Without more details on the specific behavior you are seeing though I cannot really advise on what the correct change is. This patch should not be accepted upstream without more discussion. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] au8522, au0828: Added demodulator reset
I suspect this is actually a different problem which out of dumb luck gets fixed by resetting the chip. Without more details on the specific behavior you are seeing though I cannot really advise on what the correct change is. Tim, It might be worth trying out the following patch series and see if it addresses the problem you're seeing. There was a host of problems with the clock management on the device which could result in the various sub-blocks getting wedged. The TS output block was just one of those cases. http://git.kernellabs.com/?p=dheitmueller/linuxtv.git;a=shortlog;h=refs/heads/950q_improv I'm not against the hack you've proposed if it's really warranted, but a reset is really a last resort and I'm very concerned it's masking over the real problem. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: v4l2: The device does not support the streaming I/O method.
On Wed, Jan 1, 2014 at 2:41 PM, Andy dssnos...@gmail.com wrote: I am trying to stream /dev/video0 to http and encode it in h.264. Last I checked, the ffmpeg v4l2 input interface is just for raw video. What you probably want to do is just use v4l2-ctl to setup the tuner appropriately, and then pass in /dev/video0 as a standard filehandle to ffmpeg (i.e. -i /dev/video0). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: v4l2: The device does not support the streaming I/O method.
On Wed, Jan 1, 2014 at 5:18 PM, Andy Walls awa...@md.metrocast.net wrote: uncompressed video is available from /dev/video32 in an odd Conexant macroblock format that is called 'HM12' under linux. I should have been more clear - last I checked it only supported raw video in streaming mode (mmap). So even though the driver has this capability it won't really help. raw PCM audio samples are available from /dev/video24 Same basic issue, I think it will only acquire audio via ALSA. Note that /dev/video0 is always MPEG-2 compressed video. I assume ffmpeg and mencoder can transcode from MPEG-2 PS to H.264 on the fly, however, they will consume more CPU to do the decompression of the MPEG-2 PS. The advantage of working with the MPEG-2 PS as the source is that one avoids the audio video synchronization problem one might encounter working with the separate uncompressed audio video streams. Agreed that transcoding is more CPU expensive, but I suspect if he's willing to transcode he can actually get something working today without any modifications to the sources of either the driver or ffmpeg. And as you suggested, it does help avoid the A/V sync problems associated with raw capture. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: v4l2: The device does not support the streaming I/O method.
On Wed, Jan 1, 2014 at 5:21 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Wed, Jan 1, 2014 at 5:18 PM, Andy Walls awa...@md.metrocast.net wrote: uncompressed video is available from /dev/video32 in an odd Conexant macroblock format that is called 'HM12' under linux. One more point worth making - I doubt ffmpeg supports HM12 natively. You would either have to add the functionality to ffmpeg to do the colorspace conversion, or you might be able to wrap ffmpeg around libv4l2convert via LD_LIBRARY_PATH. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v3 6/7] rtl2832_sdr: convert to SDR API
I haven't looked situation more carefully yet, but one thing that must be done at the very first is to add some lock to prevent only DVB or V4L2 API could access the hardware at time. Probably worth mentioning that we have *lots* of devices that suffer from this problem. Our general tact has to been to do nothing and let the driver crash and burn in non-predictable ways when userland tries to use both APIs at the same time. So while it's pretty pathetic that we still haven't resolved this after all these years, if you didn't address the issue in the initial release then you wouldn't be much worse off than lots of other devices. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v3 6/7] rtl2832_sdr: convert to SDR API
I think I could add some lock quite easily. I remember when I implemented cxd2820r DVB-T/T2/C demod driver and at the time it implements 2 frontends, one for DVB-T/T2 and one for DVB-C. I used shared lock to prevent access only for single fe at time. I think same solution works in that case too. Locking between v4l and dvb is more problematic because of known bugs related to the dvb_frontend deferring the shutdown of the tuner. As a result there is a race condition if you try to close the DVB device and then immediately open the V4L device (which would be a common use case if using an application like MythTV when switching from digital to analog mode). You can't simply add a lock because the V4L side will get hit with -EBUSY because the DVB frontend hasn't completely shutdown yet. Unfortunately it's one of those cases where it seems easy until you start scoping out the edge cases and race conditions. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: -19
On Tue, Dec 17, 2013 at 4:09 PM, Antti Palosaari cr...@iki.fi wrote: That shared DVB / V4L2 tuner is one problem that I have also currently (SDR is on V4L2 API and DTV is provided via DVB API). I have decided to try model where I separate RF tuner totally independent used DVB / V4L2 APIs, just to plain I2C driver model. Idea is here to provide needed set of general callbacks and communication and device binding is done via I2C driver model. I am not sure though if there is any big caveats I haven't realized yet... It's a tough problem - a more strictly defined API in theory allows for better uniformity across drivers (although admittedly we've done a piss-poor job in practice). However such a strictly defined API makes it harder to add hacks that are sometimes required by the silicon. The additional abstractions provided by v4l2 subdev and tuner-core just make it that much harder to get past those layers and poke the device directly (which as much as I hate to admit it, is sometimes required to work around bugs and weird edge cases in the silicon not addressable via the API). These problems are exacerbated by cases where there are order-of-operations requirements that cannot be accommodated by the API. All that said though, moving to an entirely I2C based API feels like to provides too much flexibility such that every bridge will talk a little differently to every tuner. Given what a crappy job we've done in the past even with a strict framework, I cringe to think how much worse the problem would be if every developer took a different approach. I'm not against implementing a callback which allows you to feed arbitrary I2C commands to a device, to be used *sparingly* for those cases where it is *really* required to do something not supported via the framework's API. But I don't see it as a replacement for the existing frameworks for addressing tuners. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: -19
Hi Connor, On Tue, Dec 17, 2013 at 12:28 AM, Connor Behan connor.be...@gmail.com wrote: Thanks for the detailed answer. I have tried your patch and updated the wiki page. Would a 950 or 950Q be safer to buy next time? The 950 has long since been obsoleted. You cannot buy them anymore. The 950q though is well supported and doesn't have this issue as it uses a different chip. On 14/12/13 05:17 PM, Devin Heitmueller wrote: I had a patch kicking around which fixed part of the issue, but it didn't completely work because of the lgdt3305 having AGC enabled at chip powerup (which interferes with analog tuning on the shared tuner), and the internal v4l-dvb APIs don't provide any easy way to reset the AGC from the analog side of the device. By this do you mean that the functions exist but they aren't part of the public API? Maybe this problem can be addressed if there is ever v4l3 or some other reason to break compatibility. No, these are internal APIs that dictate how the various driver components talk to each other. Because the V4L and DVB subsystems were developed independently of each other, they do a really crappy job of communicating between them (a problem which manifests itself in particular when sharing hardware resources such as tuners). The problem *can* be fixed, but it would likely require extensions/changes to the basic frameworks used to communicate between the different drivers. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [3.12.5] Regression with PCTV 290e DVB-T2 adapter.
I have just tested my PCTV 290e DVB-T2 adapter with 3.12.5 and discovered that it fails with logs of messages like these: [11720.780975] __tda18271_write_regs: [7-0060|M] ERROR: idx = 0x5, len = 1, i2c_transfer returned: -19 [11720.788726] tda18271_init: [7-0060|M] error -19 on line 832 [11720.793001] tda18271_tune: [7-0060|M] error -19 on line 910 [11720.797279] tda18271_set_params: [7-0060|M] error -19 on line 985 Reverting to 3.11.10 fixes this problem. I have raised https://bugzilla.kernel.org/show_bug.cgi?id=67041 Already reported and fixed. See the thread that's been going on over the last two days named stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: -19. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: -19
My basic problem is __tda18271_write_regs: [1-0060|M] ERROR: idx = 0x0, len = 39, i2c_transfer returned: -32 where it attaches lgdt3305 before tda18271. Do you know a similar patch that could help me? It's a totally different issue. The problem with the US Exeter has to do with the lgdt3305 wedging the I2C bus after initialization because there's a timing window where you have to strobe the reset after chip powerup. I had a patch kicking around which fixed part of the issue, but it didn't completely work because of the lgdt3305 having AGC enabled at chip powerup (which interferes with analog tuning on the shared tuner), and the internal v4l-dvb APIs don't provide any easy way to reset the AGC from the analog side of the device. In short, it's been a known issue for almost three years and nobody's gotten around to fixing it, and it sees unlikely anyone with the appropriate level of knowledge of the device will anytime soon. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] femon: Display SNR in dB
On Sun, Nov 24, 2013 at 1:02 PM, Chris Lee update...@gmail.com wrote: This is a frustration of mine. Some report it in SNR others report it in terms of % (current snr / (max_snr-min_snr)) others its completely random. Seems many dvb-s report arbitrary % which is stupid and many atsc report snr by 123 would be 12.3db. But there isnt any standardization around. imo everything should be reported in terms of db, why % was ever chosen is beyond logic. Is this something we can get ratified ? I wouldn't hold your breath. We've been arguing about this for years. You can check the archives for the dozens of messages exchanged on the topic. Given almost all the Linux drivers for ATSC/ClearQAM devices sold today report in 0.1 dB increments, I'm tempted to put a hack in the various applications to assume all ATSC devices are in that format. I've essentially given up on any hope that there will be any agreement on a kernel API which applications can rely on for a uniform format. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] femon: Display SNR in dB
On Sun, Nov 24, 2013 at 1:40 PM, Chris Lee update...@gmail.com wrote: I made an exception in my app if the system is ATSC/QAM it uses the snr = snr * 10.0 and havent found a card yet that it doesnt work with. Ive also converted quite a few of my dvb-s tuners to report db in the same way. Havent found a card yet that doesnt have the ability to report snr in db. Im sure there is one, but I wonder how old it is and if anyone still uses them. The devices which have the ldgt3303 demodulator report in (SNR * 1/256), and there are still quite a few of those out there and in use. But yeah, since most of the ATSC/ClearQAM devices out there nowadays have a demod driver written by one of three people, all who agreed on the same format, you won't find many devices out there nowadays which don't use 0.1 dB increments. That said, everything in the previous paragraph applies exclusively to ATSC/ClearQAM devices. There is much more variation once you start talking about DVB-T/S/S2, etc. I have found a few tuner/demods that dont have a method of reporting signal strength and just use a calc based off the snr in db to make a fake strength. Yup, there is definitely more ambiguity across demods with the signal strength field. In some cases it reports the same as the SNR field, in other cases it scales the SNR to a 0-65535 range, in yet other cases it returns garbage or no value at all. How I look at is if snr in % is completely arbitrary and means nothing when compared from one tuner to another, whats the harm in that particularly weird tuner/demod of reporting a fake SNR that is arbitrary and have every other device in Linux report something useful. Seems dumb to have every device in Linux report an arbitrary useless value just because one or two devices cant report anything useful. The whole argument over the years is what that useful format should be. The problem is bad enough where a whole new API has been proposed which allows the demod to specify its reporting format explicitly. That proposed new API has a whole host of *other* problems, but that was the last attempt to bring some clarity to the problem. I just hate seeing every device reporting useless values just because one or two tuner/demods are reporting useless values. Why destroy that useful data for the sake of making all data uniformly useless. Unfortunately we're not talking about one or two - we're talking about dozens. I wouldn't be remotely surprised to see that more than 50% of devices out there do not report in 0.1dB increments. Certainly a large part of the problem is that users such as yourself have a slightly skewed viewpoint because your experience is based on the handful of tuners you own (if you actually own a handful, that's comparatively quite a lot - most people only own a single tuner). Yeah, the situation is frustrating. No easy answers here. 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
Dual licensing for v4l2-common.h userland headers
As a result of a code audit the VLC group is doing, they stumbled on the fact that v4l2-common.h is not dual licensed (it's marked as GPL only). This obviously poses a problem especially since v4l2-common.h is included by videodev2.h (which is the key header people include when they want to use the V4L2 API from userland). Would it be possible to get the header changed to reflect dual licensing? Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SAA7134 driver reports zero frame rate
On Sat, Nov 16, 2013 at 6:19 PM, Tim E. Real termt...@rogers.com wrote:
The SAA7134 driver causes libav to crash because the
driver reports zero frame rate.
Thus it is virtually impossible to do any recording.
Step #1: Open a bug against libav. The app should return an error or
not let you start streaming. If it crashes (regardless of the
underlying reason), they've got a bug in their library.
About a year ago I debugged and found I had to do this,
(but it was not enough, more fixes would be needed):
In libav/libavdevice/v4l2.c :
static int v4l2_set_parameters(AVFormatContext *s1, AVFormatParameters *ap)
{
...
s1-streams[0]-codec-time_base.den = tpf-denominator;
s1-streams[0]-codec-time_base.num = tpf-numerator;
// By Tim. BUG: The saa7134 driver (at least) reports zero framerate,
// causing abort in rescale. So just force it.
if(s1-streams[0]-codec-time_base.den == 0 ||
s1-streams[0]-codec-time_base.num == 0)
{
s1-streams[0]-codec-time_base.num = 1;
s1-streams[0]-codec-time_base.den = 30;
}
s-timeout = 100 +
av_rescale_q(1, s1-streams[0]-codec-time_base,
(AVRational){1, 1000});
return 0;
}
I looked at the SAA7134 module parameters but couldn't seem to
find anything to help.
Does anyone know how to make the module work so it sets a proper
frame rate, or if this problem been fixed recently?
Have you tried it with the latest kernel? Many of the drivers have
had fixes in the last year for V4L2 conformance, so it's possible this
was already fixed.
I would recommend you try it with the latest kernel and see if it
still happens. If it does still occur, then somebody can dig into it
(assuming they have time/energy/inclination).
I'm not arguing that you probably found a bug, but you'll have to do a
bit more of the legwork to make sure it's still a real issue before
somebody else gets involved.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
On Fri, Nov 15, 2013 at 8:32 AM, David Howells dhowe...@redhat.com wrote: Whilst that may be so, something clears it between one call to m88ds3103_set_frontend() and the next, so you probably need to unconditionally reload the program init table. Check your GPIO config for the specific board in the cx23885 driver. Registers unexpectedly resetting to their default value between tunes could very well be because your GPIO setup is incorrect and the demodulator chip's reset line is being strobed between tuning requests. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] libv4lconvert: SDR conversion from U8 to FLOAT
On Fri, Nov 15, 2013 at 2:11 PM, Antti Palosaari cr...@iki.fi wrote: When I do it inside Kernel, in URB completion handler at the same time when copying data to videobuf2, using pre-calculated LUTs and using mmap it eats 0.5% CPU to transfer stream to app. When I do same but using libv4lconvert as that patch, it takes ~11% CPU. How are you measuring? Interrupt handlers typically don't count toward the CPU performance counters. It's possible that the cost is the same but you're just not seeing it in top. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge ImpactVCB-e 01381 PCIe driver resolution.
On Sun, Sep 15, 2013 at 7:11 PM, Steve Cookson i...@sca-uk.com wrote: Hi Devin, Thanks for responding. So my question would be then, is it worth fixing? I can't find any PCIe cards that give me a reasonable quality. If I use an external card like the Dazzle it seems quite fast and better quality than many s-video cards. Could the ImpactVCB-e be better than the Dazzle? Hi Steve, Whether it's worth fixing, it's largely a question of worth it to whom? Apparently nobody had noticed it was broken until now, hence making it questionable how important it is to the general community. It's worth noting that the problem isn't specific to the ImpactVCB-e; it would happen with any cx23885 based board. The quality will probably be comparable to the Dazzle. In terms of quite fast, they should both be the exact same speed since they are both delivering raw video in realtime. One key advantage of the ImpactVCB-e is that you can have multiple installed in a single system, while in the case of the Dazzle you will likely only be able to use one device since it uses more than half of the USB bus bandwidth. I'm not sure what other cards you've tried. Nowadays they should all deliverable comparable performance for s-video (since no chroma separation is involved), if they don't then it's almost certainly a Linux driver bug. If you have a commercial need for the device to work, we can discuss offlist doing some consulting to resolve the issue. However if not then you're pretty much at the mercy of the community in terms of the state of quality/support. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Canvassing for Linux support for Startech PEXHDCAP
On Mon, Sep 16, 2013 at 4:27 PM, Steve Cookson i...@sca-uk.com wrote: Here is the spec: http://www.startech.com/AV/Converters/Video/PCI-Express-HD-Video-Capture-Card-1080p-HDMI-DVI-VGA-Component~PEXHDCAP#tchspcs But the main spec points (for me at least) are - It's based on the Mstar MST3367CMK chip as are many similar cards, - It's PCIe connection - It has inputs of: --- Component Video (YPbPr) --- DVI-I (plus a vga adaptor) --- HDMI --- Stereo Audio - Maximum Digital Resolution: 1080p30 - TV input resolution: 1080i/p, 720p, 576i/p, 480i/p - PC input resolution: 1920x1080, 1440x900, 1280x1024, 1280x960, 1280x720, 1024x768, 800x600 - MPEG4/H.264 hardware compression. To be clear, this card is a *raw* capture card. It does not have any hardware compression for H.264. It's done entirely in software. Aside from the mstar video decoder (for which there is no public documentation), you would also need a driver for the saa7160 chip, which there have been various half-baked drivers floating around but nothing upstream, and none of them currently support HD capture (AFAIK). As always, a driver *can* be written, but it would be a rather large project (probably several weeks of an engineer working full time on it, assuming the engineer has experience in this area). In this case it's worse because a significant amount of reverse engineering would be required. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge ImpactVCB-e 01381 PCIe driver resolution.
Hi Steve, What I really want is a fast, analogue RGBS 480i 1080i capture card. Raw HD capture is essentially non-existent under Linux. We have a couple of closed source drivers, none of which are cost effective for non-commercial applications (we have drivers for a couple of Avermedia HDMI/component capture cards). Maybe like the Epiphan VGA2USB LR (internal version), but it is sooo expensive. For 25% of the price I can get a Blackmagic Design Intensity Pro, but it only does YPbPr 1080i and the decklinksrc gstreamer module is a bit ropey. Actually very ropey. But it also accepts s-video. So then I fall back on the old tried and tested s-video stuff. I have to accept 480i but I can still have a fast response. Dazzle is about 100 msecs but some others, like the old ImpactVCB pci card with 3 av ports and an s-video port, has worse quality video than the Dazzle and is slower. I've tested another couple of PCI cards but they are all very slow and poor video quality. The slow aspect is probably just a misconfiguration in the number of buffers the V4L2 driver delivers. All of the cards should support a minimum of two buffers, which would put latency at 60ms. Anything greater is probably the application doing some prebuffering. The one I'd really like, at about $100 on Amazon, is the Startech VGA capture card, I could put a synch splitter/inverter in front of it, for say $25, to convert RGB3 1080i to VGA HD1080. It runs like a dream with a fast response. It's Linux compatible as far as I can see, that is to say lspci should say something if you plug it in, but there is no driver for it. To be clear, the fact that it shows up in lspci is absolutely no indicator of being Linux compatible. It just means the device conforms to the PCI standard and can thus the hardware can be enumerated. The one I saw, which was not the Startech one but a similar one from Kato vision, was PCIe, with onboard h.264 hardware compression and a direct memory access module. It just screamed through that video signal. I wasn't able to do any timer tests on it, but I would guess much faster than the dazzle. Maybe 50 msecs latency. Are you using the same application for capture in both cases? They really shouldn't behave any differently. Raw video is essentially no latency since the card typically doesn't have enough memory to do any buffering (unlike compressed video where you can have latency of several seconds depending on the encoder used). Any latency you are seeing is either in the driver or the application. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 950Q CC Extraction (V4L2/VBI)
On Wed, Jul 31, 2013 at 11:55 AM, Trevor Anonymous trevor.for...@gmail.com wrote: Hi all, new to the list, hope this is an appropriate place to ask this. Quick question: I can extract NTSC analog closed captions with the Hauppauge 950Q as follows: 1. Run v4l2-ctl -i 1 ## Set input to composite 2. In a test application, open file /dev/video0 3. Read 1 byte from the file ** Note: This seems to be sufficient to start the device ** Calling VIDIOC_STREAMON ioctl is *not* sufficient 4. Run: zvbi-ntsc-cc -c -d /dev/vbi0 ## Prints the closed captions 5. Close file handle to /dev/video0 when finished. Device stops. My question: Is opening the device and reading 1 byte a good/ok way to start the device? I'm only interested in closed captions, and want this to be as small a footprint as possible. I'm worried that this method may break in future driver versions. Hi Trevor, The fact that you need video streaming in order to access CC is a bug in the driver (brought to my attention only a couple of weeks ago). I didn't properly setup the referencing counting for when to start/stop the isoc FIFO, so the arrival of data is implicitly tied to the use of /dev/video. The hack you've described should work as long as you keep the filehandle open (in fact it's pretty much what the other user hacked in userland to workaround the bug). That said, I would like to fix the underlying bug so that the driver behaves like it's supposed to (which means you should be able to access /dev/vbi for CC capture without having to muck with streaming from /dev/video). I suspect that the fix won't cause the workaround you're proposing to stop working. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Green/purple video from 950Q + security cam
Hi Michael, On Sun, Jul 28, 2013 at 6:00 PM, Michael Conrad m...@nrdvana.net wrote: When I plug either of these cameras into the video plug on a plain old TV, they work great. When I plug either camera into the 950Q on Windows using the supplied WinTV software, they work great. When I plug the rear-view camera into the 950Q on Linux, it works great. But when I plug the security camera into 950Q on Linux, it mostly works and then the picture starts randomly jumping sideways (like it is having trouble keeping a horizontal sync on the signal) and then will suddenly flip to a green-grayscale image with all bright areas as purple-grayscale. Once turned green/purple, it remains like this until I reset the camera, but the video is full framerate, low latency, and looks flawless aside from the bizarre colors. Yeah, there have been some issues with frame alignment on that particular chip, which primarily manifest themselves when using highly unstable video sources. This might sound like a cop-out, but you would be better suited with *any* $29 capture device from NewEgg than with the 950q. I've got workarounds in the driver code which cover most of the edge cases, but they aren't foolproof. For the tests under Linux, I am using the v4l2 API directly in a simple demo C program I wrote. It is attached. I tried both the read API, and the mmap API. Both produce identical results. Won't make a difference whether using mmap or read in this case. My other attempts on Linux had been to use v4l2-ctl to select the composite channel, and then play the device with VLC or Cheese. Neither were successful (no video at all) but I need to do this from C in the long run, anyway. Cheese typically doesn't work with anything other than webcams since they typically don't support all the colorspaces (and the 950q in particular uses one that is unusual for raw video). VLC should work though if you get the correct magic incantation of command line arguments (I use it regularly with the 950q). Anyone seen anything like this before? Yes, I have. :-) It can certainly be made to work via hacking at the driver (but I don't have a video source which readily reproduces the issue). But with Kworld 2800d units being available for $29 on Ebay, that is probably by far the easier approach. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Very verbose message about em28174 chip.
On Sun, Jul 28, 2013 at 9:19 AM, Chris Rankin ranki...@yahoo.com wrote: Hi, I plugged my PCTV 290e device into my newly compiled 3.10.3 kernel today, and found this message in the dmesg log. [ 511.041412] usb 10-4: new high-speed USB device number 3 using ehci-pci [ 511.216218] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) [ 511.223916] em28xx: DVB interface 0 found: isoc [ 511.227398] em28xx: chip ID is em28174 [ 511.548310] em28174 #0: i2c eeprom : 26 00 01 00 02 09 d8 85 80 80 e5 80 f4 f5 94 90 [ 511.54] em28174 #0: i2c eeprom 0010: 78 0d e4 f0 f5 46 12 00 5a c2 eb c2 e8 30 e9 03 [ 511.562682] em28174 #0: i2c eeprom 0020: 12 09 de 30 eb 03 12 09 10 30 ec f1 12 07 72 80 [ 511.569827] em28174 #0: i2c eeprom 0030: ec 00 60 00 e5 f5 64 01 60 09 e5 f5 64 09 60 03 [ 511.576937] em28174 #0: i2c eeprom 0040: c2 c6 22 e5 f7 b4 03 13 e5 f6 b4 87 03 02 09 92 [ 511.584138] em28174 #0: i2c eeprom 0050: e5 f6 b4 93 03 02 07 e6 c2 c6 22 c2 c6 22 12 09 [ 511.591273] em28174 #0: i2c eeprom 0060: cf 02 06 19 1a eb 67 95 13 20 4f 02 c0 13 6b 10 [ 511.598453] em28174 #0: i2c eeprom 0070: a0 1a ba 14 ce 1a 39 57 00 5c 18 00 00 00 00 00 [ 511.605572] em28174 #0: i2c eeprom 0080: 00 00 00 00 44 36 00 00 f0 10 02 00 00 00 00 00 [ 511.612694] em28174 #0: i2c eeprom 0090: 5b 23 c0 00 00 00 20 40 20 80 02 20 01 01 00 00 [ 511.619821] em28174 #0: i2c eeprom 00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 511.627001] em28174 #0: i2c eeprom 00b0: c6 40 00 00 00 00 a7 00 00 00 00 00 00 00 00 00 [ 511.634120] em28174 #0: i2c eeprom 00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 38 32 [ 511.641199] em28174 #0: i2c eeprom 00d0: 34 31 30 31 31 36 36 30 31 37 31 31 32 36 58 59 [ 511.648319] em28174 #0: i2c eeprom 00e0: 56 49 00 4f 53 49 30 30 33 30 38 44 30 31 30 36 [ 511.655473] em28174 #0: i2c eeprom 00f0: 58 59 56 49 00 00 00 00 00 00 00 00 00 00 30 36 [ 511.662628] em28174 #0: i2c eeprom 0100: ... (skipped) [ 511.666500] em28174 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x1eb936d2 [ 511.672023] em28174 #0: EEPROM info: [ 511.674338] em28174 #0: microcode start address = 0x0004, boot configuration = 0x01 [ 511.705368] em28174 #0: No audio on board. [ 511.708286] em28174 #0: 500mA max power [ 511.710988] em28174 #0: Table at offset 0x00, strings=0x, 0x, 0x [ 511.717120] em28174 #0: Identified as PCTV nanoStick T2 290e (card=78) [ 511.722436] em28174 #0: v4l2 driver version 0.2.0 [ 511.731410] em28174 #0: V4L2 video device registered as video1 [ 511.736043] em28174 #0: dvb set to isoc mode. [ 511.739638] usbcore: registered new interface driver em28xx [ 511.821414] tda18271 7-0060: creating new instance [ 511.829520] TDA18271HD/C2 detected @ 7-0060 [ 512.000542] DVB: registering new adapter (em28174 #0) [ 512.004325] usb 10-4: DVB: registering adapter 0 frontend 0 (Sony CXD2820R)... [ 512.011191] em28174 #0: Successfully loaded em28xx-dvb [ 512.015077] Em28xx: Initialized (Em28xx dvb Extension) extension [ 512.056753] Registered IR keymap rc-pinnacle-pctv-hd [ 512.060784] input: em28xx IR (em28174 #0) as /devices/pci:00/:00:1d.7/usb10/10-4/rc/rc0/input16 [ 512.069167] rc0: em28xx IR (em28174 #0) as /devices/pci:00/:00:1d.7/usb10/10-4/rc/rc0 [ 512.076882] Em28xx: Initialized (Em28xx Input Extension) extension [ 552.064828] tda18271: performing RF tracking filter calibration [ 554.417676] tda18271: RF tracking filter calibration complete Nothing out of the ordinary in this output. Presumably something this verbose is intended to be shared, so here it is. (I can't think of any other reason why this amount of information would be logged by default). The complexity of these devices (variations on demodulators, tuner chips used, etc) have resulted in putting out more debug by default on initialization compared to other drivers (typically to aid in debugging when users report issues). The amount of output is not inconsistent with most other linuxtv drivers though. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Very verbose message about em28174 chip.
On Sun, Jul 28, 2013 at 9:58 AM, Chris Rankin ranki...@yahoo.com wrote: - Original Message - From: Devin Heitmueller dheitmuel...@kernellabs.com The amount of output is not inconsistent with most other linuxtv drivers though. It's the EEPROM dump that really caught my eye: 16+ lines of pure WTF?. Yeah, nowadays the eeprom output is one of the less useful pieces of output (in fact, I intentionally didn't do support for dumping it out on the em2874, but somebody did it anyway). That said, I certainly wouldn't nack any patch submitted which changed the debug level for the eeprom output so it's not visible by default. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UVC and V4L2_CAP_AUDIO
On Thu, Jul 25, 2013 at 5:10 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Not without dirty hacks. The UVC interfaces don't report whether the device has an audio function, the driver would need to look at all the interfaces of the parent USB device and find out whether they match one of the USB audio drivers. That's not something I would be inclined to merge in the uvcvideo driver. We need this functionality anyway for other snd-usb-audio based tuners like em28xx and au0828, so I think some sort of solution is unavoidable. I hacked something together for em28xx a few years ago to do such an enumeration, but in reality we should probably have an export in snd-usb-audio which would help figuring this out in a less hacky way. If not, then it looks like the only way to find the associated alsa device is to use libmedia_dev (or its replacement, although I wonder if anyone is still working on that). Yup, it's 2013 and we still don't have a way for applications to ask the kernel which ALSA device is tied to a given /dev/video node. Hans, remember when I proposed adding a trivial ioctl() call back in 2009 that would allow this, and you rejected it saying the media controller API was the answer? It's hard not to feel like salt in the wound that it's four years later and there *still* isn't a solution. 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
Expected behavior for S_INPUT while streaming in progress?
Hello, I'm doing some cleanup on the au8522 driver, and one thing I noticed was that you are actually allowed to issue an S_INPUT while streaming is active. This seems like dangerous behavior, since it can result in things like the standard and/or resolution changing while the device is actively streaming video. Should we be returning -EBUSY for S_INPUT if streaming is in progress? I see cases in drivers where we prevent S_STD from working while streaming is in progress, but it seems like S_INPUT is a superset of S_STD (it typically happens earlier in the setup process). If we did do this, how badly do we think it would break existing applications? It could require applications to do a STREAMOFF before setting the input (to handle the possibility that the call wasn't issued previously when an app was done with the device), which I suspect many applications aren't doing today. Alternatively, we can based it on not just whether streamon was called and instead base it on the combination of streamon having been called and a filehandle actively doing streaming. In this case case would return EBUSY if both conditions were met, but if only streamon was called but streaming wasn't actively being done by a filehandle, we would internally call streamoff and then change the input. This would mean that if an application like tvtime were running, externally toggling the input would return EBUSY. But if nothing was actively streaming via a /dev/videoX device then the call to set input would be successful (after internally stopping the stream). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] au8522_dig: fix snr lookup table
On Wed, Jul 17, 2013 at 8:30 PM, Chris Lee update...@gmail.com wrote: This patch fixes an if() statement that was preventing the last element in the table from ever being utilized, preventing the snr from ever displaying 27db. Also some of the gaps in the lookup table were filled in. Signed-off-by: Chris Lee update...@gmail.com I don't have any specific objection to this patch, other than that I have no idea if the values he's adding are actually correct. I'd have to pull out the datasheet and see what the formula looks like to actually calculate the correct values. This is of course assuming Chris didn't have the formula and just picked numbers that were roughly in between the adjacent values. The off-by-one is legit (syntactically at least - there is indeed no value that would result in 0 being selected), although frankly I don't know whether value 0 is supposed to be 26.0 or 27.0. It's entirely possible that 0=26.0 and the whole table is off by one value (this was actually the case with the QAM256 table, except in that case it was much worse because it was oscillating between 40.0 and 0.00). Anyway, hard to argue this isn't an improvement and thus shouldn't be accepted -- except for the real possibility that the patch introduces wrong values into the table. Acked-by: Devin Heitmueller dheitmuel...@kernellabs.com -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cx23885: Fix interrupt storm that happens in some cards when IR is enabled.
On Wed, Jul 17, 2013 at 9:33 PM, Luis Alves lja...@gmail.com wrote: Hi, This i2c init should stop the interrupt storm that happens in some cards when the IR receiver in enabled. It works perfectly in my TBS6981. What is at I2C address 0x4c? Might be useful to have a comment in there explaining what this patch actually does. This assumes you know/understand what it does - if you don't then a comment saying I don't know why this is needed but my board doesn't work right without it is just as valuable. It would be good to test in other problematic cards. In this patch I've added the IR init to the TeVii S470/S471 (and some others that fall in the same case statment). Other cards but these that suffer the same issue should also be tested. Without fully understanding the nature of this patch and what cards that it actually effects, it may make sense to move your board into a separate case statement. Generally it's bad form to make changes like against other cards without any testing against those cards (otherwise you can introduce regressions). Stick it in its own case statement, and users of the other boards can move their cards into that case statement *after* it's actually validated. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] [media] em28xx: Fix vidioc fmt vid cap v4l2 compliance
On Tue, Jul 16, 2013 at 7:06 PM, Alban Browaeys alban.browa...@gmail.com wrote: Set fmt.pix.priv to zero in vidioc_g_fmt_vid_cap and vidioc_try_fmt_vid_cap. Any reason not to have the v4l2 core do this before dispatching to the driver? Set it to zero before the core calls g_fmt. This avoids all the drivers (most of which don't use the field) from having to set the value themselves. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cx23885: Fix interrupt storm that happens in some cards when IR is enabled.
On Wed, Jul 17, 2013 at 10:15 PM, Antti Palosaari cr...@iki.fi wrote: hmm, I looked again the cx23885 driver. 0x4c == [0x98 1] = flatiron == some internal block of the chip Yeah, ok. Pretty sure Flatiron is the codename for the ADC for the SIF. There is routine which dumps registers out, 0x00 - 0x23 cx23885_flatiron_dump() There is also existing routine to write those Flatiron registers. So, that direct I2C access could be shorten to: cx23885_flatiron_write(dev, 0x1f, 0x80); cx23885_flatiron_write(dev, 0x23, 0x80); Yeah, the internal register routines should be used to avoid confusion. Unfortunately these two register names are not defined. Something clock or interrupt related likely. Strange. The ADC output is usually tied directly to the Merlin. I wonder why it would ever generate interrupts. No easy answers here. WIll probably have to take a closer look at the datasheet, or just ask Andy. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CX23103 Video Grabber seems to be supported by cx231xx driver
On Sun, Jul 14, 2013 at 9:23 AM, Florian Streibelt flor...@inet.tu-berlin.de wrote: Be aware that I consider this driver to be flaky, so I would not at all be surprised if there are bugs lurking in the code. Hum. Because of code quality or due to the missing documentation from the vendor? While this is all too common for vendors, it really isn't a reasonable assertion in this case. Conexant (the chip vendor) wrote the original driver, and they have been very supportive in the past. They provided documentation (under NDA) and reference designs at no cost. They've also answered questions I've had in the past regarding the chip and you'll also note that the email address of the maintainer was a Conexant engineer until he left the company. Regarding the flakiness, there indeed have been some reliability problems - some of them were in the original driver sources, a couple I introduced doing the cleanup work to get it upstream (and long ago fixed), and some were regressions introduced after the driver went upstream. It's tough maintaining a driver on an ongoing basis that supports many different cards from different vendors, in particular since individuals making changes to the driver to make it work with some new device, don't have all of the other products to test with (to ensure regressions aren't introduced). These drivers also tend to suffer from bitrot. If they aren't actively being used by many people and if there isn't a developer who actively maintains the driver, then regressions sneak in there and go unnoticed for months/years. If you have any documents on the chip I would be happy. I don't think there are any documents that aren't under NDA. That said, you don't need the register docs to debug a system hang. If you don't have the time to jam a few printk() statements into the source, then there's no point in going through the effort to get you docs. Your best bet at this point is probably to wait [indefinitely] for some developer who has a need for the device to work to stumble across the problem and debug it. You get what you pay for. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media] cx25821 regression from 3.9: BUG: bad unlock balance detected!
On Sun, Jul 14, 2013 at 5:39 PM, Hans Verkuil hverk...@xs4all.nl wrote: If you can get cx25821-video.c to work with vb2, then we can take a look at the alsa code. If I can make a suggestion: fix the lock problem first. The last thing you want to do is simultaneously debug a known buffer management problem at the same time you're trying to port to VB2. I panic'd my system enough times during the em28xx conversion where you really want to know whether the source is the VB2 work in progress or some other issue with buffer management. I'm not saying to not do the VB2 port -- just that you would be well served to have a reasonable stable driver before attempting to do the port. That said, I guess it's possible that digging into the code enough to understand what specifically has to be done for a VB2 port might reveal the source of the locking problem, but that's not how I would do it. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 36/50] media: usb: em28xx: spin_lock in complete() cleanup
On Thu, Jul 11, 2013 at 5:05 AM, Ming Lei ming@canonical.com wrote:
Complete() will be run with interrupt enabled, so change to
spin_lock_irqsave().
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: linux-media@vger.kernel.org
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/media/usb/em28xx/em28xx-core.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index fc157af..0d698f9 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -941,6 +941,7 @@ static void em28xx_irq_callback(struct urb *urb)
{
struct em28xx *dev = urb-context;
int i;
+ unsigned long flags;
switch (urb-status) {
case 0: /* success */
@@ -956,9 +957,9 @@ static void em28xx_irq_callback(struct urb *urb)
}
/* Copy data from URB */
- spin_lock(dev-slock);
+ spin_lock_irqsave(dev-slock, flags);
dev-usb_ctl.urb_data_copy(dev, urb);
- spin_unlock(dev-slock);
+ spin_unlock_irqrestore(dev-slock, flags);
/* Reset urb buffers */
for (i = 0; i urb-number_of_packets; i++) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I actually stumbled across this a couple of weeks ago, and have had an
identical patch running in a local dev tree.
Reviewed-by: Devin Heitmueller dheitmuel...@kernellabs.com
Tested-by: Devin Heitmueller dheitmuel...@kernellabs.com
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: lgdt3304
On Thu, Jun 27, 2013 at 2:38 PM, Carl-Fredrik Sundstrom
c...@blueflowamericas.com wrote:
Has the driver for lgdt3304 been tested ? I am trying to get a new card
working
AVerMedia AVerTVHD Duet PCTV tuner (A188) A188-AF PCI-Express x1 Interface
It is using
1 x saa7160E
2 x LGDT3304
2 x TDA18271HD/C2
I get so far that I can load a basic driver by modifying the existing
saa716x driver, I can detect the TDA18271HD/C2, but I fail to detect the
LGDT3304 when attaching it using the 3305 driver.
I always fail at the first read from LGDT3305_GEN_CTRL_2, does this register
even exist in lgdt3304 or is it specific to lgdt3305?
/* verify that we're talking to a lg dt3304/5 */
ret = lgdt3305_read_reg(state, LGDT3305_GEN_CTRL_2, val);
if ((lg_fail(ret)) | (val == 0))
{
printk(fail 1\n);
goto fail;
}
Since I do find the TDA18271HD/C2 I don't think there is something wrong
with the i2c buss. I also tried every possible i2c address without success.
The lgdt3305 has option between address 0x0e and 0x59, is it the same for
3304 ?
This is the first time I am trying to get a driver to work in Linux. Please
help me.
Either the i2c is broken or the lgdt3304 is being held in reset by a GPIO.
Also, that device has multiple i2c busses, so you could be looking on
the wrong bus.
Do you see *any* i2c devices (such as an eeprom).
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Doing a v4l-utils-1.0.0 release
I've got a fix for a really bad performance bug, so if you can hold off on doing a release a couple of hours until I can get in front of my Linux box and submit a patch, I would appreciate it. Thanks, Devin On Fri, Jun 14, 2013 at 4:51 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Fri 14 June 2013 09:15:02 Hans de Goede wrote: Hi All, IIRC the 0.9.x series were meant as development releases leading up to a new stable 1.0.0 release. Lately there have been no maintenance 0.8.x releases and a lot of interesting development going on in the 0.9.x, while at the same time there have been no issues reported against 0.9.x (iow it seems stable). So how about taking current master and releasing that as a 1.0.0 release ? Fine by me! Note that the libv4l2rds code is now finalized, so that can be released as well. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
[PATCH] Don't call G_TUNER unless actually performing a tuning related call
Making G_TUNER calls can take a long time on some tuners, in
particular those that load firmware or do power management. As a
result, we don't want to call G_TUNER unless the user is actually
doing a tuning related call. The current code makes a G_TUNER
call regardless of what command the user is attempting to perform.
Problem originally identified on the HVR-950q, where even doing
operations like toggling from the composite to the s-video input
would take over 1000ms.
Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com
---
utils/v4l2-ctl/v4l2-ctl-tuner.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/utils/v4l2-ctl/v4l2-ctl-tuner.cpp
b/utils/v4l2-ctl/v4l2-ctl-tuner.cpp
index ebe74d3..9af6b13 100644
--- a/utils/v4l2-ctl/v4l2-ctl-tuner.cpp
+++ b/utils/v4l2-ctl/v4l2-ctl-tuner.cpp
@@ -254,6 +254,13 @@ void tuner_set(int fd)
V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
double fac = 16;
+ if (!options[OptSetFreq] ! options[OptSetTuner]
!options[OptListFreqBands]
+!options[OptSetModulator] !options[OptFreqSeek]) {
+ /* Don't actually call G_[MODULATOR/TUNER] if we don't intend to
+ actually perform any tuner related function */
+ return;
+ }
+
if (capabilities V4L2_CAP_MODULATOR) {
type = V4L2_TUNER_RADIO;
modulator.index = tuner_index;
--
1.8.1.2
--
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: Hauppauge WinTV HVR 930C-HD - new USB ID 2040:b130 ?
On Tue, May 7, 2013 at 6:39 PM, Jan Kiszka jan.kis...@web.de wrote: To pick up this old topic (as I just got the wrong 930C delivered :( ): What is blocking the development of a si2165 driver? Lacking specs (due to NDAs)? Or lacking interest / developer bandwidth? Probably a bit of both. I've got the documentation under NDA, and last I checked it's not otherwise publicly available. That said, the chip has been around for several years and no developer has ever cared to do a reverse engineered driver. The chip isn't overly complicated (I could probably write a driver for it in a week even without the datasheets), alas there has never really been any interest. In case of the latter, how much effort may it take for a kernel hacker without particular experience in the DVB subsystem to get things running? Not rocket science, for sure. Probably the bigger issue is familiarity with reverse engineering techniques and a good understanding of how demodulators work. Learning the API itself is the easy part (given there are plenty of example drivers to use as a model). I can count on one hand the number of developers who are actively contributing tuner/demod drivers. There just is very little developer interest in this area nowadays. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Driver for KWorld UB435Q Version 3 (ATSC) USB id: 1b80:e34c
On Fri, May 3, 2013 at 3:50 PM, The Bit Pit thebit...@earthlink.net wrote: I am Wilson Michaels, please let me introduce myself: Eight years ago I contributed a driver for the DViCO FusionHDTV 3 5 PCI TV tuner cards (see lgdt330x.c). The code is still in linux today. One of my tuners is starting to fail so a purchased a KWorld UB435Q Version 3 (ATSC) from Newegg. It's not supported so I started working on a driver. Is anyone else working on a driver for the KWorld UB435Q V-3? I opened the case easily as it just snaps together with a plastic clip. It is not glued :-) I verified that it contains: EM2874B NXP TDA18272/M lgdt3305 I git the latest media_build tree and added entries to make it recognize the KWorld USB id: 1b80:e34c. The added code is like the KWorld UB435Q Version 2 code with lgdt3304 replaced by lgdt3305 and no .dvb_gpio or .tuner_gpio. It reports finding an em2874 chip using bulk transfer mode as expected. No bulk support currently for em28xx dvb. I never got around to it because the only sticks I ever came across them that use them is that particular KWorld model, and from everything I've heard it's a piece of garbage (unreliable, prone to failure even under WIndows). That said, a bulk endpoint driver isn't rocket science to add support for. :-) There appears to be code in the em28xx driver to handle bulk transfer. It does not recognize the lgdt3305. The lgdt3305 is probably on the second i2c bus -- typical for em2874 based devices. The tuner is probably gated behind the 3305. It's also likely that the 3305 is being held in reset by default. You'll probably need to tweak a GPIO to take it out of reset before it will answer i2c. I discovered (brute force scan) that there are two i2c addresses 0x50 and 0xd0. The lgdt3305 detection code is able to read something from either i2c address, but is is always 0. One is probably the eeprom. Does the eeprom data below have anything to help writing a driver for the KWorld UB435Q? Almost certainly not. I suspect some initialization needs to be done, but I don't know what to try. Does anyone have any information about how the hardware is configured or information captured from the Windows driver? Does anyone know where I can get a copy of the programming spec for the lgdt3305? The em2874 spec would be useful too. I have them both, but under NDA (neither are publicly available). You probably don't need either though. Aside from the bulk support, the em2874 implementation is pretty complete. Same goes for the 3305. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Video Signal Type in V4L
Is there any way by which I can know Input signal type (in terms of DVI/Composite/USB/SDI) and refresh rate from a V4L video capture device. Any available V4L Structure/Flag from which I can deduce this information. Please help ! The extent to which the data is available is the name field in the G_FMT call: http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-enuminput.html For most devices, the driver developer names the individual inputs Composite, S-Video, Tuner, etc. The only level of distinction other than the name is the type field, which today is V4L2_INPUT_TYPE_TUNER for an RF tuner and V4L2_INPUT_TYPE_CAMERA for everything else. To my knowledge there aren't any current drivers in the main tree that support DVI or SDI capture, so nobody has really cared to make the API more flexible to extend the type field with other values (which would both be easier to machine parse, localize, and be consistent across boards). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Elgato DTT Deluxe V2
On Tue, Apr 23, 2013 at 8:13 AM, Another Sillyname anothersn...@googlemail.com wrote: I recently picked up one of these very cheap and am trying to load it into 'nix. According to this http://www.linuxtv.org/wiki/index.php/Elgato_EyeTV_DTT_deluxe_v2 It should be recognised and load, and indeed when plugged in dmesg correctly reports it being detected and lsusb sees the device and the correctly reports the device ID. However there's no DVB section loading and I'm not sure why. I've copied the two .hex files to firmware and dmesg is not reporting any other outstanding requirements, however it's just not partying Installed into a windows machine the drivers load and it reports OK (it's not tuning but I'm pretty sure that's a location issue at the moment). any ideas anyone? The driver is still in the staging tree, and isn't compiled into the kernel by default. You'll have to either recompile your kernel to include the AS102 driver, or build the media_build tree. -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Keene
On Fri, Apr 19, 2013 at 5:58 AM, Hans Verkuil hverk...@xs4all.nl wrote: So perhaps this can be solved with two generic controls: bool CID_POWER_OFF_AT_LAST_CLOSE int CID_POWER_OFF_DELAY (unit: seconds) If POWER_OFF_AT_LAST_CLOSE is false, then you never power off. If it is true, then power off after a given delay. If the delay == 0 then power off immediately. Drivers can decide on proper default values. But radio devices must start with CID_POWER_OFF_AT_LAST_CLOSE set to false for compatibility reasons. I don't have time for the next few weeks to investigate this further, so if you are interested... Bear in mind that deferred shutdown opens a huge set of problems with hybrid tuners. We already have many, many race known conditions related to closing V4L and then immediately opening the corresponding DVB device (and closing DVB then immediately opening the V4L device). Without a proper framework, a change such as this will exacerbate the problem. These race conditions typically result in completely undefined behavior, as you either having both sides of the device powered up at the same time, or you have the second half powered up and then conflicting commands are received to power it down because of deferred commands for the first half to go to sleep. It's an absolute mess. And please don't forget that this isn't just about a shared tuner chip - it's about the state of video decoders and demodulators as well. You cannot just introduce simple locking in tuner-core and hope that resolves the problem. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bttv: Add noname Bt848 capture card with 14MHz xtal
On Sun, Apr 14, 2013 at 5:19 PM, Ondrej Zary li...@rainbow-software.org wrote: I wonder why the bttv driver probes for IR chips even when the has_remote flag is not set? Probably so you can add a remote via userland even if there isn't an default remote specified in the in-kernel board profile. That said, it probably makes more sense to require a default remote in the board profile for those devices which have an onboard IR controller, and use that to determine whether IR support is present on the board at all. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] em28xx: clean up end extend the GPIO port handling
On Sat, Apr 13, 2013 at 11:30 AM, Frank Schäfer fschaefer@googlemail.com wrote: I've checked the documentation about the gpio and led frameworks a few weeks ago to find out if it makes sense to use them for the gpio/buttons/led stuff of the VAD Laplace webcam. AFAICS, there are no benfits as long as you are dealing with these things internally. It just increases the code size and adds an additional dependency in this case. Of course, the situation is different when there is an interaction with other modules or userspace. In that case using gpiolib could make sense. I don't know which case applies to the LAN stuff, but for the buttons/leds it's the first case. IMHO, it would be a bad idea to expose the actual GPIOs to userspace. Improperly setting the GPIOs can cause damage to the board, and all of the functionality that the GPIOs control are exposed through other much better supported interfaces. It's a nice debug feature for driver developers who want to hack at the driver, but you really don't want any situation where end users or applications are making direct use of the GPIOs. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] em28xx: clean up end extend the GPIO port handling
On Sat, Apr 13, 2013 at 12:21 PM, Antti Palosaari cr...@iki.fi wrote: Existing userspace sysfs interface is clearly debug interface. You will need root privileges to mount it and IIRC it was not even compiled by default (needs Kconfig debug option?). You would like to think that. Tell Mauro then, since he wanted to rely on sysfs to associate V4L2 video devices with ALSA devices (rather than just adding a simple call to the V4L2 API). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo: Dropping payload (out of sync)
On Thu, Apr 11, 2013 at 3:56 AM, André Weidemann andre.weidem...@web.de wrote: For anyone who may also run into this problem here is a solution... It seems the problem is hardware related to the Raspberry Pi. The solution can be found here: https://github.com/raspberrypi/linux/issues/238 https://github.com/P33M/linux Yup, it's been known for a while that the USB host controller on the Raspberry Pi is absolute crap. For all the great things about the Pi, I would probably consider this it's biggest weakness (it's actually prompted me to *not* use the Pi for several projects where I needed a low-cost Linux platform)... No easy answers here. It just won't be a very good platform for capturing uncompressed video over its USB port. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] mxl5007t: fix buggy register read
On Tue, Apr 9, 2013 at 7:53 PM, Antti Palosaari cr...@iki.fi wrote: Chip uses WRITE + STOP + READ + STOP sequence for I2C register read. Driver was using REPEATED START condition which makes it failing if I2C adapter was implemented correctly. Add use_broken_read_reg_intentionally option to keep old buggy implantation as there is buggy I2C adapter implementation relying that bug... Signed-off-by: Antti Palosaari cr...@iki.fi Hi Antti, The existing code actually looks fine. This is actually how most devices do register reads. Further, it *should* be done in a single call to i2c_transfer() or else you won't hold the lock and you will create a race condition. This sounds more like it's a bug in the i2c master rather than the 5007 driver. Do you have i2c bus traces that clearly show that this was the cause of the issue? If we need to define something as broken behavior, at first glance it looks like the way *you're* proposing is the broken behavior - presumably to work around a bug in the i2c master not properly supporting repeated start. Also, any reason you didn't put Mike into the cc: for this (since he owns the driver)? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] mxl5007t: fix buggy register read
On Tue, Apr 9, 2013 at 8:45 PM, Antti Palosaari cr...@iki.fi wrote: Yes, most devices do that, but not all! MxL5007t has a special register for setting register to read. Look the code and you could see it easily. It was over year ago I fixed it... That sounds kind of insane, but I haven't looked at the datasheets and if Mike Ack'd it, then so be it. Further, it *should* be done in a single call to i2c_transfer() or else you won't hold the lock and you will create a race condition. No. That's why I added new lock. Single i2c_transfer() means all messages are done using repeated START condition. No need to add a new lock to your bridge driver. You can just use __i2c_transfer() and i2c_lock_adapter(state-i2c). That's what they're doing in the drx-k driver for just such cases where they need the lock to span multiple calls to i2c_transfer(). This sounds more like it's a bug in the i2c master rather than the 5007 driver. No. Do you have i2c bus traces that clearly show that this was the cause of the issue? If we need to define something as broken behavior, at first glance it looks like the way *you're* proposing is the broken behavior - presumably to work around a bug in the i2c master not properly supporting repeated start. Yes and no. I made own Cypress FX2 firmware and saw initially that issue then. Also, as you could see looking the following patches I ensured / confirmed issue using two different I2C adapters (AF9015 and AF9035). So I have totally 3 working adapters to prove it (which are broken without that patch)! The whole think sounds screwed up, and without a real i2c trace of the bus we'll never know. That said, I'm not really in a position to dispute it given I don't have any devices with the chip in question. I would suggest renaming the configuration value to something less controversial, such as use_repeated_start_for_reads and avoid using terms like broken where it's not clear that's actually the case. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH] tuner-core fix for au0828 g_tuner bug
On Mon, Mar 25, 2013 at 7:32 AM, Hans Verkuil hverk...@xs4all.nl wrote: This fixes the bug where the au8522 detected a signal and then tuner-core overwrote it with 0 since the xc5000 tuner does not support get_rf_strength. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Nice find. That makes much more sense. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.10] au0828 driver overhaul
On Sun, Mar 24, 2013 at 1:51 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
drivers/media/dvb-frontends/au8522_decoder.c:static int au8522_g_tuner(struct
v4l2_subdev *sd, struct v4l2_tuner *vt)
drivers/media/dvb-frontends/au8522_decoder.c-{
drivers/media/dvb-frontends/au8522_decoder.c- int val = 0;
drivers/media/dvb-frontends/au8522_decoder.c- struct au8522_state *state
= to_state(sd);
drivers/media/dvb-frontends/au8522_decoder.c- u8 lock_status;
drivers/media/dvb-frontends/au8522_decoder.c-
drivers/media/dvb-frontends/au8522_decoder.c- /* Interrogate the decoder
to see if we are getting a real signal */
drivers/media/dvb-frontends/au8522_decoder.c- lock_status =
au8522_readreg(state, 0x00);
drivers/media/dvb-frontends/au8522_decoder.c- if (lock_status == 0xa2)
drivers/media/dvb-frontends/au8522_decoder.c- vt-signal = 0x;
drivers/media/dvb-frontends/au8522_decoder.c- else
drivers/media/dvb-frontends/au8522_decoder.c- vt-signal = 0x00;
drivers/media/dvb-frontends/au8522_decoder.c-
drivers/media/dvb-frontends/au8522_decoder.c- vt-capability |=
drivers/media/dvb-frontends/au8522_decoder.c-
V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_LANG1 |
drivers/media/dvb-frontends/au8522_decoder.c-
V4L2_TUNER_CAP_LANG2 | V4L2_TUNER_CAP_SAP;
drivers/media/dvb-frontends/au8522_decoder.c-
drivers/media/dvb-frontends/au8522_decoder.c- val = V4L2_TUNER_SUB_MONO;
drivers/media/dvb-frontends/au8522_decoder.c- vt-rxsubchans = val;
drivers/media/dvb-frontends/au8522_decoder.c- vt-audmode =
V4L2_TUNER_MODE_STEREO;
drivers/media/dvb-frontends/au8522_decoder.c- return 0;
As if the i2c gate is on a wrong state, au8522_readreg() won't
work anymore.
Note that au8522_g_tuner function never actually talks to the tuner.
It's handled entirely within the au8522 driver, which is not behind
the gate. The I2C gate is only required if talking to the xc5000, not
the au8522.
There's something else broken here. I suspect it's probably some
artifact of the conversion to the new control framework (if I had to
guess).
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.10] au0828 driver overhaul
On Fri, Mar 22, 2013 at 12:38 PM, Hans Verkuil hverk...@xs4all.nl wrote: It works fine with qv4l2, but there is still a bug causing tvtime to fail. That's caused by commit e58071f024aa337b7ce41682578b33895b024f8b, applied August last year, that broke g_tuner: after that 'signal' would always be 0 and tvtime expects signal to be non-zero for a valid frequency. The signal field is set by the au8522, but g_tuner is only called for the tuner (well, also for au8522 but since the i2c gate is set for the tuner that won't do anything). During your testing, did you bisect the entire media tree or just the au0828/au8522 driver. This discovery is pretty damn surprising since I actively test with tvtime whenever I do any work on that driver. Are you sure something else in the framework didn't change which caused breakage for this driver? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.10] au0828 driver overhaul
On Fri, Mar 22, 2013 at 12:38 PM, Hans Verkuil hverk...@xs4all.nl wrote: It works fine with qv4l2, but there is still a bug causing tvtime to fail. That's caused by commit e58071f024aa337b7ce41682578b33895b024f8b, applied August last year, that broke g_tuner: after that 'signal' would always be 0 and tvtime expects signal to be non-zero for a valid frequency. The signal field is set by the au8522, but g_tuner is only called for the tuner (well, also for au8522 but since the i2c gate is set for the tuner that won't do anything). Wait, are you saying that the G_TUNER call is no longer being routed to the au8522 driver? The signal level has always been set to a nonzero value by au8522 if a signal is present, and thus the state of the i2c gate isn't relevant. This is because the xc5000 driver didn't actually have implemented a call to return the signal level. If what you're saying is true, then the behavior of the framework itself changed, and who knows what else is broken. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo USERPTR mode busted?
On Thu, Mar 21, 2013 at 8:41 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Please submit it at some point :-) Is it a uvcvideo issue or a videobuf2 issue ? Yeah, it's definitely on my list. Basically if you hand videobuf2-vmalloc a piece of memory that is not page aligned, it gets treated as if paged aligned, which causes the first N bytes of every video frame to be garbage and the video is shifted right by N bytes. I saw the issue with both uvcvideo as well as em28xx. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 11/15] au0828: fix disconnect sequence.
On Wed, Mar 20, 2013 at 3:20 PM, Hans Verkuil hverk...@xs4all.nl wrote: I want to make a pull request for this. Can I have your Acked-by or do you want to look at this some more? I *looked* at all the patches, and they all look fine. That said, I haven't actually installed them at all and seen if anything got broken. The logic is so convoluted that it's entirely possible there is breakage that wouldn't be obvious simply by reviewing the patches without actual testing with real application (and no, v4l-2ctl and v4l2-compliance do *not* count as real applications). Did you try the resulting patches with anything other than v4l2-compliance/v4l2-ctl? tvtime? xawtv? mythtv? Hence, for what it's worth: Reviewed-by: Devin Heitmueller dheitmuel...@kernellabs.com Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB memory leak?
On Fri, Mar 15, 2013 at 11:19 AM, moa...@moasat.dyndns.org wrote: I've been fighting a situation where the kernel appears to be running out of memory over a period of time. I originally had my low address space reserve set to 4096 and memory compaction on. I would get this error within a few days of reboot: Mar 06 19:25:03 [kernel] [168311.801139] DVBRead: page allocation failure: order:4, mode:0xc0d0 Mar 06 19:25:03 [kernel] [168311.801145] Pid: 15153, comm: DVBRead Tainted: G C 3.7.10-gentoo #3 Mar 06 19:25:03 [kernel] [168311.801146] Call Trace: Mar 06 19:25:03 [kernel] [168311.801160] [810e7e3b] warn_alloc_failed+0xeb/0x130 Mar 06 19:25:03 [kernel] [168311.801163] [810eaddd] ? __alloc_pages_direct_compact+0x1ed/0x200 Mar 06 19:25:03 [kernel] [168311.801166] [810eb6ec] __alloc_pages_nodemask+0x8fc/0x9c0 Mar 06 19:25:03 [kernel] [168311.801175] [81598943] ? usb_start_wait_urb+0xa3/0x160 Mar 06 19:25:03 [kernel] [168311.801179] [81121b41] alloc_pages_current+0xb1/0x120 Mar 06 19:25:03 [kernel] [168311.801181] [81597d49] ? usb_alloc_urb+0x19/0x50 Mar 06 19:25:03 [kernel] [168311.801184] [810e6fe9] __get_free_pages+0x9/0x40 Mar 06 19:25:03 [kernel] [168311.801187] [8112752a] kmalloc_order_trace+0x3a/0xb0 Mar 06 19:25:03 [kernel] [168311.801193] [a00c9483] start_urb_transfer+0x83/0x1c0 [au0828] Mar 06 19:25:03 [kernel] [168311.801197] [a00c9698] au0828_dvb_start_feed+0xd8/0x100 [au0828] Mar 06 19:25:03 [kernel] [168311.801201] [8160a6ae] dmx_ts_feed_start_filtering+0x5e/0xf0 Mar 06 19:25:03 [kernel] [168311.801204] [81607a7c] dvb_dmxdev_start_feed.clone.0+0xcc/0x120 Mar 06 19:25:03 [kernel] [168311.801206] [816085ec] dvb_dmxdev_filter_start+0x28c/0x3b0 Mar 06 19:25:03 [kernel] [168311.801209] [81608d8a] dvb_demux_do_ioctl+0x51a/0x6a0 Mar 06 19:25:03 [kernel] [168311.801211] [81606e04] dvb_usercopy+0xa4/0x170 Mar 06 19:25:03 [kernel] [168311.801214] [81608870] ? dvb_demux_open+0x160/0x160 Mar 06 19:25:03 [kernel] [168311.801217] [8110ab5b] ? handle_mm_fault+0x13b/0x210 Mar 06 19:25:03 [kernel] [168311.801221] [8113e344] ? do_filp_open+0x44/0xa0 Mar 06 19:25:03 [kernel] [168311.801224] [81607480] dvb_demux_ioctl+0x10/0x20 Mar 06 19:25:03 [kernel] [168311.801226] [81140026] do_vfs_ioctl+0x96/0x4f0 Mar 06 19:25:03 [kernel] [168311.801230] [81332654] ? inode_has_perm.clone.25.clone.35+0x24/0x30 Mar 06 19:25:03 [kernel] [168311.801233] [81334f40] ? file_has_perm+0x90/0xa0 Mar 06 19:25:03 [kernel] [168311.801236] [81140511] sys_ioctl+0x91/0xa0 Mar 06 19:25:03 [kernel] [168311.801240] [818a9b52] system_call_fastpath+0x16/0x1b Mar 06 19:25:03 [kernel] [168311.801242] Mem-Info: Mar 06 19:25:03 [kernel] [168311.801243] Node 0 DMA per-cpu: Mar 06 19:25:03 [kernel] [168311.801246] CPU0: hi:0, btch: 1 usd:0 Mar 06 19:25:03 [kernel] [168311.801247] CPU1: hi:0, btch: 1 usd:0 Mar 06 19:25:03 [kernel] [168311.801249] CPU2: hi:0, btch: 1 usd:0 Mar 06 19:25:03 [kernel] [168311.801250] CPU3: hi:0, btch: 1 usd:0 Mar 06 19:25:03 [kernel] [168311.801251] Node 0 DMA32 per-cpu: Mar 06 19:25:03 [kernel] [168311.801253] CPU0: hi: 186, btch: 31 usd:0 Mar 06 19:25:03 [kernel] [168311.801255] CPU1: hi: 186, btch: 31 usd:0 Mar 06 19:25:03 [kernel] [168311.801256] CPU2: hi: 186, btch: 31 usd:0 Mar 06 19:25:03 [kernel] [168311.801258] CPU3: hi: 186, btch: 31 usd:0 Mar 06 19:25:03 [kernel] [168311.801259] Node 0 Normal per-cpu: Mar 06 19:25:03 [kernel] [168311.801260] CPU0: hi: 186, btch: 31 usd:0 Mar 06 19:25:03 [kernel] [168311.801262] CPU1: hi: 186, btch: 31 usd:0 Mar 06 19:25:03 [kernel] [168311.801264] CPU2: hi: 186, btch: 31 usd:0 Mar 06 19:25:03 [kernel] [168311.801265] CPU3: hi: 186, btch: 31 usd:0 Mar 06 19:25:03 [kernel] [168311.801269] active_anon:139468 inactive_anon:57451 isolated_anon:0 Mar 06 19:25:03 [kernel] [168311.801269] active_file:375632 inactive_file:366012 isolated_file:0 Mar 06 19:25:03 [kernel] [168311.801269] unevictable:0 dirty:556 writeback:0 unstable:0 Mar 06 19:25:03 [kernel] [168311.801269] free:10993 slab_reclaimable:32206 slab_unreclaimable:6181 Mar 06 19:25:03 [kernel] [168311.801269] mapped:11149 shmem:256 pagetables:2768 bounce:0 Mar 06 19:25:03 [kernel] [168311.801269] free_cma:0 Mar 06 19:25:03 [kernel] [168311.801272] Node 0 DMA free:15904kB min:28kB low:32kB high:40kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15648kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB
Re: DVB memory leak?
On Fri, Mar 15, 2013 at 2:45 PM, Moasat moa...@moasat.dyndns.org wrote: Thanks for looking into it. It wouldn't surprise me to find out that Myth is not checking the error condition. But even if it did, would that keep the card functioning? No, it would not keep the card functioning. But you would at least not get zero length recordings and instead you would get an error that something went wrong and that action was required. The underlying problem of course is the leak - the fact that MythTV doesn't tell you something went wrong just exacerbates the problem. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 11/15] au0828: fix disconnect sequence.
On Mon, Mar 11, 2013 at 5:00 PM, Hans Verkuil hverk...@xs4all.nl wrote: From: Hans Verkuil hans.verk...@cisco.com The driver crashed when the device was disconnected while an application still had a device node open. Fixed by using the release() callback of struct v4l2_device. This is all obviously good stuff. I actually spent a couple of days working through various disconnect scenarios, but hadn't had a chance to do a PULL request. I will review my tree and see if you missed any other cases that I took care of. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] em28xx: add support for two buses on em2874 and upper
2013/3/5 Mauro Carvalho Chehab mche...@redhat.com: The em2874 chips and upper have 2 buses. On all known devices, bus 0 is currently used only by eeprom, and bus 1 for the rest. Add support to register both buses. Did you add a mutex to ensure that both buses cannot be used at the same time? Because using the bus requires you to toggle a register (thus you cannot be using both busses at the same time), you cannot rely on the existing i2c adapter lock anymore. You don't want a situation where something is actively talking on bus 0, and then something else tries to talk on bus 1, flips the register bit and then the thread talking on bus 0 starts failing. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo USERPTR mode busted?
On Sun, Mar 3, 2013 at 4:37 AM, Rémi Denis-Courmont r...@remlab.net wrote: Hello, Trying to use USERPTR buffers with UVC, user space gets stuck either in poll(POLLIN) or in ioctl(VIDIOC_DQBUF). It seems the UVC driver never ever returns a frame in USERPTR mode. The symptoms are identical with kernel versions 3.6, 3.7 and 3.8. I also tested 3.2, but it did not support USERPTR. Tested hardware was Logitech HD Pro Webcam C920 with YUY2 pixel format. The same hardware and the same driver work fine with MMAP buffers. The same USERPTR userspace code works fine with the vivi test device... Did any have any better luck? Hi Remi, I've used userptr mode with the C920 on an ARM platform (with YUYV mode and not MPEG). It's worth noting that there is actually a bug I hit where if the memory you pass is not aligned on a page boundary then you will get garbage video. I have a fix or this but haven't submitted it upstream yet. So it should work, aside from the bug I found. Have you tried testing with v42l-ctl's streaming command? That would help identify whether it's something special about your code or whether it's the driver. Don't get me wrong, it's almost certainly a driver issue in either case, but it would help narrow down the issue if you're using v4l2-ctl as that app is really simple and readily available to the driver developers. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 PATCH 00/20] cx231xx: v4l2-compliance fixes
Hi Hans,
On Thu, Feb 7, 2013 at 10:08 AM, Hans Verkuil hverk...@xs4all.nl wrote:
On Tue January 29 2013 17:41:29 Devin Heitmueller wrote:
On Tue, Jan 29, 2013 at 11:32 AM, Hans Verkuil hverk...@xs4all.nl wrote:
I will take a closer look at the vbi support, though.. It would be nice to
get
that working.
FYI: I had the VBI support working when I submitted the driver
upstream (at least for NTSC CC). If it doesn't work, then somebody
broke it.
OK, I did some more tests and it turned out to be related to the no_alt_vanc
setting in the board definitions. If it is 1, then usb_set_interface() is
never called and the endpoint is never created.
It's unclear to me if this means that if no_alt_vanc is set, then the vbi node
should be disabled. It seems that way.
Unfortunately, of the three cx231xx devices I have no_alt_vanc is set on two
and the third (Hauppauge EXETER) is the one where the tda18271 tuner has
issues: it always gets errors when writing to it. It used to load correctly
about 10% of the time in the past, but now I can't get it to work at all.
Devin, I think you said once that you knew what is going on. Do you have
any code that I can try to make it work again?
The following will cause the tuner to initialize properly.
Unfortunately it's only half a fix because it results in the digital
demod driving the AGC, which will conflict the AGC being driven by the
Polaris when in analog mode.
Still, it should be enough to allow you to play with the VBI support
assuming you test with the baseband inputs.
Devin
--- cx231xx-avcore.c.orig 2013-01-17 11:47:40.0 -0500
+++ cx231xx-avcore.c2013-01-24 09:02:25.833076332 -0500
@@ -2207,6 +2207,7 @@
u8 value[4] = { 0, 0, 0, 0 };
u32 tmp = 0;
int status = 0;
+ int demod_reset_high = 0;
if (dev-power_mode != mode)
dev-power_mode = mode;
@@ -2406,9 +2407,25 @@
msleep(PWR_SLEEP_INTERVAL);
+ /* For Hauppauge devices based on the ldgt3305, the 3305 will hold SDA
+ low from powerup until 10ms after the device is brought out of reset.
+ As a result, we need to *always* bring the device out of reset if
+ PWR_TUNER_EN is enabled (since we have a shared power plane for both
+ the tuner and demod). If you fail to bring the chip out of reset
+ *and* wait 10ms, the i2c bus will get jammed. This is a vendor
+ documented limitation of the lgdt3305 demodulator */
+ if ((tmp PWR_TUNER_EN)
+ (dev-model == CX231XX_BOARD_HAUPPAUGE_EXETER)) {
+ demod_reset_high = 1;
+ }
+
/* For power saving, only enable Pwr_resetout_n
when digital TV is selected. */
if (mode == POLARIS_AVMODE_DIGITAL) {
+ demod_reset_high = 1;
+ }
+
+ if (demod_reset_high) {
tmp |= PWR_RESETOUT_EN;
value[0] = (u8) tmp;
value[1] = (u8) (tmp 8);
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replacement for vloopback?
On Wed, Feb 6, 2013 at 9:42 AM, Neuer User auslands...@gmx.de wrote: If it is not possible to have two applications access the same video stream, that is pretty detrimentical to quite a lot of use cases, e.g.: a.) Use motion to detect motion and record video. At the same time view the camera output on the screen. b.) Stream a webcam output over the net and at the same time view it on the screen. FWIW: usually when people ask for this sort of functionality (performing multiple functions on the same stream), they will typically use frameworks like gstreamer, which allow for creation of pipelines to perform the sorts of use cases you have described. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WinTV-HVR-1400: scandvb (and kaffeine) fails to find any channels
On Fri, Feb 1, 2013 at 9:16 AM, Chris Clayton chris2...@googlemail.com wrote: I've got some more diagnostics. I tuned on the 12c debugging in the cx23885 driver and ran the scan again. Surprisingly, the scan found 22 channels on a single frequency (that carries the BBC channels). I've attached two files - the output from dvbscan and the kernel log covering the loading of the drivers and running the scan. I'm no kernel guru, but is it possible that the root cause of the scan failures is a timing problem which is being partially offset by the time taken to produce all the debug output? w_scan does have some arguments that let you increase the timeout for tuning. You may wish to see if that has any effect. Maybe the w_scan timeout is just too short for that device. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WinTV-HVR-1400: scandvb (and kaffeine) fails to find any channels
On Fri, Feb 1, 2013 at 4:03 PM, Chris Clayton chris2...@googlemail.com wrote: Yes, I noticed that but even with the tuning timeout set at medium or longest, I doesn't find any channels. However, I've been following the debug messages through the code and ended up at drivers/media/pci/cx23885/cx23885-i2c.c. I've found that by amending I2C_WAIT_DELAY from 32 to 64, I get improved results from scanning. With that delay doubled, scandvb now finds 49 channels over 3 frequencies. That's with all debugging turned off, so no extra delays provided by the production of debug messages. I'll play around more tomorrow and update then. It could be that the cx23885 driver doesn't properly implement I2C clock stretching, which is something you don't encounter on most tuners but is an issue when communicating with the Xceive parts. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WinTV-HVR-1400: scandvb (and kaffeine) fails to find any channels
On Thu, Jan 31, 2013 at 11:21 AM, Chris Clayton chris2...@googlemail.com wrote: Hi. On linuxtv.org, the Hauppauge WinTV-HVR-1400 is listed as being supported. I've bought one, but I find that when I run the scan for dvb-t channels, none are found. I have tried kernels 2.6.11, 2.7.5 and 3.8.0-rc5+ (pulled from Linus' tree today) I know the aerial and cable are OK because, using the same cable, scanning with an internal PCI dvb-t card in a desktop computer finds 117 TV and radio channels. I know the HVR-1400 expresscard is OK because, again using the same cable, on Windows 7 the Hauppauge TV viewing application also finds all those channels. Try the patch described in this email sent last week: http://www.mail-archive.com/linux-media@vger.kernel.org/msg57577.html There's a very good chance you have the same problem. 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
