Re: mt9m111 swap_rgb_red_blue

[Guennadi Liakhovetski]

On Mon, 31 May 2010, Robert Jarzmik wrote:

> Sascha Hauer  writes:
> 
> > Hi Robert,
> >
> > I have digged around in the Datasheet and if I understand it correctly
> > the PXA swaps red/blue in RGB mode. So if we do not use rgb mode but yuv
> > (which should be a pass through) we should be able to support rgb on PXA
> > aswell. Robert, can you confirm that with the following patch applied
> > you still get an image but with red/blue swapped?
> I can confirm the color swap.
> If you want to follow that path, I would suggest instead :
>cicr1 |= CICR1_COLOR_SP_VAL(0);
> 
> There is no difference from a processing point of view, it's just that
> CICR1_COLOR_SP_VAL(0) is "raw colorspace", with means "pass through", and that
> seems to be your goal here.

That would be the default case in that switch, but raw only supports 8, 9, 
or 10 bpp, so, you'd have to use 8bpp but then fake the pixels-per-line 
field. But that would be the cleanest way, yes. Would that work like that?

> Note that the patch would have to be completed with the BGR565 into RGB565
> conversion, if the sensor was to provide only BGR565. But that could very well
> be for another patch.

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

Re: ir-core multi-protocol decode and mceusb

[Jarod Wilson]

