RE: Status of the patches under review (45 patches)

[Hiremath, Vaibhav]

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab
> Sent: Wednesday, March 10, 2010 12:36 AM
> To: LMML
> Cc: moin...@free.fr; Karicheri, Muralidharan; g.liakhovet...@gmx.de;
> pboettc...@dibcom.fr; tobias.lor...@gmx.net; awa...@radix.net; kh...@linux-
> fr.org; hdego...@redhat.com; abraham.m...@gmail.com; hverk...@xs4all.nl;
> cr...@iki.fi; davidtlw...@gmail.com; hen...@kurelid.se; st...@kernellabs.com
> Subject: Status of the patches under review (45 patches)
> 
> This is the summary of the patches that are currently under review.
> Each patch is represented by its submission date, the subject (up to 70
> chars) and the patchwork link (if submitted via email). Currently, there's
> no pending hg/git pull request or new patches at patchwork.
> 
> P.S.: This email is c/c to the developers that some review action is
> expected.
> 
>   == Waiting for my fixes on Docbook ==
> 
> Feb,25 2010: DocBook/Makefile: Make it less verbose
> http://patchwork.kernel.org/patch/82076
> Feb,25 2010: DocBook: Add rules to auto-generate some media docbooks
> http://patchwork.kernel.org/patch/82075
> Feb,25 2010: [PATCHv2,
> http://patchwork.kernel.org/patch/82074
> Feb,25 2010: [PATCHv2,
> http://patchwork.kernel.org/patch/82073
> 
>   == Videobuf patches - Need more tests before committing it -
> Volunteers? ==
> 
> Jan,19 2010: [v1,1/1] V4L: Add sync before a hardware operation to videobuf.
> http://patchwork.kernel.org/patch/73896
> Mar, 4 2010: [1/2] V4L/DVB: buf-dma-sg.c: don't assume nr_pages == sglen
> http://patchwork.kernel.org/patch/83626
> Mar, 4 2010: [2/2] V4L/DVB: buf-dma-sg.c: support non-pageable user-
> allocated   http://patchwork.kernel.org/patch/83627
> 
>   == Waiting for Antti Palosaari  review ==
> 
> Feb,26 2010: af901x: NXP TDA18218
> http://patchwork.kernel.org/patch/82494
> 
>   == Waiting for Muralidharan Karicheri 
> review ==
> 
> Feb,19 2010: video_device: don't free_irq() an element past array
> vpif_obj.dev[]http://patchwork.kernel.org/patch/80845
> 
>   == Waiting for Tobias Lorenz  review ==
> 
> Feb, 3 2010: radio-si470x-common: -EINVAL overwritten in
> si470x_vidioc_s_tuner()http://patchwork.kernel.org/patch/76786
> 
>   == waiting for Jean Delvare  final
> submission after tests ==
> 
> Jan,30 2010: saa7134: Fix IR support of some ASUS TV-FM 7135 variants
> http://patchwork.kernel.org/patch/75883
> 
>   == Waiting for its addition at linux-firmware and driver test by
> David Wong   ==
> 
> Nov, 1 2009: lgs8gxx: remove firmware for lgs8g75
> http://patchwork.kernel.org/patch/56822
> 
>   == Andy Walls  and Aleksandr Piskunov
>  are discussing around the solution ==
> 
> Oct,11 2009: AVerTV MCE 116 Plus radio
> http://patchwork.kernel.org/patch/52981
> 
>   == Patches waiting for Patrick Boettcher 
> review ==
> 
> Jan,15 2010: remove obsolete conditionalizing on DVB_DIBCOM_DEBUG
> http://patchwork.kernel.org/patch/73147
> Feb, 8 2010: dib7000p: reduce large stack usage
> http://patchwork.kernel.org/patch/77891
> Feb, 8 2010: dib3000mc: reduce large stack usage
> http://patchwork.kernel.org/patch/77892
> 
>   == IR driver for IMON - Will likely go via drivers/input tree ==
> 
> Feb,25 2010: [v2,
> http://patchwork.kernel.org/patch/82119
> 
>   == Gspca patches - Waiting Hans de Goede 
> submission/review ==
> 
> Jan,29 2010: [gspca_jf,tree] gspca zc3xx: signal when unknown packet
> received   http://patchwork.kernel.org/patch/75837
> Mar, 8 2010: [1/1] gspca-stv06xx: Remove the 046d:08da usb id from linking
> to the   http://patchwork.kernel.org/patch/84145
> 
>   == Gspca patches - Waiting Jean-Francois Moine 
> submission/review ==
> 
> Jan,14 2010: Problem with gspca and zc3xx
> http://patchwork.kernel.org/patch/72895
> Feb,24 2010: gspca pac7302: add USB PID range based on heuristics
> http://patchwork.kernel.org/patch/81612
> Feb,27 2010: [01/11] ov534: Remove ambiguous controls
> http://patchwork.kernel.org/patch/82721
> Feb,27 2010: [02/11] ov534: Remove hue control
> http://patchwork.kernel.org/patch/82722
> Feb,27 2010: [03/11] ov534: Fix autogain control, enable it by default
> http://patchwork.kernel.org/patch/82725
> Feb,27 2010: [04/11] ov534: Add Auto Exposure
> http://patchwork.kernel.org/patch/82728
> Mar, 1 2010: [v2,05/11] ov534: Fix and document setting manual exposure
> http://patchwork.kernel.org/patch/82910
> Feb,27 2010: [06/11] ov534: Fix Auto White Balance control
> http://patchwork.kernel.org/patch/82718
> Feb,27 2010: [07/11] ov534: Fixes for sharpness control
> http://patchwork.kernel.org/patch/82724
> Feb,27 2010: [08/11] ov534: Fix unsetting hflip and vflip bits
> http://patchwork.kernel.org/patch/82729
> Mar, 1 2010: [v2,09/11] ov534: Cosmetics: fix indentation and hex digits
> http://patchwork.kernel.o

Re: v4l-utils: i2c-id.h and alevt

[hermann pitton]

Hi Hans, both,

Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:
> It's nice to see this new tree, that should be make it easier to develop
> utilities!
> 
> After a quick check I noticed that the i2c-id.h header was copied from the
> kernel. This is not necessary. The only utility that includes this is v4l2-dbg
> and that one no longer needs it. Hans, can you remove this?
> 
> The second question is whether anyone would object if alevt is moved from
> dvb-apps to v4l-utils? It is much more appropriate to have that tool in
> v4l-utils.

i wonder that this stays such calm, hopefully a good sign.

In fact alevt analog should come with almost every distribution, but the
former alevt-dvb, named now only alevt, well, might be ok in some
future, is enhanced for doing also dvb-t-s and hence there ATM.

> Does anyone know of other unmaintained but useful tools that we might merge
> into v4l-utils? E.g. xawtv perhaps?

If for xawtv could be some more care, ships also since close to ever
with alevtd, that would be fine, but I'm not sure we are talking about
tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
example are also there and unmaintained.

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

Re: Hw capabilities of the HVR-2200

[Jed]

19/09/09 Jed wrote:

2) Component input for the A/V-in


Yes, this exists on the HVR2250 product only.


Ah shite, are you sure?
If you look at the specs for the reference card it was there, did they
take it out at the last minute?


It's not feature Hauppauge supports on the HVR2200 today. I have a 
suspicion this may change but I'm neither confirming, denying or 
announcing anything. It would make sense to officially support 
component cables on the HVR2200 since the silicon supports it. If/when 
it does I'm sure it will be mentioned in the forums or on the HVR2200 
product packaging.


Hi Steve, when you said this is not a feature Hauppauge supports.
Did you mean it's not fully enabled physically in the PCB...
Or is it just something they need to add support for in the driver?
If the latter do you know if their policy has changed or is about to?


3) Hw encode bypass for A/V-in


No idea. Regardless of whether it does or does not I wouldn't plan to
add basic raw TV support to the driver, without going through the
encoder.


Why do you rule it out unequivocally, is it just because I've annoyed
you? :-(


Raw analog TV isn't a high priority feature on my mental check-list. 
Analog TV via the encoder is much more interesting and applicable to 
many people.


Assuming that progress has been made on analogue to
h.263/mpeg4/VC-1/DivX/Xvid via the A/V-in encoder.
Is this still considered a low priority?

Has progress been made on hw encode via A/V-in?
I'm "finally" putting my entire system together soon, can't wait!
Looking forward to seeing how everything has progressed.
I'll be sure to do some donations once I'm up & running!


--
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: [IR RC, REGRESSION] Didn't work IR RC

[Dmitri Belimov]

Hi Jean

> Hi Mauro, Dmitri,
> 
> On Tue, 02 Mar 2010 05:49:17 -0300, Mauro Carvalho Chehab wrote:
> > Dmitri Belimov wrote:
> > > When I add 
> > > 
> > > diff -r 37ff78330942 linux/drivers/media/video/ir-kbd-i2c.c
> > > --- a/linux/drivers/media/video/ir-kbd-i2c.c  Sun Feb 28
> > > 16:59:57 2010 -0300 +++
> > > b/linux/drivers/media/video/ir-kbd-i2c.c  Tue Mar 02
> > > 10:31:31 2010 +0900 @@ -465,6 +519,11 @@ ir_type =
> > > IR_TYPE_OTHER; ir_codes= &ir_codes_avermedia_cardbus_table;
> > >   break;
> > > + case 0x2d:
> > > + /* Handled by saa7134-input */
> > > + name= "SAA713x remote";
> > > + ir_type = IR_TYPE_OTHER;
> > > + break;
> > >   }
> > >  
> > >  #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
> > > 
> > > The IR subsystem register event device. But for get key code use
> > > ir_pool_key function.
> > > 
> > > For our IR RC need use our special function. How I can do it?
> > 
> > Just add your get_key callback to "ir->get_key". If you want to do
> > this from saa7134-input, please take a look at the code at
> > em28xx_register_i2c_ir(). It basically fills the platform_data.
> > 
> > While you're there, I suggest you to change your code to work with
> > the full scancode (e. g. address + command), instead of just
> > getting the command. Currently, em28xx-input has one I2C IR already
> > changed to this mode (seek for full_code for the differences).
> > 
> > You'll basically need to change the IR tables to contain
> > address+command, and inform the used protocol (RC5/NEC) on it. The
> > getkey function will need to return the full code as well.
> 
> Sorry for the late reply. Is the problem solved by now, or is my help
> still needed?

Yes. I found what happens and solve this regression. Patch already comitted.

diff -r 37ff78330942 linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c Sun Feb 28 16:59:57 
2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-input.c Thu Mar 04 08:35:15 
2010 +0900
@@ -947,6 +947,7 @@
dev->init_data.name = "BeholdTV";
dev->init_data.get_key = get_key_beholdm6xx;
dev->init_data.ir_codes = &ir_codes_behold_table;
+   dev->init_data.type = IR_TYPE_NEC;
info.addr = 0x2d;
 #endif
break;


With my best regards, Dmitry.
--
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

Any experience with Mini-PCI MP-6100: Techwell TW2815 and SPCT6100?

[Chris Shoemaker]

[posted at video4linux-l...@redhat.com before I found linux-media]

Hi,

  I'm looking at this MP-6100:
http://www.commell.com.tw/product/Surveillance/MP-6100.htm

Their press release [1] says it has "Techwell's TW2815 video decoder
and SPCT6100 H.264 encoder DSP" and it comes with a Linux SDK for
Fedora 11.  Does anyone have any experience with these chips?  What
are the chances I'll be able to get this to capture H.264 under linux?

Any tips?

Thanks in advance,
-chris

[1] http://news.thomasnet.com/fullstory/563735
--
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: Status of the patches under review (45 patches)

[Mauro Carvalho Chehab]

Guennadi Liakhovetski wrote:
> Hi Mauro
> 
> On Tue, 9 Mar 2010, Mauro Carvalho Chehab wrote:
> 
>>  == soc_camera patches - Waiting Guennadi 
>>  submission/review == 
>>
>> Feb, 9 2010: mt9t031: use runtime pm support to restore ADDRESS_MODE 
>> registers  http://patchwork.kernel.org/patch/77997
> 
> This one is already in your tree, if I see it right:
> 
> http://git.linuxtv.org/v4l-dvb.git?a=commit;h=36e9541f11bfe175781b1ea8e4cb3032e4b23508

Ok, updated.

>> Feb, 2 2010: [2/3] soc-camera: mt9t112: modify delay time after initialize   
>>http://patchwork.kernel.org/patch/76213
>> Feb, 2 2010: [3/3] soc-camera: mt9t112: The flag which control camera-init 
>> is   http://patchwork.kernel.org/patch/76214
> 
> These two we agreed to put on hold, can be that they'll be dropped.

I'll keep it as Under Review, until you point me otherwise. So, you may expect 
them to appear on
the next week's email, if not acked/rejected until the next report.

>> Mar, 5 2010: [v2] V4L/DVB: mx1-camera: compile fix   
>>http://patchwork.kernel.org/patch/83742
> 
> Yes, I still have to process this one.

Ok.

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: Status of the patches under review (45 patches)

[Guennadi Liakhovetski]

Hi Mauro

On Tue, 9 Mar 2010, Mauro Carvalho Chehab wrote:

>   == soc_camera patches - Waiting Guennadi 
>  submission/review == 
> 
> Feb, 9 2010: mt9t031: use runtime pm support to restore ADDRESS_MODE 
> registers  http://patchwork.kernel.org/patch/77997

This one is already in your tree, if I see it right:

http://git.linuxtv.org/v4l-dvb.git?a=commit;h=36e9541f11bfe175781b1ea8e4cb3032e4b23508

> Feb, 2 2010: [2/3] soc-camera: mt9t112: modify delay time after initialize
>   http://patchwork.kernel.org/patch/76213
> Feb, 2 2010: [3/3] soc-camera: mt9t112: The flag which control camera-init is 
>   http://patchwork.kernel.org/patch/76214

These two we agreed to put on hold, can be that they'll be dropped.

> Mar, 5 2010: [v2] V4L/DVB: mx1-camera: compile fix
>   http://patchwork.kernel.org/patch/83742

Yes, I still have to process this one.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

[Hans Verkuil]

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:Tue Mar  9 19:00:29 CET 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14409:37bd06e25095
git master:   f6760aa024199cfbce564311dc4bc4d47b6fb349
git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81
gcc version:  i686-linux-gcc (GCC) 4.4.3
host hardware:x86_64
host os:  2.6.32.5

linux-2.6.32.6-armv5: ERRORS
linux-2.6.33-armv5: ERRORS
linux-2.6.34-rc1-armv5: ERRORS
linux-2.6.32.6-armv5-davinci: ERRORS
linux-2.6.33-armv5-davinci: ERRORS
linux-2.6.34-rc1-armv5-davinci: ERRORS
linux-2.6.32.6-armv5-ixp: WARNINGS
linux-2.6.33-armv5-ixp: WARNINGS
linux-2.6.34-rc1-armv5-ixp: WARNINGS
linux-2.6.32.6-armv5-omap2: ERRORS
linux-2.6.33-armv5-omap2: ERRORS
linux-2.6.34-rc1-armv5-omap2: ERRORS
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.17-i686: ERRORS
linux-2.6.24.7-i686: ERRORS
linux-2.6.25.20-i686: ERRORS
linux-2.6.26.8-i686: ERRORS
linux-2.6.27.44-i686: ERRORS
linux-2.6.28.10-i686: ERRORS
linux-2.6.29.1-i686: ERRORS
linux-2.6.30.10-i686: ERRORS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-rc1-i686: WARNINGS
linux-2.6.32.6-m32r: ERRORS
linux-2.6.33-m32r: ERRORS
linux-2.6.34-rc1-m32r: ERRORS
linux-2.6.32.6-mips: ERRORS
linux-2.6.33-mips: ERRORS
linux-2.6.34-rc1-mips: ERRORS
linux-2.6.32.6-powerpc64: ERRORS
linux-2.6.33-powerpc64: ERRORS
linux-2.6.34-rc1-powerpc64: ERRORS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.17-x86_64: ERRORS
linux-2.6.24.7-x86_64: ERRORS
linux-2.6.25.20-x86_64: ERRORS
linux-2.6.26.8-x86_64: ERRORS
linux-2.6.27.44-x86_64: ERRORS
linux-2.6.28.10-x86_64: ERRORS
linux-2.6.29.1-x86_64: ERRORS
linux-2.6.30.10-x86_64: ERRORS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-rc1-x86_64: WARNINGS
linux-git-armv5: OK
linux-git-armv5-davinci: OK
linux-git-armv5-ixp: OK
linux-git-armv5-omap2: OK
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
spec: ERRORS
spec-git: OK
sparse: ERRORS
linux-2.6.16.62-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.7-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.62-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.7-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
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/5] drivers/media: drop redundant memset

