Andy Walls | 1 Nov 01:38 2009
Picon

Re: cx18: YUV frame alignment improvements

On Sat, 2009-10-31 at 16:28 -0400, Devin Heitmueller wrote:
> On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls <awalls <at> radix.net> wrote:
> > All,
> >
> > At
> >
> > http://linuxtv.org/hg/~awalls/cx18-yuv
> >
> > I have checked in some improvements to YUV handling in the cx18
> > driver.

> > Andy
> 
> Hi Andy,
> 
> How does this code work if the cx23418 scaler is used (resulting in
> the size of the frames to be non-constant)?  Or is the scaler not
> currently supported in the driver?

It is designed to fit as many integral frames as possible into the YUV
buffers.  It should work with the scaler.  I have not tested it though.
I also have note tested scaling to much aside from down to 480x480 with
MPEG as this is the MythTV default.

Please note that with the HM12 macroblock format, the height must be a
multiple of 32 lines (IIRC) so you'll have full blocks to decode.  See
the README.hm12 under Documentation somewhere.

Regards,
Andy
(Continue reading)

Andy Walls | 1 Nov 01:41 2009
Picon

Re: cx18: YUV frame alignment improvements

On Sat, 2009-10-31 at 16:28 -0400, Devin Heitmueller wrote:
> On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls <awalls <at> radix.net> wrote:

> 
> Hi Andy,
> 
> How does this code work if the cx23418 scaler is used (resulting in
> the size of the frames to be non-constant)?  Or is the scaler not
> currently supported in the driver?

I also forgot to mention, changing size while the encoder has an analog
stream running (MPEG, VBI, YUV, IDX) is not permitted by the firmware.
So this change works just fine as it computes the buffer size to use
just as it sets up to start the capture.

Regards,
Andy

> 
> Devin
> 

Ben Hutchings | 1 Nov 03:14 2009
Picon

[PATCH] V4L/DVB: lgs8gxx: remove firmware for lgs8g75

The recently added support for lgs8g75 included some 8051 machine code
without accompanying source code.  Replace this with use of the
firmware loader.

Compile-tested only.

Signed-off-by: Ben Hutchings <ben <at> decadent.org.uk>
---
This firmware can be added to linux-firmware.git instead, and I will be
requesting that very shortly.

Ben.

 drivers/media/dvb/frontends/Kconfig   |    1 +
 drivers/media/dvb/frontends/lgs8gxx.c |   50 ++++++--------------------------
 2 files changed, 11 insertions(+), 40 deletions(-)

diff --git a/drivers/media/dvb/frontends/Kconfig b/drivers/media/dvb/frontends/Kconfig
index d7c4837..26b00ab 100644
--- a/drivers/media/dvb/frontends/Kconfig
+++ b/drivers/media/dvb/frontends/Kconfig
 <at>  <at>  -553,6 +553,7  <at>  <at>  config DVB_LGS8GL5
 config DVB_LGS8GXX
 	tristate "Legend Silicon LGS8913/LGS8GL5/LGS8GXX DMB-TH demodulator"
 	depends on DVB_CORE && I2C
+	select FW_LOADER
 	default m if DVB_FE_CUSTOMISE
 	help
 	  A DMB-TH tuner module. Say Y when you want to support this frontend.
diff --git a/drivers/media/dvb/frontends/lgs8gxx.c b/drivers/media/dvb/frontends/lgs8gxx.c
(Continue reading)

Brandon Jenkins | 1 Nov 03:25 2009

Re: cx18: YUV frame alignment improvements

On Sat, Oct 31, 2009 at 8:41 PM, Andy Walls <awalls <at> radix.net> wrote:
> On Sat, 2009-10-31 at 16:28 -0400, Devin Heitmueller wrote:
>> On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls <awalls <at> radix.net> wrote:
>
>>
>> Hi Andy,
>>
>> How does this code work if the cx23418 scaler is used (resulting in
>> the size of the frames to be non-constant)?  Or is the scaler not
>> currently supported in the driver?
>
> I also forgot to mention, changing size while the encoder has an analog
> stream running (MPEG, VBI, YUV, IDX) is not permitted by the firmware.
> So this change works just fine as it computes the buffer size to use
> just as it sets up to start the capture.
>
> Regards,
> Andy
>
>>
>> Devin
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Hi Andy,
(Continue reading)