On Sun, May 30, 2010 at 3:57 PM, Jarod Wilson  wrote:
> On Sun, May 30, 2010 at 10:02 AM, Mauro Carvalho Chehab
>  wrote:
>> Em 29-05-2010 23:24, Jarod Wilson escreveu:
>>> On Sat, May 29, 2010 at 4:01 PM, Andy Walls  wrote:
> ...
>  We do have the
> option to disable all but the relevant protocol handler on a
> per-device basis though, if that's a problem. Hrm, the key tables also
> have a protocol tied to them, not sure if that's taken into account
> when doing matching... Still getting to know the code. :)

 It does not look like

        ir_keydown()
                ir_g_keycode_from_table()
                        ir_getkeycode()

 bother to check the ir_type (e.g. IR_TYPE_NEC) of the keymap against the
 decoders type.  Neither do the decoders themselves.


 If a decoder decodes something and thinks its valid, it tries to send a
 key event with ir_keydown().  ir_keydown() won't send a key event if the
 lookup comes back KEY_RESERVED, but it doesn't tell the decoder about
 the failure to find a key mapping.  A decoder can come back saying it
 did it's job, without knowing whether or not the decoding corresponded
 to a valid key in the loaded keymap. :(


>> You will have to deal with the case that two or more decoders may match
>> and each sends an IR event.  (Unless the ir-core already deals with this
>> somehow...)
>
> Well, its gotta decode correctly to a value, and then match a value in
> the loaded key table for an input event to get sent through. At least
> for the RC6 MCE remotes, I haven't seen any of the other decoders take
> the signal and interpret it as valid -- which ought to be by design,
> if you consider that people use several different remotes with varying
> ir signals with different devices all receiving them all the time
> without problems (usually). And if we're not already, we could likely
> add some logic to give higher precedence to values arrived at using
> the protocol decoder that matches the key table we've got loaded for a
> given device.

 After looking at things, the only potential problem I can see right now
 is with the JVC decoder and NEC remotes.

 I think that problem is most easily eliminated either by

 a. having ir_keydown() (or the functions it calls) check to see that the
 decoder matches the loaded keymap, or

 b. only calling the decoder that matches the loaded keymap's protocol

 Of the above, b. saves processor cycles and frees up the global
 ir_raw_handler spin lock sooner.  That spin lock is serializing pulse
 decoding for all the IR receivers in the system  (pulse decoding can
 still be interleaved, just only one IR receiver's pulses are be
 processed at any time).  What's the point of running decoders that
 should never match the loaded keymap?
>>>
>>> For the daily use case where a known-good keymap is in place, I'm
>>> coming to the conclusion that there's no point, we're only wasting
>>> resources. For initial "figure out what this remote is" type of stuff,
>>> running all decoders makes sense. One thought I had was that perhaps
>>> we start by running through the decoder that is listed in the keymap.
>>> If it decodes to a scancode and we find a valid key in the key table
>>> (i.e., not KEY_RESERVED), we're done. If decoding fails or we don't
>>> find a valid key, then try the other decoders. However, this is
>>> possibly also wasteful -- most people with any somewhat involved htpc
>>> setup are going to be constantly sending IR signals intended for other
>>> devices that we pick up and try to decode.
>>>
>>> So I'd say we go with your option b, and only call the decoder that
>>> matches the loaded keymap. One could either pass in a modparam or
>>> twiddle a sysfs attr or use ir-keytable to put the receiver into a
>>> mode that called all decoders -- i.e., set protocol to
>>> IR_TYPE_UNKNOWN, with the intention being to figure it out based on
>>> running all decoders, and create a new keymap where IR_TYPE_FOO is
>>> known.
>>
>> There's no need to extra parameters. Decoders can be disabled by userspace,
>> per each rc sysfs node. Btw, the current version of ir-keytable already sets
>> the enabled protocols based on the protocol reported by the rc keymap.
>>
>> What it makes sense is to add a patch at RC core that will properly 
>> enable/disable
>> the protocols based on IR_TYPE, when the rc-map is stored in-kernel.
>
> Ah, yeah, that does make sense. And if we add that, ir-keytable
> doesn't actually have to worry about doing similar itself any longer.
> If you're not already working on it, I can try to whip something up,
> though I'm knee-deep in an ir-lirc-codec bridge right now...

I've now got an ir-lirc-codec bridge passing data over to a completely
unmodified lirc_dev, with the data then making its way out to the
lircd userspac

Re: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?

[CityK]

Another Sillyname wrote:
> Guys
>
> The TBS 6920 PCI-e card is in the Wiki and is a supported card.
>
> The TBS 6980 dual tuner PCI-e card is not in the Wiki at all, is there
> a reason for this given they have released a non GPL blob at least?
>   

Because the wiki relies upon user contributions.  No contributions, no
information.  Simple as that.


> Also is there a reason that an indicative price for supported cards is
> not shown in the wiki?  It would save a load of time rather then
> having to search on each card only to find out it's ridiculously
> priced at $1000.

I for one am not particularly keen on inclusion of prices because:
- prices are highly subject to temporal variance (i.e. what costs $150
now could be $80 in six months)
- prices are often highly variant across broad geographical regions
(i.e. what costs $70US in America could, after accounting for exchange
rates, cost an equivalent of $100US within Canada)
- prices are often highly variant within local geographical markets (i.e
what costs $99 at the local big box Bestbuy store could easily cost $79
at the local mom&pop computer store)
- prices require regular updating/maintenance in order for them to be in
any way "indicative" ... the wiki relies upon user contributions ...
ergo, I can already tell you in advance that its not going to happen
(because its a time consuming endeavour, and there is no critical mass
of contributors to keep the information relevant), and so, any original
submissions will inevitably just end up suffering information rot (and,
thus, end up not being indicative or of particular use for the end user).
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

2.6.35-rc1 fails to boot: OOPS in ir_register_class

[Torsten Kaiser]

Trying to boot the new -rc1 it fails with the following OOPS:
[3.454804] IR NEC protocol handler initialized
[3.461310] IR RC5(x) protocol handler initialized
[3.467865] IR RC6 protocol handler initialized
[3.474070] IR JVC protocol handler initialized
[3.480257] IR Sony protocol handler initialized
[3.480259] Linux video capture interface: v2.00
[3.480722] bttv: driver version 0.9.18 loaded
[3.480724] bttv: using 8 buffers with 2080k (520 pages) each for capture
[3.507950] bttv: Bt8xx card found (0).
[3.513845] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 19
[3.521339] bttv :05:06.0: PCI INT A -> Link[LNKC] -> GSI 19
(level, low) -> IRQ 19
[3.531039] bttv0: Bt878 (rev 17) at :05:06.0, irq: 19,
latency: 64, mmio: 0xeefff000
[3.541062] bttv0: detected: Hauppauge WinTV [card=10], PCI
subsystem ID is 0070:13eb
[3.550946] bttv0: using: Hauppauge (bt878) [card=10,autodetected]
[3.561433] bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
[3.593765] usb 2-6: new low speed USB device using ohci_hcd and address 2
[3.599016] tveeprom 4-0050: Hauppauge model 61344, rev D421, serial# 3902813
[3.599018] tveeprom 4-0050: tuner model is Philips FM1216 (idx 21, type 5)
[3.599021] tveeprom 4-0050: TV standards PAL(B/G) (eeprom 0x04)
[3.599022] tveeprom 4-0050: audio processor is MSP3415 (idx 6)
[3.599024] tveeprom 4-0050: has radio
[3.599025] bttv0: Hauppauge eeprom indicates model#61344
[3.599027] bttv0: tuner type=5
[3.609618] msp3400 4-0040: MSP3415D-B3 found @ 0x80 (bt878 #0 [sw])
[3.609620] msp3400 4-0040: msp3400 supports nicam, mode is autodetect
[3.621863] tuner 4-0061: chip found @ 0xc2 (bt878 #0 [sw])
[3.622168] tuner-simple 4-0061: creating new instance
[3.622170] tuner-simple 4-0061: type set to 5 (Philips PAL_BG
(FI1216 and compatibles))
[3.622882] bttv0: registered device video0
[3.622940] bttv0: registered device vbi0
[3.622997] bttv0: registered device radio0
[3.632337] bttv0: PLL: 28636363 => 35468950 .. ok
[3.683096] Registered IR keymap rc-rc5-tv
[3.683110] BUG: unable to handle kernel NULL pointer dereference at (null)
[3.683113] IP: [] ir_register_class+0x59/0x160
[3.683122] PGD 0
[3.683124] Oops:  [#1] SMP
[3.683125] last sysfs file:
[3.683127] CPU 2
[3.683129] Modules linked in:
[3.683130]
[3.683133] Pid: 1, comm: swapper Not tainted 2.6.35-rc1 #1 KFN5-D
SLI/KFN5-D SLI
[3.683135] RIP: 0010:[]  []
ir_register_class+0x59/0x160
[3.683139] RSP: 0018:88011ff09cd0  EFLAGS: 00010246
[3.683141] RAX:  RBX: 88011f3c1a00 RCX: 81a5baa0
[3.683142] RDX:  RSI: 817d24f0 RDI: 88011f3c1a00
[3.683144] RBP:  R08:  R09: 
[3.683146] R10:  R11: 0021 R12: 817d6960
[3.683147] R13: 88011f223000 R14: 88011f3c1a00 R15: 88011f3c1b40
[3.683150] FS:  010f8870() GS:88008020()
knlGS:
[3.683151] CS:  0010 DS:  ES:  CR0: 8005003b
[3.683153] CR2:  CR3: 01a05000 CR4: 06e0
[3.683155] DR0:  DR1:  DR2: 
[3.683157] DR3:  DR6: 0ff0 DR7: 0400
[3.683159] Process swapper (pid: 1, threadinfo 88011ff08000,
task 88007ff48000)
[3.683160] Stack:
[3.683162]  88011f223000 81a5ab30 88011f223000
817d6960
[3.683164] <0> 0021 813eb90a 88010028
817d240e
[3.683166] <0> 88011f3c1b68 0282 8800070b54e0
88011f35f100
[3.683169] Call Trace:
[3.683174]  [] ? __ir_input_register+0x2ba/0x350
[3.683178]  [] ? ir_probe+0x36a/0x4f0
[3.683181]  [] ? ir_probe+0x0/0x4f0
[3.683185]  [] ? i2c_device_probe+0xea/0x120
[3.683188]  [] ? driver_sysfs_add+0x5a/0x80
[3.683190]  [] ? driver_probe_device+0x83/0x190
[3.683193]  [] ? i2c_device_match+0x54/0x70
[3.683195]  [] ? __driver_attach+0x93/0xa0
[3.683197]  [] ? __driver_attach+0x0/0xa0
[3.683201]  [] ? bus_for_each_dev+0x58/0x80
[3.683203]  [] ? bus_add_driver+0xb0/0x250
[3.683206]  [] ? driver_register+0x6a/0x130
[3.683209]  [] ? __pci_register_driver+0x80/0xc0
[3.683212]  [] ? i2c_register_driver+0x30/0xb0
[3.683217]  [] ? bttv_init_module+0x0/0xde
[3.683220]  [] ? ir_init+0x0/0x14
[3.683224]  [] ? do_one_initcall+0x34/0x190
[3.683227]  [] ? kernel_init+0x143/0x1cd
[3.683230]  [] ? kernel_thread_helper+0x4/0x10
[3.683232]  [] ? kernel_init+0x0/0x1cd
[3.683235]  [] ? kernel_thread_helper+0x0/0x10
[3.683237] Code: c7 80 a5 ba 81 48 89 c3 e8 b5 8f e0 ff 85 c0 89
c5 78 62 48 8b 93 78 01 00 00 48 c7 c1 a0 ba a5 81 48 c7 c6 f0 24 7d
81 48 89 df <8b> 12 48 c7 83 20 01 00 00

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Theodore Kilgore]

On Mon, 31 May 2010, Ondrej Zary wrote:

> On Sunday 30 May 2010 23:58:11 Andy Walls wrote:
> > On Sun, 2010-05-30 at 23:28 +0200, Ondrej Zary wrote:
> > > On Sunday 30 May 2010 21:26:14 Andy Walls wrote:
> > > > On Sun, 2010-05-30 at 19:55 +0200, Ondrej Zary wrote:
> > > > > On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote:
> > > >
> > > > SP54 is Sunplus' ( http://www.sunplus.com.tw/ ) FourCC code for a
> > > > version of MJPEG with the headers removed according to
> > > >
> > > > http://www.fourcc.org/
> > > >
> > > > > Maybe we can dump some data, create AVI file from that and try to
> > > > > decode the file using that codec.
> > > >
> > > > FourCC.org points to this page:
> > > >
> > > > http://libland.fr.st/download.html
> > > >
> > > > which points to a utility to conver the data back into an MJPEG:
> > > >
> > > > http://mxhaard.free.fr/spca50x/Download/sp54convert.tar.gz
> > > >
> > > >
> > > > I have no idea if any of the above is true, 'cause I read it on the
> > > > Internet. ;)
> > >
> > > Modified that utility to work on raw video frame extracted from usbsnoop
> > > file. The bad news is that the resulting jpeg file is not readable.
> > >
> > > I also deleted the sp5x_32.dll file and the camera still works...
> >
> > I would try extracting a JPEG header from one of the files captured by
> > the camera in stand alone mode (either a JPEG still or MJPEG file), and
> > put that header together with the image data from the USB capture.  It
> > may not look perfect, but hopefully you will get something you
> > recognize.
> 
> Just thought about the same thing so I uploaded a video file: 
> http://www.rainbow-software.org/linux_files/spca1528/sunp0003.avi
> 
> > Attached was Theodore's first attempt of such a procedure with a header
> > extracted from a standalone image file from my Jeilin based camera and
> > USB snoop data from the same camera.  It wasn't perfect, but it was
> > recognizable.
> 
> Thanks, I'll try that tomorrow.
> 
> > I did look at the image data file Jean-Francois provided from your
> > usbsnoop logs.  To my eye the data looks like it is Huffman coded
> > (indicating JPEG).  Maybe I'm just seeing what I want to see.

Naturally, it makes me feel all excited to see my name in print. If anyone 
likes, you can send me the following:

-- usbsniff output for one or two frames (it isn't so difficult 
for me to convert this to a binary file, actually) and I can fool around 
with trying to stick a JPEG header on it.

-- one or two results of svv -gr in case that there is so much 
progress already. But the previous item ought to do just fine, too.

I could also comment that there could be some kind of obfuscated JPEG 
going on here. As a case in point I can mention the recently cracked 
decompression for the JL2005B/C/D based still cameras. The compression 
algorithm is pretty much standard JPEG, but two things are unusual. First, 
the compression or decompression proceeds down columns of width one block, 
not across rows. Second, the thing which is being compressed is the Bayer 
pattern, so each block is of width 16, not 8, and there are sub-blocks for 
each of R, G1, G2, and B.

If anyone is curious about this, the code can be pulled down from 
gphoto.svn.sourceforge.net, in trunk/libgphoto2/camlibs/jl2005c.

Theodore Kilgore
--
To unsubscribe from this list: send the line "unsubscribe 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: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?

[Konstantin Dimitrov]

On Mon, May 31, 2010 at 6:22 AM, Emmanuel  wrote:
> Konstantin Dimitrov a écrit :
>>
>>
>> On Mon, May 31, 2010 at 5:05 AM, Emmanuel > > wrote:
>>
>>    Konstantin Dimitrov a écrit :
>>
>>        hello, i can't comment on your questions about the Wiki, but i
>>        made
>>        the driver for TBS 6980 and i can ensure you that the driver
>>        will be
>>        released as open-source under GPL as soon as i have permission
>>        to do
>>        that, but compared to other cards at least even at the moment
>>        you can
>>        use the card in Linux and it's very easy to add support for it
>>        using
>>        the binary modules even to the latest V4L code from repository
>>        and so
>>        those "blobs" are actually not so big limitation.
>>
>>        also, you are very wrong about the price - as far as i know
>>        retails
>>        price is less than 200 USD, for example TBS online shop gives
>>        a price
>>        of 158.99 USD:
>>
>>        http://www.buydvb.net/pcie-dvbs2-dual-tuner-tv-card_p11.html
>>
>>        and i believe the dual DVB-S2 card with price of 1000 USD that
>>        you're
>>        talking about is the NetUP one and not the TurboSight TBS 6980
>>        dual
>>        DVB-S2 card.
>>
>>    I have two questions for you: do these board support (or will
>>    support in the near future) a CI interface for pay TV, and what is
>>    the best symbol rate they can achieve in DVB-S2 (I think I need
>>    QPSK only but could be 8PSK) RELIABLY.
>>
>>
>> TBS 6980 specifications are:
>>
>> DVB-S QPKS: 1000 - 45000 kSps
>>
>> DVB-S2 QPSK and 8PSK: 2000 - 36000 kSps
>>
>> but i personally have tested DVB-S2 8PSK up to 33500 kSps and it works
>> fine. so, DVB-S2 symbol rate range is still better than what most other
>> cards can offer i believe, which usually support 1 - 3 kSps for
>> DVB-S2. TBS are developing card that will support 1000 - 45000 kSps for
>> DVB-S2 (both QPSK and 8PSK), but i believe it won't be released any time
>> soon.
>
> OK Thansks. I am interested in a DVB-S2 card able to tune to 45000kSps rate
> with CI support (yes my provider here did things so that it is hard to get
> rid of their STB :( )
> The only one for now are the cards based upon stv0900 like the mystique

i believe stv0900 doesn't support DVB-S2 with symbol rate over 3
kSps, but maybe some of the people here familiar with stv0900 can tell
more and for sure what are the specifications of stv0900.

> satix, but I am not sure about the driver supporting CI.
> Bye
> Manu
>
--
To unsubscribe from this list: send the line "unsubscribe 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: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Theodore Kilgore]

On Sun, 30 May 2010, Andy Walls wrote:

> On Sun, 2010-05-30 at 20:13 +0200, Jean-Francois Moine wrote:
> > On Sun, 30 May 2010 19:55:22 +0200
> > Ondrej Zary  wrote:
> > 
> > > That's bad...
> > > 
> > > The driver contains file sp5x_32.dll which is registered in
> > > system.ini file as [drivers32]
> > > VIDC.SP54=SP5X_32.DLL
> > > 
> > > Seems that the codec is called SP54 - hope that it's used to
> > > decompress the data.
> > > 
> > > > All I can do is to code the driver and let you or anyone find the
> > > > decompression function...
> > > 
> > > Maybe we can dump some data, create AVI file from that and try to
> > > decode the file using that codec.
> > 
> > It is easy to get images from the usbsnoop files. I join an image
> > extracted from your file usbsnoop-video-capture-640x480.log. If you
> > want more images, they are in IsoPackets. The first 2 bytes of each isoc
> > packet mean:
> > - '02 80' or '02 81': first of intermediate part of the image ('0' or
> >   '1' is the image sequence number)
> > - '02 82' or '02 83': last part of the image
> > 
> > Someone had an idea to try and guess the compression algorithm: do
> > usbsnoop's with full black and full white images. But this idea did not
> > work with the other webcam: the images were quite the same!
> 
> I have attached an image I constructed from the image data file you
> provided, the MJPEG headers in the AVI file Ondrej provided, and the
> Huffman table in the jpeg.h file in the gspca driver.
> 
> If you zoom in, there is an small pattern in the top left portion of the
> scan.
> 
> I doesn't look quite like an whole image, but it does look like the
> start of one.
> 
> Regards,
> Andy

Downloaded it. And, hmmm. Here are the error messages on trying to look at 
the output:

kilg...@khayyam:~$ display test1.jpg
display: Corrupt JPEG data: premature end of data segment `test1.jpg' @ 
warning/jpeg.c/EmitMessage/228.
display: Unsupported marker type 0x3a `test1.jpg' @ 
error/jpeg.c/EmitMessage/233.
kilg...@khayyam:~$ 

Quite possibly it _is_ going down "strips" or such. That is what the 
JL2005C cameras are doing. Each vertical strip of 16 bytes from the 
picture is in fact a separate JPEG image, and needs to be separately 
processed, and then the results glued together into an image. This is even 
seen in the raw data, once one is so wise that it is all figured out. The 
data for each strip ends with FF D9. So one suggestion here would be to 
see how many times the FF D9 is coming up in the data. There may be a 
pattern to that.

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

Re: What ever happened to standardizing signal level?

[hermann pitton]

Hi,

Am Sonntag, den 30.05.2010, 23:02 -0400 schrieb Michael Krufky:
> Markus Rechberger wrote:
> > On Sun, May 30, 2010 at 5:21 PM, Michael Krufky  wrote:
> >> Markus Rechberger wrote:
> >>> Hi,
> >>>
> >>> A little bit more "ontopic", did anyone get around to read the
> >>> signallevel of the tda18721?
> >>> I wonder the register does not return any signallevel as indicated in
> >>> the specifications.
> >>>
> >>> Markus
> >> There is a "power level" value that can be read from the tda18271 -- I had 
> >> a
> >> patch that enabled reading of this value, for testing purposes, but it
> >> wasn't as useful as I had hoped, so I never bothered to merge it.
> >>
> >> If you'd like to play with it, I pushed up some code last year:
> >>
> >> http://kernellabs.com/hg/~mkrufky/tda18271-pl/rev/4373874cff29
> >>
> >> Let me know how this works for you, or if you choose to change it.  I If 
> >> you
> >> find it valuable, we can merge it in somehow.
> >>
> > 
> > hmm.. I somewhat tried the same but the register kept flipping back
> > and the powerlevel register returned 0.
> > 
> > Markus
> 
> ...I think it only works on the c2 rev silicon.  Not sure about that, 
> though.
> 
> -Mike
> 

that is such stuff that really happens and nobody has any "intentions"
to hide better signal/SNR measurements from the users.

Some multiple subscribed trolls may take it for a next round, but it is
_nowhere_ any better.

Even worse, on S2, the whole previous model of doing so, will come under
pressure, if I'm not totally blind.

Best,
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: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?

[Emmanuel]

Konstantin Dimitrov a écrit :



On Mon, May 31, 2010 at 5:05 AM, Emmanuel > wrote:


Konstantin Dimitrov a écrit :

hello, i can't comment on your questions about the Wiki, but i
made
the driver for TBS 6980 and i can ensure you that the driver
will be
released as open-source under GPL as soon as i have permission
to do
that, but compared to other cards at least even at the moment
you can
use the card in Linux and it's very easy to add support for it
using
the binary modules even to the latest V4L code from repository
and so
those "blobs" are actually not so big limitation.

also, you are very wrong about the price - as far as i know
retails
price is less than 200 USD, for example TBS online shop gives
a price
of 158.99 USD:

http://www.buydvb.net/pcie-dvbs2-dual-tuner-tv-card_p11.html

and i believe the dual DVB-S2 card with price of 1000 USD that
you're
talking about is the NetUP one and not the TurboSight TBS 6980
dual
DVB-S2 card.
 


I have two questions for you: do these board support (or will
support in the near future) a CI interface for pay TV, and what is
the best symbol rate they can achieve in DVB-S2 (I think I need
QPSK only but could be 8PSK) RELIABLY.


TBS 6980 specifications are:

DVB-S QPKS: 1000 - 45000 kSps

DVB-S2 QPSK and 8PSK: 2000 - 36000 kSps

but i personally have tested DVB-S2 8PSK up to 33500 kSps and it works 
fine. so, DVB-S2 symbol rate range is still better than what most 
other cards can offer i believe, which usually support 1 - 3 
kSps for DVB-S2. TBS are developing card that will support 1000 - 
45000 kSps for DVB-S2 (both QPSK and 8PSK), but i believe it won't be 
released any time soon.
OK Thansks. I am interested in a DVB-S2 card able to tune to 45000kSps 
rate with CI support (yes my provider here did things so that it is hard 
to get rid of their STB :( )
The only one for now are the cards based upon stv0900 like the mystique 
satix, but I am not sure about the driver supporting CI.

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

Re: What ever happened to standardizing signal level?

[Michael Krufky]

Markus Rechberger wrote:

On Sun, May 30, 2010 at 5:21 PM, Michael Krufky  wrote:

Markus Rechberger wrote:

Hi,

A little bit more "ontopic", did anyone get around to read the
signallevel of the tda18721?
I wonder the register does not return any signallevel as indicated in
the specifications.

Markus

There is a "power level" value that can be read from the tda18271 -- I had a
patch that enabled reading of this value, for testing purposes, but it
wasn't as useful as I had hoped, so I never bothered to merge it.

If you'd like to play with it, I pushed up some code last year:

http://kernellabs.com/hg/~mkrufky/tda18271-pl/rev/4373874cff29

Let me know how this works for you, or if you choose to change it.  I If you
find it valuable, we can merge it in somehow.



hmm.. I somewhat tried the same but the register kept flipping back
and the powerlevel register returned 0.

Markus


...I think it only works on the c2 rev silicon.  Not sure about that, 
though.


-Mike

--
To unsubscribe from this list: send the line "unsubscribe 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: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Andy Walls]

On Sun, 2010-05-30 at 20:13 +0200, Jean-Francois Moine wrote:
> On Sun, 30 May 2010 19:55:22 +0200
> Ondrej Zary  wrote:
> 
> > That's bad...
> > 
> > The driver contains file sp5x_32.dll which is registered in
> > system.ini file as [drivers32]
> > VIDC.SP54=SP5X_32.DLL
> > 
> > Seems that the codec is called SP54 - hope that it's used to
> > decompress the data.
> > 
> > > All I can do is to code the driver and let you or anyone find the
> > > decompression function...
> > 
> > Maybe we can dump some data, create AVI file from that and try to
> > decode the file using that codec.
> 
> It is easy to get images from the usbsnoop files. I join an image
> extracted from your file usbsnoop-video-capture-640x480.log. If you
> want more images, they are in IsoPackets. The first 2 bytes of each isoc
> packet mean:
> - '02 80' or '02 81': first of intermediate part of the image ('0' or
>   '1' is the image sequence number)
> - '02 82' or '02 83': last part of the image
> 
> Someone had an idea to try and guess the compression algorithm: do
> usbsnoop's with full black and full white images. But this idea did not
> work with the other webcam: the images were quite the same!

I have attached an image I constructed from the image data file you
provided, the MJPEG headers in the AVI file Ondrej provided, and the
Huffman table in the jpeg.h file in the gspca driver.

If you zoom in, there is an small pattern in the top left portion of the
scan.

I doesn't look quite like an whole image, but it does look like the
start of one.

Regards,
Andy


<>000: ff d8 ff e0 00 10 4a 46 49 46 00 01 01 00 00 01  ..JFIF..
010: 00 01 00 00 ff db 00 c5 00 0a 07 07 08 07 06 0a  
020: 08 08 08 0b 0a 0a 0b 0e 18 10 0e 0d 0d 0e 1d 15  
030: 16 11 18 23 1f 25 24 22 1f 22 21 26 2b 37 2f 26  ...#.%$"."!&+7/&
040: 29 34 29 21 22 30 41 31 34 39 3b 3e 3e 3e 25 2e  )4)!"0A149;>>>%.
050: 44 49 43 3c 48 37 3d 3e 3b 01 0a 0b 0b 0e 0d 0e  DIC;...
060: 1c 10 10 1c 3b 28 22 28 3b 3b 3b 3b 3b 3b 3b 3b  ;("(
070: 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b  
080: 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b  
090: 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 02 17 18 18 24 21  ;;$!
0a0: 24 47 26 26 47 99 66 56 66 99 99 99 99 99 99 99  $G&&G.fVf...
0b0: 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99  
0c0: 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99  
0d0: 99 99 99 99 99 99 99 99 99 99 99 ff c4 01 a2 00  
0e0: 00 01 05 01 01 01 01 01 01 00 00 00 00 00 00 00  
0f0: 00 01 02 03 04 05 06 07 08 09 0a 0b 01 00 03 01  
100: 01 01 01 01 01 01 01 01 00 00 00 00 00 00 01 02  
110: 03 04 05 06 07 08 09 0a 0b 10 00 02 01 03 03 02  
120: 04 03 05 05 04 04 00 00 01 7d 01 02 03 00 04 11  .}..
130: 05 12 21 31 41 06 13 51 61 07 22 71 14 32 81 91  ..!1A..Qa."q.2..
140: a1 08 23 42 b1 c1 15 52 d1 f0 24 33 62 72 82 09  ..#B...R..$3br..
150: 0a 16 17 18 19 1a 25 26 27 28 29 2a 34 35 36 37  ..%&'()*4567
160: 38 39 3a 43 44 45 46 47 48 49 4a 53 54 55 56 57  89:CDEFGHIJSTUVW
170: 58 59 5a 63 64 65 66 67 68 69 6a 73 74 75 76 77  XYZcdefghijstuvw
180: 78 79 7a 83 84 85 86 87 88 89 8a 92 93 94 95 96  xyz.
190: 97 98 99 9a a2 a3 a4 a5 a6 a7 a8 a9 aa b2 b3 b4  
1a0: b5 b6 b7 b8 b9 ba c2 c3 c4 c5 c6 c7 c8 c9 ca d2  
1b0: d3 d4 d5 d6 d7 d8 d9 da e1 e2 e3 e4 e5 e6 e7 e8  
1c0: e9 ea f1 f2 f3 f4 f5 f6 f7 f8 f9 fa 11 00 02 01  
1d0: 02 04 04 03 04 07 05 04 04 00 01 02 77 00 01 02  w...
1e0: 03 11 04 05 21 31 06 12 41 51 07 61 71 13 22 32  !1..AQ.aq."2
1f0: 81 08 14 42 91 a1 b1 c1 09 23 33 52 f0 15 62 72  ...B.#3R..br
200: d1 0a 16 24 34 e1 25 f1 17 18 19 1a 26 27 28 29  ...$4.%.&'()
210: 2a 35 36 37 38 39 3a 43 44 45 46 47 48 49 4a 53  *56789:CDEFGHIJS
220: 54 55 56 57 58 59 5a 63 64 65 66 67 68 69 6a 73  TUVWXYZcdefghijs
230: 74 75 76 77 78 79 7a 82 83 84 85 86 87 88 89 8a  tuvwxyz.
240: 92 93 94 95 96 97 98 99 9a a2 a3 a4 a5 a6 a7 a8  
250: a9 aa b2 b3 b4 b5 b6 b7 b8 b9 ba c2 c3 c4 c5 c6  
260: c7 c8 c9 ca d2 d3 d4 d5 d6 d7 d8 d9 da e2 e3 e4  
270: e5 e6 e7 e8 e9 ea f2 f3 f4 f5 f6 f7 f8 f9 fa ff  
280: c0 00 11 08 01 e0 02 80 03 01 21 00 02 11 01 03  ..!.
290: 11 01 ff da 00 0c 03 01 00 02 11 03 11 00 3f 00  ..?.

Re: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?

[Konstantin Dimitrov]

On Mon, May 31, 2010 at 5:05 AM, Emmanuel  wrote:
> Konstantin Dimitrov a écrit :
>>
>> hello, i can't comment on your questions about the Wiki, but i made
>> the driver for TBS 6980 and i can ensure you that the driver will be
>> released as open-source under GPL as soon as i have permission to do
>> that, but compared to other cards at least even at the moment you can
>> use the card in Linux and it's very easy to add support for it using
>> the binary modules even to the latest V4L code from repository and so
>> those "blobs" are actually not so big limitation.
>>
>> also, you are very wrong about the price - as far as i know retails
>> price is less than 200 USD, for example TBS online shop gives a price
>> of 158.99 USD:
>>
>> http://www.buydvb.net/pcie-dvbs2-dual-tuner-tv-card_p11.html
>>
>> and i believe the dual DVB-S2 card with price of 1000 USD that you're
>> talking about is the NetUP one and not the TurboSight TBS 6980 dual
>> DVB-S2 card.
>>
>
> I have two questions for you: do these board support (or will support in the
> near future) a CI interface for pay TV, and what is the best symbol rate
> they can achieve in DVB-S2 (I think I need QPSK only but could be 8PSK)

TBS 6980 specifications are:

DVB-S QPKS: 1000 - 45000 kSps

DVB-S2 QPSK and 8PSK: 2000 - 36000 kSps

but i personally have tested DVB-S2 8PSK up to 33500 kSps and it works
fine. so, DVB-S2 symbol rate range is still better than what most
other cards can offer i believe, which usually support 1 - 3
kSps for DVB-S2. TBS are developing card that will support 1000 -
45000 kSps for DVB-S2 (both QPSK and 8PSK), but i believe it won't be
released any time soon.

> RELIABLY.
> TIA
> Bye
> Manu
> --
> To unsubscribe from this list: send the line "unsubscribe 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: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?

[Emmanuel]

Konstantin Dimitrov a écrit :

hello, i can't comment on your questions about the Wiki, but i made
the driver for TBS 6980 and i can ensure you that the driver will be
released as open-source under GPL as soon as i have permission to do
that, but compared to other cards at least even at the moment you can
use the card in Linux and it's very easy to add support for it using
the binary modules even to the latest V4L code from repository and so
those "blobs" are actually not so big limitation.

also, you are very wrong about the price - as far as i know retails
price is less than 200 USD, for example TBS online shop gives a price
of 158.99 USD:

http://www.buydvb.net/pcie-dvbs2-dual-tuner-tv-card_p11.html

and i believe the dual DVB-S2 card with price of 1000 USD that you're
talking about is the NetUP one and not the TurboSight TBS 6980 dual
DVB-S2 card.
  
I have two questions for you: do these board support (or will support in 
the near future) a CI interface for pay TV, and what is the best symbol 
rate they can achieve in DVB-S2 (I think I need QPSK only but could be 
8PSK) RELIABLY.

TIA
Bye
Manu
--
To unsubscribe from this list: send the line "unsubscribe 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] Compro Videomate T750F Vista digital+analog support

[Davor Emard]

HI!

Can you also try this GPIO settings? It's my try to use last summer's
registers dump to setup gpio mask and value

case SAA7134_BOARD_VIDEOMATE_T750:
dev->has_remote = SAA7134_REMOTE_GPIO;
saa_andorl(SAA7134_GPIO_GPMODE0 >> 2,   0x8082c000, 0x8082c000);
saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0x8082c000, 0x0080c000);
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

Re: [PATCH] Compro Videomate T750F Vista digital+analog support

[Davor Emard]

HI

> 
> Forget about the later, is in new file mode.

I wanted the new file but I don't know hg diff too much
so I just manually cat >> to append to the hg diff output...

d.
--
To unsubscribe from this list: send the line "unsubscribe 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] Compro Videomate T750F Vista digital+analog support

[hermann pitton]

> 
> Hmm, somehow its #define in the saa7134.h header is missing?
> 
> I'm also wondering, why we don't see the usual three lines offset on the
> end of current patches.

Forget about the later, is in new file mode.

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: [PATCH] Compro Videomate T750F Vista digital+analog support

[hermann pitton]

Hi Davor,

Am Montag, den 31.05.2010, 01:48 +0200 schrieb Davor Emard:
> HI!
> 
> I have downloaded latest hg v4l and adapted the compro 
> t750f support patch. The patch is the same but v4l code is
> newer so there's some improvement
> 
> Restarting VDR is now stable. Tried it cca 10x VDR restarts, 
> DVB-T tuner always worked. Remote still has 10% keys lost.
> 
> ALSA device now appears with alsa=1 in the list
> arecord -l (but I haven't tried to capture anything yet)
> 
> Someone mentioned that MCE-alike remote is the same to all 
> f-series of the cards so I called it rc-videomate-f.
> 
> Here's the patch

likely one of the most difficult cards on that driver during the last
time.

Does't look such bad to me, after all, without having one.

Hmm, somehow its #define in the saa7134.h header is missing?

I'm also wondering, why we don't see the usual three lines offset on the
end of current patches.

Cheers,
Hermann


> diff -r 304cfde05b3f linux/drivers/media/IR/keymaps/Makefile
> --- a/linux/drivers/media/IR/keymaps/Makefile Tue May 25 23:50:51 2010 -0400
> +++ b/linux/drivers/media/IR/keymaps/Makefile Mon May 31 01:18:12 2010 +0200
> @@ -63,5 +63,6 @@
>   rc-tt-1500.o \
>   rc-videomate-s350.o \
>   rc-videomate-tv-pvr.o \
> + rc-videomate-f.o \
>   rc-winfast.o \
>   rc-winfast-usbii-deluxe.o
> diff -r 304cfde05b3f linux/drivers/media/video/saa7134/saa7134-cards.c
> --- a/linux/drivers/media/video/saa7134/saa7134-cards.c   Tue May 25 
> 23:50:51 2010 -0400
> +++ b/linux/drivers/media/video/saa7134/saa7134-cards.c   Mon May 31 
> 01:18:12 2010 +0200
> @@ -4920,12 +4920,14 @@
>   },
>   [SAA7134_BOARD_VIDEOMATE_T750] = {
>   /* John Newbigin  */
> + /* Emard 2010-05-10 v18-v4l  */
>   .name   = "Compro VideoMate T750",
>   .audio_clock= 0x00187de7,
>   .tuner_type = TUNER_XC2028,
>   .radio_type = UNSET,
> - .tuner_addr = ADDR_UNSET,
> + .tuner_addr = 0x61,
>   .radio_addr = ADDR_UNSET,
> + .mpeg   = SAA7134_MPEG_DVB,
>   .inputs = {{
>   .name   = name_tv,
>   .vmux   = 3,
> @@ -6752,6 +6754,11 @@
>   msleep(10);
>   saa7134_set_gpio(dev, 18, 1);
>   break;
> + case SAA7134_BOARD_VIDEOMATE_T750:
> + saa7134_set_gpio(dev, 20, 0);
> + msleep(10);
> + saa7134_set_gpio(dev, 20, 1);
> + break;
>   }
>   return 0;
>   }
> @@ -7171,6 +7178,11 @@
>   saa_andorl(SAA7134_GPIO_GPMODE0 >> 2,   0xC000, 0xC000);
>   saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0xC000, 0xC000);
>   break;
> + case SAA7134_BOARD_VIDEOMATE_T750:
> + dev->has_remote = SAA7134_REMOTE_GPIO;
> + saa_andorl(SAA7134_GPIO_GPMODE0 >> 2,   0x8000, 0x8000);
> + saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0x8000, 0x8000);
> + break;
>   }
>   return 0;
>  }
> diff -r 304cfde05b3f linux/drivers/media/video/saa7134/saa7134-dvb.c
> --- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Tue May 25 23:50:51 
> 2010 -0400
> +++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Mon May 31 01:18:12 
> 2010 +0200
> @@ -55,6 +55,7 @@
>  #include "tda8290.h"
>  
>  #include "zl10353.h"
> +#include "qt1010.h"
>  
>  #include "zl10036.h"
>  #include "zl10039.h"
> @@ -886,6 +887,17 @@
>   .disable_i2c_gate_ctrl = 1,
>  };
>  
> +static struct zl10353_config videomate_t750_zl10353_config = {
> + .demod_address  = 0x0f,
> + .no_tuner = 1,
> + .parallel_ts = 1,
> +};
> +
> +static struct qt1010_config videomate_t750_qt1010_config = {
> + .i2c_address = 0x62
> +};
> +
> +
>  /* ==
>   * tda10086 based DVB-S cards, helper functions
>   */
> @@ -1569,6 +1581,21 @@
>   __func__);
>  
>   break;
> + case SAA7134_BOARD_VIDEOMATE_T750:
> + printk("Compro VideoMate T750 DVB setup\n");
> + fe0->dvb.frontend = dvb_attach(zl10353_attach,
> + &videomate_t750_zl10353_config,
> + &dev->i2c_adap);
> + if (fe0->dvb.frontend != NULL) {
> + // if there is a gate function then the i2c bus 
> breaks.!
> + fe0->dvb.frontend->ops.i2c_gate_ctrl = 0;
> + if (dvb_attach(qt1010_attach,
> + fe0->dvb.frontend,
> + &dev->i2c_adap,
> + &videomate_t750_qt1010

Re: [PATCH] Compro Videomate T750F Vista digital+analog support

[Davor Emard]

HI!

I have downloaded latest hg v4l and adapted the compro 
t750f support patch. The patch is the same but v4l code is
newer so there's some improvement

Restarting VDR is now stable. Tried it cca 10x VDR restarts, 
DVB-T tuner always worked. Remote still has 10% keys lost.

ALSA device now appears with alsa=1 in the list
arecord -l (but I haven't tried to capture anything yet)

Someone mentioned that MCE-alike remote is the same to all 
f-series of the cards so I called it rc-videomate-f.

Here's the patch

diff -r 304cfde05b3f linux/drivers/media/IR/keymaps/Makefile
--- a/linux/drivers/media/IR/keymaps/Makefile   Tue May 25 23:50:51 2010 -0400
+++ b/linux/drivers/media/IR/keymaps/Makefile   Mon May 31 01:18:12 2010 +0200
@@ -63,5 +63,6 @@
rc-tt-1500.o \
rc-videomate-s350.o \
rc-videomate-tv-pvr.o \
+   rc-videomate-f.o \
rc-winfast.o \
rc-winfast-usbii-deluxe.o
diff -r 304cfde05b3f linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Tue May 25 23:50:51 
2010 -0400
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Mon May 31 01:18:12 
2010 +0200
@@ -4920,12 +4920,14 @@
},
[SAA7134_BOARD_VIDEOMATE_T750] = {
/* John Newbigin  */
+   /* Emard 2010-05-10 v18-v4l  */
.name   = "Compro VideoMate T750",
.audio_clock= 0x00187de7,
.tuner_type = TUNER_XC2028,
.radio_type = UNSET,
-   .tuner_addr = ADDR_UNSET,
+   .tuner_addr = 0x61,
.radio_addr = ADDR_UNSET,
+   .mpeg   = SAA7134_MPEG_DVB,
.inputs = {{
.name   = name_tv,
.vmux   = 3,
@@ -6752,6 +6754,11 @@
msleep(10);
saa7134_set_gpio(dev, 18, 1);
break;
+   case SAA7134_BOARD_VIDEOMATE_T750:
+   saa7134_set_gpio(dev, 20, 0);
+   msleep(10);
+   saa7134_set_gpio(dev, 20, 1);
+   break;
}
return 0;
}
@@ -7171,6 +7178,11 @@
saa_andorl(SAA7134_GPIO_GPMODE0 >> 2,   0xC000, 0xC000);
saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0xC000, 0xC000);
break;
+   case SAA7134_BOARD_VIDEOMATE_T750:
+   dev->has_remote = SAA7134_REMOTE_GPIO;
+   saa_andorl(SAA7134_GPIO_GPMODE0 >> 2,   0x8000, 0x8000);
+   saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0x8000, 0x8000);
+   break;
}
return 0;
 }
