Re: [PATCH 2/2 v2] gspca: Add MR97310A driver
On Thu, 15 Jan 2009 22:36:49 -0600 Kyle Guinn ely...@gmail.com wrote: This patch adds support for USB webcams based on the MR97310A chip. It was tested with an Aiptek PenCam VGA+ webcam. Hi Kyle, I added your driver to my repository. I just found a little bug. At line 250/251 data[8] = 0x01; err_code = reg_w(gspca_dev, 10); you set 9 values and you output 10 values. BTW, as many of these USB control messages are constant, you should better use static data or a table format (byte count, values)*. Regards. -- Ken ar c'hentan | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld ATSC 115 all static
Hi Mauro, Trent, On Fri, 16 Jan 2009 00:02:52 -0200, Mauro Carvalho Chehab wrote: On Thu, 15 Jan 2009 10:33:15 -0800 (PST) Trent Piepho xy...@speakeasy.org wrote: On Thu, 15 Jan 2009, Mauro Carvalho Chehab wrote: It has nothing to do with the load order. It is related to i2c binding. With the current approach (before Hans patch), the i2c core will try to bind the tuner after having 2 conditions satisfied: 1) I2C bus were registered; 2) tuner code is available. So, if you load tuner before saa7134 (or have it compiled in-kernel), the code will try to probe tuners at the moment you register i2c bus. Otherwise, it will try to bind only when request_module is handled. Some devices with DVB has an internal i2c gate. For a subset of these, the i2c gate is inside the tuner. So, you need to bind the tuner device before probing for the frontends. On the other set of devices, the gate is inside the demod. So, you need to turn the i2c gate before running the i2c address seek for tuner. I wonder if a better way to fix these problems is to use virtual I2C busses for the gate? For now, we should finish the Hans approach, since it also helps to stop using the legacy i2c methods. After having all drivers using it, we can do some cleanup at the drivers. However, I like the idea of providing a better support for those buses that have an i2c switch inside (I don't like to call it virtual - it is a real i2c bus, where part of the bus is controlled by a switch). I second this, the term virtual to qualify these buses is improper. Better speak in terms of I2C segments, multiplexers and gates. Gates can be seen as a degenerated form of multiplexers, but this is not necessarily the best approach. When a device has some kind of i2c gate, it creates a new I2C adapter for the devices behind the gate. The code for this virtual i2c adapter can just open the gate, pass of the request to the main i2c adapter, then close the gate. Creating a new i2c adapter should trigger the i2c drivers that scan to do so and find new devices behind the gate. It seems like this would solve the scan order problem, since the bus the tuner/demod/whatever is on won't exist until the gate it is behind can be properly controlled. Well, the scanning order problem is IMHO better resolved by instantiating the devices explicitly instead of letting the i2c subsystem probe for them. Everything is already in place to do this, and a number of drivers are already being converted in this direction. There are a number of additional benefits too. There are many devices that can be behind many different kinds of gates. So we have all these gate control functions that must be called manually from all over the place. This adds bloat and developers are always forgetting to call them, which doesn't cause any problem they notice because their card doesn't have a gate. With manual gate control, we must remember to close the gate when done with the device. But this isn't always done and the gate is left open. These gates are there for a reason, to shield RF devices from noise created by the I2C bus, and so leaving them opens impairs RF performance. And when the gate is only controlled by the driver in the kernel, it is hard to manually debug/test i2c devices from userspace with i2c-dev. I'm not sure if we should implement it inside v4l core, or at i2c-core. This is an excellent question, I don't know for sure myself. Maybe the latter could be more appropriate, since maybe some other devices could have similar issues, like the embedded processor/controllers, where you have an i2c bus there connected to several different devices, like those used on cellular phones. I bet that some embedded devices uses the same i2c bus for more than one subsystem (like having a radio and/or a webcam and some temperature/battery sensors). In this case, a virtual i2c support could be interesting. Maybe Jean could give us some suggestions about the better approach for such cases. Support for I2C segments and multiplexers is needed for other systems, yes. Some embedded systems have such multiplexers, and even some PC motherboards do. The goal can be to isolate some portions of the I2C bus, but in most cases it is simply a way to have more than one I2C device with the same I2C address on a given bus. Support for these multiplexers still isn't in the kernel so we are free to imagine how an implementation could look like. As far as the gate issue is concerned, the key point is whether multiplexers would always have at least one outer segment selected, or not. In terms of performance, that would be preferable, so that consecutive accesses to a given chip on any outer segment are fast (no mux change). But then we can't treat gates as muxes, because for gates we want the outer segment isolated when we don't use it. This
Re: Fw: [PATCH] E506r-composite-input
Hi,
Am Donnerstag, den 15.01.2009, 23:35 -0200 schrieb Mauro Carvalho
Chehab:
Message sent to the wrong address... it is not *-owner ;)
Forwarded message:
Date: Thu, 15 Jan 2009 21:58:55 +0900
From: Tim Farrington t...@iinet.net.au
To: Mauro Carvalho Chehab mche...@infradead.org,
linux-media-ow...@vger.kernel.org
Subject: [PATCH] E506r-composite-input
Make correction to composite input plus svideo input
to Avermedia E506R
Signed-off-by: Tim Farrington t...@iinet.net.au
Cheers,
Mauro
Unterschied
zwischen
Dateien-Anlage
(E506r_composite.patch)
Only in .: E506r_composite.patch
diff
-upr ./linux/drivers/media/video/saa7134/saa7134-cards.c
../a/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c
--- ./linux/drivers/media/video/saa7134/saa7134-cards.c 2009-01-15
21:42:05.0 +0900
+++ ../a/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c
2009-01-15 21:45:29.0 +0900
@@ -4362,13 +4362,13 @@ struct saa7134_board saa7134_boards[] =
.amux = TV,
.tv = 1,
}, {
-.name = name_comp,
-.vmux = 0,
+.name = name_comp1,
+.vmux = 3,
.amux = LINE1,
}, {
.name = name_svideo,
.vmux = 8,
-.amux = LINE1,
+.amux = LINE2,
} },
.radio = {
.name = name_radio,
Mauro, I was never sure about why that patch, which introduced name_comp
was accepted very, very late in the drivers history. It previously
always started the enumeration with name_comp1.
If it should have any sense at all, I thought it was to avoid ambiguity
on such devices which have only one Composite input.
Tim, are you sure that Composite amux is LINE1 and S-Video LINE2?
It would be the first and only card ever seen with different amux for
those inputs and should be noted as unusual case. I doubt it has two
different audio-in connectors.
Cheers,
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Twinhan DST stops working under latest v4l-dvb
It seems the latest v4l-dvb causes issues with my Twinhan 1020 bttv: driver version 0.9.17 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). ACPI: PCI Interrupt :05:08.0[A] - Link [APC3] - GSI 18 (level, low) - IRQ 18 bttv0: Bt878 (rev 17) at :05:08.0, irq: 18, latency: 32, mmio: 0xcb00 bttv0: using: Twinhan DST + clones [card=113,insmod option] bttv0: gpio: en=, out= in=00fefffe [init] bttv0: tuner absent bttv0: add subdevice dvb0 bt878: AUDIO driver version 0.0.0 loaded dvb_bt8xx: unable to determine DMA core of card 0, dvb_bt8xx: if you have the ALSA bt87x audio driver installed, try removing it. dvb-bt8xx: probe of dvb0 failed with error -14 i tried unloading all the sound modules made no difference (even though i didnt have the bt87x module loaded) This card works on earlier kernel modules. Any ideas? -- To unsubscribe from this list: send the line unsubscribe 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: The pvrusb2 stuff you just pulled
On Thu, 15 Jan 2009 23:57:01 -0600 (CST) Mike Isely is...@isely.net wrote: Mauro: Do you not find it strange that you show up as the credited source for my recent changesets on the summary page http://linuxtv.org/hg/v4l-dvb? (See 10236 - 10240.) I suspect it's because you cherry picked them, but that doesn't make it right. I could have sworn in the past that I've been able to pull in changes / contributions into hg from other pvrusb2 users and successfully preserved the credit in the change list summary. What's the problem here? Hi Mike, This is due to a deficiency at mercurial. On git, there are two concepts on their meta-tags: patch author and committer. Unfortunately, mercurial has only one meta-tag: user. When a patch is cherry-picked, mercurial will use the current user as his user meta-tag. This indicates who applied the patch at the mercurial tree. In order to preserve both information on our tree, we are using the user meta tag for the committer, and the From: field at the patch description as the patch author, as stated at README.patches. The committer info is important to allow us to see from what tree a patch came. The -git conversion scripts properly handle the From: info when giving the credits for the patch. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe 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: Fw: [PATCH] E506r-composite-input
hermann pitton wrote:
Hi,
Am Donnerstag, den 15.01.2009, 23:35 -0200 schrieb Mauro Carvalho
Chehab:
Message sent to the wrong address... it is not *-owner ;)
Forwarded message:
Date: Thu, 15 Jan 2009 21:58:55 +0900
From: Tim Farrington t...@iinet.net.au
To: Mauro Carvalho Chehab mche...@infradead.org,
linux-media-ow...@vger.kernel.org
Subject: [PATCH] E506r-composite-input
Make correction to composite input plus svideo input
to Avermedia E506R
Signed-off-by: Tim Farrington t...@iinet.net.au
Cheers,
Mauro
Unterschied
zwischen
Dateien-Anlage
(E506r_composite.patch)
Only in .: E506r_composite.patch
diff
-upr ./linux/drivers/media/video/saa7134/saa7134-cards.c
../a/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c
--- ./linux/drivers/media/video/saa7134/saa7134-cards.c 2009-01-15
21:42:05.0 +0900
+++ ../a/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c
2009-01-15 21:45:29.0 +0900
@@ -4362,13 +4362,13 @@ struct saa7134_board saa7134_boards[] =
.amux = TV,
.tv = 1,
}, {
-.name = name_comp,
-.vmux = 0,
+.name = name_comp1,
+.vmux = 3,
.amux = LINE1,
}, {
.name = name_svideo,
.vmux = 8,
-.amux = LINE1,
+.amux = LINE2,
} },
.radio = {
.name = name_radio,
Mauro, I was never sure about why that patch, which introduced name_comp
was accepted very, very late in the drivers history. It previously
always started the enumeration with name_comp1.
If it should have any sense at all, I thought it was to avoid ambiguity
on such devices which have only one Composite input.
Tim, are you sure that Composite amux is LINE1 and S-Video LINE2?
It would be the first and only card ever seen with different amux for
those inputs and should be noted as unusual case. I doubt it has two
different audio-in connectors.
Cheers,
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hermann,
For the record, Avermedia are well known for not respecting the GPL, and
finding ways to
have as many different chip combinations on as many different cards as
they can,
and as many different input configurations as they can invent.
(Try looking at all the different chip combinations they use on all
their Volar sticks.)
Avermedia make the E506R, which is a PCMCIA card.
It has a FM Radio input, a DVB-T/Analog Television input and a Remote
Control.
It also has a mini-SCSI input, to which is connected an Audio Left
cable, an Audio Right cable, and a Composite Video cable;
also separately connected to the SCSI is a S-Video input cable.
Regards,
Timf
--
To unsubscribe from this list: send the line unsubscribe 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 ATSC 115 all static
On Fri, 16 Jan 2009, Jean Delvare wrote:
Hi Mauro, Trent,
On Fri, 16 Jan 2009 00:02:52 -0200, Mauro Carvalho Chehab wrote:
On Thu, 15 Jan 2009 10:33:15 -0800 (PST)
Trent Piepho xy...@speakeasy.org wrote:
On Thu, 15 Jan 2009, Mauro Carvalho Chehab wrote:
For now, we should finish the Hans approach, since it also helps to stop
using
the legacy i2c methods. After having all drivers using it, we can do some
cleanup at the drivers.
How will this work for drivers like bttv, where the i2c address of the
tuner chips isn't know for every supported card?
However, I like the idea of providing a better support for those buses that
have an i2c switch inside (I don't like to call it virtual - it is a real
i2c
bus, where part of the bus is controlled by a switch).
I second this, the term virtual to qualify these buses is improper.
Better speak in terms of I2C segments, multiplexers and gates. Gates
can be seen as a degenerated form of multiplexers, but this is not
necessarily the best approach.
Maybe I should say virtual i2c adapter. The driver registers another i2c
adapter that does not represent a new i2c master, but instead a new i2c bus
segment on an existing i2c master.
When a device has some kind of i2c gate, it creates a new
I2C adapter for the devices behind the gate. The code for this virtual
i2c
adapter can just open the gate, pass of the request to the main i2c
adapter, then close the gate. Creating a new i2c adapter should trigger
the i2c drivers that scan to do so and find new devices behind the gate.
It seems like this would solve the scan order problem, since the bus the
tuner/demod/whatever is on won't exist until the gate it is behind can be
properly controlled.
Well, the scanning order problem is IMHO better resolved by
instantiating the devices explicitly instead of letting the i2c
subsystem probe for them. Everything is already in place to do this,
and a number of drivers are already being converted in this direction.
The problem is that then one needs to know where the i2c devices are, and
this is not known for all cards. When the bttv driver was converted to use
the new i2c subsystem a decade ago and used probing as the only way to find
devices, I said it was a bad idea. But now we have this database of
cards with no information about what chips and what address.
There are a number of additional benefits too. There are many devices
that
can be behind many different kinds of gates. So we have all these gate
control functions that must be called manually from all over the place.
This adds bloat and developers are always forgetting to call them, which
doesn't cause any problem they notice because their card doesn't have a
gate.
With manual gate control, we must remember to close the gate when done
with
the device. But this isn't always done and the gate is left open. These
gates are there for a reason, to shield RF devices from noise created by
the I2C bus, and so leaving them opens impairs RF performance.
And when the gate is only controlled by the driver in the kernel, it is
hard to manually debug/test i2c devices from userspace with i2c-dev.
I'm not sure if we should implement it inside v4l core, or at i2c-core.
This is an excellent question, I don't know for sure myself.
Why does either need support?
static int cx88_gate_i2c_xfer(struct i2c_adapter *i2c_adap,
struct i2c_msg *msgs, int num)
{
struct cx88_gate_i2c *gate= i2c_get_adapdata(i2c_adap);
int ret;
cx88_dvb_gate_ctrl(gate-core, 1);
ret = i2c_transfer(gate-core-i2c_adap, msgs, num);
cx88_dvb_gate_ctrl(gate-core, 0);
return ret;
}
...
static struct i2c_algorithm cx88_gate = {
.master_xfer = cx88_gate_i2c_xfer,
...
};
static struct i2c_adapter adap = {
.algo = cx88_gate,
...
};
struct cx88_gate_i2c *gate = kzalloc(sizeof(typeof(*gate)), GFP_KERNEL);
gate-core = core;
i2c_set_adapdata(adap, gate);
i2c_add_adapter(adap);
What part needs to go somewhere else?
of 2 other:
* At I2C bus driver level. We can have a pre-transfer handler and a
post-transfer handler, which does what needs to be done (like opening
and closing a gate) based on the address of the device that is being
accessed. I had discussed this approach with Michael Krufky long ago.
This won't work when muxes are used to put multiple i2c devices with the
same address behind a single master.
It still has the problem of probe order when one wants to scan for chips.
The i2c core does scanning when a new adapter is created. But, suppose the
mux is an i2c device on the adapter? In order for the scanner to find
anything behind the mux, it needs to be detected and working before the bus
is scanned. But this may not happen. Say one
[PATCH 2/4] em28xx: Clock (XCLK) Cleanup
em28xx: Clock (XCLK) Cleanup
From: Robert Krakora rob.krak...@messagenetsystems.com
Clock (XCLK) Cleanupt
Priority: normal
Signed-off-by: Robert Krakora rob.krak...@messagenetsystems.com
diff -r 6896782d783d linux/drivers/media/video/em28xx/em28xx-core.c
--- a/linux/drivers/media/video/em28xx/em28xx-core.cWed Jan 14
10:06:12 2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-core.cWed Jan 14
12:47:00 2009 -0500
@@ -424,7 +424,7 @@
xclk = dev-board.xclk 0x7f;
if (!dev-mute)
- xclk |= 0x80;
+ xclk |= EM28XX_XCLK_AUDIO_UNMUTE;
ret = em28xx_write_reg(dev, EM28XX_R0F_XCLK, xclk);
if (ret 0)
@@ -437,6 +437,10 @@
/* Sets volume */
if (dev-audio_mode.ac97 != EM28XX_NO_AC97) {
int vol;
+
+ em28xx_write_ac97(dev, AC97_POWER_DOWN_CTRL, 0x4200);
+ em28xx_write_ac97(dev, AC97_EXT_AUD_CTRL, 0x0031);
+ em28xx_write_ac97(dev, AC97_PCM_IN_SRATE, 0xbb80);
/* LSB: left channel - both channels with the same level */
vol = (0x1f - dev-volume) | ((0x1f - dev-volume) 8);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] em28xx: Fix audio URB transfer buffer memory leak and race condition/corruption of capture pointer
em28xx: Fix audio URB transfer buffer memory leak and race
condition/corruption of capture pointer
From: Robert Krakora rob.krak...@messagenetsystems.com
Fix audio URB transfer buffer memory leak and race
condition/corruption of capture pointer
Leak fix kindly contributed by Pádraig Brady.
Priority: normal
Signed-off-by: Robert Krakora rob.krak...@messagenetsystems.com
diff -r 7981bdd4e25a linux/drivers/media/video/em28xx/em28xx-audio.c
--- a/linux/drivers/media/video/em28xx/em28xx-audio.c Mon Jan 12
00:18:04 2009 +
+++ b/linux/drivers/media/video/em28xx/em28xx-audio.c Thu Jan 15
17:27:27 2009 -0500
@@ -66,6 +66,9 @@
usb_unlink_urb(dev-adev.urb[i]);
usb_free_urb(dev-adev.urb[i]);
dev-adev.urb[i] = NULL;
+
+ kfree(dev-adev.transfer_buffer[i]);
+ dev-adev.transfer_buffer[i] = NULL;
}
return 0;
@@ -458,11 +461,15 @@
*substream)
#endif
{
+ unsigned long flags;
+
struct em28xx *dev;
-
snd_pcm_uframes_t hwptr_done;
+
dev = snd_pcm_substream_chip(substream);
+ spin_lock_irqsave(dev-adev.slock, flags);
hwptr_done = dev-adev.hwptr_done_capture;
+ spin_unlock_irqrestore(dev-adev.slock, flags);
return hwptr_done;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] em28xx: Fix for KWorld 330U Board
em28xx: Fix for KWorld 330U Board
From: Robert Krakora rob.krak...@messagenetsystems.com
Fix for KWorld 330U Board
Many thanks to Devin and Mauro!!!
Priority: normal
Signed-off-by: Robert Krakora rob.krak...@messagenetsystems.com
diff -r 6896782d783d linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c Wed Jan 14
10:06:12 2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Wed Jan 14
12:46:43 2009 -0500
@@ -114,6 +114,18 @@
{ -1, -1, -1, -1},
};
#endif
+
+static struct em28xx_reg_seq kworld_330u_analog[] = {
+ {EM28XX_R08_GPIO, 0x6d, ~EM_GPIO_4, 10},
+ {EM2880_R04_GPO,0x00, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
+static struct em28xx_reg_seq kworld_330u_digital[] = {
+ {EM28XX_R08_GPIO, 0x6e, ~EM_GPIO_4, 10},
+ {EM2880_R04_GPO,0x08, 0xff, 10},
+ { -1, -1, -1, -1},
+};
/* Callback for the most boards */
static struct em28xx_reg_seq default_tuner_gpio[] = {
@@ -1242,29 +1254,33 @@
.gpio = hauppauge_wintv_hvr_900_analog,
} },
},
- [EM2883_BOARD_KWORLD_HYBRID_A316] = {
+ [EM2883_BOARD_KWORLD_HYBRID_330U] = {
.name = Kworld PlusTV HD Hybrid 330,
.tuner_type = TUNER_XC2028,
.tuner_gpio = default_tuner_gpio,
.decoder = EM28XX_TVP5150,
.mts_firmware = 1,
.has_dvb = 1,
- .dvb_gpio = default_digital,
+ .dvb_gpio = kworld_330u_digital,
+ .xclk = EM28XX_XCLK_FREQUENCY_12MHZ,
+ .i2c_speed= EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_EEPROM_ON_BOARD | EM28XX_I2C_EEPROM_KEY_VALID,
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = TVP5150_COMPOSITE0,
.amux = EM28XX_AMUX_VIDEO,
- .gpio = default_analog,
+ .gpio = kworld_330u_analog,
+ .aout = EM28XX_AOUT_PCM_IN | EM28XX_AOUT_PCM_STEREO,
}, {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = TVP5150_COMPOSITE1,
.amux = EM28XX_AMUX_LINE_IN,
- .gpio = hauppauge_wintv_hvr_900_analog,
+ .gpio = kworld_330u_analog,
+ .aout = EM28XX_AOUT_PCM_IN | EM28XX_AOUT_PCM_STEREO,
}, {
.type = EM28XX_VMUX_SVIDEO,
.vmux = TVP5150_SVIDEO,
.amux = EM28XX_AMUX_LINE_IN,
- .gpio = hauppauge_wintv_hvr_900_analog,
+ .gpio = kworld_330u_analog,
} },
},
[EM2820_BOARD_COMPRO_VIDEOMATE_FORYOU] = {
@@ -1318,7 +1334,7 @@
.driver_info = EM2880_BOARD_KWORLD_DVB_310U },
#endif
{ USB_DEVICE(0xeb1a, 0xa316),
- .driver_info = EM2883_BOARD_KWORLD_HYBRID_A316 },
+ .driver_info = EM2883_BOARD_KWORLD_HYBRID_330U },
{ USB_DEVICE(0xeb1a, 0xe320),
.driver_info = EM2880_BOARD_MSI_DIGIVOX_AD_II },
{ USB_DEVICE(0xeb1a, 0xe323),
@@ -1594,6 +1610,10 @@
case EM2880_BOARD_PINNACLE_PCTV_HD_PRO:
/* FIXME: Better to specify the needed IF */
ctl-demod = XC3028_FE_DEFAULT;
+ break;
+ case EM2883_BOARD_KWORLD_HYBRID_330U:
+ ctl-demod = XC3028_FE_CHINA;
+ ctl-fname = XC2028_DEFAULT_FIRMWARE;
break;
default:
ctl-demod = XC3028_FE_OREN538;
diff -r 6896782d783d linux/drivers/media/video/em28xx/em28xx-dvb.c
--- a/linux/drivers/media/video/em28xx/em28xx-dvb.c Wed Jan 14
10:06:12 2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-dvb.c Wed Jan 14
12:47:00 2009 -0500
@@ -29,6 +29,7 @@
#include lgdt330x.h
#include zl10353.h
+#include s5h1409.h
#ifdef EM28XX_DRX397XD_SUPPORT
#include drx397xD.h
#endif
@@ -231,6 +232,15 @@
.no_tuner = 1,
.parallel_ts = 1,
.if2 = 45600,
+};
+
+static struct s5h1409_config em28xx_s5h1409_with_xc3028 = {
+ .demod_address = 0x32 1,
+ .output_mode = S5H1409_PARALLEL_OUTPUT,
+ .gpio = S5H1409_GPIO_OFF,
+ .inversion = S5H1409_INVERSION_OFF,
+ .status_mode = S5H1409_DEMODLOCKING,
+ .mpeg_timing = S5H1409_MPEGTIMING_CONTINOUS_NONINVERTING_CLOCK
};
#ifdef EM28XX_DRX397XD_SUPPORT
@@ -413,7 +423,6 @@
case EM2883_BOARD_HAUPPAUGE_WINTV_HVR_850:
case EM2883_BOARD_HAUPPAUGE_WINTV_HVR_950:
case EM2880_BOARD_PINNACLE_PCTV_HD_PRO:
-
[PATCH 4/4] em28xx: Fix for KWorld 330U AC97
em28xx: Fix for KWorld 330U AC97
From: Robert Krakora rob.krak...@messagenetsystems.com
Fix for KWorld 330U AC97
Many thanks to Devin and Mauro again!!!
Priority: normal
Signed-off-by: Robert Krakora rob.krak...@messagenetsystems.com
diff -r 6896782d783d linux/drivers/media/video/em28xx/em28xx-core.c
--- a/linux/drivers/media/video/em28xx/em28xx-core.cWed Jan 14
10:06:12 2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-core.cWed Jan 14
12:47:00 2009 -0500
@@ -424,7 +424,7 @@
xclk = dev-board.xclk 0x7f;
if (!dev-mute)
- xclk |= 0x80;
+ xclk |= EM28XX_XCLK_AUDIO_UNMUTE;
ret = em28xx_write_reg(dev, EM28XX_R0F_XCLK, xclk);
if (ret 0)
@@ -437,6 +437,10 @@
/* Sets volume */
if (dev-audio_mode.ac97 != EM28XX_NO_AC97) {
int vol;
+
+ em28xx_write_ac97(dev, AC97_POWER_DOWN_CTRL, 0x4200);
+ em28xx_write_ac97(dev, AC97_EXT_AUD_CTRL, 0x0031);
+ em28xx_write_ac97(dev, AC97_PCM_IN_SRATE, 0xbb80);
/* LSB: left channel - both channels with the same level */
vol = (0x1f - dev-volume) | ((0x1f - dev-volume) 8);
--
To unsubscribe from this list: send the line unsubscribe 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 ATSC 115 all static
Hi Trent,
On Fri, 16 Jan 2009 05:34:59 -0800 (PST), Trent Piepho wrote:
On Fri, 16 Jan 2009, Jean Delvare wrote:
Hi Mauro, Trent,
On Fri, 16 Jan 2009 00:02:52 -0200, Mauro Carvalho Chehab wrote:
For now, we should finish the Hans approach, since it also helps to stop
using
the legacy i2c methods. After having all drivers using it, we can do some
cleanup at the drivers.
How will this work for drivers like bttv, where the i2c address of the
tuner chips isn't know for every supported card?
Is this a problem in practice? My understanding was that I2C gates were
relatively recent in the history of V4L devices, so I assumed that for
devices with an I2C gate we would know where the devices are.
(...)
Well, the scanning order problem is IMHO better resolved by
instantiating the devices explicitly instead of letting the i2c
subsystem probe for them. Everything is already in place to do this,
and a number of drivers are already being converted in this direction.
The problem is that then one needs to know where the i2c devices are, and
this is not known for all cards. When the bttv driver was converted to use
the new i2c subsystem a decade ago and used probing as the only way to find
devices, I said it was a bad idea. But now we have this database of
cards with no information about what chips and what address.
I understand the problem. This is why even the new-style (standard) i2c
device driver binding still offers two flavors of device detection, to
handle the older devices.
I'm not sure if we should implement it inside v4l core, or at i2c-core.
This is an excellent question, I don't know for sure myself.
Why does either need support?
static int cx88_gate_i2c_xfer(struct i2c_adapter *i2c_adap,
struct i2c_msg *msgs, int num)
{
struct cx88_gate_i2c *gate= i2c_get_adapdata(i2c_adap);
int ret;
cx88_dvb_gate_ctrl(gate-core, 1);
ret = i2c_transfer(gate-core-i2c_adap, msgs, num);
cx88_dvb_gate_ctrl(gate-core, 0);
return ret;
}
...
static struct i2c_algorithm cx88_gate = {
.master_xfer = cx88_gate_i2c_xfer,
...
};
static struct i2c_adapter adap = {
.algo = cx88_gate,
...
};
struct cx88_gate_i2c *gate = kzalloc(sizeof(typeof(*gate)), GFP_KERNEL);
gate-core = core;
i2c_set_adapdata(adap, gate);
i2c_add_adapter(adap);
What part needs to go somewhere else?
This is indeed a possible implementation. One could argue though that
it's a bit overkill to instantiate a separate i2c_adapter just for a
gate. There are also caveats you must pay attention to. Two things in
particular that come to my mind:
* You must set the adapter depth properly, otherwise lockdep will
complain.
* Your proposal above, in its simple form, is incompatible with I2C
device detection, because devices which are before the gate would be
double-detected (once on each segment.)
The first point is very easy to handle, the second is a little more
complicated. Basically you should add an address check at the beginning
of cx88_gate_i2c_xfer() to reject all transfers except to the device
you know is behind the gate.
At which point it is no longer clear why you want to have 2
i2c_adapters. You can have just one which opens (and closes) the gate
automatically for the right I2C address and not for the other addresses.
of 2 other:
* At I2C bus driver level. We can have a pre-transfer handler and a
post-transfer handler, which does what needs to be done (like opening
and closing a gate) based on the address of the device that is being
accessed. I had discussed this approach with Michael Krufky long ago.
This won't work when muxes are used to put multiple i2c devices with the
same address behind a single master.
Sorry for not being clear, I was only trying to address the gate issue
here, not the (more complex) multiplexing issue. I am not aware of V4L
devices having real I2C muxes?
It still has the problem of probe order when one wants to scan for chips.
The i2c core does scanning when a new adapter is created. But, suppose the
mux is an i2c device on the adapter? In order for the scanner to find
anything behind the mux, it needs to be detected and working before the bus
is scanned. But this may not happen. Say one calls:
i2c_add_adapter(adap); i2c_new_device(adap, the_mux);
If the client driver for the device behind the mux uses probing, and is
already loaded when i2c_add_adapter() is called, then it will be probed for
before the i2c_new_device() call and won't be found because the mux isn't
working.
You are right, this is a problem.
If instead the mux driver created a new i2c adapter for the segment(s)
behind it, which would happen when i2c_new_device() is called, then those
segments would be probed at the correct time.
This doesn't fully solve the problem, because you have
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
On Thu, 15 Jan 2009, Mauro Carvalho Chehab wrote: OK. Well, the usage he wants is something that is better fitted by using sysfs info. There, you should have all information to uniquely identify a device: driver, bus location (on PCI this can be relevant), MAC (for dvb devices), etc. IMO, the proper way is to add the serial number at sysfs, and let the bus_info point to the proper bus location. Having the bus location, an userspace app can seek the sysfs and look for the udev info. For example, on an em28xx analog device I have here, bus_info returns 1-3. Ok, this is a very bad way to specify the bus. IMO, we should use usb_make_path() to generate the canonical name for USB buses. I will review what the pvrusb2 driver is doing and change it to use usb_make_path() if needed. However given all the other information about the device that querycap returns, a serial number in that batch would be right at home there. Requiring an app to go through everything you described is a pretty complex process for what should be very simple datum. In any case, right now the serial number in the pvrusb2 is not available through that means because I haven't done anything to make it available to udev. I'd like to do something, but so far I have found no information on how to make that happen. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Cross-posting linux-media, linux-dvb etc
Hi Mauro, Since the creation of linux-media@vger.kernel.org I'm seeing lots of cross-postings between linux-dvb, linux-media and video4linux. This is a little bit annoying if you are subscribed to all of those lists. Worse is, that some people only send requests to linux-media. Like that linux-dvb-only subscribers can't help... Why not closing linux-dvb (and video4linux) and transferring the currently subscribed users to linux-media automatically? regards, Patrick. -- To unsubscribe from this list: send the line unsubscribe 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] Cross-posting linux-media, linux-dvb etc
On Friday 16 January 2009 15:48:45 Patrick Boettcher wrote: Hi Mauro, Since the creation of linux-media@vger.kernel.org I'm seeing lots of cross-postings between linux-dvb, linux-media and video4linux. This is a little bit annoying if you are subscribed to all of those lists. Worse is, that some people only send requests to linux-media. Like that linux-dvb-only subscribers can't help... Why not closing linux-dvb (and video4linux) and transferring the currently subscribed users to linux-media automatically? I agree with Patrick. I suggest a daily automatic posting to linux-dvb and video4linux telling people that on February 1st these lists disappear and that they should use linux-media instead. Then they can be closed down at the end of the month. I definitely wouldn't wait any longer since it is rather messy right now. One month transition period seems reasonable to me. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe 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 - Flexcop Streaming watchdog (VDSB)
Hi lists,
For years there has been the Video Data Stream Borken-error with VDR and
Technisat cards: The error occured randomly and unfrequently. A
work-around for that problem was to restart VDR and let the driver reset
the pid-filtering and streaming interface.
In fact it turned out, that the problem is worse with setups not based on
VDR and the VDSB-error could be really easily reproduced (I'm not sure
if this applies to all generations on SkyStar2-card). I'm skipping the
description of the problem here...
Attached you'll find a patch which works around the hardware bug which is
causing VDSB-error without needing to reload the driver.
There a struct-work-watchdog looking at the number of irq-received while
having PIDs active in the PID-filter. If no IRQs are received, the
pid-filter-system is reset.
It seems to fix the problem and so far I've not seen any false positives
(like resetting the pid-filter even though streaming is working fine).
Before asking to pull the patch I'd like to discuss an issue: my
work-around is iterating over the pid-filter-list in the dvb_demux. I'm
doing this in the struct-work-callback. In dvb_demux.c I see that this
list is protected with a spinlock. When I now try to take the spinlock in
the work-function I'll get a nice message saying, that I cannot do take a
spinlock in a work-function.
What can I do? What is the proper way to protect access to this list? Is
it needed at all?
thanks for you input in advance,
Patrick.
--
Mail: patrick.boettc...@desy.de
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/diff -r 7981bdd4e25a linux/drivers/media/dvb/b2c2/flexcop-hw-filter.c
--- a/linux/drivers/media/dvb/b2c2/flexcop-hw-filter.c Mon Jan 12 00:18:04
2009 +
+++ b/linux/drivers/media/dvb/b2c2/flexcop-hw-filter.c Fri Jan 16 15:46:32
2009 +0100
@@ -179,7 +179,7 @@
/* if it was the first or last feed request change the stream-status */
if (fc-feedcount == onoff) {
- flexcop_rcv_data_ctrl(fc,onoff);
+ flexcop_rcv_data_ctrl(fc, onoff);
if (fc-stream_control) /* device specific stream control */
fc-stream_control(fc,onoff);
@@ -192,6 +192,7 @@
return 0;
}
+EXPORT_SYMBOL(flexcop_pid_feed_control);
void flexcop_hw_filter_init(struct flexcop_device *fc)
{
diff -r 7981bdd4e25a linux/drivers/media/dvb/b2c2/flexcop-pci.c
--- a/linux/drivers/media/dvb/b2c2/flexcop-pci.cMon Jan 12 00:18:04
2009 +
+++ b/linux/drivers/media/dvb/b2c2/flexcop-pci.cFri Jan 16 15:46:32
2009 +0100
@@ -13,9 +13,9 @@
module_param(enable_pid_filtering, int, 0444);
MODULE_PARM_DESC(enable_pid_filtering, enable hardware pid filtering:
supported values: 0 (fullts), 1);
-static int irq_chk_intv;
+static int irq_chk_intv = 100;
module_param(irq_chk_intv, int, 0644);
-MODULE_PARM_DESC(irq_chk_intv, set the interval for IRQ watchdog (currently
just debugging).);
+MODULE_PARM_DESC(irq_chk_intv, set the interval for IRQ streaming watchdog.);
#ifdef CONFIG_DVB_B2C2_FLEXCOP_DEBUG
#define dprintk(level,args...) \
@@ -34,7 +34,7 @@
static int debug;
module_param(debug, int, 0644);
-MODULE_PARM_DESC(debug, set debug level (1=info,2=regs,4=TS,8=irqdma
(|-able)). DEBSTATUS);
+MODULE_PARM_DESC(debug, set debug level (1=info,2=regs,4=TS,8=irqdma,16=check
(|-able)). DEBSTATUS);
#define DRIVER_VERSION 0.1
#define DRIVER_NAME Technisat/B2C2 FlexCop II/IIb/III Digital TV PCI Driver
@@ -58,6 +58,8 @@
int active_dma1_addr; /* 0 = addr0 of dma1; 1 = addr1 of dma1 */
u32 last_dma1_cur_pos; /* position of the pointer last time the
timer/packet irq occured */
int count;
+ int count_prev;
+ int stream_problem;
spinlock_t irq_lock;
@@ -115,18 +117,47 @@
#endif
struct flexcop_device *fc = fc_pci-fc_dev;
- flexcop_ibi_value v = fc-read_ibi_reg(fc,sram_dest_reg_714);
+ if (fc-feedcount) {
+ flexcop_ibi_value v = fc-read_ibi_reg(fc,sram_dest_reg_714);
- flexcop_dump_reg(fc_pci-fc_dev,dma1_000,4);
+ // flexcop_dump_reg(fc_pci-fc_dev,dma1_000,4);
- if (v.sram_dest_reg_714.net_ovflow_error)
- deb_chk(sram net_ovflow_error\n);
- if (v.sram_dest_reg_714.media_ovflow_error)
- deb_chk(sram media_ovflow_error\n);
- if (v.sram_dest_reg_714.cai_ovflow_error)
- deb_chk(sram cai_ovflow_error\n);
- if (v.sram_dest_reg_714.cai_ovflow_error)
- deb_chk(sram cai_ovflow_error\n);
+#if 0
+ deb_chk(net_ovflow_error: %d, media_ovflow_error: %d,
cai_ovflow_error: %d, cao_ovflow_error: %d, sram_dma: %d, maximumfill: %d\n,
+ v.sram_dest_reg_714.net_ovflow_error,
+ v.sram_dest_reg_714.media_ovflow_error,
+ v.sram_dest_reg_714.cai_ovflow_error,
+
Re: [linux-dvb] Cross-posting linux-media, linux-dvb etc
On Fri, 16 Jan 2009, Hans Verkuil wrote: On Friday 16 January 2009 15:48:45 Patrick Boettcher wrote: Hi Mauro, Since the creation of linux-media@vger.kernel.org I'm seeing lots of cross-postings between linux-dvb, linux-media and video4linux. This is a little bit annoying if you are subscribed to all of those lists. Worse is, that some people only send requests to linux-media. Like that linux-dvb-only subscribers can't help... Why not closing linux-dvb (and video4linux) and transferring the currently subscribed users to linux-media automatically? I agree with Patrick. I suggest a daily automatic posting to linux-dvb and video4linux telling people that on February 1st these lists disappear and that they should use linux-media instead. Then they can be closed down at the end of the month. I definitely wouldn't wait any longer since it is rather messy right now. One month transition period seems reasonable to me. Amen to that. I've been telling people to go over to linux-media, but old habits are hard to break. It's time to actually make a clean break from the old lists. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe 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://linuxtv.org/hg/~mcisely/pvrusb2
On Friday 16 January 2009 15:39:33 Mike Isely wrote:
In any case, right now the serial number in the pvrusb2 is not available
through that means because I haven't done anything to make it available
to udev. I'd like to do something, but so far I have found no
information on how to make that happen.
You shouldn't need to do anything special. The serial number is available
through the parent USB device. It can be used for udev rules through
ATTRS{serial} and in sysfs entry of the video device through device/serial.
Janne
--
To unsubscribe from this list: send the line unsubscribe 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] Cross-posting linux-media, linux-dvb etc
On Fri, Jan 16, 2009 at 4:52 PM, Benny Amorsen benny+use...@amorsen.dk wrote: Mike Isely is...@isely.net writes: Amen to that. I've been telling people to go over to linux-media, but old habits are hard to break. It's time to actually make a clean break from the old lists. Is linux-media available on gmane? Yup, here it is: http://dir.gmane.org/gmane.linux.drivers.video-input-infrastructure and also: http://www.mail-archive.com/linux-media@vger.kernel.org/ Luca -- To unsubscribe from this list: send the line unsubscribe 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] mxl5005s tuner analog support
On Fri, Jan 16, 2009 at 11:32 AM, Andreas linuxdr...@dslextreme.com wrote: Devin I seem to be affected by that 3db loss between the old mxl500x and the mxl5005s driver. Did you ever get the datasheets and is anyone perhaps even working on squeezing a little more out of the driver? -- Gruß Andreas Hello Andreas, The guys at Pinnacle very kindly introduced me to someone over at Maxlinear, and I am trying to get the datasheet. I will be looking at the device's performance more closely over the next couple of weeks as I get it working with the Pinnacle 880e. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line unsubscribe 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] Cross-posting linux-media, linux-dvb etc
Mike Isely is...@isely.net writes: Amen to that. I've been telling people to go over to linux-media, but old habits are hard to break. It's time to actually make a clean break from the old lists. Is linux-media available on gmane? /Benny -- To unsubscribe from this list: send the line unsubscribe 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] Cross-posting linux-media, linux-dvb etc
Mike Isely wrote: On Fri, 16 Jan 2009, Hans Verkuil wrote: On Friday 16 January 2009 15:48:45 Patrick Boettcher wrote: Hi Mauro, Since the creation of linux-media@vger.kernel.org I'm seeing lots of cross-postings between linux-dvb, linux-media and video4linux. This is a little bit annoying if you are subscribed to all of those lists. Worse is, that some people only send requests to linux-media. Like that linux-dvb-only subscribers can't help... Why not closing linux-dvb (and video4linux) and transferring the currently subscribed users to linux-media automatically? I agree with Patrick. I suggest a daily automatic posting to linux-dvb and video4linux telling people that on February 1st these lists disappear and that they should use linux-media instead. Then they can be closed down at the end of the month. I definitely wouldn't wait any longer since it is rather messy right now. One month transition period seems reasonable to me. Amen to that. I've been telling people to go over to linux-media, but old habits are hard to break. It's time to actually make a clean break from the old lists. +1 from me Although I'm not an active developer (I'm just an interested user), reading the lists at the moment is hard... Lars. -- To unsubscribe from this list: send the line unsubscribe 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] Cross-posting linux-media, linux-dvb etc
On Fri, 16 Jan 2009 18:13:26 +0100 Lars Hanisch d...@cinnamon-sage.de wrote: Mike Isely wrote: On Fri, 16 Jan 2009, Hans Verkuil wrote: On Friday 16 January 2009 15:48:45 Patrick Boettcher wrote: Hi Mauro, Since the creation of linux-media@vger.kernel.org I'm seeing lots of cross-postings between linux-dvb, linux-media and video4linux. This is a little bit annoying if you are subscribed to all of those lists. Worse is, that some people only send requests to linux-media. Like that linux-dvb-only subscribers can't help... Why not closing linux-dvb (and video4linux) and transferring the currently subscribed users to linux-media automatically? I agree with Patrick. I suggest a daily automatic posting to linux-dvb and video4linux telling people that on February 1st these lists disappear and that they should use linux-media instead. Then they can be closed down at the end of the month. I definitely wouldn't wait any longer since it is rather messy right now. One month transition period seems reasonable to me. Amen to that. I've been telling people to go over to linux-media, but old habits are hard to break. It's time to actually make a clean break from the old lists. +1 from me Although I'm not an active developer (I'm just an interested user), reading the lists at the moment is hard... Instead of just removing the ML, maybe the better is to change the reply to to linux-media and send an autoreply message to the sender. Lars. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe 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] Cross-posting linux-media, linux-dvb etc
On Fri, 16 Jan 2009 15:59:12 -0200 Mauro Carvalho Chehab mche...@infradead.org wrote: Instead of just removing the ML, maybe the better is to change the reply to to linux-media and send an autoreply message to the sender. Done. Any posts to linux-dvb will receive this message: On Fri, 16 Jan 2009 18:59:48 +0100 linux-dvb-boun...@linuxtv.org wrote: This ML is deprecated. Please use linux-media@vger.kernel.org instead. For more info about linux-media@vger.kernel.org, please read: http://vger.kernel.org/vger-lists.html#linux-media Cheers, Mauro Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe 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] mxl5005s tuner analog support
Am Freitag, 16. Januar 2009 08:35:49 schrieb Devin Heitmueller: Hello Andreas, The guys at Pinnacle very kindly introduced me to someone over at Maxlinear, and I am trying to get the datasheet. I will be looking at the device's performance more closely over the next couple of weeks as I get it working with the Pinnacle 880e. Devin Devin, Thanks for the heads up and the good news! -- Gruß Andreas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] ERRORS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below.) Results of the daily build of v4l-dvb: date:Fri Jan 16 19:00:02 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10241:7981bdd4e25a gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29-rc1-armv5: ERRORS linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29-rc1-armv5-ixp: ERRORS linux-2.6.27-armv5-omap2: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29-rc1-armv5-omap2: ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29-rc1-i686: ERRORS linux-2.6.16.61-m32r: OK linux-2.6.17.14-m32r: OK linux-2.6.18.8-m32r: OK linux-2.6.19.5-m32r: OK linux-2.6.20.21-m32r: OK linux-2.6.21.7-m32r: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc1-m32r: ERRORS linux-2.6.16.61-mips: OK linux-2.6.26-mips: WARNINGS linux-2.6.27-mips: WARNINGS linux-2.6.28-mips: WARNINGS linux-2.6.29-rc1-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29-rc1-powerpc64: ERRORS linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29-rc1-x86_64: ERRORS fw/apps: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc1): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 -- To unsubscribe from this list: send the line unsubscribe 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: Where to store camera properties (upside down, needs sw whitebalance, etc). ?
On Friday 16 January 2009, Olivier Lorin wrote: snip discussion of cameras needing image flipping capability in libv4l The use of the buffer flags makes the life easier as this flag is read for every image. So we can solve for the flip/rotation issues with the help of two new buffer flags: V4L2_BUF_FLAG_NEEDS_HFLIP and V4L2_BUF_FLAG_NEEDS_VFLIP. A driver has to set them properly. Does the rotation or flip(s) apply to every image (e.g. sensor upside down) or change with frames (e.g. Genesys webcams), that no more matters . I can do the patch these days. I do not remember if there is h/v flip functions in the libv4l, maybe they have to be added. Regards, Nol That sounds like a sensible approach. The flip code is already in libv4l but is currently controlled by a static table (v4lconvert_flags) of cameras that need it. It doesn't address the issue of whether libv4l should also provide gamma adjustment, auto white balance and auto gain for cameras that could benefit from it. Again that could be done with a static table but keeping the knowledge in libv4l in step with the list of supported cameras in the kernel won't be easy. Adam -- To unsubscribe from this list: send the line unsubscribe 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: Fw: [PATCH] E506r-composite-input
Hi,
Am Freitag, den 16.01.2009, 20:26 +0900 schrieb Tim Farrington:
hermann pitton wrote:
Hi,
Am Donnerstag, den 15.01.2009, 23:35 -0200 schrieb Mauro Carvalho
Chehab:
Message sent to the wrong address... it is not *-owner ;)
Forwarded message:
Date: Thu, 15 Jan 2009 21:58:55 +0900
From: Tim Farrington t...@iinet.net.au
To: Mauro Carvalho Chehab mche...@infradead.org,
linux-media-ow...@vger.kernel.org
Subject: [PATCH] E506r-composite-input
Make correction to composite input plus svideo input
to Avermedia E506R
Signed-off-by: Tim Farrington t...@iinet.net.au
Cheers,
Mauro
Unterschied
zwischen
Dateien-Anlage
(E506r_composite.patch)
Only in .: E506r_composite.patch
diff
-upr ./linux/drivers/media/video/saa7134/saa7134-cards.c
../a/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c
--- ./linux/drivers/media/video/saa7134/saa7134-cards.c 2009-01-15
21:42:05.0 +0900
+++ ../a/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c
2009-01-15 21:45:29.0 +0900
@@ -4362,13 +4362,13 @@ struct saa7134_board saa7134_boards[] =
.amux = TV,
.tv = 1,
}, {
-.name = name_comp,
-.vmux = 0,
+.name = name_comp1,
+.vmux = 3,
.amux = LINE1,
}, {
.name = name_svideo,
.vmux = 8,
-.amux = LINE1,
+.amux = LINE2,
} },
.radio = {
.name = name_radio,
Mauro, I was never sure about why that patch, which introduced name_comp
was accepted very, very late in the drivers history. It previously
always started the enumeration with name_comp1.
If it should have any sense at all, I thought it was to avoid ambiguity
on such devices which have only one Composite input.
Tim, are you sure that Composite amux is LINE1 and S-Video LINE2?
It would be the first and only card ever seen with different amux for
those inputs and should be noted as unusual case. I doubt it has two
different audio-in connectors.
Cheers,
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hermann,
For the record, Avermedia are well known for not respecting the GPL, and
finding ways to
have as many different chip combinations on as many different cards as
they can,
and as many different input configurations as they can invent.
(Try looking at all the different chip combinations they use on all
their Volar sticks.)
At least they use unique PCI subsystem IDs these days.
Avermedia make the E506R, which is a PCMCIA card.
Can remember when it for the first time appeared on the list ;)
It has a FM Radio input, a DVB-T/Analog Television input and a Remote
Control.
It also has a mini-SCSI input, to which is connected an Audio Left
cable, an Audio Right cable, and a Composite Video cable;
also separately connected to the SCSI is a S-Video input cable.
If you have a single left/right pair as analog audio in, how can it be
for Composite one the LINE1 input pair and for S-Video on the LINE2
input pair of the chip.
There is no gpio switching on an external audio mux visible for these
inputs in the card's entry.
The error is probably taken from the E500 cardbus or I simply don't
understand what should happen on that card with the external audio in.
Unless you confirm you have tested audio on both inputs you modified,
it looks for me like a bug is left.
I thought I did help to fix this on Markus tree already and there was
sound reported for s-video working on LINE1!
I know it have been hard times with this one, but yourself introduced
vmux 0 for Composite over S-Video and now you take it away again ...
Cheers,
Hermann
Regards,
Timf
--
To unsubscribe from this list: send the line unsubscribe 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] Cross-posting linux-media, linux-dvb etc
On Fri, 16 Jan 2009, Patrick Boettcher wrote: Why not closing linux-dvb (and video4linux) and transferring the currently subscribed users to linux-media automatically? Can I offer my opinions to differ? First, I'm only subscribed to -dvb in order to post, yet still I haven't posted what I originally planned to post before unsubscribing until another device fails to work. Luckily the video4linux list was impossible to access (even the archives needed subsciption, furrfu). Anyway, soon after the creation of -media, I saw that the crossposts from v4linux were of no interest to me (I'm only interested in delivery of already-digital payloads, and am not concerned with webcams, analogue radio or TV, remote controls, and so on) -- since then I've skipped something like 2/3 of the posts on -media, and today, I wouldn't want it to appear in my mailbox. But that's just my interest. Also, I seem to recall that one intent of -media was to focus on developer interest, as the initial posts revealed, which also frees developers with better things to do than to explain how to, for example, get a list of channels, or stream a particular channel and be bothered by beginner or simple questions that could be answered by those without developer abilities. Like me. Anyway, it's no big deal to me. I'm used to how the one FreeBSD -multimedia list covers everything including sound, yet typically gets fewer posts in a week than -dvb could see in a day, and I can't see myself investing in another DVB-type receiver soon until DVB-S2 support gets properly rounded out and 100% reliable for all `experimental'-tagged devices, so I'm quite content to browse the list just as I skim the kernel list, or peer in on a few dozen other BSD- type lists whenever I feel like it. yerz, barry bouwsma off to answer a newbie question next -- To unsubscribe from this list: send the line unsubscribe 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] RFC - Flexcop Streaming watchdog (VDSB)
On Fri, 16 Jan 2009, AlexW wrote: Patrick Boettcher wrote: For years there has been the Video Data Stream Borken-error with VDR and Technisat cards: The error occured randomly and unfrequently. A In fact it turned out, that the problem is worse with setups not based on VDR and the VDSB-error could be really easily reproduced (I'm not sure if this applies to all generations on SkyStar2-card). I'm Which generation of cards have this problem? I did not see any VDSB with my two Skystar 2.6D. Same here -- never experienced this ever in some four-ish years with one SkyStar2 of model long forgotten, with that card being the primary one used whenever possible... (in use typically several times per day, sometimes half a day uninterrupted, but on a production machine at 2.6.14-ish) barry bouwsma -- To unsubscribe from this list: send the line unsubscribe 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] Problem with video4linux
Hello Guys, I have installed the patch , and everything works ok now . Best Regards Milorad -- To unsubscribe from this list: send the line unsubscribe 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] dvb-t config for Ukraine_Kiev (ua)
Hi Barry,
Am Samstag, den 17.01.2009, 01:41 +0100 schrieb BOUWSMA Barry:
Hi Dmitry, thank you for your mail!
I am posting part of it to the linux-dvb list, in case someone
there can give more or better information than I do...
On Wed, 14 Jan 2009, vdp wrote:
BB some random 8-bit chars to make sure this gets tagged as utf-8...
sory, it's really Cyrillic - I can read it with
code_table_windows_1251, not like UTF-8, but strange and interesting ;-)
Off-topic here, but to explain --
In the more-than-ten years since I last used the mail program
I am using now, the language and multi-lingual support has
greatly improved -- back then, it would make no effort to try
and display your Cyrillic characters, be they in KOI8-U, or
ISO-8859-5, or whatever - if I had selected to display, say
8859-1, or 8859-2 for Czech.
But today, even with my use of the text console and no windowing
system, I can display Cyrillic, Polish, Slovak, French, Hebrew,
Greek -- all at the same time. Yay!
However, when I sent out a message with Greek characters, I saw
in my local copy of it, that it was sent as 8859-7. But I do
not know if many mailers are able to understand how to convert
from that and display properly with a Unicode font.
The same way, when I sent the Ukranian text, it could be that
some people in western europe, or outside europe entirely, might
not see the characters correctly, because my mailer was set up
to use the smallest possible unique character set tagging,
rather than UTF-8 which has become far more common now (yes,
I should fix my mailer configuration).
So, in order to give the message a UTF-8 character set tagging,
so that it could be displayed simply by any utf-8-aware
xterm with a -10646 font, or on a text console with Unicode
enabled and a font that uses as many possible characters in
the 512 that are available, with a mailer that does not know
how to convert from 8859-x into Unicode, I needed to insert a
few German and Greek and Hebrew characters that are not common
to 8859-5.
And that is why I did not send only the Cyrillic characters,
in case some mailer fails, and displays them as western-european
or something else, the way I used to see things...
This is easy to set up with X as there are plenty of -10646
fonts available in the years since I contributed an 8859-2
font; for the very nice large font of a 25x80 text console on
a nice large monitor that does not strain my eyes, I like
SCREEN_FONT=/usr/local/src/fonty-rg-0.5/LatCyrGr-16.psf.gz
that makes many useful g00gle results readable to me.
Again, sorry for going off-topic for so long...
Now, to your question, which maybe some linux-dvb reader can
offer more help...
now work next scheme:
I tzap to some channel and read stream with emcast from
/dev/dvb/adapter0/dvr0
but it is only one channel - I would like stream all transponder
Could you help, with advice - is it possible ? (receive all
transponder with several channels simultaneous at the same time)
Yes, this is very possible.
The one thing to be certain of, is that you are not using a
USB-1 device, as the bandwidth of USB 1 is less than most DVB-T
multiplexes today -- usually you can fit at least two services
without problems, though, over USB 1.
The special ``PID'' of 8192 is used by, for example, `dvbstream'
meaning to send the entire datastream with all PIDs to its
output. It will also do all the tuning for you.
Or, if you know all the PIDs that are used on a particular
frequency, you can usually list all of them of interest, up
to the limit of the hardware PID filter, if there is one.
This can save some space, as PID 8191 usually takes up some
bandwidth for null packets to fill the available bandwidth,
and there may be unneeded services, such as data, teletext,
or whatever, that you do not care about.
For example, here is what I would use to record three of
the RTVi services which are sometimes FTA on Hotbirds:
/home/beer/bin/dvbstream ${OPERA1} -T \
-s 27500 -p h -f 12322 -I 2 -D 2 \
-o:${RECROOT:-/opt}/Partial_Transport_Streams/detskii_mir-fs-${DATE}.ts \
0 44 -v 45 -a 46 40 41 42 47 48 49 $*
(I am actually guessing that the last 6 PIDs are correct,
as I only recorded the one service...)
Then you only need to select which programme you wish during
playback with your media player (you may need to record some
additional PIDs to see the service name). Or you can split
the three services into three separate files.
I use the `8192' PID when I want the entire stream, but if
you want to use `tzap' or similar, then whatever program you
use after that needs to set all the PIDs -- for example,
`dvbtraffic' after I've tuned to a DVB-H multiplex...
-PID--FREQ-BANDWIDTH-BANDWIDTH-
20 p/s 3 kb/s31 kbit0
0011 3 p/s 0 kb/s 5 kbit 17
001223 p/s 4 kb/s35 kbit 18
Re: [PATCH 2/2 v2] gspca: Add MR97310A driver
On Friday 16 January 2009 02:47:31 Jean-Francois Moine wrote: On Thu, 15 Jan 2009 22:36:49 -0600 Kyle Guinn ely...@gmail.com wrote: This patch adds support for USB webcams based on the MR97310A chip. It was tested with an Aiptek PenCam VGA+ webcam. Hi Kyle, I added your driver to my repository. I just found a little bug. At line 250/251 data[8] = 0x01; err_code = reg_w(gspca_dev, 10); you set 9 values and you output 10 values. Good catch. Yes, that should be 9. Also that data[8] should be set to 0x00. I must have been asleep at the keyboard :) I'll send a patch. BTW, as many of these USB control messages are constant, you should better use static data or a table format (byte count, values)*. I'll look into this. Those may not all be costants, I believe the camera supports gamma adjustment and autoexposure and maybe some other controls. I plan on gathering some traces to figure that out next week. Regards, -Kyle -- To unsubscribe from this list: send the line unsubscribe 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://linuxtv.org/hg/~mcisely/pvrusb2
On Fri, 16 Jan 2009, Janne Grunau wrote:
On Friday 16 January 2009 15:39:33 Mike Isely wrote:
In any case, right now the serial number in the pvrusb2 is not available
through that means because I haven't done anything to make it available
to udev. I'd like to do something, but so far I have found no
information on how to make that happen.
You shouldn't need to do anything special. The serial number is available
through the parent USB device. It can be used for udev rules through
ATTRS{serial} and in sysfs entry of the video device through device/serial.
Ah yes!
What I said before was right in its own context, but now I see something
else.
The serial number that the pvrusb2 driver itself knows about is parsed
out of Hauppauge private data by the tveeprom module from the device's
internal I2C ROM. This data is formatted in a packetized way that is
specific to Hauppauge. What I was refering to was *that* serial number,
and since it's in the private ROM I saw no means for udev to know about
it.
However I just tested with two 24xxx devices using usbview, and the same
serial number is in fact visible in the USB configuration data.
There's simply no way for the USB core in Linux to be able to directly
know about, get at, or even understand that internal ROM. Yet there it
is. I'm thinking now that perhaps the FX2 microcontroller is either
parsing out the data itself during initialization and then writing out
the USB configuration accordingly, or the serial number is in fact
written in two places within the device! Up until now, I had not seen
any evidence to suggest that the FX2 firmware ever actually read the
nearby ROM on its own. But that could be what is happening here.
Thanks for pointing that out. These devices still surprise me.
For anyone looking at this, the serial number in the USB configuration
data for the device is just a hex-formatted version of the same value
that you can see via the pvrusb2 driver's sysfs interface.
-Mike
--
Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Am Fri, 16 Jan 2009 12:36:43 +0100 schrieb Carsten Meier c...@trexity.de: To make this mechanism work reliably with USB, the meaning of the field could be adapted to something like a binary identifier string. I really meant opaque identifier string. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
