Re: em28xx: board id [eb1a:2863 eMPIA Technology, Inc] Silver Crest VG2000 USB 2.0 Video Grabber
On Wed, Feb 9, 2011 at 5:36 PM, Martin Seekatz mar...@pibbs.de wrote: Hello Devin, I mean that list http://www.kernel.org/doc/Documentation/video4linux/CARDLIST.em28xx It actually is there: 29 - EM2860/TVP5150 Reference Design If the vendor did not build the hardware with its own unique USB ID (because they were lazy), the best we can do is refer to it by the above name (since we would not be able to distinguish between the Silvercrest and all the other clones). 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: em28xx: board id [eb1a:2863 eMPIA Technology, Inc] Silver Crest VG2000 USB 2.0 Video Grabber
On Wed, Feb 9, 2011 at 6:06 PM, Martin Seekatz mar...@pibbs.de wrote: Am Mittwoch 09 Februar 2011 schrieb Devin Heitmueller: On Wed, Feb 9, 2011 at 5:36 PM, Martin Seekatz mar...@pibbs.de wrote: Hello Devin, I mean that list http://www.kernel.org/doc/Documentation/video4linux/CARDLIST.em28 xx It actually is there: 29 - EM2860/TVP5150 Reference Design Yes, but the list refers to 1 - Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2710,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2862,eb1a:2863,eb1a:2870,eb1a:2881,eb1a:2883,eb1a:2868] because of the usb-id: eb1a:2863 If the vendor did not build the hardware with its own unique USB ID (because they were lazy), the best we can do is refer to it by the above name (since we would not be able to distinguish between the Silvercrest and all the other clones). For me it seams that this usb-id is unique. eb1a:2863 is the chipset vendor's default USB ID. All reference designs which use that chip will have that ID. And because the driver needs to do additional analysis of the hardware to figure out which design it is (it probes for other chips in the device), the static table provided in the text file cannot be specific enough. 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: em28xx: board id [eb1a:2863 eMPIA Technology, Inc] Silver Crest VG2000 USB 2.0 Video Grabber
On Tue, Feb 8, 2011 at 5:05 PM, Martin Seekatz mar...@pibbs.de wrote: The vbi0 device is not working: ERROR: Couldn't attach to DCOP server! [0x10713a0] v4l2 demux error: device does not support mmap i/o [0x10713a0] v4l2 demux error: device does not support mmap i/o [0x1270260] v4l2 access error: device does not support mmap i/o [0x1270260] v4l2 access error: device does not support mmap i/o [0x7f91d000d660] main input error: open of `v4l2:///dev/vbi0' failed: (null) VLC doesn't support VBI for any device (I have patches for VLC to add the support, but they have not been submitted upstream yet). The audio device must be explicitly selected to watch video together with sound. Correct. This is how all V4L2 devices work. The snapshot buttom shows no effect on operating. The snapshot button typically creates an input event associated with KEY_CAMERA. Your application has to explicitly support it in order for it to be used. Other video applications as motv show the video graphic, but without sound. This is not surprising. Most of the older analog tv applications were designed to have an audio output cable connecting the capture device to speakers, such that the audio is not routed through the PC. I hope it helps to enhance the drivers for better support of this products, or to advice me how to handle it with the actual sytem. 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 RESEND] Fix bug in au0828 VBI streaming
On Wed, Feb 2, 2011 at 8:58 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sun, Jan 23, 2011 at 5:12 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Attached is a patch for a V4L2 spec violation with regards to the au0828 not working in streaming mode. This was just an oversight on my part when I did the original VBI support for this bridge, as libzvbi was silently falling back to using the read() interface. Mauro, Where are we at with this patch. It's trivial and VBI is broken in V4L2 streaming mode without it. Mauro, I see this has been committed for 2.6.39. Given the trivial nature, can we get it in there for 2.6.38 as well? It's a bugfix and the au0828 VBI support is new to 2.6.38. If it doesn't go in, then the VBI support will be present but broken for a full release cycle. This could definitely cause problems for existing applications that now detect the presence of VBI support, but then break when they try to use 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: [RFC PATCH] tuner-core: fix broken G_TUNER call when tuner is in standby
On Wed, Feb 2, 2011 at 10:21 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 23-01-2011 20:22, Devin Heitmueller escreveu:
Hello all,
The following patch addresses a V4L2 specification violation where the
G_TUNER call would return complete garbage in the event that the tuner
is asleep. Per Hans' suggestion, I have split out the tuner
operational mode from whether it is in standby, and fixed the G_TUNER
call to return as much as possible when the tuner is in standby.
Without this change, products that have tuners which support standby
mode cannot be tuned from within VLC.
I recognize that changes to tuner-core tend to be pretty hairy, so I
welcome suggestions/feedback on this patch.
Regards,
Devin
-- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com
tuner_standby_mode.patch
tuner-core: fix broken G_TUNER call when tuner is in standby
From: Devin Heitmueller dheitmuel...@kernellabs.com
The logic for determining the supported device modes was combined with the
logic which dictates whether the tuner was asleep. This resulted in calls
such as G_TUNER returning complete garbage in the event that the tuner was
in standby mode (a violation of the V4L2 specification, and causing VLC to
be broken for such tuners).
This patch reworks the logic so the current tuner mode is maintained
separately
from whether it is in standby (per Hans Verkuil's suggestion). It also
restructures the G_TUNER call such that all the staticly defined information
related to the tuner is returned regardless of whether it is in standby (e.g.
the supported frequency range, etc).
Priority: normal
Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com
Cc: Hans Verkuil hverk...@xs4all.nl
--- media_build/linux/drivers/media/video/tuner-core.c 2010-10-24
19:34:59.0 -0400
+++ media_build_950qfixes//linux/drivers/media/video/tuner-core.c
2011-01-23 17:18:22.381107568 -0500
@@ -90,6 +90,7 @@
unsigned int mode;
unsigned int mode_mask; /* Combination of allowable modes */
+ unsigned int in_standby:1;
unsigned int type; /* chip type id */
unsigned int config;
@@ -700,6 +701,7 @@
static inline int set_mode(struct i2c_client *client, struct tuner *t, int
mode, char *cmd)
{
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
+ unsigned int orig_mode = t-mode;
if (mode == t-mode)
return 0;
@@ -709,7 +711,8 @@
if (check_mode(t, cmd) == -EINVAL) {
tuner_dbg(Tuner doesn't support this mode.
Putting tuner to sleep\n);
- t-mode = T_STANDBY;
+ t-mode = orig_mode;
Hmm... as orig_mode = t-mode, this is:
t-mode = t-mode...
This doesn't make sense ;)
Look again. The target mode being switched to is provided as an
argument. So the code preserves the old mode in orig_mode, switches
to the new mode, then calls check_mode() against the new mode. If the
call fails, we reset it back to the mode it was in before the call.
+ t-in_standby = 1;
if (analog_ops-standby)
analog_ops-standby(t-fe);
return -EINVAL;
@@ -769,7 +772,7 @@
if (check_mode(t, s_power) == -EINVAL)
return 0;
- t-mode = T_STANDBY;
+ t-in_standby = 1;
if (analog_ops-standby)
analog_ops-standby(t-fe);
return 0;
@@ -854,47 +857,54 @@
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
struct dvb_tuner_ops *fe_tuner_ops = t-fe.ops.tuner_ops;
- if (check_mode(t, g_tuner) == -EINVAL)
- return 0;
Some of those checks are to allow switching between radio and TV
mode. Had you test to switch between video/radio mode on your tests
(e. g. alternating video streaming on/off with radio tune)?
I don't have any radio supported devices.
switch_v4l2();
+ /* First populate everything that doesn't require talking to the
+ actual hardware */
vt-type = t-mode;
- if (analog_ops-get_afc)
- vt-afc = analog_ops-get_afc(t-fe);
if (t-mode == V4L2_TUNER_ANALOG_TV)
+ {
vt-capability |= V4L2_TUNER_CAP_NORM;
- if (t-mode != V4L2_TUNER_RADIO) {
vt-rangelow = tv_range[0] * 16;
vt-rangehigh = tv_range[1] * 16;
- return 0;
+ } else {
+ /* radio mode */
+ vt-rxsubchans = V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO;
+ vt-capability |= V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO;
+ vt-audmode = t-audmode;
+ vt-rangelow = radio_range[0] * 16000;
+ vt-rangehigh = radio_range[1] * 16000;
}
- /* radio mode */
- vt-rxsubchans =
- V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO;
- if (fe_tuner_ops-get_status) {
- u32 tuner_status
[PATCH RESEND] Fix bug in au0828 VBI streaming
On Sun, Jan 23, 2011 at 5:12 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Attached is a patch for a V4L2 spec violation with regards to the au0828 not working in streaming mode. This was just an oversight on my part when I did the original VBI support for this bridge, as libzvbi was silently falling back to using the read() interface. Mauro, Where are we at with this patch. It's trivial and VBI is broken in V4L2 streaming mode without 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 v2] video/saa7164: Fix sparse warning: Using plain integer as NULL pointer
On Sun, Jan 30, 2011 at 2:33 PM, Peter Huewe peterhu...@gmx.de wrote:
From: Peter Huewe peterhu...@gmx.de
This patch fixes the warning Using plain integer as NULL pointer,
generated by sparse, by replacing
if(var == 0)
with
if (!var)
after an allocation
and all other offending 0s with NULL.
KernelVersion: linus' tree-1f0324c
Signed-off-by: Peter Huewe peterhu...@gmx.de
---
v2: I changed the patch according to Julia's hints.
i.e. using if(!buf) instead of if(buf==NULL) after the kmalloc family,
and other allocations.
Ok, so now we've gone from eliminating a couple of sparse warnings
to going through the rest of the code and jamming in some alternate
coding style when there was nothing wrong with it in the first place.
Don't get me wrong, I appreciate the role of the kernel janitors in
general, but this patch is crap. It's changes like this that just
lower the signal/noise ratio on *real* work going on, and increasing
the likelihood that some well intentioned janitor screwed up one of
the conversions.
After all, it's not like the author of this patch actually tried the
resulting code. He only has to mess up one of those two line changes
and we go from driver that works perfectly well to driver that is
100% broken.
There are much better uses of the maintainer's time than going through
patches like this to make sure the submitter didn't screw up the a
conversion that provides no real value.
A change like this:
- if (buf == NULL) {
+ if (!buf) {
is a worthless change, and there is is a higher chance that one of
them gets screwed up in the patch than what we had to start with.
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: HVR1255 svideo
On Sat, Jan 29, 2011 at 1:53 PM, Jon Goldberg jond...@gmail.com wrote: Hi I've been trying to get the Svideo input on my HVR-1255 working. From the latest code in cx23885-cards.c, it seems that only DVB is supported. I have some experience writing Linux Kernel/Drivers so I'm determined to get this working. I copied the cx23885_boards[CX23885_BOARD_HAUPPAUGE_HVR1250] settings and did get the V4L layer connected enough to get a /dev/video0, albeit with only green video and no picture. I then realized that was probably a dumb thing to do (possibly damaging the GPIO), since the eeprom is clearly different based on what I saw in tveeprom.c. My question is, am I going down the right path to add this support? Should I go ahead and install Windows (sigh) and get the output from RegSpy? Are there any developer git trees that are focused on this area? Steven did a bunch of analog work on the cx23885, although I do not believe he brought up the 1255 specifically. I would definitely look at his tree as a starting point (if for no other reason than he's the cx23885 maintainer and will have to ACK any patches you send): https://www.kernellabs.com/hg/~stoth/cx23885-mpx/ 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: What to do with videodev.h
On Wed, Jan 26, 2011 at 6:36 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: We should touch the tools that we care of. Maybe Devin could change tvtime, we should remove V4L1 driver from xawtv3/xawtv4. Yeah, I have some tvtime work planned, and dropping v4l1 was definitely on the list. I actually dropped the private versions of videodev.h/videodev2.h from my repo, so I won't have much choice. 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: Is media_build download broken?
On Wed, Jan 26, 2011 at 9:38 AM, Jarod Wilson ja...@wilsonet.com wrote: Seems that an explicit 'pull over ssh' command was recently added to media_build, which only works if you've got a shell account on linuxtv.org. I'll ask Mauro about it and/or just fix it. He should just have to do git:// instead of ssh:// git pull git://linuxtv.org/git/media_build master 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] video/cx231xx: Fix sparse warning: Using plain integer as NULL pointer
On 01/25/2011 03:38 PM, Peter Huewe wrote:
This patch fixes the warning Using plain integer as NULL pointer,
generated by sparse, by replacing the offending 0s with NULL.
KernelVersion: linus' tree-c723fdab
Signed-off-by: Peter Huewe peterhu...@gmx.de
---
drivers/media/video/cx231xx/cx231xx-417.c |4 ++--
drivers/media/video/cx231xx/cx231xx-cards.c | 16
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/media/video/cx231xx/cx231xx-417.c
b/drivers/media/video/cx231xx/cx231xx-417.c
index fc9526a..f8f0e59 100644
--- a/drivers/media/video/cx231xx/cx231xx-417.c
+++ b/drivers/media/video/cx231xx/cx231xx-417.c
@@ -942,13 +942,13 @@ static int cx231xx_load_firmware(struct cx231xx
*dev)
p_current_fw = vmalloc(1884180 * 4);
p_fw = p_current_fw;
- if (p_current_fw == 0) {
+ if (p_current_fw == NULL) {
dprintk(2, FAIL!!!\n);
return -1;
}
p_buffer = vmalloc(4096);
- if (p_buffer == 0) {
+ if (p_buffer == NULL) {
dprintk(2, FAIL!!!\n);
return -1;
}
diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c
b/drivers/media/video/cx231xx/cx231xx-cards.c
index 588f3e8..5b9b5f4 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -357,19 +357,19 @@ struct cx231xx_board cx231xx_boards[] = {
.type = CX231XX_VMUX_TELEVISION,
.vmux = CX231XX_VIN_3_1,
.amux = CX231XX_AMUX_VIDEO,
- .gpio = 0,
+ .gpio = NULL,
}, {
.type = CX231XX_VMUX_COMPOSITE1,
.vmux = CX231XX_VIN_2_1,
.amux = CX231XX_AMUX_LINE_IN,
- .gpio = 0,
+ .gpio = NULL,
}, {
.type = CX231XX_VMUX_SVIDEO,
.vmux = CX231XX_VIN_1_1 |
(CX231XX_VIN_1_2 8) |
CX25840_SVIDEO_ON,
.amux = CX231XX_AMUX_LINE_IN,
- .gpio = 0,
+ .gpio = NULL,
} },
},
[CX231XX_BOARD_HAUPPAUGE_USBLIVE2] = {
@@ -386,14 +386,14 @@ struct cx231xx_board cx231xx_boards[] = {
.type = CX231XX_VMUX_COMPOSITE1,
.vmux = CX231XX_VIN_2_1,
.amux = CX231XX_AMUX_LINE_IN,
- .gpio = 0,
+ .gpio = NULL,
}, {
.type = CX231XX_VMUX_SVIDEO,
.vmux = CX231XX_VIN_1_1 |
(CX231XX_VIN_1_2 8) |
CX25840_SVIDEO_ON,
.amux = CX231XX_AMUX_LINE_IN,
- .gpio = 0,
+ .gpio = NULL,
} },
},
[CX231XX_BOARD_PV_PLAYTV_USB_HYBRID] = {
@@ -420,19 +420,19 @@ struct cx231xx_board cx231xx_boards[] = {
.type = CX231XX_VMUX_TELEVISION,
.vmux = CX231XX_VIN_3_1,
.amux = CX231XX_AMUX_VIDEO,
- .gpio = 0,
+ .gpio = NULL,
}, {
.type = CX231XX_VMUX_COMPOSITE1,
.vmux = CX231XX_VIN_2_1,
.amux = CX231XX_AMUX_LINE_IN,
- .gpio = 0,
+ .gpio = NULL,
}, {
.type = CX231XX_VMUX_SVIDEO,
.vmux = CX231XX_VIN_1_1 |
(CX231XX_VIN_1_2 8) |
CX25840_SVIDEO_ON,
.amux = CX231XX_AMUX_LINE_IN,
- .gpio = 0,
+ .gpio = NULL,
} },
},
};
--
1.7.2.2
Reviewed-by: Devin Heitmueller dheitmuel...@hauppauge.com
--
Devin Heitmueller
Senior Software Engineer
Hauppauge Computer Works
--
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] video/saa7164: Fix sparse warning: Using plain integer as NULL pointer
On Tue, Jan 25, 2011 at 5:54 PM, Peter Hüwe peterhu...@gmx.de wrote:
Hi Julia,
thanks for your input.
So do I understand you correctly if I say
if(!x) is better than if(x==NULL) in any case?
Or only for the kmalloc family?
Do you remember the reason why !x should be preferred?
In Documentation/CodingStyle , Chapter 7: Centralized exiting of functions
there is a function fun with looks like this:
int fun(int a)
{
int result = 0;
char *buffer = kmalloc(SIZE);
if (buffer == NULL)
return -ENOMEM;
if (condition1) {
while (loop1) {
...
}
result = 1;
goto out;
}
...
out:
kfree(buffer);
return result;
}
-- So if (buffer == NULL) is in the official CodingStyle - maybe we should
add a paragraph there as well ;)
Don't get me wrong, I just want to learn ;)
To my knowledge, the current CodingStyle doesn't enforce a particular
standard in this regard, leaving it at the discretion of the author.
Whether to do (!foo) or (foo == NULL) is one of those debates people
have similar to whether to use tabs as whitespace. People have
differing opinions and there is no clearly right answer. Personally
I strongly prefer (foo == NULL) as it makes it blindingly obvious that
it's a pointer comparison, whereas (!foo) leaves you wondering whether
it's an integer or pointer comparison.
All that said, you shouldn't submit patches which arbitrarily change
from one format to the other. With regards to the proposed patch, you
should follow whatever style the author employed in the rest of the
file.
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: DVB driver for TerraTec H7 - how do I install them?
On Tue, Jan 25, 2011 at 6:29 PM, Torfinn Ingolfsen tin...@gmail.com wrote: Anybody? If Terratec provided the driver, any support related questions should be directed to them, not to this list. 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: DViCO FusionHDTV7 Dual Express I2C write failed
On Mon, Jan 24, 2011 at 10:49 AM, Mark Zimmerman markz...@frii.com wrote: From looking at the code and a dump of the firmware file, the first i2c write would have a length of 3; so this error: xc5000: I2C write failed (len=3) tells me that there were probably no successful i2c transactions on this device. The i2c write call looks the same as that in other drivers, so I wonder if there is an initialization step that is now necessary but which is missing. Still hoping for suggestions... My guess would be that somebody screwed up either the GPIO config int the cx88 board profile, or the i2c gate, which is resulting in not being able to reach the tuner at all. Do you have an oscilloscope? If so, I bet you will find that the xc5000 pin is being held in reset. I would probably take a hard look at the board profile in cx88-cards.c as well as whether there have been any changes to the GPIO setup and power management code. 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 Nova-T-500; losing one tuner. Regression?
Hi Alex, As a refresher, the drivers in the 2.6.26.6-49 kernel didn't yet include support for the new I2C functions only supported by dib0700 firmware revisions = 1.20. I don't think this is relevant to the Nova-T-500, though, as only s5h1411_frontend_attach() and lgdt3305_frontend_attach() set fw_use_new_i2c_api to 1. There were general fixes to the i2c in the 1.20 firmware which you get the benefits of regardless of using the new API. The new API is required though for devices that perform i2c writes without a corresponding read (e.g. the s5h1411 and lgdt3305). In fact, most Nova-T 500 users noted a significant improvement in the general reliability of the mt2060 i2c after upgrading to 1.20 (with the exception of the warm boot problem). My old MythTV system worked perfectly for months at a time (i.e. between AC power failures!) and once I got a stable configuration for the Nova-T-500 card, I never had failed recordings due to losing a tuner. However, despite recreating the same config on the new hardware, I seem to be experiencing the old problems with one of the tuners on the Nova-T-500 ceasing to respond randomly many hours after boot, resulting in failed MythTV recordings. Both the tuners work immediately after the system is booted, however. When one Nova-T-500 tuner has stopped responding the other is able to record perfectly, suggesting that there isn't a signal strength or cabling problem. Tweaks I used on my old MythTV box, that I've carried forward to the upgraded system: 1) Boot kernel with usbcore.autosuspend=-1 to disable suspending of USB devices (i.e. the two USB tuners behind the VIA USB/PCI bridge on the Nova-T-500 PCI card) This shouldn't have any effect, but was a good idea to test. 2) Load the dvb_usb kernel module with disable_rc_polling=1 to disable the IR port on the Nova-T-500. I only use the IR port on the Nova-T, so I can live with this. The RC polling issue was initially a problem after I introduced the 1.20 firmware support, but was fixed in a later version of the driver (over a year ago). Therefore, setting disable_rc_polling is no longer required. 3) Load the dvb-usb-dib0700 module with force_lna_activation=1 to have the LNA permanently enabled. People have mixed results with the LNA, largely dependent on their signal quality in general, as would be expected. I believe most people who have had to force it's activation have general signal quality issues which have nothing to do with the mt2060 i2c issue. 5) Use the 1.20 firmware (MD5: f42f86e2971fd994003186a055813237) file and ensure it's being properly loaded. That is the correct firmware, It's bundled by default in Ubuntu now, and I thought Fedora was too (since I submitted it to the linux-firmware package). I've also tried the 1.10 firmware (MD5: 5878ebfcba2d8deb90b9120eb89b02da) with no apparent improvement. Well, *this* is very strange. It suggests your problem has nothing to do with the new firmware at all. Have you tried blowing the dust out the PCI slots and making sure the PCI connectors are clean? 6) Ensure that the machine is cold-booted (thereby forcing a firmware load onto the Nova-T-500) every time due to reports of warm boots being problematic. Correct: This is the one known issue with the 1.20 firmware, specifically on the Nova-T 500. It has to do with the power routing on that board compared to all other dib0700 based designs. 7) Disable EIT scanning by MythTV on both of the two Nova-T-500 tuners. Only leave it enabled on the Nova-T card. This is a good idea. I've heard mixed results from users where this has an effect, although I've never seen it personally. 8) MythTV is configured to open all the tuner devices when mythbackend starts and keep them open until mythbackend terminates (i.e. dvb_on_demand=0), rather than repeated opening and closing of the tuner devices which has also been reported as problematic for some. 9) MythTV signal_timeout=500, channel_timeout=3000, dvb_tuning_delay=0 (defaults), but I've tried increasing those to 3000, 4000 and 400 respectively, as per http://www.knoppmythwiki.org/index.php?page=NovaT500 with no apparent improvement. 10) MythTV multirec enabled, configured with 2 virtual tuners per physical tuner. 11) I briefly experimented with setting buggy_sfn_workaround=1 when loading the dib3000mc and dib7000p modules with no apparent improvement. As far as I can see, though, UK DVB-T broadcasting isn't a single frequency network, so a) this is not relevant here and b) it will impair performace. As a result, I'm NOT using the buggy_sfn_workaround. I've got debug=1 set for the mt2060, dib3000mc and dib7000p modules, debug=127 for dvb_usb and debug=7 for dvb-usb-dib0700, but I'm not seeing anything obviously bad in my kernel syslog. I've got mythbackend running with -v important,record but all that seems to report is no progress on failed recordings after TVRec(_): Successfully set up DVB
[PATCH] Fix bug in au0828 VBI streaming
Attached is a patch for a V4L2 spec violation with regards to the
au0828 not working in streaming mode.
This was just an oversight on my part when I did the original VBI
support for this bridge, as libzvbi was silently falling back to using
the read() interface.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
au0828: fix VBI handling when in V4L2 streaming mode
From: Devin Heitmueller dheitmuel...@kernellabs.com
It turns up V4L2 streaming mode (a.k.a mmap) was broken for VBI streaming.
This was causing libzvbi to fall back to V4L1 capture mode, and is a blatent
violation of the V4L2 specification.
Make the implementation work properly in this mode.
Priority: high
Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com
--- media_build/linux/drivers/media/video/au0828/au0828-video.c 2011-01-10 10:24:45.0 -0500
+++ media_build_950qfixes//linux/drivers/media/video/au0828/au0828-video.c 2011-01-23 17:05:08.461107569 -0500
@@ -1758,7 +1758,12 @@
if (rc 0)
return rc;
- return videobuf_reqbufs(fh-vb_vidq, rb);
+ if (fh-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ rc = videobuf_reqbufs(fh-vb_vidq, rb);
+ else if (fh-type == V4L2_BUF_TYPE_VBI_CAPTURE)
+ rc = videobuf_reqbufs(fh-vb_vbiq, rb);
+
+ return rc;
}
static int vidioc_querybuf(struct file *file, void *priv,
@@ -1772,7 +1777,12 @@
if (rc 0)
return rc;
- return videobuf_querybuf(fh-vb_vidq, b);
+ if (fh-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ rc = videobuf_querybuf(fh-vb_vidq, b);
+ else if (fh-type == V4L2_BUF_TYPE_VBI_CAPTURE)
+ rc = videobuf_querybuf(fh-vb_vbiq, b);
+
+ return rc;
}
static int vidioc_qbuf(struct file *file, void *priv, struct v4l2_buffer *b)
@@ -1785,7 +1795,12 @@
if (rc 0)
return rc;
- return videobuf_qbuf(fh-vb_vidq, b);
+ if (fh-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ rc = videobuf_qbuf(fh-vb_vidq, b);
+ else if (fh-type == V4L2_BUF_TYPE_VBI_CAPTURE)
+ rc = videobuf_qbuf(fh-vb_vbiq, b);
+
+ return rc;
}
static int vidioc_dqbuf(struct file *file, void *priv, struct v4l2_buffer *b)
@@ -1806,7 +1821,12 @@
dev-greenscreen_detected = 0;
}
- return videobuf_dqbuf(fh-vb_vidq, b, file-f_flags O_NONBLOCK);
+ if (fh-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ rc = videobuf_dqbuf(fh-vb_vidq, b, file-f_flags O_NONBLOCK);
+ else if (fh-type == V4L2_BUF_TYPE_VBI_CAPTURE)
+ rc = videobuf_dqbuf(fh-vb_vbiq, b, file-f_flags O_NONBLOCK);
+
+ return rc;
}
static struct v4l2_file_operations au0828_v4l_fops = {
[RFC PATCH] tuner-core: fix broken G_TUNER call when tuner is in standby
Hello all,
The following patch addresses a V4L2 specification violation where the
G_TUNER call would return complete garbage in the event that the tuner
is asleep. Per Hans' suggestion, I have split out the tuner
operational mode from whether it is in standby, and fixed the G_TUNER
call to return as much as possible when the tuner is in standby.
Without this change, products that have tuners which support standby
mode cannot be tuned from within VLC.
I recognize that changes to tuner-core tend to be pretty hairy, so I
welcome suggestions/feedback on this patch.
Regards,
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
tuner-core: fix broken G_TUNER call when tuner is in standby
From: Devin Heitmueller dheitmuel...@kernellabs.com
The logic for determining the supported device modes was combined with the
logic which dictates whether the tuner was asleep. This resulted in calls
such as G_TUNER returning complete garbage in the event that the tuner was
in standby mode (a violation of the V4L2 specification, and causing VLC to
be broken for such tuners).
This patch reworks the logic so the current tuner mode is maintained separately
from whether it is in standby (per Hans Verkuil's suggestion). It also
restructures the G_TUNER call such that all the staticly defined information
related to the tuner is returned regardless of whether it is in standby (e.g.
the supported frequency range, etc).
Priority: normal
Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com
Cc: Hans Verkuil hverk...@xs4all.nl
--- media_build/linux/drivers/media/video/tuner-core.c 2010-10-24 19:34:59.0 -0400
+++ media_build_950qfixes//linux/drivers/media/video/tuner-core.c 2011-01-23 17:18:22.381107568 -0500
@@ -90,6 +90,7 @@
unsigned intmode;
unsigned intmode_mask; /* Combination of allowable modes */
+ unsigned intin_standby:1;
unsigned inttype; /* chip type id */
unsigned intconfig;
@@ -700,6 +701,7 @@
static inline int set_mode(struct i2c_client *client, struct tuner *t, int mode, char *cmd)
{
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
+ unsigned int orig_mode = t-mode;
if (mode == t-mode)
return 0;
@@ -709,7 +711,8 @@
if (check_mode(t, cmd) == -EINVAL) {
tuner_dbg(Tuner doesn't support this mode.
Putting tuner to sleep\n);
- t-mode = T_STANDBY;
+ t-mode = orig_mode;
+ t-in_standby = 1;
if (analog_ops-standby)
analog_ops-standby(t-fe);
return -EINVAL;
@@ -769,7 +772,7 @@
if (check_mode(t, s_power) == -EINVAL)
return 0;
- t-mode = T_STANDBY;
+ t-in_standby = 1;
if (analog_ops-standby)
analog_ops-standby(t-fe);
return 0;
@@ -854,47 +857,54 @@
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
struct dvb_tuner_ops *fe_tuner_ops = t-fe.ops.tuner_ops;
- if (check_mode(t, g_tuner) == -EINVAL)
- return 0;
switch_v4l2();
+ /* First populate everything that doesn't require talking to the
+ actual hardware */
vt-type = t-mode;
- if (analog_ops-get_afc)
- vt-afc = analog_ops-get_afc(t-fe);
if (t-mode == V4L2_TUNER_ANALOG_TV)
+ {
vt-capability |= V4L2_TUNER_CAP_NORM;
- if (t-mode != V4L2_TUNER_RADIO) {
vt-rangelow = tv_range[0] * 16;
vt-rangehigh = tv_range[1] * 16;
- return 0;
+ } else {
+ /* radio mode */
+ vt-rxsubchans = V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO;
+ vt-capability |= V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO;
+ vt-audmode = t-audmode;
+ vt-rangelow = radio_range[0] * 16000;
+ vt-rangehigh = radio_range[1] * 16000;
}
- /* radio mode */
- vt-rxsubchans =
- V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO;
- if (fe_tuner_ops-get_status) {
- u32 tuner_status;
+ /* If the hardware is in sleep mode, bail out at this point */
+ if (t-in_standby)
+ return 0;
- fe_tuner_ops-get_status(t-fe, tuner_status);
- vt-rxsubchans =
- (tuner_status TUNER_STATUS_STEREO) ?
- V4L2_TUNER_SUB_STEREO :
- V4L2_TUNER_SUB_MONO;
+ /* Now populate the fields that requires the hardware to be alive */
+ if (t-mode == V4L2_TUNER_ANALOG_TV) {
+ if (analog_ops-get_afc)
+ vt-afc = analog_ops-get_afc(t-fe);
} else {
- if (analog_ops-is_stereo) {
+ if (fe_tuner_ops-get_status) {
+ u32 tuner_status;
+
+ fe_tuner_ops-get_status(t-fe, tuner_status);
vt-rxsubchans =
-analog_ops-is_stereo(t-fe) ?
+(tuner_status TUNER_STATUS_STEREO) ?
V4L2_TUNER_SUB_STEREO :
V4L2_TUNER_SUB_MONO;
+ } else {
+ if (analog_ops-is_stereo) {
+vt-rxsubchans =
+ analog_ops-is_stereo(t-fe) ?
+ V4L2_TUNER_SUB_STEREO :
+ V4L2_TUNER_SUB_MONO;
+ }
}
+ if (analog_ops-has_signal)
+ vt-signal = analog_ops-has_signal(t-fe);
}
- if (analog_ops-has_signal)
- vt-signal = analog_ops-has_signal(t-fe);
- vt-capability |=
- V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO;
- vt-audmode = t-audmode;
- vt-rangelow = radio_range[0] * 16000;
- vt-rangehigh = radio_range[1] * 16000;
+
return 0;
}
@@ -911,6 +921,11 @@
/* do
Re: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Wed, Jan 19, 2011 at 11:08 AM, Jarod Wilson ja...@wilsonet.com wrote: BTW, does your HVR-1950 have a blaster? Yes, it does, looks like a jack identical to the one on the hdpvr, which is good, since I don't have the 1950's blaster cable. Correct - it uses the same cable as the HD-PVR. The IR receiver on that device is built into the front of the unit though, unlike the PCI cards where it's on the cable. 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: DViCO FusionHDTV7 Dual Express I2C write failed
On Wed, Jan 19, 2011 at 10:59 AM, VDR User user@gmail.com wrote: Can someone please look into this and possibly provide a fix for the bug? I'm surprised it hasn't happened yet after all this time but maybe it's been forgotten the bug existed. You shouldn't be too surprised. In many cases device support for more obscure products comes not from the maintainer of the actual driver but rather from some random user who hacked in an additional board profile (in many cases, not doing it correctly but good enough so it works for them). In cases like that, the changes get committed, the original submitter disappears, and then when things break there is nobody with the appropriate knowledge and the hardware to debug 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: [linux-media] API V3 vs SAPI behavior difference in reading tuning parameters
On Fri, Jan 14, 2011 at 8:35 AM, Thierry LELEGARD tleleg...@logiways.com wrote: But there is worse. If I set a wrong parameter in the tuning operation, for instance guard interval 1/32, the API V3 returns the correct value which is actually used by the tuner (GUARD_INTERVAL_1_8), while S2API returns the cached value which was set while tuning (GUARD_INTERVAL_1_32). This is actually a bad thing. If you specify the wrong parameter and it still works, then that can lead to all sort of misleading behavior. For example, imagine the next person who submits scan results based on using such a driver. It works for him because his driver lied, but the resulting file works for nobody else. If you specify an explicit value incorrectly (not auto) and it still works, that is a driver bug which should be fixed. 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] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
On Thu, Jan 13, 2011 at 8:21 AM, Jean Delvare kh...@linux-fr.org wrote: My bet is that register at 0x00 is a control register, and writing bit 7 (value 0x80) makes the chip busy enough that it can't process I2C requests at the same time. The following naks would be until the chip is operational again. Correct. Poking bit 7 of 0xE0:00 triggers the send for all the bytes that were previously loaded into the device. It puts the chip into a busy state, doing an i2c clock stretch until it is available again. During that time it cannot see any i2c traffic, which is why you are getting NAKs. 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] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
On Thu, Jan 13, 2011 at 11:48 AM, Jean Delvare kh...@linux-fr.org wrote: On Thu, 13 Jan 2011 11:34:42 -0500, Andy Walls wrote: How should clock stretches by slaves be handled using i2c-algo-bit? It is already handled. But hdpvr-i2c doesn't use i2c-algo-bit. I2C support is done with USB commands instead. Maybe the hardware implementation doesn't support clock stretching by slaves. Apparently it doesn't support repeated start conditions either, so it wouldn't surprise me. The hardware implementation does support clock stretching, or else it wouldn't be working under Windows. That said, it's possible that the driver for the i2c master isn't checking the proper bits to detect the clock stretch. I haven't personally looked at the code for the i2c master, so I cannot say one way or the other. The Zilog is a pretty nasty beast, and for various reasons it is especially problematic on the HD-PVR due to some issues I cannot really get into on a public forum. 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: Debug code in HG repositories
On Fri, Jan 7, 2011 at 2:53 PM, Oliver Endriss o.endr...@gmx.de wrote: Hi guys, are you aware that there is a lot of '#if 0' code in the HG repositories which is not in GIT? When drivers were submitted to the kernel from HG, the '#if 0' stuff was stripped, unless it was marked as 'keep'... This was fine, when development was done with HG. As GIT is being used now, that code will be lost, as soon as the HG repositories have been removed... Any opinions how this should be handled? CU Oliver I complained about this months ago. The problem is that when we were using HG, the HG repo was a complete superset of what went into Git (including development/debug code). But now that we use Git, neither is a superset of the other. If you base your changes on Git, you have to add back in all the portability code (and any #if 0 you added as the maintainer for development/debugging). Oh, and regular users cannot test any of your changes because they aren't willing to upgrade their entire kernel. If you base your changes on Hg, nothing merges cleanly when submitted upstream so your patches get rejected. Want to know why we are seeing regressions all over the place? Because *NOBODY* is testing the code until after the kernel goes stable (since while many are willing to install a v4l-dvb tree, very few will are willing to upgrade their entire kernel just to test one driver). We've probably lost about 98% of our user base of testers. Oh, and users have to git clone 500M+ of data, and not everybody in the world has bandwidth fast enough to make that worth their time (it took me several hours last time I did it). Anyway, I've beaten this horse to death and it's fallen on deaf ears. Merge overhead has reached the point where it's just not worth my time/effort to submit anything upstream anymore. 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 with em28xx driver in Gumstix Overo
On Mon, Jan 3, 2011 at 3:13 PM, Linus Torvalds torva...@linux-foundation.org wrote: // if (!dev-progressive) // height = norm_maxh(dev); This would suggest that the device is providing progressive video and there is a mismatch between the board profile and the actual hardware, which is certainly possible but I know absolutely nothing about the product in question. It would be helpful if we could get the output of dmesg for starters, so we can see which board profile is being used. 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
V4L2 spec behavior for G_TUNER and T_STANDBY
I have been doing some application conformance for VLC, and I noticed
something interesting with regards to the G_TUNER call.
If you have a tuner which supports sleeping, making a G_TUNER call
essentially returns garbage.
===
r...@devin-laptop2:~# v4l2-ctl -d /dev/video1 --get-tuner
Tuner:
Name : Auvitek tuner
Capabilities : 62.5 kHz stereo lang1 lang2
Frequency range : 0.0 MHz - 0.0 MHz
Signal strength/AFC : 0%/0
Current audio mode : stereo
Available subchannels: mono
===
Note that the frequency range is zero (the capabilities and name are
populated by the bridge or video decoder). Some digging into the
tuner_g_tuner() function in tuner core shows that the check_mode()
call fails because the device's mode is T_STANDBY. However, it does
this despite the fact that none of values required actually interact
with the tuner. The capabilities and frequency ranges should be able
to be populated regardless of whether the device is in standby.
This is particularly bad because devices normally come out of standby
when a s_freq call occurs, but some applications (such as VLC) will
call g_tuner first to validate the target frequency is inside the
valid frequency range. So you have a chicken/egg problem: The
g_tuner won't return a valid frequency range until you do a tuning
request to wake up the tuner, but apps like VLC won't do a tuning
request unless it has validated the frequency range.
Further, look at the following block:
if (t-mode != V4L2_TUNER_RADIO) {
vt-rangelow = tv_range[0] * 16;
vt-rangehigh = tv_range[1] * 16;
return 0;
}
This basically means that a video tuner will bail out, which sounds
good because the rest of the function supposedly assumes a radio
device. However, as a result the has_signal() call (which returns
signal strength) will never be executed for video tuners. You
wouldn't notice this if a video decoder subdev is responsible for
showing signal strength, but if you're expecting the tuner to provide
the info, the call will never happen.
Are these known issues? Am I misreading the specified behavior? I
don't see anything in the spec that suggests that this call should
return invalid data if the tuner happens to be powered down.
--
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: V4L2 spec behavior for G_TUNER and T_STANDBY
Hi Hans, Thanks for the feedback. On Sat, Jan 1, 2011 at 4:18 PM, Hans Verkuil hverk...@xs4all.nl wrote: This basically means that a video tuner will bail out, which sounds good because the rest of the function supposedly assumes a radio device. However, as a result the has_signal() call (which returns signal strength) will never be executed for video tuners. You wouldn't notice this if a video decoder subdev is responsible for showing signal strength, but if you're expecting the tuner to provide the info, the call will never happen. I am not aware of any tuner that does that. I think that for video this is always done by a video decoder. That said, it isn't pretty, but a lot of this is legacy code and I wouldn't want to change it. The Xceive tuners have their analog demodulator onboard, so they make available a 0-100% signal strength. After digging some more I think that check_mode is a poor function. There are two things that check_mode does: checking if the tuner support radio and/or tv mode (that's fine), and if it is in standby: not so fine. That should be a separate function since filling in frequency ranges can be done regardless of the standby state. Yeah, I didn't realize myself that is what check_mode was doing until I had this problem. I'll see if I can cook up a patch which returns the appropriate data even when in standby, while trying to minimize the risk of introducing a regression. 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: Hauppauge USB Live 2
On Tue, Dec 14, 2010 at 4:57 AM, Gerd Hoffmann kra...@redhat.com wrote: Hi folks, Got a Hauppauge USB Live 2 after google found me that there is a linux driver for it. Unfortunaly linux doesn't manage to initialize the device. I've connected the device to a Thinkpad T60. It runs a 2.6.37-rc5 kernel with the linuxtv/staging/for_v2.6.38 branch merged in. Kernel log and lsusb output are attached. Ideas anyone? Looks like a regression got introduced since I submitted the original support for the device. Mauro? 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] support of GoTView PCI-E X5 3D Hybrid in cx23885
On Sun, Dec 5, 2010 at 12:09 PM, Alexey Chernov 4er...@gmail.com wrote: Hello, Steve, thank you very much for your comments! As for DVB maybe I'm not correct. The initialization itself, which the DVB part of patch is about, is fully tested by me and works successfully on my everyday PC. The thing I meant saying 'untested' concerned receiving DVB signal through the initialized device. So I think I was mistaken that the code itself is untested. I hope it's possible to add full of this patch. Hello Alexey, What I believe Steven is trying to say is the device successfully initializing is not enough to consider the DVB part of the driver to be working. If you have not seen the device receiving digital television, the DVB parts of this patch should not be committed. There are a variety of other reasons why DVB streaming would not work even if the device properly initializes. These can include an improperly configured IF, wrong GPIOs, missing power management code, etc. It is far worse for a user to be led to believe the driver should be working but doesn't then it is for the driver claim to not work with DVB at all. This is how we end up with users wasting hours wondering what is wrong with their MythTV setup when in fact the driver never actually worked in the first place. Find someone to test the DVB parts of the board that it shows DVB streaming. If you cannot do that, remove those parts from the patch until someone can be found who is able to test the functionality. 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: gnutv: What causes DVR overflow?
On Thu, Dec 2, 2010 at 12:46 AM, David Liontooth lionte...@cogweb.net wrote: Thanks, Devin! On my end, it looks like the DVR overflow was caused by the -out file being on a mirrored OS drive; I've moved output to a separate drive and don't see the error any more. If I run into this again, are there ways to make this more robust -- for instance, increase the cache size, either as a parameter to the kernel module, or in gnutv? Hi David, There is an ioctl you can call against the demux filehandle to increase the size of the in-kernel buffer. However I have no idea whether the gnutv application currently plays with this value. I suspect you would probably have to add an ioctl() call to the gnutv source code. http://linuxtv.org/downloads/v4l-dvb-apis/dmx_fcalls.html#dms_set_buffer_size 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: gnutv: What causes DVR overflow?
On Mon, Nov 29, 2010 at 2:54 AM, David Liontooth lionte...@cogweb.net wrote: I'm seeing great results with gnutv on HVR-1850 cards, but each recording triggers the message DVR overflow What is this, and what are the typical causes? What can I do to prevent it from happening? I don't know about gnutv specifically, but I do know that -EOVERFLOW is returned when an application fails to read the /dev/dvb/adapterX/dvr0 device fast enough. It's the driver signaling to the application that it did not read the file handle often/fast enough and that the driver is going to drop packets to keep up. The driver has a limited amount of buffering, so if you have a delay that is too long between read() calls (or your read buffer is too small to accommodate the data rate) you will encounter this condition. 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: HVR900H : IR Remote Control
On Thu, Nov 18, 2010 at 2:59 PM, Massis Sirapian msirap...@free.fr wrote: Does it mean that the IR isn't wired in the case of HVR900H ? When you said that your Terratec equals the HVR900H, does it imply that if IR works on cinergy xe, it should on the HVR900H? One thing you may wish to consider is that if I recall the Terratec remotes are typically NEC and the Hauppauge remotes are typically RC5. So it's possible that only the NEC support is working in the current tm6010 driver, which is why the Hauppauge remote doesn't work. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950q-final
On Tue, Nov 9, 2010 at 11:03 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 02-11-2010 16:47, Devin Heitmueller escreveu: On Sat, Oct 9, 2010 at 2:40 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Hello, Please pull from the following for some basic fixes related to applications such as tvtime hanging when no video is present, as well as some quality improvements for analog. http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950q-final Please let me know if there are any questions/problems. I'm still importing your patches, but, at the very first one, you forgot to send your Signed-off-by: Generating hg_15168_djh_merge_vbi_changes.patch WARNING: please, no space before tabs #39: FILE: drivers/media/video/au0828/au0828.h:155: +^Istruct au0828_buffer ^I*vbi_buf;$ ERROR: Missing Signed-off-by: line(s) Cheers, Mauro djh - merge vbi changes was just a rebase against the latest code. The very first patch in the series is one earlier (047a8c9fa9d5). 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950q-final
On Wed, Nov 3, 2010 at 7:10 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi Devin, I didn't start to pull any fixes yet. I might eventually have some time during this week, but it is more likely that I'll handle after my return back. That's fine. It's been pending for almost a month so I just wanted to be sure it didn't get lost. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950q-final
On Sat, Oct 9, 2010 at 2:40 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Hello, Please pull from the following for some basic fixes related to applications such as tvtime hanging when no video is present, as well as some quality improvements for analog. http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950q-final Please let me know if there are any questions/problems. ping -- 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: Kworld usb 2800D audio
On Thu, Oct 28, 2010 at 10:18 AM, Tim Stowell stowe...@gmail.com wrote: Hi, I'm able to capture video just fine with my Kworld usb 2800D usb device and the recent (I've installed the April v4l-dvb em28xx driver), but I can't get any audio. I tried modprobe em28xx-alsa, and the module loads, but alsa can't find any sound cards. Do I need the snd-usb-audio driver? the usb device is based on the em2860 chip. Any help would be greatly appreciated, thanks. Hello Tim, If I recall, the KWorld 2800D doesn't actually capture audio directly via the USB. The device has a 2.5mm cable that you are required to connect to our sound card's line-in. 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: Kworld usb 2800D audio
On Thu, Oct 28, 2010 at 10:36 AM, Tim Stowell stowe...@gmail.com wrote: Thanks for the response! That makes sense about the 2.5 mm cable. Not to be obstinate or anything but I found this link http://video4linux-list.1448896.n2.nabble.com/SUCCESS-KWorld-VS-USB2800D-recognized-as-PointNix-Intra-Oral-Camera-No-Composite-Input-td3069455.html where the users claims they were able to get a new capture device that didn't require using the 2.5mm cable, although I'm not sure how they did it. I guess I'm hoping to not have to buy a sound card for capture if at all possible as I'm using an embedded pc that doesn't have any sound cards, thanks Read my response in the second message in that thread you provided a link for. :-) The fact that the ALSA device was being created was actually a bug in the em28xx driver. The hardware does not support capture over the USB. There are other devices which do support audio over the USB - the limitation is specific to this particular product. 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: Kworld usb 2800D audio
On Thu, Oct 28, 2010 at 10:48 AM, Tim Stowell stowe...@gmail.com wrote: Ah my bad, I need to read a little deeper it seems :) Thanks for the info, now I'll stop pulling my hair out trying to get non-existent audio. If it's any consolation, I had to rip one of the units apart and break out a scope to come to that conclusion. 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] V4L: cx231xx, fix lock imbalance
On Wed, Oct 27, 2010 at 7:47 AM, Jiri Slaby jsl...@suse.cz wrote: Stanse found that there is mutex_lock in a fail path of cx231xx_i2c_xfer instead of mutex_unlock (i.e. double lock + leaving a function in locked state). So fix that. Signed-off-by: Jiri Slaby jsl...@suse.cz Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Devin Heitmueller dheitmuel...@hauppauge.com This was already reported and a patch was submitted by Dan Carpenter on October 21. See mail on that day with subject line: [patch] V4L/DVB: cx231xx: fix double lock typo. 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 2.6.37-rc1] V4L/DVB updates
On Wed, Oct 27, 2010 at 12:46 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: The original code is broken, as it doesn't properly honour a max size of 8. Even if we do some optimization at cx231xx, we still need to fix the tda18271 code, as it is trying to use more than 8 bytes on some writes. Also, as you noticed, the way cx231xx sends large firmwares to xc5000 is a hack: it requires to identify that the I2C device is a xc5000 and do an special treatment for it. Yes, it does currently only get run if it's an xc5000, but I believe that code path could be used for *all* devices. There is no reason that it needs to be a hack as that behavior should be the default case (presumably Conexant just didn't want to retest against 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 7/8] v4l: Add EBUSY error description for VIDIOC_STREAMON
On Sun, Oct 24, 2010 at 3:50 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: I think the patch makes sense. As you mention many drivers already implement this behaviour, so this mostly clarifies the API. Calling VIDIOC_STREAMON on an already streaming file handle isn't something applications should do in the first place anyway. I don't disagree with this behavior in principle, but Pawel should really try this out with some of the common applications to ensure it doesn't cause breakage (e.g. tvtime, xawtv, mythtv). Despite the fact that some drivers already do this, that doesn't mean that those drivers are necessarily the ones commonly used with these applications. 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: rtl2832u support
On Tue, Oct 19, 2010 at 4:27 PM, Hans Verkuil hverk...@xs4all.nl wrote: Bullshit. Not exactly the level of mutual respect for your peers that I would expect of you, Hans. First of all these rules are those of the kernel community as a whole and *not* linuxtv as such, and secondly you can upstream such drivers in the staging tree. If you want to move it out of staging, then it will take indeed more work since the quality requirements are higher there. You are correct - while I indeed say it was the position of the LinuxTV developers, I didn't intend to single them out from the rest of the Linux kernel community. The problem I described is systemic to working with the Linux kernel community in general. Them's the rules for kernel development. I've done my share of coding style cleanups. I never understand why people dislike doing that. In my experience it always greatly improves the code (i.e. I can actually understand it) and it tends to highlight the remaining problematic areas in the driver. Because it's additional work. I agree that *sometimes* it can be useful. And yet many times it's a bunch of changes that provide little actual value and only make it harder to keep the Linux driver in sync with the upstream source (in many cases, the GPL driver is derived from some Windows driver or other source). Alex makes a point that I think it's worth expanding on a bit: The Linux kernel developers' goals are different than those of the product/chipset vendor. The product/chipset vendor typically wants consistency across operating systems. This usually involves some sort of OS portability layer to abstract out the OS specific parts (which is usually done as a combination of OS specific header files and C macros). This reduces the maintenance cost for the author as it makes it easier to be confident that changes to the core will basically just work on other operating systems. The Linux kernel developer wants consistency across Linux drivers regardless of who wrote them. This makes sense for the Linux kernel community in that it makes it easier to work on drivers that you didn't necessarily write. However it also means that all of the portability code and macros are seen as crap which has to be stripped out. The net effect is a driver that looks little like the original platform independent driver, making it easier for the Linux kernel community to maintain but harder for the original author to provide updates to. I can appreciate why the Linux development community chose this route, but let's not pretend that it doesn't come at a significant cost. Kind of like how the Git move has resulted in developers who want to build drivers on a known-stable kernel (as opposed to the bleeding edge) being treated as second class citizens. 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: [RFC] Resource reservation for frontend - Was: Re: xc5000 and switch RF input
On Thu, Oct 14, 2010 at 4:33 AM, Antti Palosaari cr...@iki.fi wrote: I haven't examined this yet enough, but for the background information I can say I have one device which needs this. There is tuner behind demodulator, but instead of normal I2C-gate switch, it is rather much likely repeater. All tuner commands are send to the demod which then writes those to the tuner. DD = demod I2C addr TT = tuner I2C addr Bn = payload data traditional I2C send to the tuner: TT B0 B1 B2 ... demod as repeater send to the tuner: DD TT B0 B1 B2 ... You can accomplish this by having the demod create an i2c adapter instance, which generates i2c commands to the bridge. Then when instantiating the tuner subdev, pass a pointer to the demod's i2c adapter instead of the i2c adapter provided by the bridge. No changes required to the core framework. 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] xc5000 and switch RF input
On Wed, Oct 13, 2010 at 5:30 PM, Dmitri Belimov d.beli...@gmail.com wrote: Hi Our TV card Behold X7 has two different RF input. This RF inputs can switch between different RF sources. ANT 1 for analog and digital TV ANT 2 for FM radio The switch controlled by zl10353. I add some defines for the tuner xc5000 and use tuner callback to saa7134 part. All works well. But my patch can touch other TV cards with xc5000. Devin can you check my changes on the other TV cards. With my best regards, Dmitry. Hello Dmitri, I've looked at the patch. I really don't think this is the right approach. The tuner driver should not have any of this logic - it should be in the bridge driver. You can also look at Michael Krufky's frontend override patches, which allow the bridge to intervene when DVB frontend commands are made (for example, to toggle the antenna before the tune is performed). I understand the problem you are trying to solve, but jamming the logic into the tuner driver really is a bad idea. NACK. 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] V4L/DVB: tvp5150: COMPOSITE0 input should not force-enable TV mode
On Sat, Oct 9, 2010 at 12:31 AM, Paul Walmsley p...@booyaka.com wrote: When digitizing composite video from a analog videotape source using the TVP5150's first composite input channel, the captured stream exhibits tearing and synchronization problems[1]. It turns out that commit c0477ad9feca01bd8eff95d7482c33753d05c700 caused TV mode (as opposed to VCR mode or auto-detect) to be forcibly enabled for both composite inputs. According to the chip documentation[2], TV mode disables a chrominance trap input filter, which appears to be necessary for high-quality video capture from an analog videotape source. [ Commit c7c0b34c27bbf0671807e902fbfea6270c8f138d subsequently restricted the problem to the first composite input, apparently inadvertently. ] FYI: This isn't a newly discovered issue: http://www.mail-archive.com/linux-media@vger.kernel.org/msg13869.html 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: V4L/DVB: cx231xx: Colibri carrier offset was wrong for PAL/M
On Sat, Oct 9, 2010 at 11:23 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: cx231xx: Colibri carrier offset was wrong for PAL/M The carrier offset check at cx231xx is incomplete. I got here one concrete case where it is broken: if PAL/M is used (and this is the default for Pixelview SBTVD), the routine will return zero, and the device will be programmed incorrectly, producing a bad image. A workaround were to change to NTSC and back to PAL/M, but the better is to just fix the code ;) Thanks for spotting this. I've been focusing entirely on NTSC, so any such fixes for other standards are very welcome. 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
[PULL] http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950q-final
Hello, Please pull from the following for some basic fixes related to applications such as tvtime hanging when no video is present, as well as some quality improvements for analog. http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950q-final Please let me know if there are any questions/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 01/10] V4L/DVB: cx231xx: remove a printk warning at -avcore and at -417
On Thu, Oct 7, 2010 at 5:48 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 28-09-2010 15:46, Mauro Carvalho Chehab escreveu: drivers/media/video/cx231xx/cx231xx-avcore.c:1608: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long unsigned int’ drivers/media/video/cx231xx/cx231xx-417.c:1047: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’ Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com OK, I just updated my tree with the patches that Mkrufky acked. It basically contains the same patches from my previous post, plus the patches that Palash sent, and Devin/Mkrufky patches from polaris4 tree, rebased over the top of kernel v2.6.36-rc7 (this makes easier for me to test and to merge). The patches are at: http://git.linuxtv.org/mchehab/cx231xx.git Sri already sent his ack for the first series of the patches. The tree contains two extra patches: 1) a cx231xx large CodingStyle fix patch: http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=eacd1a7749ae45d1f2f5782c013b863ff480746d It basically solves the issues that checkpatch.pl complained on this series of patches; 2) a cx231xx-417 gcc warning fix: http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=ca3a6a8c2a4819702e93b9612c4a6d90474ea9b5 Devin, Would it be ok for you if I merge them on my main tree? They're needed for one board I'm working with (a Pixelview SBTVD Hybrid - that supports both analog and full-seg ISDB-T). Yeah, I've got additional fixes which aren't on that tree yet, but I don't see any reason why what's there cannot be merged. It would be helpful if you could get Douglas to merge both sets of patches (mine and yours) to the hg backport tree as well, so I can continue development without requiring the bleeding edge kernel (all the work going on is for an embedded target which is running a relatively old kernel). I've got another couple dozen patches and I'm willing to continue pushing this stuff upstream, but you need to meet me halfway here by not making the bleeding edge kernel a requirement for this work. 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: [linux-dvb] Asus MyCinema P7131 Dual support
On Mon, Oct 4, 2010 at 7:21 PM, hermann pitton hermann-pit...@arcor.de wrote: thanks for the report and pointing to the details again. We can see, that my testings on four different machines and Dmitri's tests have not been enough. Mauro had the Dual card=78 version from me too at least for analog TV testing. And, that was on hg with most backward compat as possible. How good are our chances, to run in such and similar troubles in the future, in fact staying only on latest -rc, rc-git and in best case on -next stuff previously? It will all come down to the distros and such a bug fix might take just a year in the future regularly ... So, if the quality control was not even sufficient on hg, what will happen on latest -rc git stuff for that? Obviously zillions of people do much more prefer to crash around there than on hg ... ;) I think it's been made pretty clear: we don't give a crap about whether users' PCs crash. Getting the code into the bleeding edge kernel is the most important thing. Reducing maintainership overhead is clearly more important than whether the code actually works. Forget about the hg backport system. We would rather get crap code into the bleeding edge kernel where almost zero users will test it than to put it into HG where there is actually a chance for users to see the problems before it goes into the mainline kernel (except for the 0.1% of users who are willing to install the latest bleeding edge kernel and make it work with all their other hardware). Yes, we should all be prepared for lots of regressions being introduced, and nobody notices them until the code is already in the distros and has reached the masses. And then maybe if the users are lucky the distro maintainers will backport fixes. It's been made pretty clear that reducing merge overhead is more important than delivering a quality product. I'll stop hijacking the thread now. 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: Help adding support for Hauppauge HVR-850 (latest version w/ USB ID 2040:b140)
On Mon, Oct 4, 2010 at 8:07 PM, Seth Jennings spartacu...@gmail.com wrote: Hi, The most recent version of the Hauppauge WinTV HVR-850 is currently not supported. The previous two hardware versions with USB ID 2040:651f and 2040:7240 are supported but the most recent version with USB ID 2040:b140 is not. I've got a tree here with support for the device. More info can be found here: Hauppauge USBLive2 and new HVR-850 support http://www.kernellabs.com/blog/?p=1445 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: [PATCH 08/10] V4L/DVB: tda18271: allow restricting max out to 4 bytes
On Tue, Sep 28, 2010 at 2:46 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
By default, tda18271 tries to optimize I2C bus by updating all registers
at the same time. Unfortunately, some devices doesn't support it.
The current logic has a problem when small_i2c is equal to 8, since there
are some transfers using 11 + 1 bytes.
Fix the problem by enforcing the max size at the right place, and allows
reducing it to max = 3 + 1.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/common/tuners/tda18271-common.c
b/drivers/media/common/tuners/tda18271-common.c
index e1f6782..195b30e 100644
--- a/drivers/media/common/tuners/tda18271-common.c
+++ b/drivers/media/common/tuners/tda18271-common.c
@@ -193,20 +193,46 @@ int tda18271_write_regs(struct dvb_frontend *fe, int
idx, int len)
unsigned char *regs = priv-tda18271_regs;
unsigned char buf[TDA18271_NUM_REGS + 1];
struct i2c_msg msg = { .addr = priv-i2c_props.addr, .flags = 0,
- .buf = buf, .len = len + 1 };
- int i, ret;
+ .buf = buf };
+ int i, ret = 1, max;
BUG_ON((len == 0) || (idx + len sizeof(buf)));
- buf[0] = idx;
- for (i = 1; i = len; i++)
- buf[i] = regs[idx - 1 + i];
+
+ switch (priv-small_i2c) {
+ case TDA18271_03_BYTE_CHUNK_INIT:
+ max = 3;
+ break;
+ case TDA18271_08_BYTE_CHUNK_INIT:
+ max = 8;
+ break;
+ case TDA18271_16_BYTE_CHUNK_INIT:
+ max = 16;
+ break;
+ case TDA18271_39_BYTE_CHUNK_INIT:
+ default:
+ max = 39;
+ }
tda18271_i2c_gate_ctrl(fe, 1);
+ while (len) {
+ if (max len)
+ max = len;
- /* write registers */
- ret = i2c_transfer(priv-i2c_props.adap, msg, 1);
+ buf[0] = idx;
+ for (i = 1; i = max; i++)
+ buf[i] = regs[idx - 1 + i];
+ msg.len = max + 1;
+
+ /* write registers */
+ ret = i2c_transfer(priv-i2c_props.adap, msg, 1);
+ if (ret != 1)
+ break;
+
+ idx += max;
+ len -= max;
+ }
tda18271_i2c_gate_ctrl(fe, 0);
if (ret != 1)
@@ -326,24 +352,7 @@ int tda18271_init_regs(struct dvb_frontend *fe)
regs[R_EB22] = 0x48;
regs[R_EB23] = 0xb0;
- switch (priv-small_i2c) {
- case TDA18271_08_BYTE_CHUNK_INIT:
- tda18271_write_regs(fe, 0x00, 0x08);
- tda18271_write_regs(fe, 0x08, 0x08);
- tda18271_write_regs(fe, 0x10, 0x08);
- tda18271_write_regs(fe, 0x18, 0x08);
- tda18271_write_regs(fe, 0x20, 0x07);
- break;
- case TDA18271_16_BYTE_CHUNK_INIT:
- tda18271_write_regs(fe, 0x00, 0x10);
- tda18271_write_regs(fe, 0x10, 0x10);
- tda18271_write_regs(fe, 0x20, 0x07);
- break;
- case TDA18271_39_BYTE_CHUNK_INIT:
- default:
- tda18271_write_regs(fe, 0x00, TDA18271_NUM_REGS);
- break;
- }
+ tda18271_write_regs(fe, 0x00, TDA18271_NUM_REGS);
/* setup agc1 gain */
regs[R_EB17] = 0x00;
diff --git a/drivers/media/common/tuners/tda18271.h
b/drivers/media/common/tuners/tda18271.h
index d7fcc36..3abb221 100644
--- a/drivers/media/common/tuners/tda18271.h
+++ b/drivers/media/common/tuners/tda18271.h
@@ -80,8 +80,9 @@ enum tda18271_output_options {
enum tda18271_small_i2c {
TDA18271_39_BYTE_CHUNK_INIT = 0,
- TDA18271_16_BYTE_CHUNK_INIT = 1,
- TDA18271_08_BYTE_CHUNK_INIT = 2,
+ TDA18271_16_BYTE_CHUNK_INIT = 16,
+ TDA18271_08_BYTE_CHUNK_INIT = 8,
+ TDA18271_03_BYTE_CHUNK_INIT = 3,
};
struct tda18271_config {
diff --git a/drivers/media/video/tuner-core.c
b/drivers/media/video/tuner-core.c
index fa406b9..1a047c5 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -428,7 +428,7 @@ static void set_type(struct i2c_client *c, unsigned int
type,
{
struct tda18271_config cfg = {
.config = t-config,
- .small_i2c = TDA18271_08_BYTE_CHUNK_INIT,
+ .small_i2c = TDA18271_03_BYTE_CHUNK_INIT,
};
if (!dvb_attach(tda18271_attach, t-fe, t-i2c-addr,
--
1.7.1
Adding the maintainer for the 18271 driver to the CC.
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 03/10] V4L/DVB: tda18271: Add some hint about what tda18217 reg ID returned
On Tue, Sep 28, 2010 at 2:46 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Instead of doing: [ 82.581639] tda18271 4-0060: creating new instance [ 82.588411] Unknown device detected @ 4-0060, device not supported. [ 82.594695] tda18271_attach: [4-0060|M] error -22 on line 1272 [ 82.600530] tda18271 4-0060: destroying instance Print: [ 468.740392] Unknown device (0) detected @ 4-0060, device not supported. for the error message, to help detecting what's going wrong with the device. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/common/tuners/tda18271-fe.c b/drivers/media/common/tuners/tda18271-fe.c index 7955e49..77e3642 100644 --- a/drivers/media/common/tuners/tda18271-fe.c +++ b/drivers/media/common/tuners/tda18271-fe.c @@ -1177,7 +1177,7 @@ static int tda18271_get_id(struct dvb_frontend *fe) break; } - tda_info(%s detected @ %d-%04x%s\n, name, + tda_info(%s (%i) detected @ %d-%04x%s\n, name, regs[R_ID] 0x7f, i2c_adapter_id(priv-i2c_props.adap), priv-i2c_props.addr, (0 == ret) ? : , device not supported.); -- 1.7.1 Adding the maintainer for the 18271 driver to the CC. 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 09/10] V4L/DVB: tda18271: Add debug message with frequency divisor
On Tue, Sep 28, 2010 at 2:47 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/common/tuners/tda18271-common.c
b/drivers/media/common/tuners/tda18271-common.c
index 195b30e..7ba3ba3 100644
--- a/drivers/media/common/tuners/tda18271-common.c
+++ b/drivers/media/common/tuners/tda18271-common.c
@@ -549,6 +549,13 @@ int tda18271_calc_main_pll(struct dvb_frontend *fe, u32
freq)
regs[R_MD1] = 0x7f (div 16);
regs[R_MD2] = 0xff (div 8);
regs[R_MD3] = 0xff div;
+
+ if (tda18271_debug DBG_REG) {
+ tda_reg(MAIN_DIV_BYTE_1 = 0x%02x\n, 0xff regs[R_MD1]);
+ tda_reg(MAIN_DIV_BYTE_2 = 0x%02x\n, 0xff regs[R_MD2]);
+ tda_reg(MAIN_DIV_BYTE_3 = 0x%02x\n, 0xff regs[R_MD3]);
+ }
+
fail:
return ret;
}
--
1.7.1
Adding the maintainer for the 18271 driver to the CC.
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: RFC: BKL, locking and ioctls
On Sun, Sep 19, 2010 at 5:17 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Sunday, September 19, 2010 23:02:31 Andy Walls wrote: Hans, On an somewhat related note, but off-topic: what is the proper way to implement VIDIOC_QUERYCAP for a driver that implements read() on /dev/video0 (MPEG) and mmap() streaming on /dev/video32 (YUV)? I'm assuming the right way is for VIDIOC_QUERYCAP to return different caps based on which device node was queried. The spec is not really clear about this. It would be the right thing to do IMHO, but the spec would need a change. The caps that are allowed to change between device nodes would have to be clearly documented. Basically only the last three in the list, and the phrase 'The device supports the...' should be replaced with 'The device node supports the...'. This would be great to straighten out. One of the common problems new users have setting up MythTV is trying to figure out what type of device they should be choosing (e.g. V4L2 capture device versus IVTV MPEG capture device). The problem is that the application cannot limit the list of /dev/videoX entries for a given type because some devices report both for all device nodes (even though, for example, the cx18 can only do MPEG on /dev/video1 and raw video on /dev/video0). This results in all sorts of confusion when people wonder why they cannot watch TV because they picked IVTV MPEG capture device, and then picked /dev/video0 as the device node. And of course the real fun comes around when they cannot figure out why they cannot capture video on /dev/video24 and /dev/video32 because those aren't actually video capture devices *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: HVR 1600 Distortion
On Sat, Sep 18, 2010 at 8:42 PM, Josh Borke joshbo...@gmail.com wrote: On Sat, Sep 18, 2010 at 8:20 AM, Andy Walls awa...@md.metrocast.net wrote: On Fri, 2010-09-17 at 18:23 -0400, Josh Borke wrote: Thanks for the response! Replies are in line. On Thu, Sep 16, 2010 at 6:48 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-09-15 at 22:54 -0400, Josh Borke wrote: I've recently noticed some distortion coming from my hvr1600 when viewing analog channels. It happens to all analog channels with some slightly better than others. I am running Fedora 12 linux with kernel version 2.6.32.21-166. I know I need to include more information but I'm not sure what to include. Any help would be appreciated. 1. Would you say the distortion is something you would possibly encounter on an analog television set, or does it look uniquely digital? On systems with a long uptime and lots of usage, MPEG encoder firmware could wind up in a screwed up state giving weird output image. Simple solution in this case is to reboot. I'm not sure if I would classify it as uniquely digital. The distortion happens across most of the screen with it being concentrated in the top third. Additionally shows that include black bars the top black bar is seemingly stretched and the image seems like the colors are over-saturated where they colors are brighter. Rebooting had no effect :( OK. 2. Have you ensured your cable plant isn't affecting signal integrity? http://ivtvdriver.org/index.php/Howto:Improve_signal_quality The cable plant hasn't changed the signal strength or integrity as far as I know. OK. Keep it in the back of your mind though. 3. Does this happen with only the RF tuner or only CVBS or only SVideo or more than one of them? If the problem is only with RF, then it could be an incoming signal distortion problem. Do you have cable or an over the air antenna for analog RF? I only have input for the RF tuner. I have cable for analog RF. Please try and test the output of a VCR or DVD play plugged into the HVR-1600. (We don't need sound, just the video.) This will tell us if the problem happens before the CX23418 chip's analog front end (i.e. in the RF and analog tuner) or not. $ v4l2-ctl -d /dev/video0 -n (List of possible inputs displayed) $ v4l2-ctl -d /dev/video0 -i 2 Video input set to 2 (Composite 1) # v4l2-ctl -d /dev/video0 -s ntsc-m Standard set to 1000 $ cat /dev/video0 foo.mpg ^C I only have S-Video but doing this produced a perfect picture. Before debugging any further, it might make sense to install the tuner into a Windows box and make sure it's not just a hardware failure in the can tuner. 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: HVR 1600 Distortion
On Sat, Sep 18, 2010 at 9:09 PM, Josh Borke joshbo...@gmail.com wrote: It could be the tuner card, it is over 2 years old...Why would the analog tuner stop functioning while the digital tuner continues to work? Is it because the analog portion goes through a different set of chips? Yes, the analog portion of the card has a completely separate tuner and demodulator. Don't get me wrong, it's possible that this is a driver issue, but given Andy has the exact same can tuner on his board it probably makes sense for you to do a sanity test of the hardware before any more time is spent investigating the software. 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: Trouble building v4l-dvb
On Fri, Sep 17, 2010 at 10:49 AM, Mauro Carvalho Chehab mauroche...@gmail.com wrote: While you're there, the better is to also disable CONFIG_ALSA on Ubuntu, as the drivers won't work anyway. Note: while building ALSA modules did fail in some versions for Ubuntu, it has been over a years since I've seen that problem. Blindly disabling ALSA for all Ubuntu users would be a huge regression for users. As we don't want to have complains from users about why driver foo is not compiling for me, IMO, it should be printing a warning message saying that compilation of ALSA/FIREWIRE drivers with that specific kernel version is not possible, due to the back packaging of kernel headers, recommending to the user to get a vanilla upstream kernel, if he needs one of the disabled drivers. I agree with this premise for firedtv, but see my comment above about ALSA. 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 WinTV-HVR1800 dual tuner help needed
On Thu, Sep 16, 2010 at 10:23 AM, Jack Snodgrass jacksnodgr...@mylinuxguy.net wrote: I can use 1 input on the card with mythtv using /dev/dvb/adapter0/frontend0 but I can't figure out how to use the 2nd tuner I'm not sure if the 2nd tuner is getting detected correctly... or if the 2nd tuner is just an analog tuner and not a digital tuner or what exactly... The HVR-1800 doesn't have two digital tuners. It has an analog tuner and a digital tuner. If you need dual ClearQAM, you need a card like the HVR-2250. 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: pwc driver breakage in recent(ish) kernels (for old hardware)
On Wed, Sep 15, 2010 at 11:59 AM, Hans Verkuil hverk...@xs4all.nl wrote: You're in luck. I fixed this last weekend. It turns out that the /dev/videoX device is created too soon and the HAL daemon starts to use it immediately causing some initialization to go wrong or something like that. Moving the creation of /dev/videoX to the end fixed this issue. This bug has been there probably for a long time, but it is only triggered if some other process opens the device node immediately. The HAL daemon opening devices immediately problem a pretty common bug with bridges (especially for hybrid devices) and I've fixed it for the ones I've seen. I'm surprised we don't get reports of this more often. 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 v1 0/7] Videobuf2 framework
On Fri, Sep 10, 2010 at 4:22 AM, Hans Verkuil hverk...@xs4all.nl wrote: It's been a long standing wish to convert the ivtv and cx18 drivers to videobuf, but it's always been too complex. With a new vb2 implementation it may become actually possible. FYI: KernelLabs has done a port of cx18 to videobuf. We just haven't submitted it upstream yet. I'm just mentioning this so nobody else feels the urge to take a crack at 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: some question about
On Sun, Sep 5, 2010 at 11:36 AM, loody milo...@gmail.com wrote: WinTV-HVR-1950 high performance USB TV tuner WinTV-HVR-950Q for laptop and notebooks Both these devices are supported under Linux, and in fact are unlikely to work properly with only Full Speed USB. At least the 950q definitely requires High speed (I put a check in there to specifically not load the driver otherwise). 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: some question about
On Sun, Sep 5, 2010 at 11:48 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sun, Sep 5, 2010 at 11:36 AM, loody milo...@gmail.com wrote: WinTV-HVR-1950 high performance USB TV tuner WinTV-HVR-950Q for laptop and notebooks Both these devices are supported under Linux, and in fact are unlikely to work properly with only Full Speed USB. At least the 950q definitely requires High speed (I put a check in there to specifically not load the driver otherwise). I perhaps misread your original email. While the 950q does present itself as a USB audio class device, the 1950 does not. It only provides MPEG encoded output (containing both the audio and video), and is not a USB audio class device. So while both these devices will work under Linux on a high speed interface, if you specifically require the device to identify itself as a USB audio class device, only the 950q does this. 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: some question about
On Sun, Sep 5, 2010 at 12:06 PM, loody milo...@gmail.com wrote: hi: 2010/9/5 Devin Heitmueller dheitmuel...@kernellabs.com: On Sun, Sep 5, 2010 at 11:48 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sun, Sep 5, 2010 at 11:36 AM, loody milo...@gmail.com wrote: WinTV-HVR-1950 high performance USB TV tuner WinTV-HVR-950Q for laptop and notebooks Both these devices are supported under Linux, and in fact are unlikely to work properly with only Full Speed USB. At least the 950q definitely requires High speed (I put a check in there to specifically not load the driver otherwise). I perhaps misread your original email. While the 950q does present itself as a USB audio class device, the 1950 does not. It only provides MPEG encoded output (containing both the audio and video), and is not a USB audio class device. So while both these devices will work under Linux on a high speed interface, if you specifically require the device to identify itself as a USB audio class device, only the 950q does this. Devin would you mind to send me the device descriptors for me? I want to check whether the input/output unit and audio/video format does meet the spec. BTW, will the device support mp3 output? since the spec define mp3 as one of input/output format. that means if I put the raw data of mp3 to that device, it should play/record well. The device descriptors can be found here: http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Identification The device does not support MP3 output (virtually no devices do as far as I know). It only provides raw 16-bit two channel PCM. The video format would not be in the spec you mentioned. It does work as a standard V4L2 device though, providing raw YUYV video frames. Perhaps if I better understood your intended application, I might be able to give better advice. 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: Gigabyte 8300
On Fri, Sep 3, 2010 at 12:01 PM, Andy Walls awa...@md.metrocast.net wrote: On Fri, 2010-09-03 at 10:55 +, Dagur Ammendrup wrote: I tried it on a windows machine where it's identified as Conextant Polaris Video Capture or oem17.inf:Conexant.NTx86:POLARIS.DVBTX.x86:6.113.1125.1210:usb\vid_1b80pid_d416mi_01 if that tells you anything. Polaris refers to the series of CX2310[012] chips IIRC. Support would need changes to the cx231xx driver, and possibly changes to the cx25480 module, depending on how far the board differs from Conexant reference designs. I've been working with Conexant on this, and have their current tree here: https://www.kernellabs.com/hg/~dheitmueller/polaris4/ So if you feel the urge to do any new device support, I would suggest using this as a starting point. 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: hvr950q stopped working: read of drv0 never returns
On Mon, Aug 23, 2010 at 12:32 AM, Brian J. Murrell br...@interlinx.bc.ca wrote: Hi, I have an HVR 950Q on my Ubuntu 2.6.32 kernel. I have in fact tried several kernel versions on a couple of different machines with the same behaviour. What seems to be happening is that /dev/dvb/adapter0/dvr0 can be opened: open(/dev/dvb/adapter0/dvr0, O_RDONLY|O_LARGEFILE) = 0 but a read from it never seems to return any data: read(0, [ process blocks waiting ] Hi Brian, What command are you using to control the frontend? If it's azap, did you remember to specify the -r argument? 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: [linux-dvb] Pinnacle Systems, Inc. PCTV 330e 2.6.34 /dev/dvb
On Wed, Aug 11, 2010 at 5:07 AM, folkert folk...@vanheusden.com wrote: Fyi: since I upgraded the modules by the mercurial tree you mentioned a few mails ago, my 18b4:1689 e3C Technologies DUTV009 significally has more signal locks. Coincidence? I don't know. The tree I pointed you to is several months old, but may be newer than whatever version of the drivers you had in your base Linux distribution. teletext with that version of the driver with the pinnacle pctv 330e works perfect by the way I'm sorry, but which version of the driver are you referring to? It works perfectly with the tree I pointed you to? Or it works perfectly with whatever you had in your base distribution? 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: Error Building the V4L-DVB drivers from source
On Wed, Aug 11, 2010 at 5:10 AM, Sicoe Alexandru Dan sicoe_a...@yahoo.com wrote: Hi, My name is Alex and I recently tried to install the v4l drivers on my machine. Environment: Ubuntu release 10.04(lucid) Kernel Linux 2.6.32-24-generic GNOME 2.30.2 Ubuntu has a bug in their packaging of the kernel headers, which results in the firedtv driver not building. Just edit v4l/.config and change the line that says firedtv=m to firedtv=n 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: [2.6.35] usb 2.0 em28xx kernel panic general protection fault: 0000 [#1] SMP RIP: 0010:[ffffffffa004fbc5] [ffffffffa004fbc5] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx]
On Wed, Aug 11, 2010 at 12:46 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em 11-08-2010 12:58, Pete Eberlein escreveu: On Wed, 2010-08-11 at 09:25 +0200, Sander Eikelenboom wrote: Hello Devin, Yes it's completely reproducible for a change: ffmpeg -f video4linux -r 25 -s 720x576 -i /dev/video0 out.flv gave an error: Use -f video4linux2. The -f video4linux option uses the old video4linux1 API. I have seen similar strange behavior when I used that ffmpeg option with a v4l2 driver I am developing. Also, ffmpeg does not use libv4l. Still, we have a bug to fix. The driver shouldn't generating a PANIC if accessed via V4L1 API. I agree with Mauro completely. There is nothing userland should be able to do which results in a panic (and I have no reason to believe Pete was suggesting otherwise). That said, it's really useful to know that this is some sort of v4l1 backward compatibility problem. I'll see if I can reproduce this here. 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: [linux-dvb] Pinnacle Systems, Inc. PCTV 330e 2.6.34 /dev/dvb
On Tue, Aug 10, 2010 at 7:22 AM, folkert folk...@vanheusden.com wrote: Teletext support is completely different that digital (DVB) support. VBI support (including teletext) was added to the in-kernel em28xx driver back in January. That'll be the analogue interface probably? e.g. /dev/vbi0 Because a.f.a.i.k. the dvb interface is /dev/dvb/adapter0/demux0 ? Yes, VBI is an analog interface, and the teletext is provided via /dev/vbi0. 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: [linux-dvb] Pinnacle Systems, Inc. PCTV 330e 2.6.34 /dev/dvb
2010/8/10 folkert folk...@vanheusden.com: Fyi: since I upgraded the modules by the mercurial tree you mentioned a few mails ago, my 18b4:1689 e3C Technologies DUTV009 significally has more signal locks. Coincidence? I don't know. The tree I pointed you to is several months old, but may be newer than whatever version of the drivers you had in your base Linux distribution. 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: [2.6.35] usb 2.0 em28xx kernel panic general protection fault: 0000 [#1] SMP RIP: 0010:[ffffffffa004fbc5] [ffffffffa004fbc5] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx]
Hello Sander, Which application were you using, and specifically which em28xx based product do you have? Devin On Tue, Aug 10, 2010 at 6:12 PM, Sander Eikelenboom li...@eikelenboom.it wrote: Hi, While trying to test try and report about some other bugs, i ran into this kernel panic when trying to grab video from my usb 2.0 em28xx videgrabber connected to a usb 2.0 port. Complete serial log attachted. [ 279.680018] general protection fault: [#1] SMP [ 279.683901] last sysfs file: /sys/devices/pci:00/:00:12.2/usb1/1-5/i2c-0/name [ 279.683901] CPU 5 [ 279.683901] Modules linked in: xt_multiport ipt_REJECT xt_recent xt_limit xt_tcpudp powernow_k8 mperf xt_state ipt_MA SQUERADE ipt_LOG iptable_mangle iptable_filter iptable_nat ip_tables nf_nat x_tables nf_conntrack_ipv4 nf_conntrack nf_d efrag_ipv4 fuse hwmon_vid loop saa7115 snd_cmipci gameport snd_opl3_lib snd_hwdep snd_mpu401_uart snd_rawmidi em28xx v4l 2_common snd_hda_codec_atihdmi snd_hda_intel snd_hda_codec snd_pcm snd_seq_device videodev snd_timer snd v4l1_compat v4l 2_compat_ioctl32 videobuf_vmalloc videobuf_core psmouse tpm_tis joydev evdev tveeprom serio_raw shpchp edac_core i2c_pii x4 soundcore pcspkr i2c_core pci_hotplug wmi snd_page_alloc processor button sd_mod r8169 thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 279.683901] [ 279.683901] Pid: 0, comm: swapper Not tainted 2.6.352.6.35-vanilla-xhci-isoc+ #6 890FXA-GD70 (MS-7640) /MS-7640 [ 279.683901] RIP: 0010:[a004fbc5] [a004fbc5] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx] [ 279.683901] RSP: 0018:880001b43c68 EFLAGS: 00010082 [ 279.683901] RAX: dead00200200 RBX: 0804 RCX: 880229625818 [ 279.683901] RDX: dead00100100 RSI: 0003 RDI: 880229625868 [ 279.683901] RBP: 880001b43d08 R08: R09: 0804 [ 279.683901] R10: 880229597000 R11: R12: [ 279.683901] R13: 88022f158820 R14: 880229597000 R15: 0344 [ 279.683901] FS: 7fa4bd3706e0() GS:880001b4() knlGS: [ 279.683901] CS: 0010 DS: ES: CR0: 8005003b [ 279.683901] CR2: 7fa4bd35f000 CR3: 00022a9ad000 CR4: 06e0 [ 279.683901] DR0: DR1: DR2: [ 279.683901] DR3: DR6: 0ff0 DR7: 0400 [ 279.683901] Process swapper (pid: 0, threadinfo 880237d4a000, task 880237d2f7a0) [ 279.683901] Stack: [ 279.683901] 8103d7a3 880001b43cb0 0082 8802375e2188 [ 279.683901] 0 0804 880229625818 880229597a40 880229597a90 [ 279.683901] 0 c90010b72000 002237d2 880229597000 [ 279.683901] Call Trace: [ 279.683901] IRQ [ 279.683901] [8103d7a3] ? enqueue_task+0x77/0x87 [ 279.683901] [a0053398] em28xx_irq_callback+0x7e/0xfe [em28xx] [ 279.683901] [81359415] usb_hcd_giveback_urb+0x84/0xb8 [ 279.683901] [8136b51b] ehci_urb_done+0xcf/0xe4 [ 279.683901] [8136cd15] ehci_work+0x504/0x8da [ 279.683901] [81370fda] ehci_irq+0x19c/0x1ce [ 279.683901] [81358bd1] usb_hcd_irq+0x3e/0x83 [ 279.683901] [8108782c] handle_IRQ_event+0x58/0x136 [ 279.683901] [81089414] handle_fasteoi_irq+0x92/0xd2 [ 279.683901] [8100b241] handle_irq+0x1f/0x2a [ 279.683901] [8100a884] do_IRQ+0x5a/0xc1 [ 279.683901] [8146c953] ret_from_intr+0x0/0x11 [ 279.683901] EOI [ 279.683901] [a0044740] ? acpi_idle_enter_simple+0x130/0x168 [processor] [ 279.683901] [a004473c] ? acpi_idle_enter_simple+0x12c/0x168 [processor] [ 279.683901] [813ad822] cpuidle_idle_call+0x9b/0xfd [ 279.683901] [81007868] cpu_idle+0x51/0x84 [ 279.683901] [81466d1b] start_secondary+0x1c0/0x1c5 [ 279.683901] Code: 83 ef 80 e8 69 39 01 e1 48 8b 4d 88 49 c7 86 18 0b 00 00 00 00 00 00 be 03 00 00 00 48 8b 51 40 48 8b 41 48 48 89 cf 48 83 c7 50 48 89 42 08 48 89 10 48 b8 00 01 10 00 00 00 ad de 48 89 41 40 [ 279.683901] RIP [a004fbc5] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx] [ 279.683901] RSP 880001b43c68 [ 279.683901] ---[ end trace 0f55a03076b067cf ]--- [ 279.683901] Kernel panic - not syncing: Fatal exception in interrupt [ 279.683901] Pid: 0, comm: swapper Tainted: G D 2.6.352.6.35-vanilla-xhci-isoc+ #6 [ 279.683901] Call Trace: [ 279.683901] IRQ [81469cf9] panic+0xb1/0x12a [ 279.683901] [81043b90] ? kmsg_dump+0x126/0x140 [ 279.683901] [8100c354] oops_end+0x89/0x96 [ 279.683901] [8100c534] die+0x55/0x5e [ 279.683901] [8100a26f] do_general_protection+0x130/0x138 [ 279.683901] [8146cc05] general_protection+0x25/0x30 [
Re: [2.6.35] usb 2.0 em28xx kernel panic general protection fault: 0000 [#1] SMP RIP: 0010:[ffffffffa004fbc5] [ffffffffa004fbc5] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx]
On Tue, Aug 10, 2010 at 6:57 PM, Sander Eikelenboom li...@eikelenboom.it wrote: Hello Devin, It's a k-world, which used to work fine (altough with another program, but I can't use that since it seems at least 2 other bugs prevent me from using my VM's :-) It's this model http://global.kworld-global.com/main/prod_in.aspx?mnuid=1248modid=6pcid=47ifid=17prodid=104 Tried to grab with ffmpeg. Is it reproducible? Or did it just happen once? If you have a sequence to reproduce, can you provide the command line you used, etc? 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: [linux-dvb] Pinnacle Systems, Inc. PCTV 330e 2.6.34 /dev/dvb
On Mon, Aug 9, 2010 at 9:32 AM, folkert folk...@vanheusden.com wrote: Hi, I have a: Bus 001 Device 006: ID 2304:0226 Pinnacle Systems, Inc. PCTV 330e inserted in a system with kernel 2.6.34. The PCTV 330e support for digital hasn't been merged upstream yet. See here: http://www.kernellabs.com/blog/?cat=35 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: [linux-dvb] Pinnacle Systems, Inc. PCTV 330e 2.6.34 /dev/dvb
On Mon, Aug 9, 2010 at 10:35 AM, folkert folk...@vanheusden.com wrote: Hi Devin, I have a: Bus 001 Device 006: ID 2304:0226 Pinnacle Systems, Inc. PCTV 330e inserted in a system with kernel 2.6.34. The PCTV 330e support for digital hasn't been merged upstream yet. See here: http://www.kernellabs.com/blog/?cat=35 Does that mean teletext won't work either? Teletext support is completely different that digital (DVB) support. VBI support (including teletext) was added to the in-kernel em28xx driver back in January. 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: [linux-dvb] Pinnacle Systems, Inc. PCTV 330e 2.6.34 /dev/dvb
On Mon, Aug 9, 2010 at 10:56 AM, folkert folk...@vanheusden.com wrote: Ah and I see in the code that you are the maintainer :-) I'm not sure I would call myself the maintainer, but I did do the VBI support for both NTSC and PAL (including teletext). Something seems to be odd with the vbi support: mauer:~# alevt -vbi /dev/vbi0 DMX_SET_FILTER: Invalid argument alevt: v4l2: broken vbi format specification alevt: cannot open device: /dev/vbi0 I'll have to look at the source code to alevt and see what exactly it considers to be invalid. The teletext support was tested with mtt, but not alevt. 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: pinnacle 801e help please!
On Sun, Aug 8, 2010 at 7:53 PM, Ray Bullins bbull...@triad.rr.com wrote: I am new to Linux (somewhat) and I am running Linux mint 9. So far so good, I have replaced dreamweaver with NVU, office with open office. Outlook with evolution and so on. Everything is now perfect no looking back to windows except I just spent about 1.5 hours going through configuring mythtv only to find it doesn't think my pinnacle usb hd stick is a dvb device. So i did more research and stumbled upon all of your hard work and tried downloading the tar for my device but it wouldn't download. 2 questions 1) will this device work now 2) how do I implement all of you fixes in mint Linux 9 gnome running mythtv? thanks for any help Ray The 801e driver only has support currently for ATSC/ClearQAM (which is why it appears as a DVB device). The driver does not have any support for analog (e.g. the analog tuner or the composite/s-video inputs). Run ls /dev/dvb/adapter0/frontend0 and if you see an entry then the driver loaded successfully. Also, you may need to load firmware (it's bundled by default with a number of distributions but I don't know about Mint). If you don't have it, you can get it here: http://kernellabs.com/firmware/dib0700/ 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: [patch -next] V4L: au0828: move dereference below sanity checks
On Fri, Jul 23, 2010 at 6:09 AM, Dan Carpenter erro...@gmail.com wrote:
This function has sanity checks to make sure that dev is non-null. I
moved the dereference down below the checks. In the current code dev
is never actually null.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/au0828/au0828-video.c
b/drivers/media/video/au0828/au0828-video.c
index d97e0a2..7989a7b 100644
--- a/drivers/media/video/au0828/au0828-video.c
+++ b/drivers/media/video/au0828/au0828-video.c
@@ -441,7 +441,7 @@ static void au0828_copy_vbi(struct au0828_dev *dev,
unsigned char *outp, unsigned long len)
{
unsigned char *startwrite, *startread;
- int bytesperline = dev-vbi_width;
+ int bytesperline;
int i, j = 0;
if (dev == NULL) {
@@ -464,6 +464,8 @@ static void au0828_copy_vbi(struct au0828_dev *dev,
return;
}
+ bytesperline = dev-vbi_width;
+
if (dma_q-pos + len buf-vb.size)
len = buf-vb.size - dma_q-pos;
In reality the check for dev can be removed since it will *never*
happen (I added it during some debugging, as can be seen by the rest
of the NULL checks).
Either way though, this patch is fine.
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: RFC: Use of s_std calling s_freq when tuner powered down
Hi Andy, On Sun, Jul 11, 2010 at 9:23 AM, Andy Walls awa...@md.metrocast.net wrote: At the risk of missing something obvious: In your bridge driver's VIDIOC_S_STD ioctl() a. power up the analog tuner if it is not already b. call s_std for the subdevices (including the tuner), c. power down that analog tuner if not using the tuner input. No I2C errors in the log and the tuner is powered down when not in use, IMO, VIDIOC_S_STD is not a timing critical operation from userspace and it doesn't happen that often. You can also filter the cases when VIDIOC_S_STD is called on the same input, but the standard is not being changed. Thanks for taking the time to provide feedback. It's not timing critical, but on some tuners initialization can take several seconds (e.g. tda18271, xc5000). I'm not thrilled about it taking 3-5 seconds to change the standard (something which some applications may very well do on every channel change). I'm tempted to just jam a zero into the tuner-tv_freq when powering down the tuner, but that's not a very clean solution obviously. The tuner core makes decisions based on tuner-tv_freq not being zero, so I believe tuner_core should provide some way to reset it back to zero as needed. 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: Support for Pinnacle PCTV Quatro stick
On Sun, Jul 11, 2010 at 9:18 AM, Alexander Wirt formo...@formorer.de wrote: Hi, I recently got a Pinnacle PCTV Quatro stick which announces itself as PCTV 510e (ID: 2304:0242). It seemed that the em28xx-new driver had support for that stick, but as this is dead I know need some help. Is there anywhere support for this stick available? Not currently. The problem isn't the em28xx driver. The device uses the Micronas drx-k demodulator, for which there is not currently any open source 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
RFC: Use of s_std calling s_freq when tuner powered down
Hello all, Here's the scenario: 1. I have a USB device that supports both an analog tuner and composite/s-video inputs 2. The bridge is smart enough to power down the tuner when capturing on composite/s-video 3. Changing the video standard appears to send set_freq() calls to the tuner, which in i2c fail because it's powered down. So I looked at the tuner-core code, and I'm seeing that tuner_s_std() will call set_freq() if the tuner-tv_freq field is nonzero. This seems reasonable, except as far as I can tell there is no way to set it to zero (because the places that set the value to zero will return failure because zero is outside the tuning range). This behavior happens with tvtime, which always does a tuning on startup, before switching to the A/V inputs. While I agree that I should probably fix tvtime so it doesn't do this, it seems strange that there is no way to reset tv_freq to zero when toggling away from the tuner input, so that these errors don't occur. Any thoughts? Obviously I would like to eliminate the i2c errors from littering the dmesg log when there is no real failure condition. 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: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On Fri, Jul 9, 2010 at 2:03 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 09-07-2010 14:19, Ivan escreveu: On 07/09/2010 08:47 AM, Mauro Carvalho Chehab wrote: I never saw the em28xx scaler generating such vertical stripes. This could be a mplayer or a video adapter driver problem. Are you using a proprietary video driver? You may try to use ffmeg or mencoder to generate a mpeg file at 640x480 and then try to play it on another player (preferably on another machine), to see if this problem disappears. Huh? Does there even *exist* a proprietary linux driver for my card? And because you never saw stripes with em28xx, they must not exist? :^P Well, it depends. What are your video adapter card? ATI? Nvidia? Mauro, His issue with the vertical stripes has been fixed when he updated to the latest v4l-dvb code. It's the issue I fixed a couple of months ago with the saa7113 chroma gain behavior when there is an overdriven signal. The problem he's having now with the latest is the picture appears to be shifted. I have to wonder if perhaps I screwed something up when I did the VBI support, in that it may not work properly when the scaler is in use. I will have to do some testing. 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: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On Thu, Jul 8, 2010 at 1:44 PM, Ivan ivan.q.pub...@gmail.com wrote: Now, regarding the difference in image quality between the Linux and Windows drivers, I took some snapshots. Linux is first, then Windows: http://www3.picturepush.com/photo/a/3762966/img/3762966.png http://www4.picturepush.com/photo/a/3762977/img/3762977.png I would have thought that the digitized video coming from the card would be essentially the same in both cases, but the vertical stripes and the difference in width don't seem to be merely a matter of postprocessing. Does the driver have a greater level of control than I suspected over the digitization process in the card? (The difference in sharpness, on the other hand, I would guess to be postprocessing.) So I'm mainly wondering whether the vertical stripes can be eliminated by controlling the card differently, or if we have no control over that and have to deal with it by postprocessing. The vertical stripes were a problem with the anti-alias filter configuration, which I fixed a few months ago (and probably just hasn't made it into your distribution). Just install the current v4l-dvb code and it should go away: http://linuxtv.org/repo 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: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On Thu, Jul 8, 2010 at 3:52 PM, Ivan ivan.q.pub...@gmail.com wrote: On 07/08/2010 01:52 PM, Devin Heitmueller wrote: The vertical stripes were a problem with the anti-alias filter configuration, which I fixed a few months ago (and probably just hasn't made it into your distribution). Just install the current v4l-dvb code and it should go away: http://linuxtv.org/repo Yep, that gets rid of the vertical stripes but adds in a lovely horizontal shift: http://www3.picturepush.com/photo/a/3763906/img/3763906.png Also, vertical lines look slightly more ragged than they did before, to my eye at least. I'm also encountering this old compilation problem: http://www.mail-archive.com/linux-media@vger.kernel.org/msg06865.html I worked around it by disabling firedtv in v4l/.config. (I'm running 2.6.32-23-generic on Ubuntu Lucid.) Ivan The jagged vertical lines is probably this issue, which was fixed in git but the fix hasn't hit the hg repository yet: http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=9db74cf24c038292d353d746cec11f6da368ef4c The horizontal shift issue is interesting. Does that happen every time? And did you unplug/replug the device? Try to reboot? Regarding the compilation issue, yeah it's annoying. Perhaps someday the Ubuntu people will fix their kernel packaging process. 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: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On Thu, Jul 8, 2010 at 5:33 PM, Ivan ivan.q.pub...@gmail.com wrote: Ok, the horizontal shift disappears if I switch to 720x480 instead of 640x480. Does the card always output 720x480 (in NTSC mode anyway), then, and any scaling is done by V4L? That card does have an onboard scaler, although it's not clear to me why it isn't working. Exactly what command line did you use? I also have a question about dropped frames. After running mplayer or mencoder, I see a line like: v4l2: 1199 frames successfully processed, -3 frames dropped. I can only guess that the negative number means that V4L received frames at a slightly faster rate than the expected 3/1001 fps. In my case, it would seem that my SNES is producing something more like 30.05 fps, and so V4L reports a negative dropped frame every 12.5 seconds or so. Yeah, I don't know. You would have to ask the mplayer/mencoder people. It would also seem that V4L doesn't actually discard any frames, but still passes them on to mplayer/mencoder, because mencoder shows an encoding fps of 30.04 (and it will skip a frame every 12.5 seconds or so unless you pass it -noskip). Am I right about all this? Again, this would be an mplayer/mencoder thing. 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: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On Wed, Jul 7, 2010 at 9:56 PM, Ivan ivan.q.pub...@gmail.com wrote: I recently purchased ($20 special deal from newegg; the price has gone back up) the following USB stick that captures composite video and S-video (no TV tuner): KWORLD DVD Maker USB 2.0 (VS-USB2800) It seemed likely to be supported by the em28xx driver, and I'm pleased to report that, in fact, it is! Yup, it's supported. Does the em28xx driver load a firmware? No firmware is involved at all for this device. The Merlin ROM you are seeing is for other devices that use the same underlying driver. Also, any firmware that gets loaded only persists until the device is unplugged, right? And so my prior successful test on Windows has nothing to do with my later success on Linux... just want to be sure about that. I also tried testing with Windows in Virtualbox, but had no luck-- does anyone know if this should be possible? (I can provide more info about my virtualbox testing if anyone's interested.) Again, no firmware involved, and there is no transient state from Windows to Linux. Do a cold boot into Linux and you will see the device works fine. VirtualBox performs poorly with devices of this nature because the USB emulation isn't really designed for high-speed realtime delivery of video (and an uncompressed analog stream is about 20MB/sec). I guess the part about the snapshot button means that I can use the push button on the USB stick to trigger stuff if I want (yay!), but I have no idea how to make that actually happen. If your device actually has a physical button on it then yes it will work. The driver will generate a KEY_CAMERA input event via inputdev (similar to a keyboard event). Read up on inputdev to see how to write a userland application which can see it. 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
Call for testers: PCTV 80e support
Hello all, I'm finally happy to announce that we've got a working version of the drx-j driver (with the appropriate licensing) and I'm looking for testers if you happen to own an PCTV 80e. More details as to where to find the tree and how to install it can be found here: http://www.kernellabs.com/blog/?p=1435 Feedback welcome (either here or in the blog post comments) Thanks go out to Trident Microsystems for finally allowing a driver to be released, as well as to Hauppauge/PCTV for pushing for its release for so long. 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: [PATCH] xc5000, rework xc_write_reg
On Mon, Jul 5, 2010 at 12:11 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Devin/Dmitri, Any progress about this patch? Cheers, Mauro Sorry for the delay. I did some testing with it today, and it looks fine. Acked-by: Devin Heitmueller dheitmuel...@kernellabs.com 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-em28xx-isoc/
On Sat, Jun 26, 2010 at 11:05 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: This patch tries to fix a problem, but it is broken: Let's suppose that you have 2 i2c drivers that implements control, one for video (like tvp5150) and another for audio (like msp3400). That's the case of HVR-950, for example. As both drivers implement s_ctrl, the -ENOIOCTLCMD will not be returned by the drivers. Instead, if you try to set an audio CTRL to tvp5150, it will return -EINVAL. The same happens if you try to set a video CTRL to msp3400. If you use v4l2_device_call_until_err(), depending on the order that tvp5150 and msp3400 will be loaded, or video or audio CTRL's will always fail, due to -EINVAL. What we need here is something like v4l2_device_call_until_not_err(), e. g. something that will stop sending CTRL's if the return code is 0. Yeah, you're right. The patch is indeed broken in that use case. I had looked at various other bridges, but didn't see any consistent approach. Let's move this to a new thread so that we can get input from Hans (given this is a subdev issue). Thanks for pulling the other patches though. 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
Correct way to do s_ctrl ioctl taking into account subdev framework?
First, a bit of background: A bug in the em28xx implementation of s_ctrl() was present where it would always return 1, even in success cases, regardless of what the subdev servicing the request said (in this case the video decoder). It was using v4l2_device_call_all(), and disregarding the return value from any of the subdevs. This prompted me to change the code so that it started using v4l2_device_call_until_err(), figuring that subdevs that did not support it would simply return -ENOIOCTLCMD. However, as Mauro correctly pointed out, subdevs that do implement s_ctrl, but not the desired control will return -EINVAL, which would cause the bridge to stop sending the command to other subdevs and return an error. I looked at various other bridges, and don't see any consistent approach for this case. Some of the bridges always return zero (regardless of what happened during the call). Some of them look at the content of the resulting struct for some value that suggests it was changed. Others feed the call to different classes of subdevice depending on what the actual control being set was. So what's the right approach? I'm willing to conform to whatever the recommendation is here, since it will obviously be an improvement over always returning 1 (even always returning zero would be better since at least applications wouldn't treat it as a failure). Hans? 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: Correct way to do s_ctrl ioctl taking into account subdev framework?
On Sat, Jun 26, 2010 at 2:51 PM, Hans Verkuil hverk...@xs4all.nl wrote: There really is no good way at the moment to handle cases like this, or at least not without a lot of work. Ok, it's good to know I'm not missing something obvious. The plan is to have the framework merged in time for 2.6.36. My last patch series for the framework already converts a bunch of subdevs to use it. Your best bet is to take the patch series and convert any remaining subdevs used by em28xx and em28xx itself. I'd be happy to add those patches to my patch series, so that when I get the go ahead the em28xx driver will be fixed automatically. It would be useful for me anyway to have someone else use it: it's a good check whether my documentation is complete. Sure, could you please point me to the tree in question and I'll take a look? Given I've got applications failing, for the short term I will likely just submit a patch which makes the s_ctrl always return zero regardless of the subdev response, instead of returning 1. 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: Correct way to do s_ctrl ioctl taking into account subdev framework?
On Sat, Jun 26, 2010 at 9:34 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: would do the trick. Yet, the application is broken, as it is considering a positive return as an error. A positive code should never be considered as an error. So, we need to fix v4l2-ctl as well (ok, returning 1 is wrong as well, as this is a non-v4l2 compliance in this case). A strict interpretation of the spec would read that returning zero is success, -1 is an well-formed error condition, and *ANYTHING* else is a violation of the spec and an application used for testing compliance should complain very loudly (which is exactly what it does). In effect, the only patch I would consider valid for v4l2-ctl would be one that makes the error even more LOUD than it already is. We might add a new handler at subdev, but, as Laurent is reworking it, the above trick would be an acceptable workaround. Great. I'll submit a patch to this effect, which would be applicable until we have a final solution in place. 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: em28xx/xc3028 - kernel driver vs. Markus Rechberger's driver
On Tue, Jun 22, 2010 at 5:25 PM, Thorsten Hirsch t.hir...@web.de wrote: Hi, as far as I know there's been some trouble in the past regarding Markus Rechberger's em28xx driver (em28xx-new) and the official development line, resulting in the current situation: - M. Rechberger isn't developing his driver anymore - kernel driver doesn't support em28xx/xc3028 based usb sticks (cinergy usb t xs) Can I help to solve the situation? So far I opened a bug report on launchpad (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/460636) describing the situation with both drivers. I also tried to update M. Rechberger's driver making it work in more recent kernels. This worked for a short while, but then my usb stick lost its official (terratec branded) usb id and I couldn't manage to make it work again since. The current situation for my patched version of M. Rechberger's driver is, that everything seems to work fine except for locking channels / some tuning stuff ...well, I don't know exactly, I just see that kaffeine detects the device and can scan for channels. While the 2 signal bars (snr/quality) are pretty active and even the green tuning led (in kaffeine) is very often active, there is just no channel entering the list. Regarding the official em28xx driver my usb stick is far away from working. It stops as soon as when the firmware is being loaded: [ 576.009547] xc2028 5-0060: Incorrect readback of firmware version I already wrote an email to Mauro Carvalho Chehab (the author of the em28xx driver) and he told me that my firmware file must be corrupted. That's xc3028-v27.fw. My version is from Ubuntu's nonfree firmware package. But it's the same file as when I follow Mauro's description of how to extract the firmware from the Windows driver (extract_xc3028.pl). So it looks as if the Cinergy USB T XS needs a different xc3028-v27.fw file. What about the firmware in M. Rechberger's driver? Well, it doesn't depend on an external firmware file, because the firmware is included in xc3028/xc3028_firmwares.h, which has the following copyright note: (c) 2006, Xceive Corporation. Looks like the official one, so I guess it should work. And since my device was already working with that firmware a while ago when Markus was still developing his driver I guess I should focus on the following question: = How can I extract the firmware from Xceive's official xc3028/xc3028_firmwares.h and making it work with the em28xx driver (vanilla kernel)? I hate to say that you're totally on the wrong track, except that's almost certainly the case. You've got the right firmware already (and there isn't a 'different v.27'). That error occurs if the driver is unable to read back the version from the chip after loading the firmware. It's most likely the board profile isn't setup properly to bring the chip out of reset. The firmware is separated out because the Linux kernel process does permit firmware embedding. It *must* be provided as a separate blob. Also, Xceive hasn't granted permission to redistribute the xc3028 firmware, which is why it usually has to be extracted from the Windows driver (unlike the xc4000 and xc5000 where they have explicitly granted redistribution rights). Regarding the statement that the kernel driver doesn't support em28xx/xc3028 based usb sticks, this is simply incorrect. The current kernel supports a variety of devices that have a combination of the em28xx and xc3028. A board profile needs to be added for the device in question (I have the board but haven't had a chance to do the necessary work). Exactly what is the USB ID of the board you have (there are a variety different versions of the board with that name). I probably have the board already, but I want to be sure. In the end, it's probably something like 12 lines of code need to be added to the current 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: How to use aux input on ATI TV Wonder 600 USB?
On Mon, Jun 21, 2010 at 11:09 AM, Steve Freitas sfl...@ihonk.com wrote: Hi all, I have an ATI TV Wonder 600 USB and have successfully used it for its DVB features, thanks to the work of many of you on this list. However, this device also has an auxiliary s-video/composite input[1] which I'd like to use in VLC, and I can't figure out how. Is there any capability in the driver to switch to that? I'm using kernel 2.6.32 on Debian, with firmware xc3028L-v36.fw. The device's USB id is 0438:b002. I'm happy to provide any other logs or info requested and appreciate any help I can get. Yes, it's fully supported. But bear in mind it's an analog input, so you need to use a V4L application as opposed to something designed for DVB. Once you use an analog app (such as tvtime), just toggle over to input 1 for composite or input 2 for S-Video (input zero is the analog tuner input). 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: How to use aux input on ATI TV Wonder 600 USB?
On Mon, Jun 21, 2010 at 11:48 AM, Steve Freitas sfl...@ihonk.com wrote: Yes, it's fully supported. But bear in mind it's an analog input, so you need to use a V4L application as opposed to something designed for DVB. Once you use an analog app (such as tvtime), just toggle over to input 1 for composite or input 2 for S-Video (input zero is the analog tuner input). That was just the help I needed. Thanks! Would it be appropriate for me to add that input number information to the wiki page[1]? I'm not sure how much value it would provide. Pretty much all the applications show an input description next to the number (for example, with tvtime you actually see Tuner, Composite, and S-Video as the options). The driver shows you the mapping if you run v4l2-ctl --list-inputs. But feel free to update the Wiki if you think it helps. 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: About Viewcast Osprey 450e
On Mon, Jun 21, 2010 at 10:37 PM, a...@librelogiciel.com wrote: Is there any chance this card will be supported by V4L in the future (or is it already) ? KernelLabs has written a driver for both the 240e and 450e (in cooperation with ViewCast) and it is currently in testing (with plans to be merged upstream). Keep an eye on the KernelLabs blog for more info. http://www.kernellabs.com/blog/ 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
[PULL] http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950qvbi
Hello, Please PULL from http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950qvbi for the following: * Add closed captioning support for the HVR-950q Thanks go out to GetWellNetwork Inc. for sponsoring this work. 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
[PULL] http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-em28xx-isoc/
Hello, Please PULL from http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-em28xx-isoc for the following: * Make em28xx s_ctrl not always return error * Fix case where fields were not at the correct start location. This addresses two bugs found in the em28xx driver (one with video rendering and one with the s_ctrl ioctl always returning an error). Thanks to Eugeniy Meshcheryakov for bringing the field rendering issue to my attention. 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 with em28xx card, PAL and teletext
On Sun, Jun 13, 2010 at 11:21 PM, Eugeniy Meshcheryakov eu...@debian.org wrote: Thanks, that patch fixes the shifting problem, all the pixels are in the right place. Ok, I'll issue a PULL request to get that upstream. Thanks for testing. In the meantime though, you can work around the issue by cropping out the lines with the following command: /usr/bin/mplayer -vo xv,x11 tv:// -tv driver=v4l2:device=/dev/video0:norm=PAL:width=720:height=576:input=1 -vf crop=720:572:0:0 Thanks for the tip. It worked with 640x480. But when I tried to use 720x576 I got a picture with a lot of noise made of horizontal white lines. However maybe it is because of damaged USB connector... If you email me a screenshot (preferably off list due to the size), I can probably provide some additional advice. Also please provide the exact mplayer command you used so I can try to reproduce it here. Also teletext is still unreadable (both with 640x480 and 720x576). Does mplayer support teletext correctly? And can it work with resolution 640x480? I don't know how good mplayer's teletext support is. When I did the original work, I did the testing using mtt, and in fact I had to do it over an SSH link since I didn't have a teletext feed here. It should work at 640x480 though. I would suggest you try it with mtt/tvtime at 720x576 and see if it works. If it does, then we have a starting point to narrow down whether it's an issue with the application, the selected capture resolution, the driver itself, or something strange about the teletext feed itself. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with em28xx card, PAL and teletext
On Sun, Jun 13, 2010 at 11:09 AM, Eugeniy Meshcheryakov
eu...@debian.org wrote:
Hi,
I was waiting with reply to look at improvements you made in the driver.
But the problem did not go away. Actually it became worser. In recent
kernels the picture is not only shifted, but amount of shift changes
with the time. Every second or so picture is shifted 1-2 pixels right
or left. This problem is introduced with this patch:
V4L/DVB: em28xx: rework buffer pointer tracking for offset to start of video
5fee334039550bdd5efed9e69af7860a66a9de37
After reverting this patch the picture does not move anymore. Also there
is still green line on the bottom, and still some pixels that should be
on the right edge are on the left edge.
I'm using mplayer to watch tv. If it helps, it is cable tv in Germany.
Some maplyer parameters related to tv:
norm=pal-bg:device=/dev/video1:tdevice=/dev/vbi0:width=640:height=480:alsa=yes:adevice=hw.2,0:amode=1:immediatemode=0:audiorate=48000
Regards,
Eugeniy Meshcheryakov
Hello Eugeniy,
I finally found a couple of hours to debug this issue. Please try the
attached patch and report back whether it addresses the problem you
were seeing with the fields shifting left/right.
Regarding the green lines at the bottom, this is an artifact of the
VBI changes, resulting from the fact that there is some important VBI
content inside of the Active Video area (line 23 WSS in particular),
and the chip cannot handle providing it both in YUYV format for the
video area as well as in 8 bit greyscale for the VBI. As a result, we
had to drop the lines from the video area.
What probably needs to happen is I will need to change the driver to
inject black lines into each field to make up for the two lines per
field we're not sending in the video area. In the meantime though,
you can work around the issue by cropping out the lines with the
following command:
/usr/bin/mplayer -vo xv,x11 tv:// -tv
driver=v4l2:device=/dev/video0:norm=PAL:width=720:height=576:input=1
-vf crop=720:572:0:0
(in particular, look at the -vf crop=720:572:0:0 portion)
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
Fix case where fields were not at the correct start location.
From: Devin Heitmueller dheitmuel...@kernellabs.com
This patch address an arithmetic error for the case where the only remaining
content in the USB packet was the 225A start of active video. In cases
where that happened to be at the end of the frame, we would inject it into the
videobuf (which is incorrect). This caused fields to be intermittently
rendered off by two pixels.
Thanks to Eugeniy Meshcheryakov for bringing this issue to my attention
Priority: high
Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com
Cc: Eugeniy Meshcheryakov eu...@debian.org
diff -r b594029d762f linux/drivers/media/video/em28xx/em28xx-video.c
--- a/linux/drivers/media/video/em28xx/em28xx-video.c Thu May 13 16:59:15 2010 -0300
+++ b/linux/drivers/media/video/em28xx/em28xx-video.c Sun Jun 13 15:42:27 2010 -0400
@@ -684,12 +684,12 @@
}
if (buf != NULL dev-capture_type == 2) {
- if (len 4 p[0] == 0x88 p[1] == 0x88
+ if (len = 4 p[0] == 0x88 p[1] == 0x88
p[2] == 0x88 p[3] == 0x88) {
p += 4;
len -= 4;
}
- if (len 4 p[0] == 0x22 p[1] == 0x5a) {
+ if (len = 4 p[0] == 0x22 p[1] == 0x5a) {
em28xx_isocdbg(Video frame %d, len=%i, %s\n,
p[2], len, (p[2] 1) ?
odd : even);
Re: please update V4L-DVB wiki concerning Compro DVD-T300 support
On Thu, Jun 10, 2010 at 10:20 PM, Rohan Carly se...@rohan.id.au wrote: Hi, I had success with some TV tuner hardware that wasn't listed on the linuxtv.org V4L-DVB wiki. Could you please update it? The Wiki is open to anyone's contributions. If you have found an inaccuracy or some missing info, you should feel free to just create an account and contribute the changes yourself. 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: avertv h830 hybrid tv usb stick
On Wed, Jun 9, 2010 at 6:41 PM, Jacques Weber jacqwe...@gmail.com wrote: I just have bought an avertv h830 hybrid tv usb stick, the vendor having certified to me it will work under linux... By now it does not. When I plug the stick, no /dev/video device is created. I suppose it lacks some firmware supporting this hardware. Does somebody know if this stick will be supported in the future ? If the vendor certified it, then you should be calling their technical support instead of asking us. 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