diff -r 304cfde05b3f linux/drivers/media/video/saa7134/saa7134-dvb.c
--- a/linux/drivers/media/video/saa7134/saa7134-dvb.c   Tue May 25 23:50:51 
2010 -0400
+++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c   Mon May 31 01:18:12 
2010 +0200
@@ -55,6 +55,7 @@
 #include "tda8290.h"
 
 #include "zl10353.h"
+#include "qt1010.h"
 
 #include "zl10036.h"
 #include "zl10039.h"
@@ -886,6 +887,17 @@
.disable_i2c_gate_ctrl = 1,
 };
 
+static struct zl10353_config videomate_t750_zl10353_config = {
+   .demod_address  = 0x0f,
+   .no_tuner = 1,
+   .parallel_ts = 1,
+};
+
+static struct qt1010_config videomate_t750_qt1010_config = {
+   .i2c_address = 0x62
+};
+
+
 /* ==
  * tda10086 based DVB-S cards, helper functions
  */
@@ -1569,6 +1581,21 @@
__func__);
 
break;
+   case SAA7134_BOARD_VIDEOMATE_T750:
+   printk("Compro VideoMate T750 DVB setup\n");
+   fe0->dvb.frontend = dvb_attach(zl10353_attach,
+   &videomate_t750_zl10353_config,
+   &dev->i2c_adap);
+   if (fe0->dvb.frontend != NULL) {
+   // if there is a gate function then the i2c bus 
breaks.!
+   fe0->dvb.frontend->ops.i2c_gate_ctrl = 0;
+   if (dvb_attach(qt1010_attach,
+   fe0->dvb.frontend,
+   &dev->i2c_adap,
+   &videomate_t750_qt1010_config) == NULL)
+   wprintk("error attaching QT1010\n");
+   }
+   break;
case SAA7134_BOARD_ZOLID_HYBRID_PCI:
fe0->dvb.frontend = dvb_attach(tda10048_attach,
   &zolid_tda10048_config,
diff -r 304cfde05b3f linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c Tue May 25 23:50:51 
2010 -0400
+++ b/linux/drivers/media/video/saa7134/

[PATCH] support for medion dvb stick 1660:1921

[Stéphane Elmaleh]

Hello,
I'm not sure of doing this the right way since I'm not a programmer.



diff -r b576509ea6d2 linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Wed May 19 19:34:33 
2010 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Mon May 31 00:34:44 
2010 +0200
@@ -2083,6 +2083,7 @@
{ USB_DEVICE(USB_VID_PCTV,  USB_PID_PINNACLE_PCTV282E) },
{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK7770P) },
 /* 60 */{ USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_CINERGY_T_XXS_2) },
+   { USB_DEVICE(USB_VID_MEDION,USB_PID_MEDION_STICK_CTX_1921) },
{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK807XPVR) },
{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK807XP) },
{ USB_DEVICE(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD) },
@@ -2606,10 +2607,14 @@
},
},
 