[Julia Lawall]

From: Julia Lawall 

The region set by the call to memset is immediately overwritten by the
subsequent call to memcpy.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
expression e1,e2,e3,e4;
@@

- memset(e1,e2,e3);
  memcpy(e1,e4,e3);
// 

Signed-off-by: Julia Lawall 

---
 drivers/media/dvb/bt8xx/dst.c |2 --
 1 file changed, 2 deletions(-)

diff -u -p a/drivers/media/dvb/bt8xx/dst.c b/drivers/media/dvb/bt8xx/dst.c
--- a/drivers/media/dvb/bt8xx/dst.c
+++ b/drivers/media/dvb/bt8xx/dst.c
@@ -930,7 +930,6 @@ static int dst_fw_ver(struct dst_state *
dprintk(verbose, DST_INFO, 1, "Unsupported Command");
return -1;
}
-   memset(&state->fw_version, '\0', 8);
memcpy(&state->fw_version, &state->rxbuffer, 8);
dprintk(verbose, DST_ERROR, 1, "Firmware Ver = %x.%x Build = %02x, on 
%x:%x, %x-%x-20%02x",
state->fw_version[0] >> 4, state->fw_version[0] & 0x0f,
@@ -1053,7 +1052,6 @@ static int dst_get_tuner_info(struct dst
goto force;
}
}
-   memset(&state->board_info, '\0', 8);
memcpy(&state->board_info, &state->rxbuffer, 8);
if (state->type_flags & DST_TYPE_HAS_MULTI_FE) {
dprintk(verbose, DST_ERROR, 1, "DST type has TS=188");
--
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 with RTL2832U DVB-T dongle (LeadTek WinFast DTV Dongle Mini)

[Mauro Carvalho Chehab]

Jan Hoogenraad wrote:
> Mauro:
> 
> Can you remove the VERY OLD branch:
> http://linuxtv.org/hg/~mchehab/rtl2831/rev/d116540ebaab
> It is giving some confusion here.

Removed. It would be great if you could work on put it at a good shape,
in order to allow its merge upstream.

> 
> Thomas & Jan:
> 
> I've got the RTL2831 code (mind the last digit) vetted off by LeadTek.
> For the rtl2832, I haven't had contact with them.
> 
> Certainly, Jan could try any of the three archives.
> I know Antti has thoughts on the rtl2832, I'm sure he knows more.
> 
> thomas schorpp wrote:
>> Jan Hoogenraad wrote:
>>> Antti has been working on drivers for the RTL283x.
>>>
>>> http://linuxtv.org/hg/~anttip/rtl2831u
>>> or
>>> http://linuxtv.org/hg/~anttip/qt1010/
>>
>> ~jhoogenraad/rtl2831-r2 rtl2831-r2 development repository: *known
>> working version* Jan Hoogenraad
>>
>> Should Jan Slaninka try it?
>>>
>>> If you have more information on the RTL2832, I'd be happy to add it at:
>>> http://www.linuxtv.org/wiki/index.php/Rtl2831_devices
>>
>> Nothing on the Realtek website yet.
>>
>>>
>>>
>>> Jan Slaninka wrote:
 Hi,

 I'd like to ask for a support with getting LeadTek WindFast DTV Dongle
 mini running on Linux. So far I was able to fetch latest v4l-dvb from
 HG, and successfully compiled module dvb_usb_rtl2832u found in
>>
 090730_RTL2832U_LINUX_Ver1.1.rar  
>>
>> Can be considered as GPL code then according to
>>
>> http://linuxtv.org/hg/~mchehab/rtl2831/rev/d116540ebaab
>>
>> Patch to make RTL2831U DVB-T USB2.0 DEVICE work, based on RealTek
>> version 080314
>>
>> ~mchehab/rtl2831 rtl2831 development repository with *RealTek GPL
>> code* for rtl2831 Mauro Carvalho Chehab 24 months ago
>>
>> ?
>>
>> y
>> tom
>> -- 
>> 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: Status of the patches under review (45 patches)

[VDR User]

On Tue, Mar 9, 2010 at 12:05 PM, Devin Heitmueller
 wrote:
> On Tue, Mar 9, 2010 at 2:55 PM, VDR User  wrote:
>> What happened to the statistics patch?
>
> The statistics patch still needs a ton of work before it could be
> accepted upstream.  Mostly these things are related to clarification
> as to how the API should behave and how a variety of edge cases should
> be handled.  I came up with about three paragraphs worth of issues
> with the proposed approach, but haven't had a chance to push it to the
> mailing list for further discussion.

Ok, thanks.  I look forward to reading your review when you get the
chance to push it out.
--
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: s2-liplianin, mantis: sysfs: cannot create duplicate filename '/devices/virtual/irrcv'

[VDR User]

2010/3/9 Igor M. Liplianin :
> On 8 марта 2010 22:41:26 VDR User wrote:
>> This isn't an answer to your questions but I don't recommend using the
>> s2-liplianin tree as it contains timing patches which can cause
>> serious damage to your tuner.  This has also been confirmed by the
>> manufacturer as well and to my knowledge has unfortunately not been
>> reverted in that tree.
> Funny enough.
> VDR User, you are wrong for years. Look here
> http://mercurial.intuxication.org/hg/s2-liplianin/rev/c15f31375c53

Sorry, I was unaware you finally removed the dangerous code.  It's too
bad it was left there as long as it was but at least it's gone now.
Btw, looking at the changelog, it was only removed one year ago, not
years.

>> I strongly urge you to use either of these _safe_ trees:
>>
>> http://jusst.de/hg/mantis-v4l-dvb (for development drivers, which may
>> still be stable)
>> http://linuxtv.org/hg/v4l-dvb (for more stable drivers)
> MartinG, I'm already planning to replace mantis related part with linuxtv one,
> so please use http://linuxtv.org/hg/v4l-dvb.
> But not get wrong, this tree isn't panacea, your reports are welcome.

I'm glad to hear you're going to rebase the mantis driver with the
up-to-date code rather then keeping the old outdated stuff that's
currently in there!  Do you know when you'll be doing this??
--
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: Status of the patches under review (45 patches)