hermann pitton | 1 Nov 03:40 2009
Picon

Re: [PATCH] Multifrontend support for saa7134

Hi Lukas, Petr and Eddi,

thanks for working on it.

Am Samstag, den 31.10.2009, 21:21 +0100 schrieb Lukáš Karas:
> Hi all, 
> here is patch for multifrontend support in saa7134 driver. It is derived from 
> patches on page http://tux.dpeddi.com/lr319sta/
> 
> This patch has effect on these cards:
>  * FlyDVB Trio
>  * Medion MD8800 Quadro
>  * ASUSTeK Tiger 3in1

The a little bit hidden low profile triple CTX948 is also involved, just
to have it mentioned. We treat it like the Medion MD8800 Quadro, CTX944,
with subsystem 16be:0007.

> It was tested with FlyDVB Trio card.
> If you could, please test it with other cards too.

Some first tests on the CTX944 don't look such promising yet.
On DVB-T only one transponder remains and even that one is heavily
disturbed.

On DVB-S only about one third of the previous services is still
available. Lots of such.

saa7133[1]/dvb: saa7134_dvb_bus_ctrl(acquire=0) returns 0
saa7133[1]/dvb: saa7134_dvb_bus_ctrl(acquire=1)
(Continue reading)

Németh Márton | 1 Nov 07:16 2009
Picon

Re: [PATCH 20/21] gspca pac7302/pac7311: separate the two subdrivers

From: Márton Németh <nm127 <at> freemail.hu>

All PAC7311 specific functions remain in pac7311.c. All PAC7302 specific
functions are moved to pac7302.c. The USB device table is also divided into
two parts. This makes it possible to remove the last sensor specific
decision in sd_probe() functions.

The common functions are just copied to both subdrivers. These common
functions can be separated later to a common file or helper module.

Signed-off-by: Márton Németh <nm127 <at> freemail.hu>
Cc: Thomas Kaiser <thomas <at> kaiser-linux.li>
Cc: Theodore Kilgore <kilgota <at> auburn.edu>
Cc: Kyle Guinn <elyk03 <at> gmail.com>
---
Patch rebased to the latest http://linuxtv.org/hg/v4l-dvb/ (rev 13254).
---
diff -uprN t/drivers/media/video/gspca/Kconfig u/drivers/media/video/gspca/Kconfig
--- t/drivers/media/video/gspca/Kconfig	2009-11-01 06:54:04.000000000 +0100
+++ u/drivers/media/video/gspca/Kconfig	2009-11-01 06:58:14.000000000 +0100
 <at>  <at>  -104,6 +104,15  <at>  <at>  config USB_GSPCA_PAC207
 	  To compile this driver as a module, choose M here: the
 	  module will be called gspca_pac207.

+config USB_GSPCA_PAC7302
+	tristate "Pixart PAC7302 USB Camera Driver"
+	depends on VIDEO_V4L2 && USB_GSPCA
+	help
+	  Say Y here if you want support for cameras based on the PAC7302 chip.
+
(Continue reading)

Németh Márton | 1 Nov 07:17 2009
Picon

Re: [PATCH 21/21] gspca pac7302/pac7311: remove prefixes

From: Márton Németh <nm127 <at> freemail.hu>

The pac7302_ and pac7311_ prefixes are no longer needed as these
functions are in separated files. The sensor information can also
be removed from the USB tables.

Signed-off-by: Márton Németh <nm127 <at> freemail.hu>
Cc: Thomas Kaiser <thomas <at> kaiser-linux.li>
Cc: Theodore Kilgore <kilgota <at> auburn.edu>
Cc: Kyle Guinn <elyk03 <at> gmail.com>
---
Patch rebased to the latest http://linuxtv.org/hg/v4l-dvb/ (rev 13254).
---
diff -uprN u/drivers/media/video/gspca/pac7302.c v/drivers/media/video/gspca/pac7302.c
--- u/drivers/media/video/gspca/pac7302.c	2009-11-01 07:00:04.000000000 +0100
+++ v/drivers/media/video/gspca/pac7302.c	2009-11-01 07:03:06.000000000 +0100
 <at>  <at>  -60,7 +60,7  <at>  <at>  MODULE_DESCRIPTION("Pixart PAC7302");
 MODULE_LICENSE("GPL");

 /* specific webcam descriptor for pac7302 */