-   .num_device_descs = 2,
+   .num_device_descs = 3,
.devices = {
{   "DiBcom STK7770P reference design",
{ &dib0700_usb_id_table[59], NULL },
+   { NULL },
+   },
+   {   "Medion Stick ctx 1921",
+   { &dib0700_usb_id_table[61], NULL },
{ NULL },
},
{   "Terratec Cinergy T USB XXS (HD)/ T3",
diff -r b576509ea6d2 linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Wed May 19 19:34:33 
2010 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Mon May 31 00:34:44 
2010 +0200
@@ -303,4 +303,5 @@
 #define USB_PID_TERRATEC_DVBS2CI_V20x10ac
 #define USB_PID_TECHNISAT_USB2_HDCI_V1 0x0001
 #define USB_PID_TECHNISAT_USB2_HDCI_V2 0x0002
+#define USB_PID_MEDION_STICK_CTX_1921  0x1921
 #endif

--
To unsubscribe from this list: send the line "unsubscribe 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: mt9m111 swap_rgb_red_blue

[Robert Jarzmik]

Sascha Hauer  writes:

> Hi Robert,
>
> I have digged around in the Datasheet and if I understand it correctly
> the PXA swaps red/blue in RGB mode. So if we do not use rgb mode but yuv
> (which should be a pass through) we should be able to support rgb on PXA
> aswell. Robert, can you confirm that with the following patch applied
> you still get an image but with red/blue swapped?
I can confirm the color swap.
If you want to follow that path, I would suggest instead :
   cicr1 |= CICR1_COLOR_SP_VAL(0);

There is no difference from a processing point of view, it's just that
CICR1_COLOR_SP_VAL(0) is "raw colorspace", with means "pass through", and that
seems to be your goal here.

Note that the patch would have to be completed with the BGR565 into RGB565
conversion, if the sensor was to provide only BGR565. But that could very well
be for another patch.

Cheers.

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

[PATCH 3/3] Gspca-gl860 driver update

[Olivier Lorin]

gspca - gl860: minor functional changes

From: Olivier Lorin 

- Setting changes applied after an end of image marker reception
  This is the way MI2020 sensor works.
  It seems to be logical to wait for a complete image before 
  to change a setting.
- 1 ms "msleep" applied to each sensor after USB control data exchange
  This was done for two sensors because these exchanges were known to
  be too quick depending on laptop model.
  It should be fairly logical to apply this delay to each sensor
  in order to prevent from having errors with untested hardwares.

Priority: normal

Signed-off-by: Olivier Lorin 

diff -urpN der_gl860i3/gl860.c gl860/gl860.c
--- der_gl860i3/gl860.c 2010-04-29 21:01:15.0 +0200
+++ gl860/gl860.c   2010-04-28 23:45:19.0 +0200
@@ -63,7 +63,7 @@ static int sd_set_##thename(struct gspca
 \
sd->vcur.thename = val;\
if (gspca_dev->streaming)\
-   sd->dev_camera_settings(gspca_dev);\
+   sd->waitSet = 1;\
return 0;\
 } \
 static int sd_get_##thename(struct gspca_dev *gspca_dev, s32 *val)\
@@ -595,10 +595,7 @@ int gl860_RTx(struct gspca_dev *gspca_de
else if (len > 1 && r < len)
PDEBUG(D_ERR, "short ctrl transfer %d/%d", r, len);
 
-   if (_MI2020_ && (val || index))
-   msleep(1);
-   if (_OV2640_)
-   msleep(1);
+   msleep(1);
 
return r;
 }


--
To unsubscribe from this list: send the line "unsubscribe 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 2/3] Gspca-gl860 - MI2030 sensor subdriver rewrite

[Olivier Lorin]

gspca - gl860: new driver for MI2020 sensor

From: Olivier Lorin 

- new MI2020 driver version made from a webcam given to me
- remove all previous flavors of this driver

Priority: normal

Signed-off-by: Olivier Lorin 

diff -urpN der_gl860i1/gl860.c gl860/gl860.c
--- der_gl860i1/gl860.c 2010-04-28 23:26:53.0 +0200
+++ gl860/gl860.c   2010-04-29 21:01:15.0 +0200
@@ -91,7 +91,6 @@ SD_SETGET(contrast)
 /* control table */
 static struct ctrl sd_ctrls_mi1320[GL860_NCTRLS];
 static struct ctrl sd_ctrls_mi2020[GL860_NCTRLS];
-static struct ctrl sd_ctrls_mi2020b[GL860_NCTRLS];
 static struct ctrl sd_ctrls_ov2640[GL860_NCTRLS];
 static struct ctrl sd_ctrls_ov9655[GL860_NCTRLS];
 
@@ -121,8 +120,6 @@ static int gl860_build_control_table(str
sd_ctrls = sd_ctrls_mi1320;
else if (_MI2020_)
sd_ctrls = sd_ctrls_mi2020;
-   else if (_MI2020b_)
-   sd_ctrls = sd_ctrls_mi2020b;
else if (_OV2640_)
sd_ctrls = sd_ctrls_ov2640;
else if (_OV9655_)
@@ -187,19 +184,6 @@ static const struct sd_desc sd_desc_mi20
.dq_callback = sd_callback,
 };
 
-static const struct sd_desc sd_desc_mi2020b = {
-   .name= MODULE_NAME,
-   .ctrls   = sd_ctrls_mi2020b,
-   .nctrls  = GL860_NCTRLS,
-   .config  = sd_config,
-   .init= sd_init,
-   .isoc_init   = sd_isoc_init,
-   .start   = sd_start,
-   .stop0   = sd_stop0,
-   .pkt_scan= sd_pkt_scan,
-   .dq_callback = sd_callback,
-};
-
 static const struct sd_desc sd_desc_ov2640 = {
.name= MODULE_NAME,
.ctrls   = sd_ctrls_ov2640,
@@ -344,8 +328,6 @@ static int sd_config(struct gspca_dev *g
sd->sensor = ID_OV9655;
else if (strcmp(sensor, "MI2020") == 0)
sd->sensor = ID_MI2020;
-   else if (strcmp(sensor, "MI2020b") == 0)
-   sd->sensor = ID_MI2020b;
 
/* Get sensor and set the suitable init/start/../stop functions */
if (gl860_guess_sensor(gspca_dev, vendor_id, product_id) == -1)
@@ -369,13 +351,6 @@ static int sd_config(struct gspca_dev *g
dev_init_settings   = mi2020_init_settings;
break;
 
-   case ID_MI2020b:
-   gspca_dev->sd_desc = &sd_desc_mi2020b;
-   cam->cam_mode = mi2020_mode;
-   cam->nmodes = ARRAY_SIZE(mi2020_mode);
-   dev_init_settings   = mi2020_init_settings;
-   break;
-
case ID_OV2640:
gspca_dev->sd_desc = &sd_desc_ov2640;
cam->cam_mode = ov2640_mode;
@@ -620,7 +595,7 @@ int gl860_RTx(struct gspca_dev *gspca_de
else if (len > 1 && r < len)
PDEBUG(D_ERR, "short ctrl transfer %d/%d", r, len);
 
-   if ((_MI2020_ || _MI2020b_ || _MI2020c_) && (val || index))
+   if (_MI2020_ && (val || index))
msleep(1);
if (_OV2640_)
msleep(1);
@@ -767,8 +742,6 @@ static int gl860_guess_sensor(struct gsp
PDEBUG(D_PROBE, "05e3:f191 sensor MI1320 (1.3M)");
} else if (_MI2020_) {
PDEBUG(D_PROBE, "05e3:0503 sensor MI2020 (2.0M)");
-   } else if (_MI2020b_) {
-   PDEBUG(D_PROBE, "05e3:0503 sensor MI2020 alt. driver (2.0M)");
} else if (_OV9655_) {
PDEBUG(D_PROBE, "05e3:0503 sensor OV9655 (1.3M)");
} else if (_OV2640_) {
diff -urpN der_gl860i1/gl860.h gl860/gl860.h
--- der_gl860i1/gl860.h 2010-04-28 13:56:51.0 +0200
+++ gl860/gl860.h   2010-04-28 13:36:36.0 +0200
@@ -32,12 +32,9 @@
 #define ID_OV2640   2
 #define ID_OV9655   4
 #define ID_MI2020   8
-#define ID_MI2020b 16
 
 #define _MI1320_  (((struct sd *) gspca_dev)->sensor == ID_MI1320)
 #define _MI2020_  (((struct sd *) gspca_dev)->sensor == ID_MI2020)
-#define _MI2020b_ (((struct sd *) gspca_dev)->sensor == ID_MI2020b)
-#define _MI2020c_ 0
 #define _OV2640_  (((struct sd *) gspca_dev)->sensor == ID_OV2640)
 #define _OV9655_  (((struct sd *) gspca_dev)->sensor == ID_OV9655)
 
diff -urpN der_gl860i1/gl860-mi2020.c gl860/gl860-mi2020.c
--- der_gl860i1/gl860-mi2020.c  2009-12-30 18:19:11.0 +0100
+++ gl860/gl860-mi2020.c2010-05-30 23:41:56.0 +0200
@@ -1,6 +1,7 @@
 /* Subdriver for the GL860 chip with the MI2020 sensor
- * Author Olivier LORIN, from Ice/Soro2005's logs(A), Fret_saw/Hulkie's
- * logs(B) and Tricid"s logs(C). With the help of
Kytrix/BUGabundo/Blazercist.
+ * Author Olivier LORIN, from logs by Iceman/Soro2005 +
Fret_saw/Hulkie/Tricid
+ * with the help of Kytrix/BUGabundo/Blazercist.
+ * Driver achieved thanks to a webcam gift by Kytrix.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -20,47 +21,70 @@
 
 #include "gl860.h"
 
+static u8 dat_wbal1[] = {0x8c, 0xa2, 0x0c};
+
 static u8 dat_bright1[] = {0x8c, 0xa2, 0x

[PATCH 1/3] Gspca-gl860 driver update

[Olivier Lorin]

gspca - gl860: minor fixes

From: Olivier Lorin 

- Change of rounded image resolutions to the real ones
- Fix for an irrelevant OV9655 image resolution identifier name
- Extra spaces to align some variable names and a defined value

Priority: normal

Signed-off-by: Olivier Lorin 

diff -rupN der_gl860b/gl860.c gl860/gl860.c
--- der_gl860b/gl860.c  2010-03-27 10:08:16.0 +0100
+++ gl860/gl860.c   2010-04-28 23:26:53.0 +0200
@@ -235,9 +235,9 @@ static struct v4l2_pix_format mi2020_mod
.colorspace = V4L2_COLORSPACE_SRGB,
.priv = 0
},
-   { 800,  600, V4L2_PIX_FMT_SGBRG8, V4L2_FIELD_NONE,
+   { 800,  598, V4L2_PIX_FMT_SGBRG8, V4L2_FIELD_NONE,
.bytesperline = 800,
-   .sizeimage = 800 * 600,
+   .sizeimage = 800 * 598,
.colorspace = V4L2_COLORSPACE_SRGB,
.priv = 1
},
@@ -247,9 +247,9 @@ static struct v4l2_pix_format mi2020_mod
.colorspace = V4L2_COLORSPACE_SRGB,
.priv = 2
},
-   {1600, 1200, V4L2_PIX_FMT_SGBRG8, V4L2_FIELD_NONE,
+   {1600, 1198, V4L2_PIX_FMT_SGBRG8, V4L2_FIELD_NONE,
.bytesperline = 1600,
-   .sizeimage = 1600 * 1200,
+   .sizeimage = 1600 * 1198,
.colorspace = V4L2_COLORSPACE_SRGB,
.priv = 3
},
diff -rupN der_gl860b/gl860.h gl860/gl860.h
--- der_gl860b/gl860.h  2010-03-27 10:08:25.0 +0100
+++ gl860/gl860.h   2010-04-28 13:56:51.0 +0200
@@ -44,7 +44,7 @@
 #define IMAGE_640   0
 #define IMAGE_800   1
 #define IMAGE_1280  2
-#define IMAGE_1600 3
+#define IMAGE_1600  3
 
 struct sd_gl860 {
u16 backlight;
@@ -75,10 +75,10 @@ struct sd {
int  (*dev_camera_settings)(struct gspca_dev *);
 
u8   swapRB;
-   u8  mirrorMask;
-   u8  sensor;
-   s32 nbIm;
-   s32 nbRightUp;
+   u8   mirrorMask;
+   u8   sensor;
+   s32  nbIm;
+   s32  nbRightUp;
u8   waitSet;
 };
 
diff -rupN der_gl860b/gl860-ov9655.c gl860/gl860-ov9655.c
--- der_gl860b/gl860-ov9655.c   2010-03-27 10:08:16.0 +0100
+++ gl860/gl860-ov9655.c2010-04-28 13:39:14.0 +0200
@@ -69,7 +69,7 @@ static u8 *tbl_640[] = {
"\xd0\x01\xd1\x08\xd2\xe0\xd3\x01" "\xd4\x10\xd5\x80"
 };
 
-static u8 *tbl_800[] = {
+static u8 *tbl_1280[] = {
"\x00\x40\x07\x6a\x06\xf3\x0d\x6a" "\x10\x10\xc1\x01"
,
"\x12\x80\x00\x00\x01\x98\x02\x80" "\x03\x12\x04\x01\x0b\x57\x0e\x61"
@@ -217,7 +217,7 @@ static int ov9655_init_post_alt(struct g
 
ctrl_out(gspca_dev, 0x40, 5, 0x0001, 0x, 0, NULL);
 
-   tbl = (reso == IMAGE_640) ? tbl_640 : tbl_800;
+   tbl = (reso == IMAGE_640) ? tbl_640 : tbl_1280;
 
ctrl_out(gspca_dev, 0x40, 3, 0x, 0x0200,
tbl_length[0], tbl[0]);


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

[PATH 0/3] gspca-gl860 driver update

[Olivier Lorin]

Hello

Here is three patches for the gspca_gl860 driver.
The main patch is the second one, it is a rewrite for the sensor MI2020.

These patches have been proposed on February 28th and refused some days
later because of a concern about the use of "udelay" instead of
"msleep".
Compared to February, there is no more use of "udelay". I also 
mapped a new setting to an already existing one in V4L2 instead of the
new one.

--
To unsubscribe from this list: send the line "unsubscribe 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: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Ondrej Zary]

On Sunday 30 May 2010 23:58:11 Andy Walls wrote:
> On Sun, 2010-05-30 at 23:28 +0200, Ondrej Zary wrote:
> > On Sunday 30 May 2010 21:26:14 Andy Walls wrote:
> > > On Sun, 2010-05-30 at 19:55 +0200, Ondrej Zary wrote:
> > > > On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote:
> > >
> > > SP54 is Sunplus' ( http://www.sunplus.com.tw/ ) FourCC code for a
> > > version of MJPEG with the headers removed according to
> > >
> > >   http://www.fourcc.org/
> > >
> > > > Maybe we can dump some data, create AVI file from that and try to
> > > > decode the file using that codec.
> > >
> > > FourCC.org points to this page:
> > >
> > >   http://libland.fr.st/download.html
> > >
> > > which points to a utility to conver the data back into an MJPEG:
> > >
> > >   http://mxhaard.free.fr/spca50x/Download/sp54convert.tar.gz
> > >
> > >
> > > I have no idea if any of the above is true, 'cause I read it on the
> > > Internet. ;)
> >
> > Modified that utility to work on raw video frame extracted from usbsnoop
> > file. The bad news is that the resulting jpeg file is not readable.
> >
> > I also deleted the sp5x_32.dll file and the camera still works...
>
> I would try extracting a JPEG header from one of the files captured by
> the camera in stand alone mode (either a JPEG still or MJPEG file), and
> put that header together with the image data from the USB capture.  It
> may not look perfect, but hopefully you will get something you
> recognize.

Just thought about the same thing so I uploaded a video file: 
http://www.rainbow-software.org/linux_files/spca1528/sunp0003.avi

> Attached was Theodore's first attempt of such a procedure with a header
> extracted from a standalone image file from my Jeilin based camera and
> USB snoop data from the same camera.  It wasn't perfect, but it was
> recognizable.

Thanks, I'll try that tomorrow.

> I did look at the image data file Jean-Francois provided from your
> usbsnoop logs.  To my eye the data looks like it is Huffman coded
> (indicating JPEG).  Maybe I'm just seeing what I want to see.
>
>
> Regards,
> Andy

-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe 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: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Andy Walls]

On Sun, 2010-05-30 at 23:28 +0200, Ondrej Zary wrote:
> On Sunday 30 May 2010 21:26:14 Andy Walls wrote:
> > On Sun, 2010-05-30 at 19:55 +0200, Ondrej Zary wrote:
> > > On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote:

> >
> > SP54 is Sunplus' ( http://www.sunplus.com.tw/ ) FourCC code for a
> > version of MJPEG with the headers removed according to
> >
> > http://www.fourcc.org/
> >
> > > Maybe we can dump some data, create AVI file from that and try to decode
> > > the file using that codec.
> >
> > FourCC.org points to this page:
> >
> > http://libland.fr.st/download.html
> >
> > which points to a utility to conver the data back into an MJPEG:
> >
> > http://mxhaard.free.fr/spca50x/Download/sp54convert.tar.gz
> >
> >
> > I have no idea if any of the above is true, 'cause I read it on the
> > Internet. ;)
> 
> Modified that utility to work on raw video frame extracted from usbsnoop 
> file. 
> The bad news is that the resulting jpeg file is not readable.
> 
> I also deleted the sp5x_32.dll file and the camera still works...

I would try extracting a JPEG header from one of the files captured by
the camera in stand alone mode (either a JPEG still or MJPEG file), and
put that header together with the image data from the USB capture.  It
may not look perfect, but hopefully you will get something you
recognize.

Attached was Theodore's first attempt of such a procedure with a header
extracted from a standalone image file from my Jeilin based camera and
USB snoop data from the same camera.  It wasn't perfect, but it was
recognizable.


I did look at the image data file Jean-Francois provided from your
usbsnoop logs.  To my eye the data looks like it is Huffman coded
(indicating JPEG).  Maybe I'm just seeing what I want to see.


Regards,
Andy
<>

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Ondrej Zary]

On Sunday 30 May 2010 21:26:14 Andy Walls wrote:
> On Sun, 2010-05-30 at 19:55 +0200, Ondrej Zary wrote:
> > On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote:
> > > On Sat, 29 May 2010 21:32:07 +0200
> > >
> > > Ondrej Zary  wrote:
> > > > The Color Space/Compression reported by the driver is only one: RGB
> > > > 24 The driver also uses these files which may (or may not) be related
> > > > to used compression: iyuv_32.dll, msh263.drv, msyuv.dll, tsbyuv.dll
> > > > In standalone mode, the camera records video in MJPEG format.
> > >
> > > Hello Ondrej,
> > >
> > > Bad news, the images are compressed by an unknown algorithm (unknown
> > > from Linux point of vue). The decompression function could be found in
> > > some part of the ms-win driver, but:
> > > - first, I have no time to search and disassemble this function,
> > > - then, I did have this problem with an other webcam (17a1:0118), and
> > >   after searching for a long time, nobody could find the function, and
> > >   the driver is in stand-by since 2 years,
> > > - eventually, is this legal?
> >
> > That's bad...
> >
> > The driver contains file sp5x_32.dll which is registered in system.ini
> > file as [drivers32]
> > VIDC.SP54=SP5X_32.DLL
> >
> > Seems that the codec is called SP54 - hope that it's used to decompress
> > the data.
> >
> > > All I can do is to code the driver and let you or anyone find the
> > > decompression function...
>
> SP54 is Sunplus' ( http://www.sunplus.com.tw/ ) FourCC code for a
> version of MJPEG with the headers removed according to
>
>   http://www.fourcc.org/
>
> > Maybe we can dump some data, create AVI file from that and try to decode
> > the file using that codec.
>
> FourCC.org points to this page:
>
>   http://libland.fr.st/download.html
>
> which points to a utility to conver the data back into an MJPEG:
>
>   http://mxhaard.free.fr/spca50x/Download/sp54convert.tar.gz
>
>
> I have no idea if any of the above is true, 'cause I read it on the
> Internet. ;)

Modified that utility to work on raw video frame extracted from usbsnoop file. 
The bad news is that the resulting jpeg file is not readable.

I also deleted the sp5x_32.dll file and the camera still works...

-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe 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 for 2.6.34] saa7134: add support for Compro VideoMate M1F

[hermann-pitton]

 
Hi,

- Original Nachricht 
Von: Mauro Carvalho Chehab 
An:  Pavel Osnova 
Datum:   30.05.2010 20:05
Betreff: Re: [PATCH for 2.6.34] saa7134: add support for Compro VideoMate
 M1F

> Em 26-05-2010 17:30, Pavel Osnova escreveu:
> > Sorry for the line breakages.
> 
> Patch doesn't apply:
>

Pavel, please send a new version against current.

You diff against changes not documented in the master repo.

We also better would know, which tuner is on it exactly.

We can expect at least three different ones.
PAL/SECAM, NTSC/System-M and Japan.

http://www.comprousa.com/en/product/m1f/m1f-Specifications.html

The tuner size is small, like a MK5, but you say LG API is fine, even on UHF 
and no tda9886.
It is not a LG PAL NEW TAPC, just something compatible I guess.

Then they would have a lot of different tuners for the PAL/SECAM region, like 
in the old days.

A little hard to believe, without knowing more about chips and filters on that 
tuner, or at least
that something under the Compro sticker says Pal BG/DK only or so, which would 
make us aware to 
expect different tuners on PAL-I, SECAM etc.

http://www.comprousa.com/en/product/m1f/m1f-hardware.html

Please also identify the IR decoder chip and its xtal, the blue RF filter and 
the chip above it.

Cheers,
Hermann


> $ test_patch 
> patching file Documentation/video4linux/CARDLIST.saa7134
> Hunk #1 FAILED at 176.
> 1 out of 1 hunk FAILED -- saving rejects to file
> Documentation/video4linux/CARDLIST.saa7134.rej
> patching file drivers/media/IR/keymaps/Makefile
> Hunk #1 FAILED at 61.
> 1 out of 1 hunk FAILED -- saving rejects to file
> drivers/media/IR/keymaps/Makefile.rej
> patching file drivers/media/IR/keymaps/rc-videomate-m1f.c
> patching file drivers/media/video/saa7134/saa7134-cards.c
> Hunk #1 FAILED at 5428.
> Hunk #2 FAILED at 6890.
> 2 out of 2 hunks FAILED -- saving rejects to file
> drivers/media/video/saa7134/saa7134-cards.c.rej
> patching file drivers/media/video/saa7134/saa7134.h
> Hunk #1 FAILED at 303.
> 1 out of 1 hunk FAILED -- saving rejects to file
> drivers/media/video/saa7134/saa7134.h.rej
> patching file drivers/media/video/saa7134/saa7134-input.c
> Hunk #1 FAILED at 815.
> 1 out of 1 hunk FAILED -- saving rejects to file
> drivers/media/video/saa7134/saa7134-input.c.rej
> patching file include/media/rc-map.h
> Hunk #1 succeeded at 112 (offset 1 line).
> >>> Patch
> patches/lmml_102504_for_2_6_34_saa7134_add_support_for_compro_videomate_m1f.
> patch doesn't apply
> 
> > 
> > diff -uprN v4l-dvb_orig/Documentation/video4linux/CARDLIST.saa7134
> v4l-dvb/Documentation/video4linux/CARDLIST.saa7134
> > --- v4l-dvb_orig/Documentation/video4linux/CARDLIST.saa7134 2010-05-26
> 20:34:06.0 +0300
> > +++ v4l-dvb/Documentation/video4linux/CARDLIST.saa7134  2010-05-26
> 21:12:28.247684250 +0300
> > @@ -176,5 +176,6 @@
> >  175 -> Leadtek Winfast DTV1000S [107d:6655]
> >  176 -> Beholder BeholdTV 505 RDS[:5051]
> >  177 -> Hawell HW-404M7
> > -179 -> Beholder BeholdTV H7[5ace:7190]
> > -180 -> Beholder BeholdTV A7[5ace:7090]
> > +178 -> Beholder BeholdTV H7[5ace:7190]
> > +179 -> Beholder BeholdTV A7[5ace:7090]
> > +180 -> Compro VideoMate M1F[185b:c900]
> > diff -uprN v4l-dvb_orig/drivers/media/IR/keymaps/Makefile
> v4l-dvb/drivers/media/IR/keymaps/Makefile
> > --- v4l-dvb_orig/drivers/media/IR/keymaps/Makefile  2010-05-26
> 20:34:09.0 +0300
> > +++ v4l-dvb/drivers/media/IR/keymaps/Makefile   2010-05-26
> 21:09:41.498117258 +0300
> > @@ -61,6 +61,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t
> > rc-terratec-cinergy-xs.o \
> > rc-tevii-nec.o \
> > rc-tt-1500.o \
> > +   rc-videomate-m1f.o \
> > rc-videomate-s350.o \
> > rc-videomate-tv-pvr.o \
> > rc-winfast.o \
> > diff -uprN v4l-dvb_orig/drivers/media/IR/keymaps/rc-videomate-m1f.c
> v4l-dvb/drivers/media/IR/keymaps/rc-videomate-m1f.c
> > --- v4l-dvb_orig/drivers/media/IR/keymaps/rc-videomate-m1f.c1970-01-01
> 03:00:00.0 +0300
> > +++ v4l-dvb/drivers/media/IR/keymaps/rc-videomate-m1f.c 2010-05-26
> 22:27:31.99335 +0300
> > @@ -0,0 +1,92 @@
> > +/* videomate-m1f.h - Keytable for videomate_m1f Remote Controller
> > + *
> > + * keymap imported from ir-keymaps.c
> > + *
> > + * Copyright (c) 2010 by Pavel Osnova 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include 
> > +
> > +static struct ir_scancode videomate_m1f[] = {
> > +   { 0x01, KEY_POWER },
> > +   { 0x31, KEY_TUNER },
> > +   { 0x

Re: ir-core multi-protocol decode and mceusb

[Jarod Wilson]

On Sun, May 30, 2010 at 10:02 AM, Mauro Carvalho Chehab
 wrote:
> Em 29-05-2010 23:24, Jarod Wilson escreveu:
>> On Sat, May 29, 2010 at 4:01 PM, Andy Walls  wrote:
...
  We do have the
 option to disable all but the relevant protocol handler on a
 per-device basis though, if that's a problem. Hrm, the key tables also
 have a protocol tied to them, not sure if that's taken into account
 when doing matching... Still getting to know the code. :)
>>>
>>> It does not look like
>>>
>>>        ir_keydown()
>>>                ir_g_keycode_from_table()
>>>                        ir_getkeycode()
>>>
>>> bother to check the ir_type (e.g. IR_TYPE_NEC) of the keymap against the
>>> decoders type.  Neither do the decoders themselves.
>>>
>>>
>>> If a decoder decodes something and thinks its valid, it tries to send a
>>> key event with ir_keydown().  ir_keydown() won't send a key event if the
>>> lookup comes back KEY_RESERVED, but it doesn't tell the decoder about
>>> the failure to find a key mapping.  A decoder can come back saying it
>>> did it's job, without knowing whether or not the decoding corresponded
>>> to a valid key in the loaded keymap. :(
>>>
>>>
> You will have to deal with the case that two or more decoders may match
> and each sends an IR event.  (Unless the ir-core already deals with this
> somehow...)

 Well, its gotta decode correctly to a value, and then match a value in
 the loaded key table for an input event to get sent through. At least
 for the RC6 MCE remotes, I haven't seen any of the other decoders take
 the signal and interpret it as valid -- which ought to be by design,
 if you consider that people use several different remotes with varying
 ir signals with different devices all receiving them all the time
 without problems (usually). And if we're not already, we could likely
 add some logic to give higher precedence to values arrived at using
 the protocol decoder that matches the key table we've got loaded for a
 given device.
>>>
>>> After looking at things, the only potential problem I can see right now
>>> is with the JVC decoder and NEC remotes.
>>>
>>> I think that problem is most easily eliminated either by
>>>
>>> a. having ir_keydown() (or the functions it calls) check to see that the
>>> decoder matches the loaded keymap, or
>>>
>>> b. only calling the decoder that matches the loaded keymap's protocol
>>>
>>> Of the above, b. saves processor cycles and frees up the global
>>> ir_raw_handler spin lock sooner.  That spin lock is serializing pulse
>>> decoding for all the IR receivers in the system  (pulse decoding can
>>> still be interleaved, just only one IR receiver's pulses are be
>>> processed at any time).  What's the point of running decoders that
>>> should never match the loaded keymap?
>>
>> For the daily use case where a known-good keymap is in place, I'm
>> coming to the conclusion that there's no point, we're only wasting
>> resources. For initial "figure out what this remote is" type of stuff,
>> running all decoders makes sense. One thought I had was that perhaps
>> we start by running through the decoder that is listed in the keymap.
>> If it decodes to a scancode and we find a valid key in the key table
>> (i.e., not KEY_RESERVED), we're done. If decoding fails or we don't
>> find a valid key, then try the other decoders. However, this is
>> possibly also wasteful -- most people with any somewhat involved htpc
>> setup are going to be constantly sending IR signals intended for other
>> devices that we pick up and try to decode.
>>
>> So I'd say we go with your option b, and only call the decoder that
>> matches the loaded keymap. One could either pass in a modparam or
>> twiddle a sysfs attr or use ir-keytable to put the receiver into a
>> mode that called all decoders -- i.e., set protocol to
>> IR_TYPE_UNKNOWN, with the intention being to figure it out based on
>> running all decoders, and create a new keymap where IR_TYPE_FOO is
>> known.
>
> There's no need to extra parameters. Decoders can be disabled by userspace,
> per each rc sysfs node. Btw, the current version of ir-keytable already sets
> the enabled protocols based on the protocol reported by the rc keymap.
>
> What it makes sense is to add a patch at RC core that will properly 
> enable/disable
> the protocols based on IR_TYPE, when the rc-map is stored in-kernel.

Ah, yeah, that does make sense. And if we add that, ir-keytable
doesn't actually have to worry about doing similar itself any longer.
If you're not already working on it, I can try to whip something up,
though I'm knee-deep in an ir-lirc-codec bridge right now...

-- 
Jarod Wilson
ja...@wilsonet.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: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Andy Walls]

On Sun, 2010-05-30 at 19:55 +0200, Ondrej Zary wrote:
> On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote:
> > On Sat, 29 May 2010 21:32:07 +0200
> >
> > Ondrej Zary  wrote:
> > > The Color Space/Compression reported by the driver is only one: RGB 24
> > > The driver also uses these files which may (or may not) be related to
> > > used compression: iyuv_32.dll, msh263.drv, msyuv.dll, tsbyuv.dll
> > > In standalone mode, the camera records video in MJPEG format.
> >
> > Hello Ondrej,
> >
> > Bad news, the images are compressed by an unknown algorithm (unknown
> > from Linux point of vue). The decompression function could be found in
> > some part of the ms-win driver, but:
> > - first, I have no time to search and disassemble this function,
> > - then, I did have this problem with an other webcam (17a1:0118), and
> >   after searching for a long time, nobody could find the function, and
> >   the driver is in stand-by since 2 years,
> > - eventually, is this legal?
> 
> That's bad...
> 
> The driver contains file sp5x_32.dll which is registered in system.ini file as
> [drivers32]
> VIDC.SP54=SP5X_32.DLL
> 
> Seems that the codec is called SP54 - hope that it's used to decompress the 
> data.
> 
> > All I can do is to code the driver and let you or anyone find the
> > decompression function...


SP54 is Sunplus' ( http://www.sunplus.com.tw/ ) FourCC code for a
version of MJPEG with the headers removed according to 

http://www.fourcc.org/


> Maybe we can dump some data, create AVI file from that and try to decode the 
> file using that codec.

FourCC.org points to this page:

http://libland.fr.st/download.html

which points to a utility to conver the data back into an MJPEG:
 
http://mxhaard.free.fr/spca50x/Download/sp54convert.tar.gz


I have no idea if any of the above is true, 'cause I read it on the
Internet. ;)

Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe 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:Sun May 30 19:00:24 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14875:304cfde05b3f
git master:   f6760aa024199cfbce564311dc4bc4d47b6fb349
git media-master: 4fcfa8824391ef0f9cff82122067f31c6d920921
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: OK
linux-2.6.33-armv5: OK
linux-2.6.34-armv5: ERRORS
linux-2.6.32.6-armv5-davinci: OK
linux-2.6.33-armv5-davinci: OK
linux-2.6.34-armv5-davinci: ERRORS
linux-2.6.32.6-armv5-ixp: OK
linux-2.6.33-armv5-ixp: OK
linux-2.6.34-armv5-ixp: ERRORS
linux-2.6.32.6-armv5-omap2: OK
linux-2.6.33-armv5-omap2: OK
linux-2.6.34-armv5-omap2: ERRORS
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.17-i686: ERRORS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.20-i686: WARNINGS
linux-2.6.26.8-i686: WARNINGS
linux-2.6.27.44-i686: WARNINGS
linux-2.6.28.10-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30.10-i686: WARNINGS
linux-2.6.31.12-i686: OK
linux-2.6.32.6-i686: OK
linux-2.6.33-i686: OK
linux-2.6.34-i686: ERRORS
linux-2.6.32.6-m32r: OK
linux-2.6.33-m32r: OK
linux-2.6.34-m32r: ERRORS
linux-2.6.32.6-mips: OK
linux-2.6.33-mips: OK
linux-2.6.34-mips: ERRORS
linux-2.6.32.6-powerpc64: OK
linux-2.6.33-powerpc64: OK
linux-2.6.34-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: WARNINGS
linux-2.6.25.20-x86_64: WARNINGS
linux-2.6.26.8-x86_64: WARNINGS
linux-2.6.27.44-x86_64: WARNINGS
linux-2.6.28.10-x86_64: WARNINGS
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30.10-x86_64: WARNINGS
linux-2.6.31.12-x86_64: OK
linux-2.6.32.6-x86_64: OK
linux-2.6.33-x86_64: OK
linux-2.6.34-x86_64: ERRORS
linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
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/Sunday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.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

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Andy Walls]

On Sun, 2010-05-30 at 13:34 +0200, Jean-Francois Moine wrote:
> On Sat, 29 May 2010 21:32:07 +0200
> Ondrej Zary  wrote:
> 
> > The Color Space/Compression reported by the driver is only one: RGB 24
> > The driver also uses these files which may (or may not) be related to
> > used compression: iyuv_32.dll, msh263.drv, msyuv.dll, tsbyuv.dll
> > In standalone mode, the camera records video in MJPEG format.
> 
> Hello Ondrej,
> 
> Bad news, the images are compressed by an unknown algorithm (unknown
> from Linux point of vue). The decompression function could be found in
> some part of the ms-win driver, but:
> - first, I have no time to search and disassemble this function,
> - then, I did have this problem with an other webcam (17a1:0118), and
>   after searching for a long time, nobody could find the function, and
>   the driver is in stand-by since 2 years,
> - eventually, is this legal?
> 
> All I can do is to code the driver and let you or anyone find the
> decompression function...

I ran into this with my daughetr's cheap little Sakar webcam based on a
Jeilin chip.  After some investigation about the chip and learning it
being only able to perform JPEG compression, it was rather easy to
figure out it was just sending MJPEG data with the headers stripped off.

This thread from last year tells most of the story

http://www.mail-archive.com/linux-media@vger.kernel.org/msg06766.html

(Many thanks to Theodore for doing the legwork on experiments and a new
GSPCA driver - jeilinj)

Since your camera records MJPEG in stand-alone mode (mine recorded MJPEG
in an AVI container in stand-alone mode), it stands to reason, your
camera may be doing the same sort of thing.  The payload of MJPEG data
will look very random since the compressed data is Huffman (entropy)
encoded in the final step of encoding.


Regards,
Andy



--
To unsubscribe from this list: send the line "unsubscribe 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: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Jean-Francois Moine]

On Sun, 30 May 2010 19:55:22 +0200
Ondrej Zary  wrote:

> That's bad...
> 
> The driver contains file sp5x_32.dll which is registered in
> system.ini file as [drivers32]
> VIDC.SP54=SP5X_32.DLL
> 
> Seems that the codec is called SP54 - hope that it's used to
> decompress the data.
> 
> > All I can do is to code the driver and let you or anyone find the
> > decompression function...
> 
> Maybe we can dump some data, create AVI file from that and try to
> decode the file using that codec.

It is easy to get images from the usbsnoop files. I join an image
extracted from your file usbsnoop-video-capture-640x480.log. If you
want more images, they are in IsoPackets. The first 2 bytes of each isoc
packet mean:
- '02 80' or '02 81': first of intermediate part of the image ('0' or
  '1' is the image sequence number)
- '02 82' or '02 83': last part of the image

Someone had an idea to try and guess the compression algorithm: do
usbsnoop's with full black and full white images. But this idea did not
work with the other webcam: the images were quite the same!

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/


image640.dat
Description: Binary data

Re: [PATCH for 2.6.34] saa7134: add support for Compro VideoMate M1F

[Mauro Carvalho Chehab]

Em 26-05-2010 17:30, Pavel Osnova escreveu:
> Sorry for the line breakages.

Patch doesn't apply:

$ test_patch 
patching file Documentation/video4linux/CARDLIST.saa7134
Hunk #1 FAILED at 176.
1 out of 1 hunk FAILED -- saving rejects to file 
Documentation/video4linux/CARDLIST.saa7134.rej
patching file drivers/media/IR/keymaps/Makefile
Hunk #1 FAILED at 61.
1 out of 1 hunk FAILED -- saving rejects to file 
drivers/media/IR/keymaps/Makefile.rej
patching file drivers/media/IR/keymaps/rc-videomate-m1f.c
patching file drivers/media/video/saa7134/saa7134-cards.c
Hunk #1 FAILED at 5428.
Hunk #2 FAILED at 6890.
2 out of 2 hunks FAILED -- saving rejects to file 
drivers/media/video/saa7134/saa7134-cards.c.rej
patching file drivers/media/video/saa7134/saa7134.h
Hunk #1 FAILED at 303.
1 out of 1 hunk FAILED -- saving rejects to file 
drivers/media/video/saa7134/saa7134.h.rej
patching file drivers/media/video/saa7134/saa7134-input.c
Hunk #1 FAILED at 815.
1 out of 1 hunk FAILED -- saving rejects to file 
drivers/media/video/saa7134/saa7134-input.c.rej
patching file include/media/rc-map.h
Hunk #1 succeeded at 112 (offset 1 line).
>>> Patch 
>>> patches/lmml_102504_for_2_6_34_saa7134_add_support_for_compro_videomate_m1f.patch
>>>  doesn't apply

> 
> diff -uprN v4l-dvb_orig/Documentation/video4linux/CARDLIST.saa7134 
> v4l-dvb/Documentation/video4linux/CARDLIST.saa7134
> --- v4l-dvb_orig/Documentation/video4linux/CARDLIST.saa7134 2010-05-26 
> 20:34:06.0 +0300
> +++ v4l-dvb/Documentation/video4linux/CARDLIST.saa7134  2010-05-26 
> 21:12:28.247684250 +0300
> @@ -176,5 +176,6 @@
>  175 -> Leadtek Winfast DTV1000S [107d:6655]
>  176 -> Beholder BeholdTV 505 RDS[:5051]
>  177 -> Hawell HW-404M7
> -179 -> Beholder BeholdTV H7[5ace:7190]
> -180 -> Beholder BeholdTV A7[5ace:7090]
> +178 -> Beholder BeholdTV H7[5ace:7190]
> +179 -> Beholder BeholdTV A7[5ace:7090]
> +180 -> Compro VideoMate M1F[185b:c900]
> diff -uprN v4l-dvb_orig/drivers/media/IR/keymaps/Makefile 
> v4l-dvb/drivers/media/IR/keymaps/Makefile
> --- v4l-dvb_orig/drivers/media/IR/keymaps/Makefile  2010-05-26 
> 20:34:09.0 +0300
> +++ v4l-dvb/drivers/media/IR/keymaps/Makefile   2010-05-26 21:09:41.498117258 
> +0300
> @@ -61,6 +61,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t
> rc-terratec-cinergy-xs.o \
> rc-tevii-nec.o \
> rc-tt-1500.o \
> +   rc-videomate-m1f.o \
> rc-videomate-s350.o \
> rc-videomate-tv-pvr.o \
> rc-winfast.o \
> diff -uprN v4l-dvb_orig/drivers/media/IR/keymaps/rc-videomate-m1f.c 
> v4l-dvb/drivers/media/IR/keymaps/rc-videomate-m1f.c
> --- v4l-dvb_orig/drivers/media/IR/keymaps/rc-videomate-m1f.c1970-01-01 
> 03:00:00.0 +0300
> +++ v4l-dvb/drivers/media/IR/keymaps/rc-videomate-m1f.c 2010-05-26 
> 22:27:31.99335 +0300
> @@ -0,0 +1,92 @@
> +/* videomate-m1f.h - Keytable for videomate_m1f Remote Controller
> + *
> + * keymap imported from ir-keymaps.c
> + *
> + * Copyright (c) 2010 by Pavel Osnova 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +
> +static struct ir_scancode videomate_m1f[] = {
> +   { 0x01, KEY_POWER },
> +   { 0x31, KEY_TUNER },
> +   { 0x33, KEY_VIDEO },
> +   { 0x2f, KEY_RADIO },
> +   { 0x30, KEY_CAMERA },
> +   { 0x2d, KEY_NEW }, /* TV record button */
> +   { 0x17, KEY_CYCLEWINDOWS },
> +   { 0x2c, KEY_ANGLE },
> +   { 0x2b, KEY_LANGUAGE },
> +   { 0x32, KEY_SEARCH }, /* '...' button */
> +   { 0x11, KEY_UP },
> +   { 0x13, KEY_LEFT },
> +   { 0x15, KEY_OK },
> +   { 0x14, KEY_RIGHT },
> +   { 0x12, KEY_DOWN },
> +   { 0x16, KEY_BACKSPACE },
> +   { 0x02, KEY_ZOOM }, /* WIN key */
> +   { 0x04, KEY_INFO },
> +   { 0x05, KEY_VOLUMEUP },
> +   { 0x03, KEY_MUTE },
> +   { 0x07, KEY_CHANNELUP },
> +   { 0x06, KEY_VOLUMEDOWN },
> +   { 0x08, KEY_CHANNELDOWN },
> +   { 0x0c, KEY_RECORD },
> +   { 0x0e, KEY_STOP },
> +   { 0x0a, KEY_BACK },
> +   { 0x0b, KEY_PLAY },
> +   { 0x09, KEY_FORWARD },
> +   { 0x10, KEY_PREVIOUS },
> +   { 0x0d, KEY_PAUSE },
> +   { 0x0f, KEY_NEXT },
> +   { 0x1e, KEY_1 },
> +   { 0x1f, KEY_2 },
> +   { 0x20, KEY_3 },
> +   { 0x21, KEY_4 },
> +   { 0x22, KEY_5 },
> +   { 0x23, KEY_6 },
> +   { 0x24, KEY_7 },
> +   { 0x25, KEY_8 },
> +   { 0x26, KEY_9 },
> +   { 0x2a, KEY_NUMERIC_STAR }, /* * key */
> +   { 0x1d, KEY_0 },
> +   { 0x29, KEY_SUBTITLE }, /* # key 

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Ondrej Zary]

On Sunday 30 May 2010 13:34:55 Jean-Francois Moine wrote:
> On Sat, 29 May 2010 21:32:07 +0200
>
> Ondrej Zary  wrote:
> > The Color Space/Compression reported by the driver is only one: RGB 24
> > The driver also uses these files which may (or may not) be related to
> > used compression: iyuv_32.dll, msh263.drv, msyuv.dll, tsbyuv.dll
> > In standalone mode, the camera records video in MJPEG format.
>
> Hello Ondrej,
>
> Bad news, the images are compressed by an unknown algorithm (unknown
> from Linux point of vue). The decompression function could be found in
> some part of the ms-win driver, but:
> - first, I have no time to search and disassemble this function,
> - then, I did have this problem with an other webcam (17a1:0118), and
>   after searching for a long time, nobody could find the function, and
>   the driver is in stand-by since 2 years,
> - eventually, is this legal?

That's bad...

The driver contains file sp5x_32.dll which is registered in system.ini file as
[drivers32]
VIDC.SP54=SP5X_32.DLL

Seems that the codec is called SP54 - hope that it's used to decompress the 
data.

> All I can do is to code the driver and let you or anyone find the
> decompression function...

Maybe we can dump some data, create AVI file from that and try to decode the 
file using that codec.

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

Re: What ever happened to standardizing signal level?

[Markus Rechberger]

On Sun, May 30, 2010 at 5:21 PM, Michael Krufky  wrote:
> Markus Rechberger wrote:
>>
>> Hi,
>>
>> A little bit more "ontopic", did anyone get around to read the
>> signallevel of the tda18721?
>> I wonder the register does not return any signallevel as indicated in
>> the specifications.
>>
>> Markus
>
> There is a "power level" value that can be read from the tda18271 -- I had a
> patch that enabled reading of this value, for testing purposes, but it
> wasn't as useful as I had hoped, so I never bothered to merge it.
>
> If you'd like to play with it, I pushed up some code last year:
>
> http://kernellabs.com/hg/~mkrufky/tda18271-pl/rev/4373874cff29
>
> Let me know how this works for you, or if you choose to change it.  I If you
> find it valuable, we can merge it in somehow.
>

hmm.. I somewhat tried the same but the register kept flipping back
and the powerlevel register returned 0.

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

Re: What ever happened to standardizing signal level?

[hermann-pitton]

 


- Original Nachricht 
Von: VDR User 
An:  hermann pitton 
Datum:   30.05.2010 09:01
Betreff: Re: What ever happened to standardizing signal level?

> On Sat, May 29, 2010 at 10:52 PM, hermann pitton
>  wrote:
> >
> ...troll spam removed...
> >
> 
> Hermann, you're a known troll with clearly nothing to contribute to
> this thread therefore you're comments are unwelcome.  

On requests without success

http://linuxtv.org/pipermail/linux-dvb/2009-August/032299.html

you are well known for being in good company soon.

http://linuxtv.org/pipermail/linux-dvb/2008-December/030704.html

I wonder, if this will ever change, but hope so.

Hermann


Und was machen Sie heute abend? Alles Events Ihrer Gegend auf einen Blick im 
Arcor.de-Veranstaltungskalender: http://www.arcor.de/rd/footer.events
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What ever happened to standardizing signal level?

[Michael Krufky]

Markus Rechberger wrote:

Hi,

A little bit more "ontopic", did anyone get around to read the
signallevel of the tda18721?
I wonder the register does not return any signallevel as indicated in
the specifications.

Markus


There is a "power level" value that can be read from the tda18271 -- I 
had a patch that enabled reading of this value, for testing purposes, 
but it wasn't as useful as I had hoped, so I never bothered to merge it.


If you'd like to play with it, I pushed up some code last year:

http://kernellabs.com/hg/~mkrufky/tda18271-pl/rev/4373874cff29

Let me know how this works for you, or if you choose to change it.  I If 
you find it valuable, we can merge it in somehow.


Regards,

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

Re: What ever happened to standardizing signal level?

[Michael Krufky]

Hans Verkuil wrote:

On Sunday 30 May 2010 09:07:46 VDR User wrote:

On Sat, May 29, 2010 at 2:09 AM, Mike Booth  wrote:

i think someone is too concerned about being precisely accurate. So much so
that no-one can see the woods for the trees any more.

Its not important to me that accuracy is spot on. I only want to know that
when tuning the dish I'm getting \better or worse.

I tend to agree with this.  Ultimately what's important is not
necessarily that the readings are 100% accurate, but rather simply put
into some kind of universal scale that provides useful output to the
user.  Many users were happy to see some activity addressing this
issue and unfortunately it seems to have stalled out but I'm not sure
why.  I honestly felt there was enough common ground being discussed
that we'd have a solution by now.


To the best of my knowledge Mike Krufky intended to work on this but he
clearly no longer has time to do that work.

Mike, can you perhaps explain what you wanted to do? Hopefully someone else
can find the time to implement it.

Regards,

Hans




..."clearly no longer has time" -- please do not speak on my behalf -- I 
have taken a break from v4l-dvb, and I will return when I have time for 
it again.


I already did a lot of the work for standardizing signal level, but I 
need to clean it up, consider new demod modules, push trees and send 
pull requests.  Right now, correct -- I don't have time for it.  I'll 
likely get to this by mid-august -- I will have more time again by then.


I have a plethora of changes in my queue that I have to burn through and 
merge, including j-rod's lgdt3304 support.  I used to get this stuff 
done very quickly, but there is a lot of change going on in my life 
right now... When things settle down here, I'll be back in full force.  :-)


Regards,

Mike Krufky

Regards,

Mike
--
To unsubscribe from this list: send the line "unsubscribe 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: schedule inside spin_lock_irqsave?

[Jiri Slaby]

On 05/30/2010 05:24 PM, Jiri Slaby wrote:
> struct smscore_buffer_t *get_entry(void)
> {
>   struct smscore_buffer_t *cb = NULL;
>   spin_lock_irqsave(&coredev->bufferslock, flags);
>   if (!list_empty(&coredev->buffers)) {
> cb = (struct smscore_buffer_t *) coredev->buffers.next;

Looking at the smscore_buffer_t definition, this is really ugly since it
relies on entry being the first in the structure. It should be
list_first_entry(&coredev->buffers, ...) instead, cast-less.

> list_del(&cb->entry);
>   }
>   spin_unlock_irqrestore(&coredev->bufferslock, flags);
>   return cb;
> }


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

Re: What ever happened to standardizing signal level?

[Hans Verkuil]

On Sunday 30 May 2010 17:18:25 Michael Krufky wrote:
> Hans Verkuil wrote:
> > On Sunday 30 May 2010 09:07:46 VDR User wrote:
> >> On Sat, May 29, 2010 at 2:09 AM, Mike Booth  
> >> wrote:
> >>> i think someone is too concerned about being precisely accurate. So much 
> >>> so
> >>> that no-one can see the woods for the trees any more.
> >>>
> >>> Its not important to me that accuracy is spot on. I only want to know that
> >>> when tuning the dish I'm getting \better or worse.
> >> I tend to agree with this.  Ultimately what's important is not
> >> necessarily that the readings are 100% accurate, but rather simply put
> >> into some kind of universal scale that provides useful output to the
> >> user.  Many users were happy to see some activity addressing this
> >> issue and unfortunately it seems to have stalled out but I'm not sure
> >> why.  I honestly felt there was enough common ground being discussed
> >> that we'd have a solution by now.
> > 
> > To the best of my knowledge Mike Krufky intended to work on this but he
> > clearly no longer has time to do that work.
> > 
> > Mike, can you perhaps explain what you wanted to do? Hopefully someone else
> > can find the time to implement it.
> > 
> > Regards,
> > 
> > Hans
> > 
> 
> 
> ..."clearly no longer has time" -- please do not speak on my behalf -- I 
> have taken a break from v4l-dvb, and I will return when I have time for 
> it again.

My apologies, that was poorly phrased. 'appears to have little time' would
have been much better. Sorry about that.

> 
> I already did a lot of the work for standardizing signal level, but I 
> need to clean it up, consider new demod modules, push trees and send 
> pull requests.  Right now, correct -- I don't have time for it.  I'll 
> likely get to this by mid-august -- I will have more time again by then.
> 
> I have a plethora of changes in my queue that I have to burn through and 
> merge, including j-rod's lgdt3304 support.  I used to get this stuff 
> done very quickly, but there is a lot of change going on in my life 
> right now... When things settle down here, I'll be back in full force.  :-)

Looking forward to that!

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line "unsubscribe 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: schedule inside spin_lock_irqsave?

[Jiri Slaby]

On 05/30/2010 04:52 PM, Richard Zidlicky wrote:
> Hi,
> 
> came across following snippet of code 
> (2.6.34:drivers/media/dvb/siano/smscoreapi.c) and 
> since prepare_to_wait is new for me I am wondering if this is can work?
> 
> struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
> {
>   struct smscore_buffer_t *cb = NULL;
>   unsigned long flags;
> 
>   DEFINE_WAIT(wait);
> 
>   spin_lock_irqsave(&coredev->bufferslock, flags);
> 
>   /* This function must return a valid buffer, since the buffer list is
>* finite, we check that there is an available buffer, if not, we wait
>* until such buffer become available.
>*/
> 
>   prepare_to_wait(&coredev->buffer_mng_waitq, &wait, TASK_INTERRUPTIBLE);
> 
>   if (list_empty(&coredev->buffers))
>   schedule();
> 
>   finish_wait(&coredev->buffer_mng_waitq, &wait);
> 
>   cb = (struct smscore_buffer_t *) coredev->buffers.next;
>   list_del(&cb->entry);
> 
>   spin_unlock_irqrestore(&coredev->bufferslock, flags);


Yep, that's a double bug.
1) If the waiting is interrupted, it will die because the list is still
empty.
2) If there is no entry in the list, it will deadlock at least on UP.
This should be
wait_event(&coredev->buffer_mng_waitq, cb = get_entry());
with get_entry like:
struct smscore_buffer_t *get_entry(void)
{
  struct smscore_buffer_t *cb = NULL;
  spin_lock_irqsave(&coredev->bufferslock, flags);
  if (!list_empty(&coredev->buffers)) {
cb = (struct smscore_buffer_t *) coredev->buffers.next;
list_del(&cb->entry);
  }
  spin_unlock_irqrestore(&coredev->bufferslock, flags);
  return cb;
}

regards,
-- 
js
--
To unsubscribe from this list: send the line "unsubscribe 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-core multi-protocol decode and mceusb

[Mauro Carvalho Chehab]

Em 29-05-2010 23:24, Jarod Wilson escreveu:
> On Sat, May 29, 2010 at 4:01 PM, Andy Walls  wrote:
>> On Sat, 2010-05-29 at 12:58 -0400, Jarod Wilson wrote:
>>> On Sat, May 29, 2010 at 8:39 AM, Andy Walls  wrote:
 On Fri, 2010-05-28 at 00:47 -0400, Jarod Wilson wrote:
> So I'm inching closer to a viable mceusb driver submission -- both a
> first-gen and a third-gen transceiver are now working perfectly with
> multiple different mce remotes. However, that's only when I make sure
> the mceusb driver is loaded w/only the rc6 decoder loaded. When
> ir-core comes up, it requests all decoders to load, starting with the
> nec decoder, followed by the rc5 decoder, then the rc6 decoder and so
> on (init_decoders() in ir-raw-event.c). When I call
> ir_raw_event_handle, all decoders get run on the ir data buffer,
> starting with nec. Well, the nec decoder doesn't like the rc6 data, so
> it pukes. The RUN_DECODER macro break's out of the routine when that
> happens, and the rc6 decoder never gets a chance to run. (Similarly,
> if only ir-nec-decoder has been removed, the rc5 decoder pukes on the
> rc6 data, same problem).

 Yes, if the system kernel is going to attempt to discriminate between
 various input singals, it needs to let all its "correlators" run and
 produce a "confidence" number from each.

 Then ideally one would take the result with the highest confidence.

 Right now it looks like all the confidence determinations are boolean (0
 or -EINVAL) and there is no chance to deal with the case that two
 different decoders validly decode something.  The first decoder that
 declares a match "wins" and sends an event.
>>>
>>> Yeah, it does look that way. I wonder how likely it is that e.g. a
>>> valid RC6 signal would be decoded to something by say the NEC decoder,
>>
>> NEC is a pulse position code and RC-6 is manchester encoded, so that
>> particular case would be unlikely.
>>
>> I would think one would have a better chance of false positiive
>> detections between similar encoding types: pulse position, pulse width,
>> or manchester.
>>
>> Looking at slide 11 of this:
>>
>>http://www.audiodevelopers.com/temp/Remote_Controls.ppt
>>
>> It looks like the pulse position protocols with a header space of 8T
>> (where 8T is about 4ms) would be the only ones that could get confused.
>>
>> Since these are streaming decoders, it looks like JVC would come up with
>> false detections first, since it has the shortest payload of the pulse
>> position protocols.  I think JVC will always claim to decode an NEC
>> pulse train.  (I'll try to test that sometime.)
>>
>>
>>> with a resulting value that matched an entry in the (RC6) keymap
>>> loaded for the remote... Certainly seems like something that *could*
>>> happen somehow, but probably unlikely? I dunno...
>>
>> I don't know either.  There appears to be a chance for the first 16 bits
>> of a transmitted NEC (Addr:Addr') or Extended NEC (AddrHi:AddrLo)
>> sequence, to be interpreted as JVC (Addr:Cmd), and the JVC decoder
>> matching a scancode in the keytable for the NEC remote.
>>
>>
>>
>>
>>>  We do have the
>>> option to disable all but the relevant protocol handler on a
>>> per-device basis though, if that's a problem. Hrm, the key tables also
>>> have a protocol tied to them, not sure if that's taken into account
>>> when doing matching... Still getting to know the code. :)
>>
>> It does not look like
>>
>>ir_keydown()
>>ir_g_keycode_from_table()
>>ir_getkeycode()
>>
>> bother to check the ir_type (e.g. IR_TYPE_NEC) of the keymap against the
>> decoders type.  Neither do the decoders themselves.
>>
>>
>> If a decoder decodes something and thinks its valid, it tries to send a
>> key event with ir_keydown().  ir_keydown() won't send a key event if the
>> lookup comes back KEY_RESERVED, but it doesn't tell the decoder about
>> the failure to find a key mapping.  A decoder can come back saying it
>> did it's job, without knowing whether or not the decoding corresponded
>> to a valid key in the loaded keymap. :(
>>
>>
 You will have to deal with the case that two or more decoders may match
 and each sends an IR event.  (Unless the ir-core already deals with this
 somehow...)
>>>
>>> Well, its gotta decode correctly to a value, and then match a value in
>>> the loaded key table for an input event to get sent through. At least
>>> for the RC6 MCE remotes, I haven't seen any of the other decoders take
>>> the signal and interpret it as valid -- which ought to be by design,
>>> if you consider that people use several different remotes with varying
>>> ir signals with different devices all receiving them all the time
>>> without problems (usually). And if we're not already, we could likely
>>> add some logic to give higher precedence to values arrived at using
>>> the protocol decoder that matches the key table we've

[PATCH 3/3] tm6000: move dvb into a separate kern module

[stefan . ringel]

From: Stefan Ringel 

move dvb into a separate kern module


Signed-off-by: Stefan Ringel 
---
 drivers/staging/tm6000/Kconfig|4 +-
 drivers/staging/tm6000/Makefile   |5 +--
 drivers/staging/tm6000/tm6000-cards.c |   31 +---
 drivers/staging/tm6000/tm6000-core.c  |1 +
 drivers/staging/tm6000/tm6000-dvb.c   |   83 -
 drivers/staging/tm6000/tm6000.h   |1 +
 6 files changed, 89 insertions(+), 36 deletions(-)

diff --git a/drivers/staging/tm6000/Kconfig b/drivers/staging/tm6000/Kconfig
index 3657e33..c725356 100644
--- a/drivers/staging/tm6000/Kconfig
+++ b/drivers/staging/tm6000/Kconfig
@@ -26,8 +26,8 @@ config VIDEO_TM6000_ALSA
  module will be called tm6000-alsa.
 
 config VIDEO_TM6000_DVB
-   bool "DVB Support for tm6000 based TV cards"
-   depends on VIDEO_TM6000 && DVB_CORE && EXPERIMENTAL
+   tristate "DVB Support for tm6000 based TV cards"
+   depends on VIDEO_TM6000 && DVB_CORE && USB && EXPERIMENTAL
select DVB_ZL10353
---help---
  This adds support for DVB cards based on the tm5600/tm6000 chip.
diff --git a/drivers/staging/tm6000/Makefile b/drivers/staging/tm6000/Makefile
index 93370fc..4129c18 100644
--- a/drivers/staging/tm6000/Makefile
+++ b/drivers/staging/tm6000/Makefile
@@ -4,12 +4,9 @@ tm6000-objs := tm6000-cards.o \
   tm6000-video.o \
   tm6000-stds.o
 
-ifeq ($(CONFIG_VIDEO_TM6000_DVB),y)
-tm6000-objs += tm6000-dvb.o
-endif
-
 obj-$(CONFIG_VIDEO_TM6000) += tm6000.o
 obj-$(CONFIG_VIDEO_TM6000_ALSA) += tm6000-alsa.o
+obj-$(CONFIG_VIDEO_TM6000_DVB) += tm6000-dvb.o
 
 EXTRA_CFLAGS = -Idrivers/media/video
 EXTRA_CFLAGS += -Idrivers/media/common/tuners
diff --git a/drivers/staging/tm6000/tm6000-cards.c 
b/drivers/staging/tm6000/tm6000-cards.c
index 553ebe4..87b0bc4 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -346,7 +346,7 @@ int tm6000_xc5000_callback(void *ptr, int component, int 
command, int arg)
}
return (rc);
 }
-
+EXPORT_SYMBOL_GPL(tm6000_xc5000_callback);
 
 /* Tuner callback to provide the proper gpio changes needed for xc2028 */
 
@@ -436,6 +436,7 @@ int tm6000_tuner_callback(void *ptr, int component, int 
command, int arg)
}
return rc;
 }
+EXPORT_SYMBOL_GPL(tm6000_tuner_callback);
 
 int tm6000_cards_setup(struct tm6000_core *dev)
 {
@@ -693,31 +694,12 @@ static int tm6000_init_dev(struct tm6000_core *dev)
goto err;
 
tm6000_add_into_devlist(dev);
-
tm6000_init_extension(dev);
 
-   if (dev->caps.has_dvb) {
-   dev->dvb = kzalloc(sizeof(*(dev->dvb)), GFP_KERNEL);
-   if (!dev->dvb) {
-   rc = -ENOMEM;
-   goto err2;
-   }
-
-#ifdef CONFIG_VIDEO_TM6000_DVB
-   rc = tm6000_dvb_register(dev);
-   if (rc < 0) {
-   kfree(dev->dvb);
-   dev->dvb = NULL;
-   goto err2;
-   }
-#endif
}
mutex_unlock(&dev->lock);
return 0;
 
-err2:
-   v4l2_device_unregister(&dev->v4l2_dev);
-
 err:
mutex_unlock(&dev->lock);
return rc;
@@ -918,13 +900,6 @@ static void tm6000_usb_disconnect(struct usb_interface 
*interface)
 
mutex_lock(&dev->lock);
 
-#ifdef CONFIG_VIDEO_TM6000_DVB
-   if (dev->dvb) {
-   tm6000_dvb_unregister(dev);
-   kfree(dev->dvb);
-   }
-#endif
-
if (dev->gpio.power_led) {
switch (dev->model) {
case TM6010_BOARD_HAUPPAUGE_900H:
@@ -954,8 +929,8 @@ static void tm6000_usb_disconnect(struct usb_interface 
*interface)
 
usb_put_dev(dev->udev);
 
-   tm6000_remove_from_devlist(dev);
tm6000_close_extension(dev);
+   tm6000_remove_from_devlist(dev);
 
mutex_unlock(&dev->lock);
kfree(dev);
diff --git a/drivers/staging/tm6000/tm6000-core.c 
b/drivers/staging/tm6000/tm6000-core.c
index b5965a8..cd87b14 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -396,6 +396,7 @@ int tm6000_init_digital_mode (struct tm6000_core *dev)
 
return 0;
 }
+EXPORT_SYMBOL(tm6000_init_digial_mode);
 
 struct reg_init {
u8 req;
diff --git a/drivers/staging/tm6000/tm6000-dvb.c 
b/drivers/staging/tm6000/tm6000-dvb.c
index b9e9ef1..7830826 100644
--- a/drivers/staging/tm6000/tm6000-dvb.c
+++ b/drivers/staging/tm6000/tm6000-dvb.c
@@ -38,6 +38,19 @@
dev->name, __FUNCTION__, ##arg);\
} while (0)
 
+MODULE_DESCRIPTION("DVB driver extension module for tm5600/6000/6010 based TV 
cards");
+MODULE_AUTHOR("Mauro Carvalho Chehab ");
+MODULE_LICENSE("GPL");
+
+MODULE_SUPPORTED_DEVICE("{{Trident, tm5600},"
+   "{{Trident, tm6000},"
+   "{{Trident, tm6010}");
+
+static int debug
+
+module_param(debug

[PATCH 2/3] tm6000: move debug info print from header into c file

[stefan . ringel]

From: Stefan Ringel 

move debug info print from header into c file

Signed-off-by: Stefan Ringel 
---
 drivers/staging/tm6000/tm6000-core.c  |6 ++
 drivers/staging/tm6000/tm6000-dvb.c   |8 
 drivers/staging/tm6000/tm6000-video.c |6 ++
 drivers/staging/tm6000/tm6000.h   |7 ---
 4 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-core.c 
b/drivers/staging/tm6000/tm6000-core.c
index 624c276..b5965a8 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -29,6 +29,12 @@
 #include 
 #include 
 
+#define dprintk(dev, level, fmt, arg...) do {  \
+   if (tm6000_debug & level)   \
+   printk(KERN_INFO "(%lu) %s %s :"fmt, jiffies,   \
+   dev->name, __FUNCTION__, ##arg);\
+   } while (0)
+
 #define USB_TIMEOUT5*HZ /* ms */
 
 int tm6000_read_write_usb (struct tm6000_core *dev, u8 req_type, u8 req,
diff --git a/drivers/staging/tm6000/tm6000-dvb.c 
b/drivers/staging/tm6000/tm6000-dvb.c
index 714b384..b9e9ef1 100644
--- a/drivers/staging/tm6000/tm6000-dvb.c
+++ b/drivers/staging/tm6000/tm6000-dvb.c
@@ -30,6 +30,14 @@
 #include "tuner-xc2028.h"
 #include "xc5000.h"
 
+#undef dprintk
+
+#define dprintk(dev, level, fmt, arg...) do {  \
+   if (debug >= level) \
+   printk(KERN_INFO "(%lu) %s %s :"fmt, jiffies,   \
+   dev->name, __FUNCTION__, ##arg);\
+   } while (0)
+
 static void inline print_err_status (struct tm6000_core *dev,
 int packet, int status)
 {
diff --git a/drivers/staging/tm6000/tm6000-video.c 
b/drivers/staging/tm6000/tm6000-video.c
index 9746fe7..98af4a5 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -42,6 +42,12 @@
 #include "tm6000-regs.h"
 #include "tm6000.h"
 
+#define dprintk(dev, level, fmt, arg...) do {  \
+   if (tm6000_debug & level)   \
+   printk(KERN_INFO "(%lu) %s %s :"fmt, jiffies,   \
+   dev->name, __FUNCTION__, ##arg);\
+   } while (0)
+
 #define BUFFER_TIMEOUT msecs_to_jiffies(2000)  /* 2 seconds */
 
 /* Limits minimum and default number of buffers */
diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h
index 231e2be..fd94ed6 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -316,13 +316,6 @@ int tm6000_queue_init(struct tm6000_core *dev);
 
 /* Debug stuff */
 
-extern int tm6000_debug;
-
-#define dprintk(dev, level, fmt, arg...) do {\
-   if (tm6000_debug & level) \
-   printk(KERN_INFO "(%lu) %s %s :"fmt, jiffies,   \
-dev->name, __FUNCTION__ , ##arg); } while (0)
-
 #define V4L2_DEBUG_REG 0x0004
 #define V4L2_DEBUG_I2C 0x0008
 #define V4L2_DEBUG_QUEUE   0x0010
-- 
1.7.0.3

--
To unsubscribe from this list: send the line "unsubscribe 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/3] tm6000: rewrite init and fini

[stefan . ringel]

From: Stefan Ringel 

rewrite tm6000_audio_init and tm6000_audio_fini

Signed-off-by: Stefan Ringel 
---
 drivers/staging/tm6000/tm6000-alsa.c |  127 +-
 drivers/staging/tm6000/tm6000.h  |   15 
 2 files changed, 63 insertions(+), 79 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-alsa.c 
b/drivers/staging/tm6000/tm6000-alsa.c
index ce081cd..477dd78 100644
--- a/drivers/staging/tm6000/tm6000-alsa.c
+++ b/drivers/staging/tm6000/tm6000-alsa.c
@@ -35,29 +35,6 @@
} while (0)
 
 /
-   Data type declarations - Can be moded to a header file later
- /
-
-struct snd_tm6000_card {
-   struct snd_card*card;
-
-   spinlock_t reg_lock;
-
-   atomic_t   count;
-
-   unsigned int   period_size;
-   unsigned int   num_periods;
-
-   struct tm6000_core *core;
-   struct tm6000_buffer   *buf;
-
-   intbufsize;
-
-   struct snd_pcm_substream *substream;
-};
-
-
-/
Module global static vars
  /
 
@@ -311,21 +288,6 @@ static struct snd_pcm_ops snd_tm6000_pcm_ops = {
 /*
  * create a PCM device
  */
-static int __devinit snd_tm6000_pcm(struct snd_tm6000_card *chip,
-   int device, char *name)
-{
-   int err;
-   struct snd_pcm *pcm;
-
-   err = snd_pcm_new(chip->card, name, device, 0, 1, &pcm);
-   if (err < 0)
-   return err;
-   pcm->private_data = chip;
-   strcpy(pcm->name, name);
-   snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &snd_tm6000_pcm_ops);
-
-   return 0;
-}
 
 /* FIXME: Control interface - How to control volume/mute? */
 
@@ -336,73 +298,64 @@ static int __devinit snd_tm6000_pcm(struct 
snd_tm6000_card *chip,
 /*
  * Alsa Constructor - Component probe
  */
-
-int tm6000_audio_init(struct tm6000_core *dev, int idx)
+int tm6000_audio_init(struct tm6000_core *dev)
 {
-   struct snd_card *card;
-   struct snd_tm6000_card  *chip;
-   int rc, len;
-   charcomponent[14];
+   struct snd_card *card;
+   struct snd_tm6000_card  *chip;
+   int rc;
+   static int  devnr;
+   charcomponent[14];
+   struct snd_pcm  *pcm;
+
+   if (!dev)
+   return 0;
 
-   if (idx >= SNDRV_CARDS)
+   if (devnr >= SNDRV_CARDS)
return -ENODEV;
 
-   if (!enable[idx])
+   if (!enable[devnr])
return -ENOENT;
 
-   rc = snd_card_create(index[idx], id[idx], THIS_MODULE, 0, &card);
+   rc = snd_card_create(index[devnr], id[devnr], THIS_MODULE, 0, &card);
if (rc < 0) {
-   snd_printk(KERN_ERR "cannot create card instance %d\n", idx);
+   snd_printk(KERN_ERR "cannot create card instance %d\n", devnr);
return rc;
}
 
-   chip = kzalloc(sizeof(*chip), GFP_KERNEL);
+   chip = kzalloc(sizeof(struct snd_tm6000_card), GFP_KERNEL);
if (!chip) {
rc = -ENOMEM;
goto error;
}
 
-   chip->core = dev;
-   chip->card = card;
-
-   strcpy(card->driver, "tm6000-alsa");
sprintf(component, "USB%04x:%04x",
le16_to_cpu(dev->udev->descriptor.idVendor),
le16_to_cpu(dev->udev->descriptor.idProduct));
-   snd_component_add(card, component);
-
-   if (dev->udev->descriptor.iManufacturer)
-   len = usb_string(dev->udev,
-dev->udev->descriptor.iManufacturer,
-card->longname, sizeof(card->longname));
-   else
-   len = 0;
-
-   if (len > 0)
-   strlcat(card->longname, " ", sizeof(card->longname));
+   snd_component_add(card, component); 
 
-   strlcat(card->longname, card->shortname, sizeof(card->longname));
-
-   len = strlcat(card->longname, " at ", sizeof(card->longname));
-
-   if (len < sizeof(card->longname))
-   usb_make_path(dev->udev, card->longname + len,
- sizeof(card->longname) - len);
-
-   strlcat(card->longname,
-   dev->udev->speed == USB_SPEED_LOW ? ", low speed" :
-   dev->udev->speed == USB_SPEED_FULL ? ", full speed" :
-  ", high speed",
-   sizeof(card->longname));
-
-   rc = snd_tm6000_pcm(chip, 0, "tm6000 Digital");
+   spin_lock_init(&chip->reg_lock);
+   rc = snd_pcm_new(card, "TM6000 Audio", 0, 0, 1

Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode

[Jean-Francois Moine]

On Sat, 29 May 2010 21:32:07 +0200
Ondrej Zary  wrote:

> The Color Space/Compression reported by the driver is only one: RGB 24
> The driver also uses these files which may (or may not) be related to
> used compression: iyuv_32.dll, msh263.drv, msyuv.dll, tsbyuv.dll
> In standalone mode, the camera records video in MJPEG format.

Hello Ondrej,

Bad news, the images are compressed by an unknown algorithm (unknown
from Linux point of vue). The decompression function could be found in
some part of the ms-win driver, but:
- first, I have no time to search and disassemble this function,
- then, I did have this problem with an other webcam (17a1:0118), and
  after searching for a long time, nobody could find the function, and
  the driver is in stand-by since 2 years,
- eventually, is this legal?

All I can do is to code the driver and let you or anyone find the
decompression function...

Best regards.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Idea of a v4l -> fb interface driver

[Dave Airlie]

On Sat, May 29, 2010 at 6:06 AM, Ville Syrjälä  wrote:
> On Fri, May 28, 2010 at 03:41:46PM -0400, Alex Deucher wrote:
>> On Fri, May 28, 2010 at 3:15 PM, Florian Tobias Schandinat
>> > If he wants different (independent) content on each output, just provide
>> > multiple /dev/fbX devices. I admit that we could use a controlling 
>> > interface
>> > here that decides which user (application) might draw at a time to the
>> > interface which they currently only do if they are the active VT.
>> > If you want 2 or more outputs to be merged as one just configure this in 
>> > the
>> > driver.
>> > The only thing that is impossible to do in fbdev is controlling 2 or more
>> > independent display outputs that access the same buffer. But that's not an
>> > issue I think.
>> > The things above only could use a unification of how to set them up on
>> > module load time (as only limited runtime changes are permited given that 
>> > we
>> > must always be able to support a mode that we once entered during runtime).
>> >
>>
>> What about changing outputs on the fly (turn off VGA, turn on DVI,
>> switch between multi-head and single-head, etc) or encoders shared
>> between multiple connectors (think a single dac shared between a VGA
>> and a TV port); how do you expose them easily as separate fbdevs?
>> Lots of stuff is doable with fbdev, but it's nicer with kms.
>
> But actually getting your data onto the screen is a lot easier with
> fbdev. There's no standard API in drm to actually allocate the
> framebuffer and manipulate it. You always need a user space driver
> to go along with the kernel bits.
>
> I'm not saying fbdev is better than drm/kms but at least it can be
> used to write simple applications that work across different
> hardware. Perhaps that's something that should be addressed in the
> drm API.
>

http://www.mail-archive.com/dri-de...@lists.sourceforge.net/msg48461.html

I started writing a "dumb" API for KMS, it got stuck on whether to
expose cursors or not, I must dig out the branch.

It basically was a create + map API. I'll see if I can get it finished off.

The main reason we avoided a fully generic interface is there isn't
really a generic way to abstract acceleration on a modern GPU, and
buffer allocation on most modern GPUs doesn't want a linear simple
buffer. We felt doing a compromised generic interface would lead
people down the wrong path into believing they could easily move from
the "dumb" interface to a real accelerated one.

There is a userspace library called libkms that abstracts this stuff,
but I'd like to just have the kernel do it.

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

PROBLEM: 2.6.34-rc7 kernel panics "BUG: unable to handle kernel NULL pointer dereference at (null)" while channel scan running

[Silamael]

Hi there,

When i try to scan for available DBV-S channels kernel panics:
BUG: unable to handle kernel NULL pointer dereference at (null)

I'm trying to setup a TV box. Contains an Intel Atom N270 CPU, 2GB RAM,
1 TB SATA Hard-Drive. Mainboard is a MSI IM-945GSE Mini-ITX motherboard.
The DVB-S card is a WinTV Nexus-S Rev 2.3 card.
Kernel is a custom built kernel:
Linux version 2.6.34-rc7 (r...@filmdose) (gcc version 4.4.4 (Debian
4.4.4-1) ) #7 SMP Fri May 21 18:06:19 CEST 2010

Channel scan starts fine, finds some channels and after a random
duration it crashes. I already tried starting the kernel with nosmp,
noapic, and noacpi options but that does not change anything.

Kernel trace:
---
[  773.280361] IP: [] saa7146_buffer_next+0x5e/0x1ed [saa7146_vv]
[  773.280361] *pde = 
[  773.280361] Oops:  [#1] SMP
[  773.280361] last sysfs file: /sys/module/nfsd/initstate
[  773.280361] Modules linked in: nfsd exportfs nfs lockd nfs_acl
auth_rpcgss sunrpc f71882fg coretemp loop lnbp21 stv0299 dvb_ttpci
snd_hda_codec_realtek dvb_core saa7146_vv videodev v4l1_compat
snd_hda_intel saa7146 snd_hda_codec videobuf_dma_sg snd_hwdep
videobuf_core snd_pcm i2c_i801 ttpci_eeprom psmouse snd_timer intel_agp
evdev pcspkr snd i2c_core serio_raw agpgart video processor rng_core
soundcore button output snd_page_alloc usb_storage uhci_hcd ehci_hcd
thermal sd_mod crc_t10dif thermal_sys usbcore nls_base e1000e [last
unloaded: scsi_wait_scan]
[  773.280361]
[  773.280361] Pid: 0, comm: swapper Not tainted 2.6.34-rc7 #7
A9830IMS/A9830IMS
[  773.280361] EIP: 0060:[] EFLAGS: 00010246 CPU: 0
[  773.280361] EIP is at saa7146_buffer_next+0x5e/0x1ed [saa7146_vv]
[  773.280361] EAX: f68b3008 EBX: f733d900 ECX: 0001 EDX: 0002
[  773.280361] ESI: ffd4 EDI: f68b3000 EBP:  ESP: c135fefc
[  773.280361]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  773.280361] Process swapper (pid: 0, ti=c135e000 task=c138cb60
task.ti=c135e000)
[  773.280361] Stack:
[  773.280361]  f68b3000 f733d900 c13640bc 000a f825e5f6 f733d900
fff7fbf7 f825a759
[  773.280361] <0> f733d900  f812bdfc fff7fbf7 f6a1e240 
c106793a 
[  773.280361] <0>  c1364080 000a c13640bc c135ff80 c1069072
000a 000a
[  773.280361] Call Trace:
[  773.280361]  [] ? vbi_irq_done+0x99/0x9f [saa7146_vv]
[  773.280361]  [] ? vv_callback+0x10f/0x112 [saa7146_vv]
[  773.280361]  [] ? interrupt_hw+0x9f/0x1a8 [saa7146]
[  773.280361]  [] ? handle_IRQ_event+0x49/0xe7
[  773.280361]  [] ? handle_level_irq+0x55/0x9e
[  773.280361]  [] ? handle_irq+0x17/0x1c
[  773.280361]  [] ? do_IRQ+0x38/0x8e
[  773.280361]  [] ? common_interrupt+0x30/0x38
[  773.280361]  [] ? mwait_idle+0x59/0x5e
[  773.280361]  [] ? cpu_idle+0x91/0xaa
[  773.280361]  [] ? start_kernel+0x31c/0x321
[  773.280361] Code: 50 fc 25 f8 e8 9d 0e 01 c9 83 c4 1c 8b 43 44 89 c2
c1 fa 08 38 c2 75 04 0f 0b eb fe 8b 77 08 8d 47 08 39 c6 74 6b 83 ee 2c
31 ed <8b> 4e 2c 8b 56 30 89 51 04 89 0a c7 46 2c 00 01 10 00 c7 46 30
[  773.280361] EIP: [] saa7146_buffer_next+0x5e/0x1ed
[saa7146_vv] SS:ESP 0068:c135fefc
[  773.280361] CR2: 
[  773.985900] ---[ end trace ec43c18100749f7e ]---
[  773.999765] Kernel panic - not syncing: Fatal exception in interrupt
[  774.018832] Pid: 0, comm: swapper Tainted: G  D2.6.34-rc7 #7
[  774.037908] Call Trace:
[  774.045272]  [] ? panic+0x37/0xa8
[  774.057844]  [] ? oops_end+0x88/0x93
[  774.071195]  [] ? no_context+0x10d/0x116
[  774.085581]  [] ? do_page_fault+0x0/0x242
[  774.100232]  [] ? bad_area_nosemaphore+0xa/0xc
[  774.116194]  [] ? error_code+0x73/0x78
[  774.130077]  [] ? saa7146_buffer_next+0x5e/0x1ed [saa7146_vv]
[  774.149941]  [] ? vbi_irq_done+0x99/0x9f [saa7146_vv]
[  774.167718]  [] ? vv_callback+0x10f/0x112 [saa7146_vv]
[  774.185762]  [] ? interrupt_hw+0x9f/0x1a8 [saa7146]
[  774.203023]  [] ? handle_IRQ_event+0x49/0xe7
[  774.218459]  [] ? handle_level_irq+0x55/0x9e
[  774.233890]  [] ? handle_irq+0x17/0x1c
[  774.247758]  [] ? do_IRQ+0x38/0x8e
[  774.260590]  [] ? common_interrupt+0x30/0x38
[  774.276023]  [] ? mwait_idle+0x59/0x5e
[  774.289890]  [] ? cpu_idle+0x91/0xaa
[  774.303243]  [] ? start_kernel+0x31c/0x321

I can easily reproduce this panic using following command:
scan -v /usr/share/dvb/dvb-s/Astra-19.2E

Environment:

scripts/ver_linux output:
Linux filmdose 2.6.34-rc7 #7 SMP Fri May 21 18:06:19 CEST 2010 i686
GNU/Linux

Gnu C  4.4.4
Gnu make   3.81
binutils   2.20.1
util-linux scripts/ver_linux: 23: fdformat: not found
mount  support
module-init-tools  found
Linux C Library2.10.2
Dynamic linker (ldd)   2.10.2
Procps 3.2.8
Kbd1.15.1
Sh-utils   8.5
Modules Loaded nfsd exportfs nfs lockd nfs_acl auth_rpcgss
sunrpc f71882fg coret

Re: [PATCH v3 4/4] V4L2: WL1273 FM Radio: Controls for the FM radio.

[Hans Verkuil]

On Monday 24 May 2010 14:21:43 Matti J. Aaltonen wrote:
> This file implements V4L2 controls for using the Texas Instruments
> WL1273 FM Radio.
> 
> Signed-off-by: Matti J. Aaltonen 
> ---
>  drivers/media/radio/Kconfig|   15 +
>  drivers/media/radio/Makefile   |1 +
>  drivers/media/radio/radio-wl1273.c | 1876 
> 
>  3 files changed, 1892 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/media/radio/radio-wl1273.c
> 
> diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
> index 83567b8..209fd37 100644
> --- a/drivers/media/radio/Kconfig
> +++ b/drivers/media/radio/Kconfig
> @@ -452,4 +452,19 @@ config RADIO_TIMBERDALE
> found behind the Timberdale FPGA on the Russellville board.
> Enabling this driver will automatically select the DSP and tuner.
>  
> +config RADIO_WL1273
> + tristate "Texas Instruments WL1273 I2C FM Radio"
> +depends on I2C && VIDEO_V4L2 && SND
> + select FW_LOADER
> + ---help---
> +   Choose Y here if you have this FM radio chip.
> +
> +   In order to control your radio card, you will need to use programs
> +   that are compatible with the Video For Linux 2 API.  Information on
> +   this API and pointers to "v4l2" programs may be found at
> +   .
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called radio-wl1273.
> +
>  endif # RADIO_ADAPTERS
> diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
> index f615583..d297074 100644
> --- a/drivers/media/radio/Makefile
> +++ b/drivers/media/radio/Makefile
> @@ -26,5 +26,6 @@ obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
>  obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o
>  obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
>  obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o
> +obj-$(CONFIG_RADIO_WL1273) += radio-wl1273.o
>  
>  EXTRA_CFLAGS += -Isound
> diff --git a/drivers/media/radio/radio-wl1273.c 
> b/drivers/media/radio/radio-wl1273.c
> new file mode 100644
> index 000..f19b100
> --- /dev/null
> +++ b/drivers/media/radio/radio-wl1273.c
> @@ -0,0 +1,1876 @@
> +/*
> + * Driver for the Texas Instruments WL1273 FM radio.
> + *
> + * Copyright (C) Nokia Corporation
> + * Author: Matti J. Aaltonen 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +
> +#undef DEBUG
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRIVER_DESC "Wl1273 FM Radio - V4L2"
> +
> +#define WL1273_POWER_SET_OFF 0
> +#define WL1273_POWER_SET_FM  (1 << 0)
> +#define WL1273_POWER_SET_RDS (1 << 1)
> +#define WL1273_POWER_SET_RETENTION   (1 << 4)
> +
> +#define WL1273_PUPD_SET_OFF  0x00
> +#define WL1273_PUPD_SET_ON   0x01
> +#define WL1273_PUPD_SET_RETENTION0x10
> +
> +#define WL1273_FREQ_MULT (1 / 625)
> +#define WL1273_INV_FREQ_MULT (625 / 1)
> +/*
> + * static unsigned char radio_band - Band
> + *
> + * The bands are 0=Japan, 1=USA-Europe. USA-Europe is the default.
> + */
> +static unsigned char radio_band = 1;
> +module_param(radio_band, byte, 0);
> +MODULE_PARM_DESC(radio_band, "Band: 0=Japan, 1=USA-Europe*");
> +
> +/*
> + * static int radio_nr - The number of the radio device
> + *
> + * The default is 0.
> + */
> +static int radio_nr = -1;
> +module_param(radio_nr, int, 0);
> +MODULE_PARM_DESC(radio_nr, "Radio Nr");
> +
> +struct wl1273_device {
> + struct v4l2_device v4l2dev;
> + struct video_device videodev;
> + struct device *dev;
> + struct wl1273_core *core;
> + bool rds_on;
> +};
> +
> +static int wl1273_fm_set_tx_freq(struct wl1273_core *core, unsigned int freq)
> +{
> + int r = 0;
> +
> + if (freq < core->bands[core->band].bottom_frequency) {
> + dev_err(&core->i2c_dev->dev,
> + "Frequency out of range: %d < %d\n",
> + freq, core->bands[core->band].bottom_frequency);
> + return -EDOM;
> + }
> +
> + if (freq > core->bands[core->band].top_frequency) {
> + dev_err(&core->i2c_dev->dev,
> + "Frequency out of range: %d > %d\n",
> + freq, core->bands[core->band].top_frequency);
> + return -EDOM;
> + }

I understood that the band

Re: [PATCH v3 2/4] MFD: WL1273 FM Radio: MFD driver for the FM radio.

[Hans Verkuil]

On Monday 24 May 2010 14:21:41 Matti J. Aaltonen wrote:
> This is a parent driver for two child drivers: the V4L2 driver and
> the ALSA codec driver. The MFD part provides the I2C communication
> to the device and a couple of functions that are called from both
> children.
> 
> Signed-off-by: Matti J. Aaltonen 
> ---
>  drivers/mfd/Kconfig |6 +
>  drivers/mfd/Makefile|2 +
>  drivers/mfd/wl1273-core.c   |  606 
> +++
>  include/linux/mfd/wl1273-core.h |  326 +
>  4 files changed, 940 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/mfd/wl1273-core.c
>  create mode 100644 include/linux/mfd/wl1273-core.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 413576a..5998a94 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -135,6 +135,12 @@ config TWL4030_CODEC
>   select MFD_CORE
>   default n
>  
> +config WL1273_CORE
> + bool
> + depends on I2C
> + select MFD_CORE
> + default n
> +
>  config MFD_TMIO
>   bool
>   default n
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 78295d6..46e611d 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -30,6 +30,8 @@ obj-$(CONFIG_TWL4030_CORE)  += twl-core.o twl4030-irq.o 
> twl6030-irq.o
>  obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
>  obj-$(CONFIG_TWL4030_CODEC)  += twl4030-codec.o
>  
> +obj-$(CONFIG_WL1273_CORE)+= wl1273-core.o
> +
>  obj-$(CONFIG_MFD_MC13783)+= mc13783-core.o
>  
>  obj-$(CONFIG_MFD_CORE)   += mfd-core.o
> diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
> new file mode 100644
> index 000..7e02c36
> --- /dev/null
> +++ b/drivers/mfd/wl1273-core.c
> @@ -0,0 +1,606 @@
> +/*
> + * MFD driver for wl1273 FM radio and audio codec submodules.
> + *
> + * Author:   Matti Aaltonen 
> + *
> + * Copyright:   (C) 2010 Nokia Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> + * 02110-1301 USA
> + *
> + */
> +
> +#undef DEBUG
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRIVER_DESC "WL1273 FM Radio Core"
> +
> +#define WL1273_IRQ_MASK   (WL1273_FR_EVENT   |   \
> +   WL1273_POW_ENB_EVENT)
> +
> +static const struct band_info bands[] = {
> + /* Japan */
> + {
> + .bottom_frequency   = 76000,
> + .top_frequency  = 9,
> + .band   = 0,
> + },
> + /* USA & Europe */
> + {
> + .bottom_frequency   = 87500,
> + .top_frequency  = 108000,
> + .band   = 1,
> + },
> +};
> +
> +/*
> + * static unsigned char radio_band - Band
> + *
> + * The bands are 0=Japan, 1=USA-Europe. USA-Europe is the default.
> + */
> +static unsigned char radio_band = 1;
> +module_param(radio_band, byte, 0);
> +MODULE_PARM_DESC(radio_band, "Band: 0=Japan, 1=USA-Europe*");
> +
> +/*
> + * static unsigned int rds_buf - the number of RDS buffer blocks used.
> + *
> + * The default number is 100.
> + */
> +static unsigned int rds_buf = 100;
> +module_param(rds_buf, uint, 0);
> +MODULE_PARM_DESC(rds_buf, "RDS buffer entries: *100*");
> +
> +int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value)
> +{
> + struct i2c_client *client = core->i2c_dev;
> + u8 b[2];
> + int r;
> +
> + r = i2c_smbus_read_i2c_block_data(client, reg, 2, b);
> + if (r != 2) {
> + dev_err(&client->dev, "%s: Read: %d fails.\n", __func__, reg);
> + return -EREMOTEIO;
> + }
> +
> + *value = (u16)b[0] << 8 | b[1];
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(wl1273_fm_read_reg);
> +
> +int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param)
> +{
> + struct i2c_client *client = core->i2c_dev;
> + u8 buf[] = { (param >> 8) & 0xff, param & 0xff };
> + int r;
> +
> + r = i2c_smbus_write_i2c_block_data(client, cmd, 2, buf);
> + if (r) {
> + dev_err(&client->dev, "%s: Cmd: %d fails.\n", __func__, cmd);
> + return r;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(wl1273_fm_write_cmd);
> +
> +int wl1273_fm_write_da

Re: [PATCH v3 1/4] V4L2: Add features to the interface.

[Hans Verkuil]

On Monday 24 May 2010 14:21:40 Matti J. Aaltonen wrote:
> Add fields spacing, level_min, level_max and level to struct 
> v4l2_hw_freq_seek.
> The level is used for determining which channels are considered receivable
> during HW scan.

As mentioned I don't think the level stuff should be added at the moment.
The spacing field is no problem, but don't forget to update the V4L2 spec as
well. Also document there what should happen if spacing == 0 (which is the
case for existing apps). It basically boils down to the fact that the driver
uses the spacing as a hint only and will adjust it to whatever the hardware
supports.

> Add  VIDIOC_G_HW_FREQ_SEEK to IOCTL codes. This is used for getting the 
> minimum and
> maximum values for the level field in the v4l2_hw_freq_seek struct.

Without level support we can drop this for now.

Regards,

Hans

> 
> Signed-off-by: Matti J. Aaltonen 
> ---
>  include/linux/videodev2.h  |6 +-
>  include/media/v4l2-ioctl.h |2 ++
>  2 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 418dacf..7a81a9c 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -1377,7 +1377,11 @@ struct v4l2_hw_freq_seek {
>   enum v4l2_tuner_type  type;
>   __u32 seek_upward;
>   __u32 wrap_around;
> - __u32 reserved[8];
> + __u32 spacing;
> + __s32 level_min;
> + __s32 level_max;
> + __s32 level;
> + __u32 reserved[4];
>  };
>  
>  /*
> diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
> index e8ba0f2..828cf13 100644
> --- a/include/media/v4l2-ioctl.h
> +++ b/include/media/v4l2-ioctl.h
> @@ -220,6 +220,8 @@ struct v4l2_ioctl_ops {
>   /* Log status ioctl */
>   int (*vidioc_log_status)   (struct file *file, void *fh);
>  
> + int (*vidioc_g_hw_freq_seek)   (struct file *file, void *fh,
> + struct v4l2_hw_freq_seek *a);
>   int (*vidioc_s_hw_freq_seek)   (struct file *file, void *fh,
>   struct v4l2_hw_freq_seek *a);
>  
> 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line "unsubscribe 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 v3 0/4] WL1273 FM Radio Driver

[Hans Verkuil]

On Monday 24 May 2010 14:21:39 Matti J. Aaltonen wrote:
> Hello again.
> 
> And thanks for the comments.
> 
> It the first patch I'm kind of suggesting a couple of additions to the
> general interface: signal level stuff in the hw seek struct and then a 
> function / IOCTL for asking for minimum and maximum for the level.
> 
> There are many changes I'll follow by commenting to Hans's comments:
> 
> >> 1. WL1273_CID_FM_REGION for setting the region. This may not be a good
> >> candidate for standardization as the region control shouldn't exist 
> >> in the kernel in general...
> >
> >Is this region relevant for receive, transmit or both?
> 
> Region is relevant for receiving only. Now I've changes the naming to "band"
> because TI uses that in their latest document version.

Based on this article: http://en.wikipedia.org/wiki/FM_broadcasting, there
seem to be only three bands for FM radio in practice: 87.5-108, 76-90 (Japan)
and 65-74 (former Soviet republics, some former eastern bloc countries).

So this should be a standard control. Since the latter band is being phased
out I think a menu control with just the two other bands is sufficient.

And I also think this should be a control of a new FM_RX class.

I know, that's not what I said last time. So sue me :-)

BTW: don't forget to update the V4L2 spec when adding new controls!
 
> >> 2. WL1273_CID_FM_SEEK_SPACING: defines what resolution is used when 
> >> scanning 
> >> automatically for stations (50KHz, 100KHz or 200KHz). This could be
> >> useful in general. Could this be a field in the v4l2_hw_freq_seek struct?
> >
> >I think this belongs in v4l2_hw_freq_seek.
> 
> I've added spacing to the hw seek struct.
> 
> >> 3. WL1273_CID_FM_RDS_CTRL for turning on and off the RDS reception / 
> >> transmission. To me this seems like a useful standard control...
> >
> >This already exists. You can enable/disable RDS by setting the 
> > V4L2_TUNER_SUB_RDS subchannel bit when calling S_TUNER or S_MODULATOR.
> 
> I did this.
> 
> >> 4. WL1273_CID_SEARCH_LVL for setting the threshold level when detecting 
> >> radio
> >> channels when doing automatic scan. This could be useful for fine tuning
> >> because automatic  scanning seems to be kind of problematic... This could 
> >> also be a field in the v4l2_hw_freq_seek struct?
> >
> >This too seems reasonable to add to v4l2_hw_freq_seek. Although what sort of
> >unit this level would have might be tricky. What is the unit for your 
> >hardware?
> 
> I've added this as well. The unit is some kind of dB value: "8 bit signed
> number in 2أ�s complement format Each LSB = 1.5051 dBuV". I also added min
> and max values for the level.

I'm uncertain about this. I wonder if this shouldn't be something that is
hardcoded in the driver. Setting these levels to sensible values is not a
trivial exercise. It is also very much device specific.

I think it is best to do hardcode it now and once we can expose controls
that are sub-device specific (this is being worked on), then we can add
WL1273-specific controls for this.

> 
> 
> >> Could the VIDIOC_S_MODULATOR and VIDIOC_S_TUNER IOCTLs be used for setting
> >> the TX/RX mode?
> >
> >Not entirely sure what you want to achieve here. I gather that the radio is
> >either receiving, transmitting or off? So it can't receive and transmit at 
> >the
> >same time, right?
> 
> Yes the radio can only transmit or receive at a time. And the states are:
> On (RX or TX), Off and Suspended. In the suspended mode that firmware patch
> is kept in the memory and it doesn't need to get uploaded again when operation
> resumes.
> 
> > would expect in that case that calling S_TUNER or S_MODULATOR would switch 
> > it
> > to either receive or transmit mode. S_HW_FREQ_SEEK would of course also 
> > switch
> > it to receive mode.
> 
> I added this...
> 
> > There isn't anything to turn off the radio at the moment. Perhaps you can 
> > just
> > automatically turn it off if nobody has the radio device or alsa device 
> > open?
> 
> Yes that can be done. Also volume control could be used. But also there's
> nothing to put the radio to stand-by (suspension).

Is there a difference in power consumption between the 'off' and 'suspend' state
of the device? I assume that 'off' has the lowest power consumption.

In that case I would have the driver go to suspend when no one has opened the
radioX device. And if the driver is asked to go to suspend (that's the linux
suspend state), then the driver can turn off the radio and on resume it will
reload the firmware.

Does that sound reasonable?
  
> >> Now there already exits a class for fm transmitters: V4L2_CTRL_CLASS_FM_TX.
> >> Should a corresponding class be created for FM tuners?
> >
> >I'm not sure that we need any. I think the only control that we need is to 
> >set
> >the region, and I think that is more appropriate as a private (?) user 
> >control
> >since it is definitely something that users should be easily able to change.
> 
> OK, that's fine by me
> 
> >

Re: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?

[Davor Emard]

> hello, i can't comment on your questions about the Wiki, but i made
> the driver for TBS 6980 and i can ensure you that the driver will be
> released as open-source under GPL as soon as i have permission to do
> that, but compared to other cards at least even at the moment you can

Does this card need some firmware (and if it needs is it open or closed 
source)

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

Version 2: Tentative agenda for Helsinki mini-summit

[Hans Verkuil]

Hi all,

This is the second version of a tentative agenda for the Helsinki mini-summit
on June 14-16.

Please reply to this thread if you have comments or want to add topics.

If you want to attend the summit then contact Sakari Ailus
(sakari.ai...@maxwell.research.nokia.com). We are very full already (over 20
attendees), so I'm not sure if there is still room left.

The overall layout of the summit is to use the first day to go through all
topics and either come to a conclusion quickly for the 'simple' topics, or
discuss enough so that everyone understands the problem for the more complex
issues.

The second day will be used for in-depth discussions on those complex topics
and on the third day we will go through all topics again and translate the
discussions into something concrete like a time-line, action items, etc.

We have a lot to discuss, so we almost certainly have to split the second day
into two tracks, each discussing different topics. If we do split up, then one
track will touch on the videobuf-related topics and the other on the remaining
topics.

The first day will also feature a few short presentations on various topics.
Presentations shouldn't be longer than, say, 10 minutes tops. Please keep them
as short and to the point as possible. These presentations are meant to get
everyone up to speed quickly. Most of us have an extensive background in video
hardware and the v4l subsystem, so you don't need to spend time explaining
things.

After each topic I've put the names of the main developers active in that area.
If you see your name, then make sure you know the status of that topic so you
can explain it to everyone else. If I think it warrants a presentation, then I
will mention that. Of course, if you disagree, or want/don't want to do a
presentation then just say so. It's a tentative agenda only.

The topics below are in no particular order except for the first one. I am
very pleased that Qualcomm has joined this project so I think it would be
nice to start the meeting off with a presentation on their HW architecture.

1) Presentation on the Qualcomm video hw architecture. Most of us have no
   experience with Qualcomm hardware, so I've asked Jeff Zhong to give a short
   overview of their video hardware.

2) Removal of V4L1: status of driver conversion in the kernel, status of
   moving v4l1->v4l2 conversion into libv4l1. What needs to be done, when
   will it be done and who will do it. Driver conversion: Hans Verkuil,
   libv4l1 conversion: Hans de Goede.

3) videobuf/videobuf2: what are the shortcomings, what are the requirements for
   a 'proper' videobuf implementation, can the existing videobuf be fixed or do
   we need a videobuf2. If the latter, what would be needed to convert existing
   drivers over to a videobuf2. Related topics (custom/pluggable allocators,
   out-of-order buffer dequeuing and per-buffer wait queues) will also be part
   of this topic.
   Laurent Pinchart and Pawel Osciak with presentations.

4) Multi-planar support. Pawel Osciak.

5) Media Controller Roadmap. Laurent Pinchart has a presentation.

6) TO DO list regarding V4L2 core framework including the new control framework.
   Hans Verkuil. Will be a presentation.

7) Status of the Texas Instruments drivers: omapX (Laurent Pinchart/Hiremath 
Vaibhav)
   and DM (Sergio Aguirre). Probably should be a short presentation.

8) soc-camera status. Particularly with regards to the remaining soc-camera
   dependencies in sensor drivers. Guennadi Liakhovetski.

9) Driver compliance. We need a framework for V4L2 driver compliance. Hans
   Verkuil.

10) Discuss list of 'reference' programs to test against. Mauro Carvalho Chehab.

11) Adopting old V4L1 programs and converting to V4L2. Hans de Goede?

12) Status of intel drivers. Xiaolin Zhang.