[Karicheri, Muralidharan]

Mauro,

Feb,19 2010: video_device: don't free_irq() an element past array 
vpif_obj.dev[]http://patchwork.kernel.org/patch/80845

I had discussed this and am waiting for a response from the author against my 
last comment.


Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com

>-Original Message-
>From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
>Sent: Tuesday, March 09, 2010 2:06 PM
>To: LMML
>Cc: moin...@free.fr; Karicheri, Muralidharan; g.liakhovet...@gmx.de;
>pboettc...@dibcom.fr; tobias.lor...@gmx.net; awa...@radix.net; kh...@linux-
>fr.org; hdego...@redhat.com; abraham.m...@gmail.com; hverk...@xs4all.nl;
>cr...@iki.fi; davidtlw...@gmail.com; hen...@kurelid.se;
>st...@kernellabs.com
>Subject: Status of the patches under review (45 patches)
>
>This is the summary of the patches that are currently under review.
>Each patch is represented by its submission date, the subject (up to 70
>chars) and the patchwork link (if submitted via email). Currently, there's
>no pending hg/git pull request or new patches at patchwork.
>
>P.S.: This email is c/c to the developers that some review action is
>expected.
>
>   == Waiting for my fixes on Docbook ==
>
>Feb,25 2010: DocBook/Makefile: Make it less verbose
>http://patchwork.kernel.org/patch/82076
>Feb,25 2010: DocBook: Add rules to auto-generate some media docbooks
>http://patchwork.kernel.org/patch/82075
>Feb,25 2010: [PATCHv2,
>http://patchwork.kernel.org/patch/82074
>Feb,25 2010: [PATCHv2,
>http://patchwork.kernel.org/patch/82073
>
>   == Videobuf patches - Need more tests before committing it -
>Volunteers? ==
>
>Jan,19 2010: [v1,1/1] V4L: Add sync before a hardware operation to videobuf.
>http://patchwork.kernel.org/patch/73896
>Mar, 4 2010: [1/2] V4L/DVB: buf-dma-sg.c: don't assume nr_pages == sglen
>http://patchwork.kernel.org/patch/83626
>Mar, 4 2010: [2/2] V4L/DVB: buf-dma-sg.c: support non-pageable user-
>allocated   http://patchwork.kernel.org/patch/83627
>
>   == Waiting for Antti Palosaari  review ==
>
>Feb,26 2010: af901x: NXP TDA18218
>http://patchwork.kernel.org/patch/82494
>
>   == Waiting for Muralidharan Karicheri 
>review ==
>
>Feb,19 2010: video_device: don't free_irq() an element past array
>vpif_obj.dev[]http://patchwork.kernel.org/patch/80845
>
>   == Waiting for Tobias Lorenz  review ==
>
>Feb, 3 2010: radio-si470x-common: -EINVAL overwritten in
>si470x_vidioc_s_tuner()http://patchwork.kernel.org/patch/76786
>
>   == waiting for Jean Delvare  final
>submission after tests ==
>
>Jan,30 2010: saa7134: Fix IR support of some ASUS TV-FM 7135 variants
>http://patchwork.kernel.org/patch/75883
>
>   == Waiting for its addition at linux-firmware and driver test
>by David Wong   ==
>
>Nov, 1 2009: lgs8gxx: remove firmware for lgs8g75
>http://patchwork.kernel.org/patch/56822
>
>   == Andy Walls  and Aleksandr Piskunov
> are discussing around the solution ==
>
>Oct,11 2009: AVerTV MCE 116 Plus radio
>http://patchwork.kernel.org/patch/52981
>
>   == Patches waiting for Patrick Boettcher 
>review ==
>
>Jan,15 2010: remove obsolete conditionalizing on DVB_DIBCOM_DEBUG
>http://patchwork.kernel.org/patch/73147
>Feb, 8 2010: dib7000p: reduce large stack usage
>http://patchwork.kernel.org/patch/77891
>Feb, 8 2010: dib3000mc: reduce large stack usage
>http://patchwork.kernel.org/patch/77892
>
>   == IR driver for IMON - Will likely go via drivers/input tree
>==
>
>Feb,25 2010: [v2,
>http://patchwork.kernel.org/patch/82119
>
>   == Gspca patches - Waiting Hans de Goede 
>submission/review ==
>
>Jan,29 2010: [gspca_jf,tree] gspca zc3xx: signal when unknown packet
>received   http://patchwork.kernel.org/patch/75837
>Mar, 8 2010: [1/1] gspca-stv06xx: Remove the 046d:08da usb id from linking
>to the   http://patchwork.kernel.org/patch/84145
>
>   == Gspca patches - Waiting Jean-Francois Moine
> submission/review ==
>
>Jan,14 2010: Problem with gspca and zc3xx
>http://patchwork.kernel.org/patch/72895
>Feb,24 2010: gspca pac7302: add USB PID range based on heuristics
>http://patchwork.kernel.org/patch/81612
>Feb,27 2010: [01/11] ov534: Remove ambiguous controls
>http://patchwork.kernel.org/patch/82721
>Feb,27 2010: [02/11] ov534: Remove hue control
>http://patchwork.kernel.org/patch/82722
>Feb,27 2010: [03/11] ov534: Fix autogain control, enable it by default
>http://patchwork.kernel.org/patch/82725
>Feb,27 2010: [04/11] ov534: Add Auto Exposure
>http://patchwork.kernel.org/patch/82728
>Mar, 1 2010: [v2,05/11] ov534: Fix and document setting manual exposure
>http://patchwork.kernel.org/patch/82910
>Feb,27 2010: [06/11] ov534: Fix Auto White Balance control
>http://patchwork.kernel.org/patch/82718
>Feb,27 2010: [07/11] ov534: Fixes for sharpness control
>http://patchwork.kernel.org/patch/82724
>Feb,27 2010: [08

[PATCH - FIX] V4L: vpfe_capture - free ccdc_lock when memory allocation fails

[m-karicheri2]

From: Murali Karicheri 

This patch fixes a bug in vpfe_probe() that doesn't call mutex_unlock() if 
memory
allocation for ccdc_cfg fails. See also the smatch warning report from Dan
Carpenter that shows this as an issue.

Signed-off-by: Murali Karicheri 
---
 drivers/media/video/davinci/vpfe_capture.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c 
b/drivers/media/video/davinci/vpfe_capture.c
index 885cd54..91f665b 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1829,7 +1829,7 @@ static __init int vpfe_probe(struct platform_device *pdev)
if (NULL == ccdc_cfg) {
v4l2_err(pdev->dev.driver,
 "Memory allocation failed for ccdc_cfg\n");
-   goto probe_free_dev_mem;
+   goto probe_free_lock;
}
 
strncpy(ccdc_cfg->name, vpfe_cfg->ccdc, 32);
@@ -1981,8 +1981,9 @@ probe_out_video_release:
 probe_out_release_irq:
free_irq(vpfe_dev->ccdc_irq0, vpfe_dev);
 probe_free_ccdc_cfg_mem:
-   mutex_unlock(&ccdc_lock);
kfree(ccdc_cfg);
+probe_free_lock:
+   mutex_unlock(&ccdc_lock);
 probe_free_dev_mem:
kfree(vpfe_dev);
return ret;
-- 
1.6.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Status of the patches under review (45 patches)

[Devin Heitmueller]

On Tue, Mar 9, 2010 at 2:55 PM, VDR User  wrote:
> What happened to the statistics patch?

The statistics patch still needs a ton of work before it could be
accepted upstream.  Mostly these things are related to clarification
as to how the API should behave and how a variety of edge cases should
be handled.  I came up with about three paragraphs worth of issues
with the proposed approach, but haven't had a chance to push it to the
mailing list for further discussion.

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: Status of the patches under review (45 patches)

[VDR User]

What happened to the statistics patch?
--
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: s2-liplianin, mantis: sysfs: cannot create duplicate filename '/devices/virtual/irrcv'

[Igor M. Liplianin]

On 8 марта 2010 22:41:26 VDR User wrote:
> This isn't an answer to your questions but I don't recommend using the
> s2-liplianin tree as it contains timing patches which can cause
> serious damage to your tuner.  This has also been confirmed by the
> manufacturer as well and to my knowledge has unfortunately not been
> reverted in that tree.
Funny enough.
VDR User, you are wrong for years. Look here
http://mercurial.intuxication.org/hg/s2-liplianin/rev/c15f31375c53

>
> I strongly urge you to use either of these _safe_ trees:
>
> http://jusst.de/hg/mantis-v4l-dvb (for development drivers, which may
> still be stable)
> http://linuxtv.org/hg/v4l-dvb (for more stable drivers)
MartinG, I'm already planning to replace mantis related part with linuxtv one,
so please use http://linuxtv.org/hg/v4l-dvb.
But not get wrong, this tree isn't panacea, your reports are welcome.

Linuxoid greetings for all.
-- 
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
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

Status of the patches under review (45 patches)

[Mauro Carvalho Chehab]

This is the summary of the patches that are currently under review.
Each patch is represented by its submission date, the subject (up to 70 
chars) and the patchwork link (if submitted via email). Currently, there's
no pending hg/git pull request or new patches at patchwork.

P.S.: This email is c/c to the developers that some review action is expected.

== Waiting for my fixes on Docbook == 

Feb,25 2010: DocBook/Makefile: Make it less verbose 
http://patchwork.kernel.org/patch/82076
Feb,25 2010: DocBook: Add rules to auto-generate some media docbooks
http://patchwork.kernel.org/patch/82075
Feb,25 2010: [PATCHv2,  
http://patchwork.kernel.org/patch/82074
Feb,25 2010: [PATCHv2,  
http://patchwork.kernel.org/patch/82073

== Videobuf patches - Need more tests before committing it - 
Volunteers? == 

Jan,19 2010: [v1,1/1] V4L: Add sync before a hardware operation to videobuf.
http://patchwork.kernel.org/patch/73896
Mar, 4 2010: [1/2] V4L/DVB: buf-dma-sg.c: don't assume nr_pages == sglen
http://patchwork.kernel.org/patch/83626
Mar, 4 2010: [2/2] V4L/DVB: buf-dma-sg.c: support non-pageable user-allocated   
http://patchwork.kernel.org/patch/83627

== Waiting for Antti Palosaari  review == 

Feb,26 2010: af901x: NXP TDA18218   
http://patchwork.kernel.org/patch/82494

== Waiting for Muralidharan Karicheri  
review == 

Feb,19 2010: video_device: don't free_irq() an element past array 
vpif_obj.dev[]http://patchwork.kernel.org/patch/80845

== Waiting for Tobias Lorenz  review == 

Feb, 3 2010: radio-si470x-common: -EINVAL overwritten in 
si470x_vidioc_s_tuner()http://patchwork.kernel.org/patch/76786

== waiting for Jean Delvare  final 
submission after tests == 

Jan,30 2010: saa7134: Fix IR support of some ASUS TV-FM 7135 variants   
http://patchwork.kernel.org/patch/75883

== Waiting for its addition at linux-firmware and driver test 
by David Wong   == 

Nov, 1 2009: lgs8gxx: remove firmware for lgs8g75   
http://patchwork.kernel.org/patch/56822

== Andy Walls  and Aleksandr Piskunov 
 are discussing around the solution == 

Oct,11 2009: AVerTV MCE 116 Plus radio  
http://patchwork.kernel.org/patch/52981

== Patches waiting for Patrick Boettcher  
review == 

Jan,15 2010: remove obsolete conditionalizing on DVB_DIBCOM_DEBUG   
http://patchwork.kernel.org/patch/73147
Feb, 8 2010: dib7000p: reduce large stack usage 
http://patchwork.kernel.org/patch/77891
Feb, 8 2010: dib3000mc: reduce large stack usage
http://patchwork.kernel.org/patch/77892

== IR driver for IMON - Will likely go via drivers/input tree 
== 

Feb,25 2010: [v2,   
http://patchwork.kernel.org/patch/82119

== Gspca patches - Waiting Hans de Goede  
submission/review == 

Jan,29 2010: [gspca_jf,tree] gspca zc3xx: signal when unknown packet received   
http://patchwork.kernel.org/patch/75837
Mar, 8 2010: [1/1] gspca-stv06xx: Remove the 046d:08da usb id from linking to 
the   http://patchwork.kernel.org/patch/84145

== Gspca patches - Waiting Jean-Francois Moine 
 submission/review == 

Jan,14 2010: Problem with gspca and zc3xx   
http://patchwork.kernel.org/patch/72895
Feb,24 2010: gspca pac7302: add USB PID range based on heuristics   
http://patchwork.kernel.org/patch/81612
Feb,27 2010: [01/11] ov534: Remove ambiguous controls   
http://patchwork.kernel.org/patch/82721
Feb,27 2010: [02/11] ov534: Remove hue control  
http://patchwork.kernel.org/patch/82722
Feb,27 2010: [03/11] ov534: Fix autogain control, enable it by default  
http://patchwork.kernel.org/patch/82725
Feb,27 2010: [04/11] ov534: Add Auto Exposure   
http://patchwork.kernel.org/patch/82728
Mar, 1 2010: [v2,05/11] ov534: Fix and document setting manual exposure 
http://patchwork.kernel.org/patch/82910
Feb,27 2010: [06/11] ov534: Fix Auto White Balance control  
http://patchwork.kernel.org/patch/82718
Feb,27 2010: [07/11] ov534: Fixes for sharpness control 
http://patchwork.kernel.org/patch/82724
Feb,27 2010: [08/11] ov534: Fix unsetting hflip and vflip bits  
http://patchwork.kernel.org/patch/82729
Mar, 1 2010: [v2,09/11] ov534: Cosmetics: fix indentation and hex di

Re: HG pull http://jusst.de/hg/mantis-v4l-dvb

[Mauro Carvalho Chehab]

Manu Abraham wrote:
> Mauro,
> 
> Please pull from http://jusst.de/hg/mantis-v4l-dvb

This tree also needs rebase. Some of the patches were already applied:

# Mercurial patches imported from http://jusst.de/hg/mantis-v4l-dvb
hg_14410_stv090x_code_simplification.patch
hg_14411_stv090x_stv6110x_use_tuner_sleep_within_the_demodulator_control.patch
hg_14412_stv090x_use_gate_control_while_tuner_is_being_accessed.patch
hg_14413_budget_stv090x_stv6110x_initialize_the_demodulator_immediately_after.patch
hg_14414_stv090x_add_some_notes_about_the_internal_tuner_i_o_control.patch
hg_14415_mantis_remote_control_for_mantis.patch
hg_14416_mantis_hopper_use_module_device_table.patch
hg_14417_mantis_hopper_do_not_unregister_modules_twice.patch

Also, if just the last 3 patches are applied, lots of checkpacth errors are 
produced:

WARNING: line over 80 characters
#172: FILE: drivers/media/dvb/mantis/mantis_cards.c:223:
+   dprintk(MANTIS_ERROR, 1, "ERROR: Mantis INPUT initialization 
failed <%d>", err);

WARNING: line over 80 characters
#355: FILE: drivers/media/dvb/mantis/mantis_dvb.c:292:
+   mantis->demux.dmx.remove_frontend(&mantis->demux.dmx, 
&mantis->fe_mem);

WARNING: line over 80 characters
#356: FILE: drivers/media/dvb/mantis/mantis_dvb.c:293:
+   mantis->demux.dmx.remove_frontend(&mantis->demux.dmx, 
&mantis->fe_hw);

ERROR: trailing whitespace
#489: FILE: drivers/media/dvb/mantis/mantis_input.c:57:
+^Isnprintf(mir->rc_name, sizeof(mir->rc_name), $

ERROR: code indent should use tabs where possible
#490: FILE: drivers/media/dvb/mantis/mantis_input.c:58:
+^I "Mantis %s IR Receiver", mantis->hwconfig->model_name);$

ERROR: trailing whitespace
#491: FILE: drivers/media/dvb/mantis/mantis_input.c:59:
+^Isnprintf(mir->rc_phys, sizeof(mir->rc_phys), $

ERROR: code indent should use tabs where possible
#492: FILE: drivers/media/dvb/mantis/mantis_input.c:60:
+^I "pci-%s/ir0", pci_name(mantis->pdev));$

WARNING: line over 80 characters
#499: FILE: drivers/media/dvb/mantis/mantis_input.c:64:
+   dprintk(MANTIS_ERROR, 1, "Input device %s PCI: %s", mir->rc_name, 
mir->rc_phys);

WARNING: line over 80 characters
#551: FILE: drivers/media/dvb/mantis/mantis_input.c:105:
+   dprintk(MANTIS_ERROR, 0, "RC Input Sendkey:%d <%02x>\n", i, 
buf[i]);

ERROR: space required before the open parenthesis '('
#588: FILE: drivers/media/dvb/mantis/mantis_uart.c:106:
+   if(config->uart_work) {

WARNING: braces {} are not necessary for single statement blocks
#588: FILE: drivers/media/dvb/mantis/mantis_uart.c:106:
+   if(config->uart_work) {
+   config->uart_work(mantis, buf);
+   }

ERROR: code indent should use tabs where possible
#592: FILE: drivers/media/dvb/mantis/mantis_uart.c:110:
+/* reenable interrupt */$

ERROR: code indent should use tabs where possible
#593: FILE: drivers/media/dvb/mantis/mantis_uart.c:111:
+mmwrite(mmread(MANTIS_INT_MASK) | 0x800, MANTIS_INT_MASK);$

ERROR: code indent should use tabs where possible
#594: FILE: drivers/media/dvb/mantis/mantis_uart.c:112:
+mmwrite(mmread(MANTIS_UART_CTL) | MANTIS_UART_RXINT, MANTIS_UART_CTL);$

WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
#670: FILE: drivers/media/dvb/mantis/mantis_vp1041.c:102:
+EXPORT_SYMBOL_GPL(ir_codes_mantis_vp1041_table);

WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
#767: FILE: drivers/media/dvb/mantis/mantis_vp2033.c:107:
+EXPORT_SYMBOL_GPL(ir_codes_mantis_vp2033_table);

WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
#850: FILE: drivers/media/dvb/mantis/mantis_vp2040.c:93:
+EXPORT_SYMBOL_GPL(ir_codes_mantis_vp2040_table);

total: 8 errors, 9 warnings, 798 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

-- 

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: HG pull http://jusst.de/hg/az6027

[Mauro Carvalho Chehab]

Manu Abraham wrote:
> Mauro,
> 
> Please pull from http://jusst.de/hg/az6027
> 
> for the following changes ..
> 
> changeset 14171
> AZ6027: Fix initialization for some cards.
> http://jusst.de/hg/az6027/rev/e3fc5ce24047
> 
> changeset 14170
> AZ6027: Add support for Technisat V1 device
> http://jusst.de/hg/az6027/rev/ae49a54b4524

Applied.

Could you please rebase your tree on a next pull request?

It is importing again the entire az6027 tree:

# Mercurial patches imported from http://jusst.de/hg/az6027
hg_14410_dst_fixes_for_dvb_c_twinhan_vp2031.patch
hg_14411_az6027_initial_import_of_the_driver.patch
hg_14412_az6027_add_driver_supported_id_s.patch
hg_14413_az6027_update_build.patch
hg_14414_az6027_add_driver_supported_id_s.patch
hg_14415_az6027_fix_checkpatch_violations.patch
hg_14416_az6027_fix_build_warnings.patch
hg_14417_az6027_add_support_for_technisat_v1_device.patch
hg_14418_az6027_fix_initialization_for_some_cards.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: Help with RTL2832U DVB-T dongle (LeadTek WinFast DTV Dongle Mini)

[thomas schorpp]

LiM wrote:

Hi,

for information...i have the same dongle (LeadTek WinFast DTV Dongle
Mini - Bus 001 Device 003: ID 0413:6a03 Leadtek Research, Inc. )
and after compiled RTL2832U + change VID+PID in rtl2832u.h (i changed
USB_VID_GTEK + USB_PID_GTEK_WARM to leadtek`s 0413:6a03)
is tuner working!  (me-tv + kaffeine)



Good. Supported tuner chip. Pls do extensive tests (multiple recording streams, long time use usb-disconnects, 
other dvb apps...) and report any issues.


But we must support the MSI and others, too, so introduce an USB-ids array and device detection for 
USB_VID_GTEK + USB_PID_GTEK_WARM, see the other drivers for example code.


I don't have got the devices.


Installation of Realtek rtl2832u-based DVB-T-USB-Sticks:




gedit ./linux/drivers/media/dvb/dvb-usb/Makefile


Not acceptable in linux software development, pls *attach* patch to a mail with [PATCH]... in subject line 
by using linux diff utility (man diff) 
Example:

diff -rNU3   > ubuntuusers-de-rtl2832u-01.patch
With signed-off-by  


For patching non-driver user space apps, please contact their project devlists.

y
tom


Jan Hoogenraad napsal(a):

Mauro:

Can you remove the VERY OLD branch:
http://linuxtv.org/hg/~mchehab/rtl2831/rev/d116540ebaab
It is giving some confusion here.

Thomas & Jan:

I've got the RTL2831 code (mind the last digit) vetted off by LeadTek.
For the rtl2832, I haven't had contact with them.

Certainly, Jan could try any of the three archives.
I know Antti has thoughts on the rtl2832, I'm sure he knows more.

thomas schorpp wrote:

Jan Hoogenraad wrote:

Antti has been working on drivers for the RTL283x.

http://linuxtv.org/hg/~anttip/rtl2831u
or
http://linuxtv.org/hg/~anttip/qt1010/

~jhoogenraad/rtl2831-r2 rtl2831-r2 development repository: *known
working version* Jan Hoogenraad

Should Jan Slaninka try it?

If you have more information on the RTL2832, I'd be happy to add it at:
http://www.linuxtv.org/wiki/index.php/Rtl2831_devices

Nothing on the Realtek website yet.



Jan Slaninka wrote:

Hi,

I'd like to ask for a support with getting LeadTek WindFast DTV Dongle
mini running on Linux. So far I was able to fetch latest v4l-dvb from
HG, and successfully compiled module dvb_usb_rtl2832u found in
090730_RTL2832U_LINUX_Ver1.1.rar  

Can be considered as GPL code then according to

http://linuxtv.org/hg/~mchehab/rtl2831/rev/d116540ebaab

Patch to make RTL2831U DVB-T USB2.0 DEVICE work, based on RealTek
version 080314

~mchehab/rtl2831 rtl2831 development repository with *RealTek GPL
code* for rtl2831 Mauro Carvalho Chehab 24 months ago

?

y
tom

--
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] V4L: vpfe_capture - free ccdc_lock when memory allocation fails

[m-karicheri2]

From: Murali Karicheri 

This patch fixes a bug in vpfe_probe() that doesn't call mutex_unlock() if 
memory
allocation for ccdc_cfg fails. See also the smatch warning report from Dan
Carpenter that shows this as an issue.

Signed-off-by: Murali Karicheri 
---
 drivers/media/video/davinci/vpfe_capture.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c 
b/drivers/media/video/davinci/vpfe_capture.c
index 885cd54..91f665b 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1829,7 +1829,7 @@ static __init int vpfe_probe(struct platform_device *pdev)
if (NULL == ccdc_cfg) {
v4l2_err(pdev->dev.driver,
 "Memory allocation failed for ccdc_cfg\n");
-   goto probe_free_dev_mem;
+   goto probe_free_lock;
}
 
strncpy(ccdc_cfg->name, vpfe_cfg->ccdc, 32);
@@ -1981,8 +1981,9 @@ probe_out_video_release:
 probe_out_release_irq:
free_irq(vpfe_dev->ccdc_irq0, vpfe_dev);
 probe_free_ccdc_cfg_mem:
-   mutex_unlock(&ccdc_lock);
kfree(ccdc_cfg);
+probe_free_lock:
+   mutex_unlock(&ccdc_lock);
 probe_free_dev_mem:
kfree(vpfe_dev);
return ret;
-- 
1.6.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KWorld UB435-Q Support

[Amy Overmyer]

On Tue, Nov 17, 2009 at 11:59 PM, Jarod Wilson  wrote:

snip

>>Or a few months later. About two weeks ago, I finally poked at these
>>sticks some more, after getting a bit of info from another user, and
>>we've finally got an actual fix for this problem -- .deny_i2c_rptr = 1
>>just needed to be set in the lgdt3305_config struct, as the device's
>>tuner isn't actually behind an i2c gate. With that change, the stick
>>behaves quite well w/o any alterations to the tda18271 code. Patches
>>are here:
>>
>>http://wilsonet.com/jarod/junk/kworld-a340-20100218/
>>
>>They're in Mike's hands now, since they rely so heavily on the lgdt3305 
>>driver.

I compiled up this change on my setup and the Kworld is working wonderfully for 
me now. I was able to do a full ATSC us center freq scan pretty quickly and 
then added it to mythtv and its working well there, too. It's doing OTA capture.

Thanks, Jarod.


  
--
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: Hw capabilities of the HVR-2200

[Jed]

19/09/09 Jed wrote:

2) Component input for the A/V-in


Yes, this exists on the HVR2250 product only.


Ah shite, are you sure?
If you look at the specs for the reference card it was there, did they
take it out at the last minute?


It's not feature Hauppauge supports on the HVR2200 today. I have a 
suspicion this may change but I'm neither confirming, denying or 
announcing anything. It would make sense to officially support 
component cables on the HVR2200 since the silicon supports it. If/when 
it does I'm sure it will be mentioned in the forums or on the HVR2200 
product packaging.


Hi Steve, when you said this is not a feature Hauppauge supports.
Did you mean it's not fully enabled physically in the PCB...
Or is it just something they need to add support for in the driver?
If the latter do you know if their policy has changed or is about to?


3) Hw encode bypass for A/V-in


No idea. Regardless of whether it does or does not I wouldn't plan to
add basic raw TV support to the driver, without going through the
encoder.


Why do you rule it out unequivocally, is it just because I've annoyed
you? :-(


Raw analog TV isn't a high priority feature on my mental check-list. 
Analog TV via the encoder is much more interesting and applicable to 
many people.


Assuming that progress has been made on analogue to 
h.263/mpeg4/VC-1/DivX/Xvid via the A/V-in encoder.

Is this still considered a low priority?

Has progress been made on hw encode via A/V-in?
I'm "finally" putting my entire system together soon, can't wait!
Looking forward to seeing how everything has progressed.
I'll be sure to do some donations once I'm up & running!

--
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 1/3] gspca: add LEDs subsystem connection

[Richard Purdie]

On Tue, 2010-03-09 at 12:27 +0100, Laurent Pinchart wrote:
> Hi Màrton,
> 
> Thanks for the patch.
> 
> On Wednesday 03 March 2010 00:42:23 Németh Márton wrote:
> > From: Márton Németh 
> > 
> > On some webcams one or more LEDs can be found. One type of these LEDs
> > are feedback LEDs: they usually shows the state of streaming mode.
> > The LED can be programmed to constantly switched off state (e.g. for
> > power saving reasons, preview mode) or on state (e.g. the application
> > shows motion detection or "on-air").
> > 
> > The second type of LEDs are used to create enough light for the sensor
> > for example visible or in infra-red light.
> > 
> > Both type of these LEDs can be handled using the LEDs subsystem. This
> > patch add support to connect a gspca based driver to the LEDs subsystem.
> 
> They can indeed, but I'm not sure if the LEDs subsystem was designed for that 
> kind of use cases.

The LED subsystem was designed to support LED lights and the above
scenarios can certainly fit that. It provides a nice system where
default use cases should just work (power light on a laptop) but the
system has the control to override than and do other interesting things
with it if it so wishes.

> The LED framework was developed to handle LEDs found in embedded systems 
> (usually connected to GPIOs) that needed to be connected to software triggers 
> or controlled by drivers and/or specific userspace applications.

Its used by many laptops so its not just embedded systems.

>  Webcam LEDs 
> seem a bit out of scope to me, especially the "light" LED that might be 
> better 
> handled by a V4L2 set of controls (we're currently missing controls for 
> camera 
> flashes, be they LEDs or Xenon based).
> 
> I'll let Richard speak on this.

I'm not going to push one way or another and its up to individual
subsystems to way up the benefits and drawbacks and make their decision.
There is nothing in the design of the system which would stop it working
or being used in this case though. If the susystsme needs improvements
to work well, I'm happy to accept patches too.

Cheers,

Richard





--
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 v8 0/6] V4L2 file handles and event interface

[Mauro Carvalho Chehab]

Sakari,

As usual, I'm marking those patches as RFC. Please add them on some tree
and ask me to pull from it, when you think that event interface is ready 
for upstream merge.

Cheers,
Mauro.

Sakari Ailus wrote:
> Hi,
> 
> Here's the tenth version of the V4L2 file handle and event interface
> patchset.
> 
> The patchset has been tested with the OMAP 3 ISP driver. Patches for
> OMAP 3 ISP are not part of this patchset but are available in Gitorious
> (branch is called event):
> 
>   git://gitorious.org/omap3camera/mainline.git event
> 
> The patchset I'm posting now is against the v4l-dvb tree instead of
> linux-omap. The omap3camera tree thus has a slightly different
> version of these patches (just Makefiles) due to different baselines.
> 
> Some more comments from Hans and Randy. There are only improvements in
> documentation this time.
> 
> Comments are welcome as always.
> 
> Cheers,
> 


-- 

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: [RFC, PATCH 1/3] gspca: add LEDs subsystem connection

[Laurent Pinchart]

Hi Màrton,

Thanks for the patch.

On Wednesday 03 March 2010 00:42:23 Németh Márton wrote:
> From: Márton Németh 
> 
> On some webcams one or more LEDs can be found. One type of these LEDs
> are feedback LEDs: they usually shows the state of streaming mode.
> The LED can be programmed to constantly switched off state (e.g. for
> power saving reasons, preview mode) or on state (e.g. the application
> shows motion detection or "on-air").
> 
> The second type of LEDs are used to create enough light for the sensor
> for example visible or in infra-red light.
> 
> Both type of these LEDs can be handled using the LEDs subsystem. This
> patch add support to connect a gspca based driver to the LEDs subsystem.

They can indeed, but I'm not sure if the LEDs subsystem was designed for that 
kind of use cases.

The LED framework was developed to handle LEDs found in embedded systems 
(usually connected to GPIOs) that needed to be connected to software triggers 
or controlled by drivers and/or specific userspace applications. Webcam LEDs 
seem a bit out of scope to me, especially the "light" LED that might be better 
handled by a V4L2 set of controls (we're currently missing controls for camera 
flashes, be they LEDs or Xenon based).

I'll let Richard speak on this.

-- 
Regards,

Laurent Pinchart
--
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 1/3] v4l: Add support for multi-plane buffers to V4L2 API.

[Mauro Carvalho Chehab]

Pawel Osciak wrote:
> Current V4L2 API assumes that each video buffer contains exactly one,
> contiguous memory buffer for video data. Even in case of planar video
> formats, e.g. YCbCr with each component residing in a separate area
> of memory, it is specified that each of those planes immediately follows
> the previous one in memory.
> 
> There exist hardware video devices that handle, or even require, each of
> the planes to reside in a separate, arbitrary memory area. Some even
> require different planes to be placed in different, physical memory banks.
> 
> This patch introduces a backward-compatible extension of V4L2 API, which
> allows passing additional, per-plane info in the video buffer structure.
> 
> Signed-off-by: Pawel Osciak 
> Reviewed-by: Marek Szyprowski 
> Reviewed-by: Kyungmin Park 
> ---
>  drivers/media/video/v4l2-ioctl.c |   97 ++---
>  include/linux/videodev2.h|   33 -
>  2 files changed, 99 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/media/video/v4l2-ioctl.c 
> b/drivers/media/video/v4l2-ioctl.c
> index 4b11257..b89b73f 100644
> --- a/drivers/media/video/v4l2-ioctl.c
> +++ b/drivers/media/video/v4l2-ioctl.c
> @@ -172,6 +172,8 @@ static const char *v4l2_memory_names[] = {
>   [V4L2_MEMORY_MMAP]= "mmap",
>   [V4L2_MEMORY_USERPTR] = "userptr",
>   [V4L2_MEMORY_OVERLAY] = "overlay",
> + [V4L2_MEMORY_MULTI_USERPTR] = "multi-userptr",
> + [V4L2_MEMORY_MULTI_MMAP]= "multi-mmap",
>  };
>  
>  #define prt_names(a, arr) a) >= 0) && ((a) < ARRAY_SIZE(arr))) ? \
> @@ -1975,7 +1977,7 @@ static unsigned long cmd_input_size(unsigned int cmd)
>   switch (cmd) {
>   CMDINSIZE(ENUM_FMT, fmtdesc,type);
>   CMDINSIZE(G_FMT,format, type);
> - CMDINSIZE(QUERYBUF, buffer, type);
> + CMDINSIZE(QUERYBUF, buffer, length);
>   CMDINSIZE(G_PARM,   streamparm, type);
>   CMDINSIZE(ENUMSTD,  standard,   index);
>   CMDINSIZE(ENUMINPUT,input,  index);
> @@ -2000,6 +2002,46 @@ static unsigned long cmd_input_size(unsigned int cmd)
>   }
>  }
>  
> +static int check_array_args(unsigned int cmd, void *parg, size_t *array_size,
> + void * __user *user_ptr, void ***kernel_ptr)
> +{
> + int ret = 0;
> +
> + switch(cmd) {
> + case VIDIOC_QUERYBUF:
> + case VIDIOC_QBUF:
> + case VIDIOC_DQBUF: {
> + struct v4l2_buffer *buf = parg;
> +
> + if ((buf->memory == V4L2_MEMORY_MULTI_USERPTR
> +  || buf->memory == V4L2_MEMORY_MULTI_MMAP)) {
> + *user_ptr = (void __user *)buf->m.planes;
> + *kernel_ptr = (void **)&buf->m.planes;
> + *array_size = sizeof(struct v4l2_plane) * buf->length;
> + ret = 1;
> + }
> + break;
> + }
> +
> + case VIDIOC_S_EXT_CTRLS:
> + case VIDIOC_G_EXT_CTRLS:
> + case VIDIOC_TRY_EXT_CTRLS: {
> + struct v4l2_ext_controls *ctrls = parg;
> +
> + if (ctrls->count != 0) {
> + *user_ptr = (void __user *)ctrls->controls;
> + *kernel_ptr = (void **)&ctrls->controls;
> + *array_size = sizeof(struct v4l2_ext_control)
> + * ctrls->count;
> + ret = 1;
> + }
> + break;
> + }
> + }
> +
> + return ret;
> +}
> +
>  long video_ioctl2(struct file *file,
>  unsigned int cmd, unsigned long arg)
>  {
> @@ -2007,15 +2049,16 @@ long video_ioctl2(struct file *file,
>   void*mbuf = NULL;
>   void*parg = NULL;
>   longerr  = -EINVAL;
> - int is_ext_ctrl;
> - size_t  ctrls_size = 0;
> + int has_array_args;
> + size_t  array_size = 0;
>   void __user *user_ptr = NULL;
> + void**kernel_ptr = NULL;
>  
>  #ifdef __OLD_VIDIOC_
>   cmd = video_fix_command(cmd);
>  #endif
> - is_ext_ctrl = (cmd == VIDIOC_S_EXT_CTRLS || cmd == VIDIOC_G_EXT_CTRLS ||
> -cmd == VIDIOC_TRY_EXT_CTRLS);
> + /*is_ext_ctrl = (cmd == VIDIOC_S_EXT_CTRLS || cmd == VIDIOC_G_EXT_CTRLS 
> ||
> +cmd == VIDIOC_TRY_EXT_CTRLS);*/

Just drop it if not used anymore.

>  
>   /*  Copy arguments into temp kernel buffer  */
>   if (_IOC_DIR(cmd) != _IOC_NONE) {
> @@ -2045,43 +2088,39 @@ long video_ioctl2(struct file *file,
>   }
>   }
>  
> - if (is_ext_ctrl) {
> - struct v4l2_ext_controls *p = parg;
> + has_array_args = check_array_args(cmd, parg, &array_size,
> +   &user_ptr, &kernel_ptr);
>  
> - /* In case of an error, tell the caller that it wasn't
> -   

[PATCH v2 2/3] v4l: videobuf: Add support for multi-plane buffers.

[Pawel Osciak]

Add support for multiplanar buffers to videobuf core, dma-contig
and vmalloc memory types.

Signed-off-by: Pawel Osciak 
Reviewed-by: Kyungmin Park 
---
 drivers/media/video/videobuf-core.c   |  375 -
 drivers/media/video/videobuf-dma-contig.c |  297 +--
 drivers/media/video/videobuf-vmalloc.c|  188 ---
 include/media/videobuf-core.h |   59 +++--
 include/media/videobuf-dma-contig.h   |3 +
 include/media/videobuf-vmalloc.h  |2 +
 6 files changed, 722 insertions(+), 202 deletions(-)

diff --git a/drivers/media/video/videobuf-core.c 
b/drivers/media/video/videobuf-core.c
index bb0a1c8..f54bbc8 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -29,6 +29,10 @@
printk(KERN_ERR "magic mismatch: %x (expected %x)\n", is, should); \
BUG(); } } while (0)
 
+#define is_multiplane(vb)\
+   (vb->memory == V4L2_MEMORY_MULTI_MMAP\
+|| vb->memory == V4L2_MEMORY_MULTI_USERPTR)
+
 static int debug;
 module_param(debug, int, 0644);
 
@@ -45,22 +49,24 @@ MODULE_LICENSE("GPL");
 #define CALL(q, f, arg...) \
((q->int_ops->f) ? q->int_ops->f(arg) : 0)
 
-void *videobuf_alloc(struct videobuf_queue *q)
+void *videobuf_alloc(struct videobuf_queue *q, unsigned int num_planes)
 {
struct videobuf_buffer *vb;
 
BUG_ON(q->msize < sizeof(*vb));
+   BUG_ON(0 == num_planes);
 
if (!q->int_ops || !q->int_ops->alloc) {
printk(KERN_ERR "No specific ops defined!\n");
BUG();
}
 
-   vb = q->int_ops->alloc(q->msize);
+   vb = q->int_ops->alloc(q->msize, num_planes);
 
if (NULL != vb) {
init_waitqueue_head(&vb->done);
vb->magic = MAGIC_BUFFER;
+   vb->num_planes = num_planes;
}
 
return vb;
@@ -106,6 +112,17 @@ void *videobuf_queue_to_vmalloc (struct videobuf_queue *q,
 }
 EXPORT_SYMBOL_GPL(videobuf_queue_to_vmalloc);
 
+void *videobuf_queue_plane_to_vmalloc(struct videobuf_queue *q,
+ struct videobuf_buffer *buf,
+ unsigned int plane)
+{
+   if (q->int_ops->plane_vmalloc)
+   return q->int_ops->plane_vmalloc(buf, plane);
+   else
+   return NULL;
+}
+EXPORT_SYMBOL_GPL(videobuf_queue_plane_to_vmalloc);
+
 /* - */
 
 
@@ -131,7 +148,8 @@ void videobuf_queue_core_init(struct videobuf_queue *q,
q->int_ops   = int_ops;
 
/* All buffer operations are mandatory */
-   BUG_ON(!q->ops->buf_setup);
+   BUG_ON(!q->ops->buf_negotiate);
+   BUG_ON(!q->ops->buf_setup_plane);
BUG_ON(!q->ops->buf_prepare);
BUG_ON(!q->ops->buf_queue);
BUG_ON(!q->ops->buf_release);
@@ -169,7 +187,7 @@ int videobuf_queue_is_busy(struct videobuf_queue *q)
for (i = 0; i < VIDEO_MAX_FRAME; i++) {
if (NULL == q->bufs[i])
continue;
-   if (q->bufs[i]->map) {
+   if (q->bufs[i]->mapped) {
dprintk(1, "busy: buffer #%d mapped\n", i);
return 1;
}
@@ -242,6 +260,8 @@ enum v4l2_field videobuf_next_field(struct videobuf_queue 
*q)
 static void videobuf_status(struct videobuf_queue *q, struct v4l2_buffer *b,
struct videobuf_buffer *vb, enum v4l2_buf_type type)
 {
+   unsigned int i;
+
MAGIC_CHECK(vb->magic, MAGIC_BUFFER);
MAGIC_CHECK(q->int_ops->magic, MAGIC_QTYPE_OPS);
 
@@ -251,20 +271,50 @@ static void videobuf_status(struct videobuf_queue *q, 
struct v4l2_buffer *b,
b->memory   = vb->memory;
switch (b->memory) {
case V4L2_MEMORY_MMAP:
-   b->m.offset  = vb->boff;
-   b->length= vb->bsize;
+   b->m.offset  = vb->planes[0].boff;
+   b->length= vb->planes[0].bsize;
break;
case V4L2_MEMORY_USERPTR:
-   b->m.userptr = vb->baddr;
-   b->length= vb->bsize;
+   b->m.userptr = vb->planes[0].baddr;
+   b->length= vb->planes[0].bsize;
break;
case V4L2_MEMORY_OVERLAY:
-   b->m.offset  = vb->boff;
+   b->m.offset  = vb->planes[0].boff;
+   break;
+   case V4L2_MEMORY_MULTI_MMAP:
+   if (NULL == b->m.planes) {
+   dprintk(1, "Warning: buffer details not copied back "
+  "as no planes array has been provided\n");
+   break;
+   }
+
+   BUG_ON(b->length < vb->num_planes);
+   b->length= vb->num_planes;
+   for (i = 0; i < vb->num_planes; ++i) {
+   b->m.planes[i].m.of

[PATCH v2 3/3] v4l: vivi: add 2- and 3-planar YCbCr422

[Pawel Osciak]

Add example 2- and 3- planar YCbCr422 formats for multi-plane
format testing.

Signed-off-by: Pawel Osciak 
Reviewed-by: Kyungmin Park 
---
 drivers/media/video/vivi.c |  179 +++-
 include/linux/videodev2.h  |3 +
 2 files changed, 147 insertions(+), 35 deletions(-)

diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index 37632a0..bc1ec0d 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -132,6 +132,9 @@ struct vivi_fmt {
char  *name;
u32   fourcc;  /* v4l2 format id */
int   depth;
+   unsigned int num_planes;
+   unsigned int plane_w_shr;
+   unsigned int plane_h_shr;
 };
 
 static struct vivi_fmt formats[] = {
@@ -139,31 +142,53 @@ static struct vivi_fmt formats[] = {
.name = "4:2:2, packed, YUYV",
.fourcc   = V4L2_PIX_FMT_YUYV,
.depth= 16,
+   .num_planes = 1,
},
{
.name = "4:2:2, packed, UYVY",
.fourcc   = V4L2_PIX_FMT_UYVY,
.depth= 16,
+   .num_planes = 1,
},
{
.name = "RGB565 (LE)",
.fourcc   = V4L2_PIX_FMT_RGB565, /* gggb rggg */
.depth= 16,
+   .num_planes = 1,
},
{
.name = "RGB565 (BE)",
.fourcc   = V4L2_PIX_FMT_RGB565X, /* rggg gggb */
.depth= 16,
+   .num_planes = 1,
},
{
.name = "RGB555 (LE)",
.fourcc   = V4L2_PIX_FMT_RGB555, /* gggb argg */
.depth= 16,
+   .num_planes = 1,
},
{
.name = "RGB555 (BE)",
.fourcc   = V4L2_PIX_FMT_RGB555X, /* argg gggb */
.depth= 16,
+   .num_planes = 1,
+   },
+   {
+   .name   = "YUV 4:2:2, 3-planar",
+   .fourcc = V4L2_PIX_FMT_YUV422PM,
+   .depth  = 16,
+   .num_planes = 3,
+   .plane_w_shr= 1,
+   .plane_h_shr= 0,
+   },
+   {
+   .name   = "YUV 4:2:2, 2-planar",
+   .fourcc = V4L2_PIX_FMT_NV16M,
+   .depth  = 16,
+   .num_planes = 2,
+   .plane_w_shr= 1,
+   .plane_h_shr= 0,
},
 };
 
@@ -361,6 +386,8 @@ static void precalculate_bars(struct vivi_fh *fh)
switch (fh->fmt->fourcc) {
case V4L2_PIX_FMT_YUYV:
case V4L2_PIX_FMT_UYVY:
+   case V4L2_PIX_FMT_YUV422PM:
+   case V4L2_PIX_FMT_NV16M:
is_yuv = 1;
break;
case V4L2_PIX_FMT_RGB565:
@@ -410,6 +437,8 @@ static void gen_twopix(struct vivi_fh *fh, unsigned char 
*buf, int colorpos)
 
switch (fh->fmt->fourcc) {
case V4L2_PIX_FMT_YUYV:
+   case V4L2_PIX_FMT_YUV422PM:
+   case V4L2_PIX_FMT_NV16M:
switch (color) {
case 0:
case 2:
@@ -558,30 +587,58 @@ end:
 static void vivi_fillbuff(struct vivi_fh *fh, struct vivi_buffer *buf)
 {
struct vivi_dev *dev = fh->dev;
-   int h , pos = 0;
+   int i, x, h, curr_plane = 0, pos = 0;
int hmax  = buf->vb.height;
int wmax  = buf->vb.width;
struct timeval ts;
-   char *tmpbuf;
-   void *vbuf = videobuf_to_vmalloc(&buf->vb);
+   char *tmpbuf, *p_tmpbuf;
+   char *vbuf[VIDEO_MAX_PLANES];
+
+   for (i = 0; i < fh->fmt->num_planes; ++i) {
+   vbuf[i] = videobuf_plane_to_vmalloc(&buf->vb, i);
+   if (!vbuf[i]) {
+   dprintk(dev, 1, "Failed acquiring vaddr for a plane\n");
+   return;
+   }
+   }
 
-   if (!vbuf)
-   return;
+   if (fh->fmt->num_planes > 1) {
+   tmpbuf = kmalloc(wmax * 2, GFP_ATOMIC);
+   if (!tmpbuf)
+   return;
+
+   for (h = 0; h < hmax; h++) {
+   gen_line(fh, tmpbuf, 0, wmax, hmax, h, dev->mv_count,
+dev->timestr);
+   p_tmpbuf = tmpbuf;
+
+   for (x = 0; x < wmax; ++x) {
+   *(vbuf[0]++) = *p_tmpbuf++;
+   *(vbuf[curr_plane + 1]++) = *p_tmpbuf++;
+   if (V4L2_PIX_FMT_YUV422PM == fh->fmt->fourcc)
+   curr_plane = !curr_plane;
+   }
+   }
 
-   tmpbuf = kmalloc(wmax * 2, GFP_ATOMIC);
-   if (!tmpbuf)
-   return;
+   dev->mv_count++;
 
-   for (h =

[PATCH/RFC v2 0/3] Multi-plane video buffer support for V4L2 API and videobuf

[Pawel Osciak]

Hello,

this version differs only slightly from the previous one, it fixes some
memory allocation/freeing-related problems of the previous patchset.

As was the case with v1, it is still intended for 
demonstration/discussion/testing
purposes only.


Changes since v2:
- simplified videobuf_buffer allocation
- fixed some videobuf_buffer memory leaks (missing kfrees)


The series contains:

[PATCH v2 1/3] v4l: Add support for multi-plane buffers to V4L2 API.
[PATCH v2 2/3] v4l: videobuf: Add support for multi-plane buffers.
[PATCH v2 3/3] v4l: vivi: add 2- and 3-planar YCbCr422

Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center
--
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 v2 1/3] v4l: Add support for multi-plane buffers to V4L2 API.

[Pawel Osciak]

Current V4L2 API assumes that each video buffer contains exactly one,
contiguous memory buffer for video data. Even in case of planar video
formats, e.g. YCbCr with each component residing in a separate area
of memory, it is specified that each of those planes immediately follows
the previous one in memory.

There exist hardware video devices that handle, or even require, each of
the planes to reside in a separate, arbitrary memory area. Some even
require different planes to be placed in different, physical memory banks.

This patch introduces a backward-compatible extension of V4L2 API, which
allows passing additional, per-plane info in the video buffer structure.

Signed-off-by: Pawel Osciak 
Reviewed-by: Marek Szyprowski 
Reviewed-by: Kyungmin Park 
---
 drivers/media/video/v4l2-ioctl.c |   97 ++---
 include/linux/videodev2.h|   33 -
 2 files changed, 99 insertions(+), 31 deletions(-)

diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 4b11257..b89b73f 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -172,6 +172,8 @@ static const char *v4l2_memory_names[] = {
[V4L2_MEMORY_MMAP]= "mmap",
[V4L2_MEMORY_USERPTR] = "userptr",
[V4L2_MEMORY_OVERLAY] = "overlay",
+   [V4L2_MEMORY_MULTI_USERPTR] = "multi-userptr",
+   [V4L2_MEMORY_MULTI_MMAP]= "multi-mmap",
 };
 
 #define prt_names(a, arr) a) >= 0) && ((a) < ARRAY_SIZE(arr))) ? \
@@ -1975,7 +1977,7 @@ static unsigned long cmd_input_size(unsigned int cmd)
switch (cmd) {
CMDINSIZE(ENUM_FMT, fmtdesc,type);
CMDINSIZE(G_FMT,format, type);
-   CMDINSIZE(QUERYBUF, buffer, type);
+   CMDINSIZE(QUERYBUF, buffer, length);
CMDINSIZE(G_PARM,   streamparm, type);
CMDINSIZE(ENUMSTD,  standard,   index);
CMDINSIZE(ENUMINPUT,input,  index);
@@ -2000,6 +2002,46 @@ static unsigned long cmd_input_size(unsigned int cmd)
}
 }
 
+static int check_array_args(unsigned int cmd, void *parg, size_t *array_size,
+   void * __user *user_ptr, void ***kernel_ptr)
+{
+   int ret = 0;
+
+   switch(cmd) {
+   case VIDIOC_QUERYBUF:
+   case VIDIOC_QBUF:
+   case VIDIOC_DQBUF: {
+   struct v4l2_buffer *buf = parg;
+
+   if ((buf->memory == V4L2_MEMORY_MULTI_USERPTR
+|| buf->memory == V4L2_MEMORY_MULTI_MMAP)) {
+   *user_ptr = (void __user *)buf->m.planes;
+   *kernel_ptr = (void **)&buf->m.planes;
+   *array_size = sizeof(struct v4l2_plane) * buf->length;
+   ret = 1;
+   }
+   break;
+   }
+
+   case VIDIOC_S_EXT_CTRLS:
+   case VIDIOC_G_EXT_CTRLS:
+   case VIDIOC_TRY_EXT_CTRLS: {
+   struct v4l2_ext_controls *ctrls = parg;
+
+   if (ctrls->count != 0) {
+   *user_ptr = (void __user *)ctrls->controls;
+   *kernel_ptr = (void **)&ctrls->controls;
+   *array_size = sizeof(struct v4l2_ext_control)
+   * ctrls->count;
+   ret = 1;
+   }
+   break;
+   }
+   }
+
+   return ret;
+}
+
 long video_ioctl2(struct file *file,
   unsigned int cmd, unsigned long arg)
 {
@@ -2007,15 +2049,16 @@ long video_ioctl2(struct file *file,
void*mbuf = NULL;
void*parg = NULL;
longerr  = -EINVAL;
-   int is_ext_ctrl;
-   size_t  ctrls_size = 0;
+   int has_array_args;
+   size_t  array_size = 0;
void __user *user_ptr = NULL;
+   void**kernel_ptr = NULL;
 
 #ifdef __OLD_VIDIOC_
cmd = video_fix_command(cmd);
 #endif
-   is_ext_ctrl = (cmd == VIDIOC_S_EXT_CTRLS || cmd == VIDIOC_G_EXT_CTRLS ||
-  cmd == VIDIOC_TRY_EXT_CTRLS);
+   /*is_ext_ctrl = (cmd == VIDIOC_S_EXT_CTRLS || cmd == VIDIOC_G_EXT_CTRLS 
||
+  cmd == VIDIOC_TRY_EXT_CTRLS);*/
 
/*  Copy arguments into temp kernel buffer  */
if (_IOC_DIR(cmd) != _IOC_NONE) {
@@ -2045,43 +2088,39 @@ long video_ioctl2(struct file *file,
}
}
 
-   if (is_ext_ctrl) {
-   struct v4l2_ext_controls *p = parg;
+   has_array_args = check_array_args(cmd, parg, &array_size,
+ &user_ptr, &kernel_ptr);
 
-   /* In case of an error, tell the caller that it wasn't
-  a specific control that caused it. */
-   p->error_idx = p->count;
-   user_ptr = (void __user *)p->controls;
-   if (p->count) 

Re: [patch] em28xx : Terratec Cinergy Hybrid T USB XS FR is now really working.

[Mauro Carvalho Chehab]

Hi Michel,

Catimimi wrote:
> Hi,
> 
> As I told you earlier, my previous patch was not working with a 64 bits
> kernel.
> So forget it.
> 
> 
> I now succed in running Cinergy Hybrid T USB XS FR with 32 and 64bits
> kernels.
> One problem remains, because of msp3400 driver, I don't have sound in
> analog mode.
> I'am still working on that problem.

First of all, as your previous patch got applied already at -git, you should
be sending us a diff patch against it (as the one enclosed), and not a complete
patch.

Also, please always send us patches with your Signed-off-by line as stated at 
kernel
Documentation/SubmittingPatches file.

With respect to msp3400, one of the things you may need to do is to change the 
i2s
speed, as msp3400 support two different speeds. If you use it with a wrong 
speed, you
won't listen the audio. 

There are two valid values: 1024000 and 2048000. The default is 1024000.

So, if your board uses 2048000 speed on i2s, you'll need to add this:

case EM2880_BOARD_TERRATEC_HYBRID_XS_FR:
dev->i2s_speed = 2048000;

to em28xx_pre_card_setup().

If the GPIO's for analog are ok, this should be enough to have audio working on 
it.

-- 

Cheers,
Mauro

---
 drivers/media/video/em28xx/em28xx-cards.c |   21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

--- work.orig/drivers/media/video/em28xx/em28xx-cards.c
+++ work/drivers/media/video/em28xx/em28xx-cards.c
@@ -170,6 +170,18 @@ static struct em28xx_reg_seq pinnacle_hy
{   -1, -1, -1, -1},
 };
 
+static struct em28xx_reg_seq terratec_cinergy_USB_XS_analog[] = {
+   {EM28XX_R08_GPIO,   0x6d,   ~EM_GPIO_4, 10},
+   {EM2880_R04_GPO,0x00,   0xff,   10},
+   { -1,   -1, -1, -1},
+};
+
+static struct em28xx_reg_seq terratec_cinergy_USB_XS_digital[] = {
+   {EM28XX_R08_GPIO,   0x6e,   ~EM_GPIO_4, 10},
+   {EM2880_R04_GPO,0x08,   0xff,   10},
+   { -1,   -1, -1, -1},
+};
+
 /* eb1a:2868 Reddo DVB-C USB TV Box
GPIO4 - CU1216L NIM
Other GPIOs seems to be don't care. */
@@ -750,22 +762,22 @@ struct em28xx_board em28xx_boards[] = {
.tuner_gpio   = default_tuner_gpio,
.decoder  = EM28XX_TVP5150,
.has_dvb  = 1,
-   .dvb_gpio = default_digital,
+   .dvb_gpio = terratec_cinergy_USB_XS_digital,
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = TVP5150_COMPOSITE0,
.amux = EM28XX_AMUX_VIDEO,
-   .gpio = default_analog,
+   .gpio = terratec_cinergy_USB_XS_analog,
}, {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = TVP5150_COMPOSITE1,
.amux = EM28XX_AMUX_LINE_IN,
-   .gpio = default_analog,
+   .gpio = terratec_cinergy_USB_XS_analog,
}, {
.type = EM28XX_VMUX_SVIDEO,
.vmux = TVP5150_SVIDEO,
.amux = EM28XX_AMUX_LINE_IN,
-   .gpio = default_analog,
+   .gpio = terratec_cinergy_USB_XS_analog,
} },
},
[EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900] = {
@@ -2118,6 +2130,7 @@ static void em28xx_setup_xc3028(struct e
ctl->demod = XC3028_FE_ZARLINK456;
break;
case EM2880_BOARD_TERRATEC_HYBRID_XS:
+   case EM2880_BOARD_TERRATEC_HYBRID_XS_FR:
case EM2881_BOARD_PINNACLE_HYBRID_PRO:
ctl->demod = XC3028_FE_ZARLINK456;
break;
--
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

Post DSO scan file for Aberdare

[Mike]

Please see attached scan file for uk-Aberdare if anyone finds it useful

# UK, Aberdare
# Auto-generated from http://www.dtg.org.uk/retailer/dtt_channels.html
# and http://www.ofcom.org.uk/static/reception_advice/index.asp.html
# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
T 489833000 8MHz 2/3 NONE QAM64 2k 1/32 NONE
T 497833000 8MHz 2/3 NONE QAM64 2k 1/32 NONE
T 513833000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
T 538167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
T 562167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE
T 570167000  8MHz 3/4 NONE QAM16 2k 1/32 NONE

Re: [IR RC, REGRESSION] Didn't work IR RC

[Jean Delvare]

Hi Mauro, Dmitri,

On Tue, 02 Mar 2010 05:49:17 -0300, Mauro Carvalho Chehab wrote:
> Dmitri Belimov wrote:
> > When I add 
> > 
> > diff -r 37ff78330942 linux/drivers/media/video/ir-kbd-i2c.c
> > --- a/linux/drivers/media/video/ir-kbd-i2c.cSun Feb 28 16:59:57 
> > 2010 -0300
> > +++ b/linux/drivers/media/video/ir-kbd-i2c.cTue Mar 02 10:31:31 
> > 2010 +0900
> > @@ -465,6 +519,11 @@
> > ir_type = IR_TYPE_OTHER;
> > ir_codes= &ir_codes_avermedia_cardbus_table;
> > break;
> > +   case 0x2d:
> > +   /* Handled by saa7134-input */
> > +   name= "SAA713x remote";
> > +   ir_type = IR_TYPE_OTHER;
> > +   break;
> > }
> >  
> >  #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
> > 
> > The IR subsystem register event device. But for get key code use 
> > ir_pool_key function.
> > 
> > For our IR RC need use our special function. How I can do it?
> 
> Just add your get_key callback to "ir->get_key". If you want to do this from
> saa7134-input, please take a look at the code at em28xx_register_i2c_ir(). 
> It basically fills the platform_data.
> 
> While you're there, I suggest you to change your code to work with the
> full scancode (e. g. address + command), instead of just getting the command.
> Currently, em28xx-input has one I2C IR already changed to this mode (seek
> for full_code for the differences).
> 
> You'll basically need to change the IR tables to contain address+command, and
> inform the used protocol (RC5/NEC) on it. The getkey function will need to
> return the full code as well.

Sorry for the late reply. Is the problem solved by now, or is my help
still needed?

-- 
Jean Delvare
--
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

Issue with dvbsnoop

[Mike]

Hi

I have been using dvbsnoop for quite a while to get an epg. However it
has jjust started hanging when I give a -n value of more than about 300

command
dvbsnoop -s sec -timeout 500-nph -n 1500 0x12

This gets run via a loop which tunes to each available frequency in turn
so I dont neccessarily care if each iteration completes as long as it
exits. 

Any way to stop the hang as I need to get more packets than 300 to get a
sensible epg

thanks


--
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 subdevices and fops

[m7aalton]

Hi.

On Mon, 2010-03-08 at 19:03 +0100, ext Hans Verkuil wrote:
> On Monday 08 March 2010 13:44:25 m7aalton wrote:
> > Hello.
> > 
> > I'm writing a radio driver which uses subdevice file operations to
> > handle RDS reception and transmission. Some IOCTL call-backs to the main
> > device are easy to pass to the subdevice driver. To me it seems that
> > adding the fops pointer to the following struct in v4l2-subdev.h would
> > make passing the file operation call-backs equally convenient.
> > 
> > struct v4l2_subdev_ops {
> > const struct v4l2_subdev_core_ops  *core;
> > const struct v4l2_subdev_tuner_ops *tuner;
> > const struct v4l2_subdev_audio_ops *audio;
> > const struct v4l2_subdev_video_ops *video;
> > const struct v4l2_subdev_pad_ops   *pad;
> > };
> > 
> > Could I expand the above struct in the way I described? Have I missed
> > something? Do you understand what I'm saying? :-)
> 
> Yes, I understand :-)
> 
> It is possible to add rds ops. The question is whether it is used often enough
> to warrant the addition of a new rds_ops struct. Until recently rds was a rare
> beast to see inside a driver. If the rds ops are general enough to be used in
> more than one subdev driver, then I think you should make a proposal. If the
> rds ops are unique to your driver, though, then it should be done through
> the core ops ioctl callback.

I mean file operation like open, close, read and write, which should be
general enough. Our driver just passes through the RDS data... But it's
probably best if we send the patches to this list so that everyone can
comment. It may need a couple of iterations before it gets accepted.

Thanks,

Matti

> Regards,
> 
>   Hans
> 
> > 
> > Cheers,
> > Matti 
> > 
> > --
> > 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
> > 
> > 
> 


--
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 with RTL2832U DVB-T dongle (LeadTek WinFast DTV Dongle Mini)

[LiM]

Hi,

for information...i have the same dongle (LeadTek WinFast DTV Dongle
Mini - Bus 001 Device 003: ID 0413:6a03 Leadtek Research, Inc. )
and after compiled RTL2832U + change VID+PID in rtl2832u.h (i changed
USB_VID_GTEK + USB_PID_GTEK_WARM to leadtek`s 0413:6a03)
is tuner working!  (me-tv + kaffeine)

[5.033094] usb 1-2: new high speed USB device using ehci_hcd and
address 3
[5.174858] usb 1-2: configuration #1 chosen from 1 choice
[5.287045] dvb-usb: found a 'RT DTV 2832U' in warm state.
[5.287056] dvb-usb: will pass the complete MPEG2 transport stream to
the software demuxer.
[5.288707] DVB: registering new adapter (RT DTV 2832U)
[5.289274] DVB: registering adapter 0 frontend 0 (Realtek RTL2832
DVB-T)...
[5.289324] dvb-usb: RT DTV 2832U successfully initialized and connected.
[5.289360] usbcore: registered new interface driver dvb_usb_rtl2832u


compilation is the same as instruction for msi digivox mini II v3.0

--cut 
Installation of Realtek rtl2832u-based DVB-T-USB-Sticks:

sudo apt-get install unrar build-essential mercurial
mkdir digivox; cd digivox
hg clone http://linuxtv.org/hg/v4l-dvb 
wget
http://media.ubuntuusers.de/forum/attachments/2103272/090730_RTL2832U_LINUX_Ver1.1.rar

unrar x -ep 090730_RTL2832U_LINUX_Ver1.1.rar
./v4l-dvb/linux/drivers/media/dvb/dvb-usb
cd v4l-dvb
for i in `find . -name *.pl`; do chmod +x $i ; done
gedit ./linux/drivers/media/dvb/dvb-usb/Makefile

(Insertion nearly to the end of file
:)
dvb-usb-rtl2832u-objs = demod_rtl2832.o dvbt_demod_base.o
dvbt_nim_base.o foundation.o math_mpi.o nim_rtl2832_mxl5007t.o
nim_rtl2832_fc2580.o nim_rtl2832_mt2266.o rtl2832u.o rtl2832u_fe.o
rtl2832u_io.o tuner_mxl5007t.o tuner_fc2580.o tuner_mt2266.o
tuner_tua9001.o nim_rtl2832_tua9001.o
obj-$(CONFIG_DVB_USB_RTL2832U) += dvb-usb-rtl2832u.o

gedit ./linux/drivers/media/dvb/dvb-usb/Kconfig

(Insertion to the end of file
:)
config DVB_USB_RTL2832U
tristate "Realtek RTL2832U DVB-T USB2.0 support"
depends on DVB_USB
help
  Realtek RTL2832U DVB-T driver

gedit ./linux/drivers/media/dvb/dvb-usb/rtl2832u.c

(1. Remove // of line 12:)
//DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);

(2. replace line 61-63 by:)
if ( ( 0==
dvb_usb_device_init(intf,&rtl2832u_1st_properties,THIS_MODULE,NULL,adapter_nr)
)||
( 0==
dvb_usb_device_init(intf,&rtl2832u_2nd_properties,THIS_MODULE,NULL,adapter_nr)
) ||
( 0==
dvb_usb_device_init(intf,&rtl2832u_3th_properties,THIS_MODULE,NULL,adapter_nr)
))

gedit ./linux/drivers/media/dvb/dvb-usb/tuner_tua9001.c

(search for 19.2 AND 20.48 and replace it by 19_2 AND 20_48:)
#elif defined(CRYSTAL_19.2_MHZ) /* Frequency 19.2 MHz */
#elif defined(CRYSTAL_19_2_MHZ) /* Frequency 19.2 MHz */
#elif defined(CRYSTAL_20.48_MHZ) /* Frequency 20,48 MHz */
#elif defined(CRYSTAL_20_48_MHZ) /* Frequency 20,48 MHz */

make

STRG^C after some secs.

gedit ./v4l/.config

(replace FIREDTV=m by FIREDTV=n:)
CONFIG_DVB_FIREDTV=m
CONFIG_DVB_FIREDTV=n

make clean
make
sudo make install

--cut 

Jan Hoogenraad napsal(a):
> Mauro:
>
> Can you remove the VERY OLD branch:
> http://linuxtv.org/hg/~mchehab/rtl2831/rev/d116540ebaab
> It is giving some confusion here.
>
> Thomas & Jan:
>
> I've got the RTL2831 code (mind the last digit) vetted off by LeadTek.
> For the rtl2832, I haven't had contact with them.
>
> Certainly, Jan could try any of the three archives.
> I know Antti has thoughts on the rtl2832, I'm sure he knows more.
>
> thomas schorpp wrote:
>> Jan Hoogenraad wrote:
>>> Antti has been working on drivers for the RTL283x.
>>>
>>> http://linuxtv.org/hg/~anttip/rtl2831u
>>> or
>>> http://linuxtv.org/hg/~anttip/qt1010/
>>
>> ~jhoogenraad/rtl2831-r2 rtl2831-r2 development repository: *known
>> working version* Jan Hoogenraad
>>
>> Should Jan Slaninka try it?
>>>
>>> If you have more information on the RTL2832, I'd be happy to add it at:
>>> http://www.linuxtv.org/wiki/index.php/Rtl2831_devices
>>
>> Nothing on the Realtek website yet.
>>
>>>
>>>
>>> Jan Slaninka wrote:
 Hi,

 I'd like to ask for a support with getting LeadTek WindFast DTV Dongle
 mini running on Linux. So far I was able to fetch latest v4l-dvb from
 HG, and successfully compiled module dvb_usb_rtl2832u found in
>>
 090730_RTL2832U_LINUX_Ver1.1.rar  
>>
>> Can be considered as GPL code then according to
>>
>> http://linuxtv.org/hg/~mchehab/rtl2831/rev/d116540ebaab
>>
>> Patch to make RTL2831U DVB-T USB2.0 DEVICE work, based on RealTek
>> version 080314
>>
>> ~mchehab/rtl2831 rtl2831 development repository with *RealTek GPL
>> code* for rtl2831 Mauro Carvalho Chehab 24 months ago
>>
>> ?
>>
>> y
>> tom
>> -- 
>> To unsubscribe from this list: send the line "unsubscri