-struct pac7302_sd {
+struct sd {
 	struct gspca_dev gspca_dev;		/* !! must be the first item */

 	unsigned char brightness;
 <at>  <at>  -72,8 +72,6  <at>  <at>  struct pac7302_sd {
 	__u8 hflip;
 	__u8 vflip;

-#define SENSOR_PAC7302 0
(Continue reading)

Michael Krufky | 1 Nov 07:21 2009

http://kernellabs.com/hg/~mkrufky/tda18271

Mauro,

In my last tda18271 pull request, I caused a regression for devices
that specify a tda18271 std_map override.  Please pull in the fix for
this as soon as possible.

Please pull from:

http://kernellabs.com/hg/~mkrufky/tda18271

for:

- tda18271: fix regression preventing std map override from taking effect

 tda18271-fe.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

Special thanks to Michael Obst for his testing, which helped me to
find the cause of this problem.

Cheers,

Mike
Michael Krufky | 1 Nov 07:27 2009

Re: Leadtek DTV-1000S

On Sat, Oct 31, 2009 at 7:17 PM, Michael Krufky <mkrufky <at> kernellabs.com> wrote:
>> 2009/11/1 Michael Krufky <mkrufky <at> kernellabs.com>:
>>> On Sat, Oct 31, 2009 at 6:43 PM, Michael Krufky <mkrufky <at> kernellabs.com> wrote:
>>>> On Sat, Oct 31, 2009 at 6:08 PM, Michael Obst
>>>> <m.obst <at> ugrad.unimelb.edu.au> wrote:
>>>>> Hi,
>>>>>    Thanks for fixing this, I can confirm that it now compiles and
>>>>> inserts and the remote works, so does the av input to the tvcard
>>>>> however the card does not seem to be able to tune any channels, I have
>>>>> checked the old driver and that is still able to tune in channels. The
>>>>> output from my dmesg is below.
>>>>>
>>>>> Thanks
>>>>> Michael Obst
>>>>
>>>> Michael,
>>>>
>>>> This is an interesting problem -- the part of your dmesg that stands
>>>> out to me is this:
>>>>
>>>>> [  502.928544] tuner 0-0060: chip found  <at>  0xc0 (saa7130[0])
>>>>> [  502.960501] tda8290: no gate control were provided!
>>>>
>>>> That error message was added as a safety measure -- it shouldn't be
>>>> possible to ever hit that code path.  Are you running any non-GPL
>>>> binary drivers on your system, such as NVIDIA or anything else?
>>>>
>>>> Let me explain:
>>>>
>>>> The "no gate control were provided!" message was added by Mauro to the
(Continue reading)

Jean-Francois Moine | 1 Nov 09:52 2009
Picon

Re: [PATCH 00/21] gspca pac7302/pac7311: separate the two drivers

On Sun, 01 Nov 2009 00:13:10 +0100
Németh Márton <nm127 <at> freemail.hu> wrote:

> the following patchset refactores the Pixart PAC7311 subdriver. The
> current situation is that the code contains a lot of decisions
> like this:
> 
>     if (sd->sensor == SENSOR_PAC7302) {
>         ... do this ...
>     } else {
>         ... do something else ...
>     }
> 
> The sensor type is determined using the USB Vendor ID and Product
> ID which means that the decisions shown are not really necessary.
> 
> The goal of the patchset is to have a PAC7302 and a PAC7311 subdriver
> which have the benefit that there is no decision necessary on sensor
> type at runtime. The common functions can be extracted later but this
> would be a different patchset.

Hello Márton,

Splitting the pac7311 subdriver is a good idea, but I don't like your
patchset: a lot of changes (function prefixes) are nullified by the
last patch. I'd better like only one change for the pac7302 creation
and a second one for the interface change of pac_find_sof() in
pac_common.h (BTW, this file could now be compiled separately).

Regards.
(Continue reading)


Gmane