13) Remote Controllers. Presentation by Mauro Carvalho Chehab.

14) V4L2 video output vs. framebuffer. Guennadi Liakhovetski.

15) A processing plugin API for libv4l. Hans de Goede.
See: http://www.mail-archive.com/linux-media@vger.kernel.org/msg18993.html

It is my understanding that we will also have X11 and gstreamer experts on hand.
Topics relating to that are welcome.

During the memory handling brainstorming session earlier this year we also
touched on creating some sort of a generic buffer model allowing for easy
exchange between v4l buffers, framebuffers, texture buffers, etc. It is my
opinion that we should not discuss this in Helsinki. The list of topics is
already quite long and I think it is too early to start working on that. We
probably need another brainstorming session first in order to come up with
a reasonable proposal.

Comments? Topics I missed?

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line "unsubscribe 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: Tentative agenda for Helsinki mini-summit

[Hans Verkuil]

On Sunday 30 May 2010 09:59:59 Hans Verkuil wrote:
> On Wednesday 26 May 2010 17:46:16 Pawel Osciak wrote:
> > Hi Hans,
> > 
> > thank you for your work on this!
> > 
> > >Hans Verkuil wrote:
> > 
> > >3) videobuf/videobuf2: what are the shortcomings, what are the requirements
> > >for a 'proper' videobuf implementation, can the existing videobuf be fixed 
> > >or
> > >do we need a videobuf2. If the latter, what would be needed to convert
> > >existing drivers over to a videobuf2. Laurent Pinchart and Pawel Osciak. 
> > >This I'm
> > >sure requires a presentation.
> > 
> > As Laurent volunteered to prepare the "videobuf problems" presentation, I 
> > will
> > hopefully make it before the summit with an initial (general) design for 
> > the new
> > videobuf2 - requirements, API, things like that. So I'm thinking about a 
> > short
> > presentation on this. What do you think?
> 
> That's OK.
> 
> > >4) Multi-planar support. Pawel Osciak.
> > 
> > Yes. Will provide a short status update. Is a presentation of the whole 
> > concept
> > required? If so, I can conduct one as well.
> 
> I don't think a presentation is required.
> 
> > >9) Driver compliance. We need a framework for V4L2 driver compliance. Hans
> > >   Verkuil.
> > 
> > I am very interested in this!
> > 
> > >10) Discuss list of 'reference' programs to test against. Mauro?
> > >
> > 
> > Ditto.
> > 
> > >During the memory handling brainstorming session earlier this year we also
> > >touched on creating some sort of a generic buffer model allowing for easy
> > >exchange between v4l buffers, framebuffers, texture buffers, etc. It is my
> > >opinion that we should not discuss this in Helsinki. The list of topics is
> > >already quite long and I think it is too early to start working on that. We
> > >probably need another brainstorming session first in order to come up with
> > >a reasonable proposal.
> > 
> > I agree.
> > 
> > >Comments? Topics I missed?
> > 
> > It would be great to touch on the following subjects if we find some time
> > (and if people would be interested, I had little feedback on the list):
> > 
> > 1) Custom/pluggable allocators
> > As most of us are aware there are important problems with memory allocation
> > in videobuf that most of us have already faced.
> > For those unfamiliar with the topic, please see my recent RFC:
> > http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/19581
> > 
> > I'd like to provide a design of an API:
> > * for videobuf that would allow drivers to plug-in their own memory 
> > allocation
> >   routines,
> > * future-proof enough to be usable with videobuf2 as well.
> > 
> > Hoping for a (short-ish) discussion on that.
> > 
> > 2) Out-of-order buffer dequeuing and per-buffer wait queues in videobuf. 
> > See:
> > RFC: http://www.mail-archive.com/linux-media@vger.kernel.org/msg17319.html
> > Patches: 
> > http://www.mail-archive.com/linux-media@vger.kernel.org/msg17886.html
> 
> These topics should all be folded into the videobuf topic. Due to the 
> importance
> of videobuf I expect that a considerable amount of time will be spend on this.
> 
> On the first day I will probably put this topic last on the list and try to 
> get
> through the other topics fairly quickly so that we hopefully have 2-3 hours 
> for
> this topic.
> 
> What makes this a difficult topic is that you have this list of relatively
> small sub-topics (like allocators, out-of-order dequeuing, videobuf 
> improvements,
> caching, etc. etc.), but it is not always easy to see the big picture: i.e.
> what is the goal that you are working towards and what is the purpose for 
> these
> smaller sub-topics in the bigger picture.
> 
> I know that was difficult for me in the beginning, so I think it will probably
> help people if you also provide the big picture and the context within which 
> to
> place these sub-topics. The 'big picture' also includes the memory pool idea.
> Not that we will discuss this in Helsinki, but people should be aware that it
> will be part of a next phase.
> 
> BTW, the videobuf presentation(s) can be longer than 10 minutes if needed.
> This is the 'big topic' of the summit, so we will have more time for this.

I just realized this is the second time I replied to your post :-)

Still, my comments at the end of my second reply are hopefully still useful.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line "unsubscribe 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: Tentative agenda for Helsinki mini-summit

[Hans Verkuil]

On Sunday 23 May 2010 20:02:59 Guennadi Liakhovetski wrote:
> On Sun, 23 May 2010, Hans Verkuil wrote:
> 
> > Hi all,
> > 
> > This is a tentative agenda for the Helsinki mini-summit on June 14-16.
> > 
> > Please reply to this thread if you have comments or want to add topics.
> 
> [snip]
> 
> > 8) soc-camera status. Particularly with regards to the remaining soc-camera
> >dependencies in sensor drivers. Guennadi Liakhovetski.
> 
> Don't think a formal presentation is needed, but I can tell a couple of 
> words to clarify the current status a bit.
> 
> > Comments? Topics I missed?
> 
> No idea whether this is a worthy and suitable topic for this meeting, but:
> 
> V4L(2) video output vs. framebuffer.
> 
> Problem: Currently the standard way to provide graphical output on various 
> (embedded) displays like LCDs is to use a framebuffer driver. The 
> interface is well supported and widely adopted in the user-space, many 
> applications, including the X-server, various libraries like directfb, 
> gstreamer, mplayer, etc. In the kernel space, however, the subsystem has a 
> number of problems. It is unmaintained. The infrastructure is not being 
> further developed, every specific hardware driver is being supported by 
> the respective architecture community. But as video output hardware 
> evolves, more complex displays and buses appear and have to be supported, 
> the subsystem shows its aging. For example, there is currently no way to 
> write reusable across multiple platforms display drivers.
> 
> OTOH V4L2 has a standard vodeo output driver support, it is not very 
> widely used, in the userspace I know only of gstreamer, that somehow 
> supports video-output v4l2 devices in latest versions. But, being a part 
> of the v4l2 subsystem, these drivers already now can take a full advantage 
> of all v4l2 APIs, including the v4l2-subdev API for the driver reuse.
> 
> So, how can we help graphics driver developers on the one hand by 
> providing them with a capable driver framework (v4l2) and on the other 
> hand by simplifying the task of interfacing to the user-space?
> 
> How about a v4l2-output - fbdev translation layer? You write a v4l2-output 
> driver and get a framebuffer device free of charge... TBH, I haven't given 
> this too much of a thought, but so far I don't see anything that would 
> make this impossible in principle. The video buffer management is quite 
> different between the two systems, but maybe we can teach video-output 
> drivers to work with just one buffer too? Anyway, feel free to tell me why 
> this is an absolutely impossible / impractical idea;)

I've added this to the agenda. I think this probably doesn't need a presentation
but will be more an open discussion.

I also think this is a very interesting topic to discuss more in-depth on
Tuesday.

Sakari, does Nokia have any framebuffer experts that might be interested in
discussing this as well on Tuesday?

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line "unsubscribe 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: Tentative agenda for Helsinki mini-summit

[Hans Verkuil]

On Wednesday 26 May 2010 17:46:16 Pawel Osciak wrote:
> Hi Hans,
> 
> thank you for your work on this!
> 
> >Hans Verkuil wrote:
> 
> >3) videobuf/videobuf2: what are the shortcomings, what are the requirements
> >for a 'proper' videobuf implementation, can the existing videobuf be fixed or
> >do we need a videobuf2. If the latter, what would be needed to convert
> >existing drivers over to a videobuf2. Laurent Pinchart and Pawel Osciak. 
> >This I'm
> >sure requires a presentation.
> 
> As Laurent volunteered to prepare the "videobuf problems" presentation, I will
> hopefully make it before the summit with an initial (general) design for the 
> new
> videobuf2 - requirements, API, things like that. So I'm thinking about a short
> presentation on this. What do you think?

That's OK.

> >4) Multi-planar support. Pawel Osciak.
> 
> Yes. Will provide a short status update. Is a presentation of the whole 
> concept
> required? If so, I can conduct one as well.

I don't think a presentation is required.

> >9) Driver compliance. We need a framework for V4L2 driver compliance. Hans
> >   Verkuil.
> 
> I am very interested in this!
> 
> >10) Discuss list of 'reference' programs to test against. Mauro?
> >
> 
> Ditto.
> 
> >During the memory handling brainstorming session earlier this year we also
> >touched on creating some sort of a generic buffer model allowing for easy
> >exchange between v4l buffers, framebuffers, texture buffers, etc. It is my
> >opinion that we should not discuss this in Helsinki. The list of topics is
> >already quite long and I think it is too early to start working on that. We
> >probably need another brainstorming session first in order to come up with
> >a reasonable proposal.
> 
> I agree.
> 
> >Comments? Topics I missed?
> 
> It would be great to touch on the following subjects if we find some time
> (and if people would be interested, I had little feedback on the list):
> 
> 1) Custom/pluggable allocators
> As most of us are aware there are important problems with memory allocation
> in videobuf that most of us have already faced.
> For those unfamiliar with the topic, please see my recent RFC:
> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/19581
> 
> I'd like to provide a design of an API:
> * for videobuf that would allow drivers to plug-in their own memory allocation
>   routines,
> * future-proof enough to be usable with videobuf2 as well.
> 
> Hoping for a (short-ish) discussion on that.
> 
> 2) Out-of-order buffer dequeuing and per-buffer wait queues in videobuf. See:
> RFC: http://www.mail-archive.com/linux-media@vger.kernel.org/msg17319.html
> Patches: http://www.mail-archive.com/linux-media@vger.kernel.org/msg17886.html

These topics should all be folded into the videobuf topic. Due to the importance
of videobuf I expect that a considerable amount of time will be spend on this.

On the first day I will probably put this topic last on the list and try to get
through the other topics fairly quickly so that we hopefully have 2-3 hours for
this topic.

What makes this a difficult topic is that you have this list of relatively
small sub-topics (like allocators, out-of-order dequeuing, videobuf 
improvements,
caching, etc. etc.), but it is not always easy to see the big picture: i.e.
what is the goal that you are working towards and what is the purpose for these
smaller sub-topics in the bigger picture.

I know that was difficult for me in the beginning, so I think it will probably
help people if you also provide the big picture and the context within which to
place these sub-topics. The 'big picture' also includes the memory pool idea.
Not that we will discuss this in Helsinki, but people should be aware that it
will be part of a next phase.

BTW, the videobuf presentation(s) can be longer than 10 minutes if needed.
This is the 'big topic' of the summit, so we will have more time for this.

Regards,

Hans

> 
> 
> Please let me know what you think. Thanks!
> 
> Best regards
> --
> Pawel Osciak
> Linux Platform Group
> Samsung Poland R&D Center
> 
> 
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What ever happened to standardizing signal level?

[Markus Rechberger]

Hi,

A little bit more "ontopic", did anyone get around to read the
signallevel of the tda18721?
I wonder the register does not return any signallevel as indicated in
the specifications.

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

Re: What ever happened to standardizing signal level?

[Hans Verkuil]

On Sunday 30 May 2010 09:07:46 VDR User wrote:
> On Sat, May 29, 2010 at 2:09 AM, Mike Booth  
> wrote:
> > i think someone is too concerned about being precisely accurate. So much so
> > that no-one can see the woods for the trees any more.
> >
> > Its not important to me that accuracy is spot on. I only want to know that
> > when tuning the dish I'm getting \better or worse.
> 
> I tend to agree with this.  Ultimately what's important is not
> necessarily that the readings are 100% accurate, but rather simply put
> into some kind of universal scale that provides useful output to the
> user.  Many users were happy to see some activity addressing this
> issue and unfortunately it seems to have stalled out but I'm not sure
> why.  I honestly felt there was enough common ground being discussed
> that we'd have a solution by now.

To the best of my knowledge Mike Krufky intended to work on this but he
clearly no longer has time to do that work.

Mike, can you perhaps explain what you wanted to do? Hopefully someone else
can find the time to implement it.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What ever happened to standardizing signal level?

[VDR User]

On Sat, May 29, 2010 at 2:09 AM, Mike Booth  wrote:
> i think someone is too concerned about being precisely accurate. So much so
> that no-one can see the woods for the trees any more.
>
> Its not important to me that accuracy is spot on. I only want to know that
> when tuning the dish I'm getting \better or worse.

I tend to agree with this.  Ultimately what's important is not
necessarily that the readings are 100% accurate, but rather simply put
into some kind of universal scale that provides useful output to the
user.  Many users were happy to see some activity addressing this
issue and unfortunately it seems to have stalled out but I'm not sure
why.  I honestly felt there was enough common ground being discussed
that we'd have a solution by now.

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

Re: What ever happened to standardizing signal level?

[VDR User]

On Sat, May 29, 2010 at 10:52 PM, hermann pitton
 wrote:
>
...troll spam removed...
>

Hermann, you're a known troll with clearly nothing to contribute to
this thread therefore you're comments are unwelcome.  Your mostly
incoherent rant sounds like the ramblings of somebody who has consumed
too much alcohol, and you're obviously using this mailing list as a
cry for attention.  I'll ask you kindly to stop wasting everyones time
with your moronic nonsense and direct your harassment elsewhere.  I'm
sure you can find something better to do with your time then polluting
this mailing list and making yourself look foolish.

To everyone else, please disregard this post and the imbecile in which
I'm replying to.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html