Reception issue: DViCO Fusion HDTV DVB-T Dual Express
Hi All, I am having reception issues with this particular card, the problem manifests itself with missing video frames and popping sounds on the audio streams. As far as I can tell it only some channels do it, Nine and its multiplexes are the worst for it You can see that TZAP every now and reports some unc/ber: crystal:/usr/share/dvb/dvb-t# tzap -a 0 -c 0 Nine Digital HD using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '0' tuning to 191625000 Hz video pid 0x0200, audio pid 0x status 00 | signal 0b28 | snr | ber | unc 12c8 | status 1e | signal b64c | snr dede | ber | unc 13ce | FE_HAS_LOCK status 1e | signal bb88 | snr cece | ber | unc 1420 | FE_HAS_LOCK status 1e | signal 9b78 | snr e1e1 | ber | unc 1420 | FE_HAS_LOCK status 1e | signal 95a4 | snr e0e0 | ber | unc 1420 | FE_HAS_LOCK status 1e | signal ae4c | snr ecec | ber | unc 1420 | FE_HAS_LOCK status 1e | signal a7b4 | snr e9e9 | ber 0316 | unc 1420 | FE_HAS_LOCK status 1e | signal b7bc | snr d7d7 | ber 0316 | unc 1420 | FE_HAS_LOCK status 1e | signal a988 | snr f2f2 | ber 0316 | unc 1420 | FE_HAS_LOCK status 1e | signal a5a0 | snr f1f1 | ber 0316 | unc 1420 | FE_HAS_LOCK status 1e | signal ad70 | snr e5e5 | ber 0316 | unc 1420 | FE_HAS_LOCK status 1e | signal b358 | snr dfdf | ber 000d | unc 1432 | FE_HAS_LOCK status 1e | signal 9de8 | snr e5e5 | ber 000d | unc 1432 | FE_HAS_LOCK status 1e | signal 9dd0 | snr dada | ber 000d | unc 1432 | FE_HAS_LOCK status 1e | signal ac04 | snr eded | ber 000d | unc 1432 | FE_HAS_LOCK status 1e | signal a340 | snr e9e9 | ber 000d | unc 1432 | FE_HAS_LOCK status 1e | signal a910 | snr e7e7 | ber 01e7 | unc 1432 | FE_HAS_LOCK status 1e | signal aefc | snr e7e7 | ber 01e7 | unc 1432 | FE_HAS_LOCK status 1e | signal 8d34 | snr f6f6 | ber 01e7 | unc 1432 | FE_HAS_LOCK status 1e | signal 10ac | snr f8f8 | ber 01e7 | unc 1432 | FE_HAS_LOCK status 1e | signal 0224 | snr f6f6 | ber 01e7 | unc 1432 | FE_HAS_LOCK status 1e | signal 9b74 | snr ecec | ber | unc 1432 | FE_HAS_LOCK status 1e | signal 24cc | snr f4f4 | ber | unc 1432 | FE_HAS_LOCK status 1e | signal a2f4 | snr f9f9 | ber | unc 1432 | FE_HAS_LOCK status 1e | signal 9d20 | snr f6f6 | ber | unc 1432 | FE_HAS_LOCK status 1e | signal a7d8 | snr f0f0 | ber | unc 1432 | FE_HAS_LOCK status 1e | signal a74c | snr f4f4 | ber 00a9 | unc 1432 | FE_HAS_LOCK status 1e | signal a0fc | snr f1f1 | ber 00a9 | unc 1432 | FE_HAS_LOCK status 1e | signal a2d4 | snr f1f1 | ber 00a9 | unc 1432 | FE_HAS_LOCK status 1e | signal | snr fafa | ber 00a9 | unc 1432 | FE_HAS_LOCK status 1e | signal a490 | snr e7e7 | ber 00a9 | unc 1432 | FE_HAS_LOCK status 1e | signal | snr fafa | ber | unc 1432 | FE_HAS_LOCK I have 2 other DVB-T cards in my system and they are fine: crystal:/usr/share/dvb/dvb-t# tzap -a 3 -c 0 Nine Digital HD using '/dev/dvb/adapter3/frontend0' and '/dev/dvb/adapter3/demux0' reading channels from file '0' tuning to 191625000 Hz video pid 0x0200, audio pid 0x status 01 | signal b15f | snr | ber | unc | status 1f | signal b27f | snr ebeb | ber | unc | FE_HAS_LOCK status 1f | signal b2ef | snr ebeb | ber | unc | FE_HAS_LOCK status 1f | signal b1af | snr eaea | ber | unc | FE_HAS_LOCK status 1f | signal b23f | snr eaea | ber | unc | FE_HAS_LOCK status 1f | signal b0df | snr ebeb | ber | unc | FE_HAS_LOCK status 1f | signal b2ff | snr ebeb | ber | unc | FE_HAS_LOCK status 1f | signal b27f | snr e9e9 | ber | unc | FE_HAS_LOCK status 1f | signal b20f | snr ebeb | ber | unc | FE_HAS_LOCK status 1f | signal b36f | snr ebeb | ber | unc | FE_HAS_LOCK status 1f | signal b3bf | snr e8e8 | ber | unc | FE_HAS_LOCK status 1f | signal b17f | snr ebeb | ber | unc | FE_HAS_LOCK status 1f | signal b36f | snr eaea | ber | unc | FE_HAS_LOCK status 1f | signal b28f | snr ebeb | ber | unc | FE_HAS_LOCK status 1f | signal b33f | snr ebeb | ber | unc | FE_HAS_LOCK status 1f | signal b30f | snr ebeb | ber | unc | FE_HAS_LOCK status 1f | signal b2ef | snr ebeb | ber | unc | FE_HAS_LOCK status 1f | signal b10f | snr e8e8 | ber | unc | FE_HAS_LOCK status 1f | signal b2df | snr eaea | ber | unc | FE_HAS_LOCK status 1f | signal b30f | snr ebeb | ber | unc | FE_HAS_LOCK status 1f | signal b37f | snr eaea | ber | unc | FE_HAS_LOCK status 1f | signal
Re: [PATCH 11/36] drivers/media: Remove unnecessary casts of private_data
Hi Joe, On Monday 12 July 2010 22:50:03 Joe Perches wrote: Signed-off-by: Joe Perches j...@perches.com For uvcvideo, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC v4] Multi-plane buffer support for V4L2 API
Hi Mauro, thanks for taking the time to look at this. Mauro Carvalho Chehab mche...@redhat.com wrote: With Hans proposed changes that you've already acked, I think the proposal is ok, except for one detail: 4. Format enumeration -- struct v4l2_fmtdesc, used for format enumeration, does include the v4l2_buf_type enum as well, so the new types can be handled properly here as well. For drivers supporting both versions of the API, 1-plane formats should be returned for multiplanar buffer types as well, for consistency. In other words, for multiplanar buffer types, the formats returned are a superset of those returned when enumerating with the old buffer types. We shouldn't mix types here. If the userspace is asking for multi-planar types, the driver should return just the multi-planar formats. If the userspace wants to know about both, it will just call for both types of formats. Yes. Although the idea here is that we wanted to be able to use single-planar formats with either the old API or the new multiplane API. In the new API, you could just set num_planes=1. So multiplanar API != multiplanar format. When you enum_fmt for mutliplanar types, you get all formats you can use with the multiplanar API and not all formats that have num_planes 1. This can simplify applications - they don't have to switch between APIs when switching between formats. They may even choose not to use the old API at all (if a driver allows it). Do we want to lose the ability to use multiplanar API for single-plane formats? Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reception issue: DViCO Fusion HDTV DVB-T Dual Express
On 13/07/2010, at 17:24, David Shirley wrote: I am having reception issues with this particular card, the problem manifests itself with missing video frames and popping sounds on the audio streams. As far as I can tell it only some channels do it, Nine and its multiplexes are the worst for it I have the same card an It Works For Me (tm). However I had serious issues with mythtv when I upgraded recently, however mplayer seemed fine and it turned out to be a DB problem (I think it was a bit of voodoo getting it working..) You can see that TZAP every now and reports some unc/ber: crystal:/usr/share/dvb/dvb-t# tzap -a 0 -c 0 Nine Digital HD using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '0' tuning to 191625000 Hz video pid 0x0200, audio pid 0x status 00 | signal 0b28 | snr | ber | unc 12c8 | status 1e | signal b64c | snr dede | ber | unc 13ce | FE_HAS_LOCK [mythtv 19:22] ~ tzap -a 1 Nine HD using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' reading channels from file '/home/myth/.tzap/channels.conf' tuning to 191625000 Hz video pid 0x0201, audio pid 0x status 00 | signal c520 | snr | ber | unc 3691 | status 1e | signal c4a8 | snr | ber | unc 36f0 | FE_HAS_LOCK status 1e | signal c4f0 | snr abab | ber | unc 36f0 | FE_HAS_LOCK status 1e | signal c4e4 | snr abab | ber | unc 36f0 | FE_HAS_LOCK status 1e | signal c4d8 | snr acac | ber | unc 36f0 | FE_HAS_LOCK status 1e | signal c50c | snr | ber | unc 36f0 | FE_HAS_LOCK status 1e | signal c4fc | snr abab | ber 0792 | unc 36f0 | FE_HAS_LOCK status 1e | signal c540 | snr acac | ber 0792 | unc 36f0 | FE_HAS_LOCK Hopefully someone can help or give me instructions on how to debug... Dunno sorry :( However if you need some comparison stuff run let me know :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -- 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] Add interlace support to sh_mobile_ceu_camera.c
On Tue, 13 Jul 2010, Kuninori Morimoto wrote:
Dear Guennadi
I've got a question to you, regarding your interlaced support
implementation for the CEU: do I understand it right, that the kind of
support you actually have implemented is, that if an interlaced format is
now requested from the CEU, it will interpret incoming data as interlaced
and deinterlace it internally?
It is correct excluding interlaced format is now requested from the CEU.
Now, the device which request interlace format is video device.
If you use Ecovec, it is tw9910.
That's one part of the equation, yes.
If this is really the case, then, I think,
it is a wrong way to implement this functionality. If a user requests
interlaced data, it means, (s)he wants it interlaced in memory. Whereas
deinterlacing should happen transparently - if the user requested
progressive data and your source provides interlaced, you can decide to
deinterlace it internally. Or am I misunderstanding your implementation?
Hmm...
Now only CEU + tw9910 pair use interlace mode in CEU.
But it doesn't support interlace mode from user space.
(I don't know how to request it from user space)
The S_FMT ioctl() has a field fmt.pix.field, which carries exactly this
information. So, by executing this ioctl() with different field values you
request progressive or one of interlaced formats. And returning
interlaced, when you actually supply progressive data to the user is not
a good idea, and this is what's currently happening, I think. It's just
our luck, that mplayer (and gstreamer?) ignore returned field value. But
we'll have to fix this in sh_mobile_ceu_camera.
Now interlace mode is used internally.
This mean, it seems as progressive mode from user space.
Exactly, we return progressive data, but give interlaced back in reply
to S_FMT. Or at least we do not differentiate between user field setting
and driver field setting, which we really should.
Regardless of theoretical correctness - does your patch still work? Have
you been able back then to get CEU to deinterlace data, and when have you
last tested it?
I tested CEU interlace mode by using Ecovec board.
I can watch correct video image on at least v2.6.34.
I used this command.
VIDIX=-vo fbdev:vidix:sh_veu
SIZE=-tv width=1280:height=720
NTSC=-tv norm=NTSC
OUT=tv:// -tv outfmt=nv12
DEVICE=-tv device=/dev/video0
mplayer ${VIDIX} ${SIZE} ${NTSC} ${OUT} ${DEVICE}
Well, I think, 720p is a little too optimistic for tw9910;) tw9910 works
on migor for me, but not on ecovec, although the chip can be detected. Are
there any modifications necessary to the kernel or to the board to get it
to work? Maybe a jumper or something? I plug in a video signal source in
the video in connector, next to the viceo out one, using the same
cable, so, cabling should work too. But I'm only getting select timeouts
and no interrupts on the CEU.
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
TeVii S470 Tunning Issue (Kernel 2.6.27-21)
Hi all, I am trying to install a 'Tevii S470' card from TeVii technology as described here http://linuxtv.org/wiki/index.php/TeVii_S470. My configuration is : - intel x86 platform - Kernel 2.6.27-21 - tevii_ds3000.tar.gz (firmware archive from http://tevii.com/tevii_ds3000.tar.gz ), - s2-liplianin mercurial sources ( from http://mercurial.intuxication.org/hg/s2-liplianin)last changes at 05/29/2010, All work fine i.e drivers/firmware installation after madprobe a right modules. # lsmod Module Size Used byNot tainted cx2388582416 0 tveeprom9348 1 cx23885 btcx_risc 1928 1 cx23885 cx2341x 7748 1 cx23885 ir_common 23936 1 cx23885 videobuf_dma_sg 5060 1 cx23885 ir_core 3596 2 cx23885,ir_common v4l2_common 8896 2 cx23885,cx2341x videodev 25376 2 cx23885,v4l2_common videobuf_dvb2820 1 cx23885 videobuf_core 8388 3 cx23885,videobuf_dma_sg,videobuf_dvb lnbp21 1024 0 dvb_core 54832 2 cx23885,videobuf_dvb ds3000 9668 1 # dmesg Linux video capture interface: v2.00 cx23885 driver version 0.0.2 loaded CORE cx23885[0]: subsystem: d470:9022, board: TeVii S470 [card=15,autodetected] cx23885_dvb_register() allocating 1 frontend(s) cx23885[0]: cx23885 based dvb card DS3000 chip version: 0.192 attached. DVB: registering new adapter (cx23885[0]) DVB: registering adapter 0 frontend 0 (Montage Technology DS3000/TS2020)... cx23885_dev_checkrevision() Hardware revision = 0xb0 cx23885[0]/0: found at :03:00.0, rev: 2, irq: 11, latency: 0, mmio: 0xdf80 cx23885 :03:00.0: setting latency timer to 64 tun: Universal TUN/TAP device driver, 1.6 A problem appear when tunning card using szap-s2 : # szap-s2 szap-s2 -c /root/channels.conf -x -M 5 -C 89 -l 9750 -S 1 MyCh reading channels from file '/root/channels.conf' zapping to 1 'MyCh': delivery DVB-S2, modulation 8PSK sat 0, frequency 8420 MHz V, symbolrate 2940, coderate 8/9,rolloff 0.35 vpid 0x0286, apid 0x1fff, sid 0x using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)... firmware: requesting dvb-fe-ds3000.fw ds3000_firmware_ondemand: Waiting for firmware upload(2)... ds3000_firmware_ondemand: No firmware uploaded (timeout or file not found?) ds3000_tune: Unable initialise the firmware Apparently it can't locate a firmware file, yet : # ls -l /lib/firmware/ -rwxr-xr-x1 root root 8192 May 3 07:09 dvb-fe-ds3000.fw Any ideas why this happens? Thanks and best regards, Hamza Ferrag -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] TeVii S470 Tunning Issue (Kernel 2.6.27-21)
I don't really know why, but it happens sometimes on my machine with the same card as well. When I have problems, I power off the computer and then restart it again. The card will not properly load or function untill I do. There is probably some hardware lock that needs to be reset by powering off the card. The loading of the firmware sometimes takes a couple of seconds in my machine, it's not very fast. Besides check if the card, which is on a PCI-1x slot, doesn't share an IRQ with the onboard soundcard. That will seriously effect the performance of both the card and the sound. Good luck, Hans Op 13-07-10 20:28, Hamza Ferrag schreef: Hi all, I am trying to install a 'Tevii S470' card from TeVii technology as described here http://linuxtv.org/wiki/index.php/TeVii_S470. My configuration is : - intel x86 platform - Kernel 2.6.27-21 - tevii_ds3000.tar.gz (firmware archive from http://tevii.com/tevii_ds3000.tar.gz ), - s2-liplianin mercurial sources ( from http://mercurial.intuxication.org/hg/s2-liplianin)last changes at 05/29/2010, All work fine i.e drivers/firmware installation after madprobe a right modules. # lsmod Module Size Used byNot tainted cx2388582416 0 tveeprom9348 1 cx23885 btcx_risc 1928 1 cx23885 cx2341x 7748 1 cx23885 ir_common 23936 1 cx23885 videobuf_dma_sg 5060 1 cx23885 ir_core 3596 2 cx23885,ir_common v4l2_common 8896 2 cx23885,cx2341x videodev 25376 2 cx23885,v4l2_common videobuf_dvb2820 1 cx23885 videobuf_core 8388 3 cx23885,videobuf_dma_sg,videobuf_dvb lnbp21 1024 0 dvb_core 54832 2 cx23885,videobuf_dvb ds3000 9668 1 # dmesg Linux video capture interface: v2.00 cx23885 driver version 0.0.2 loaded CORE cx23885[0]: subsystem: d470:9022, board: TeVii S470 [card=15,autodetected] cx23885_dvb_register() allocating 1 frontend(s) cx23885[0]: cx23885 based dvb card DS3000 chip version: 0.192 attached. DVB: registering new adapter (cx23885[0]) DVB: registering adapter 0 frontend 0 (Montage Technology DS3000/TS2020)... cx23885_dev_checkrevision() Hardware revision = 0xb0 cx23885[0]/0: found at :03:00.0, rev: 2, irq: 11, latency: 0, mmio: 0xdf80 cx23885 :03:00.0: setting latency timer to 64 tun: Universal TUN/TAP device driver, 1.6 A problem appear when tunning card using szap-s2 : # szap-s2 szap-s2 -c /root/channels.conf -x -M 5 -C 89 -l 9750 -S 1 MyCh reading channels from file '/root/channels.conf' zapping to 1 'MyCh': delivery DVB-S2, modulation 8PSK sat 0, frequency 8420 MHz V, symbolrate 2940, coderate 8/9,rolloff 0.35 vpid 0x0286, apid 0x1fff, sid 0x using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)... firmware: requesting dvb-fe-ds3000.fw ds3000_firmware_ondemand: Waiting for firmware upload(2)... ds3000_firmware_ondemand: No firmware uploaded (timeout or file not found?) ds3000_tune: Unable initialise the firmware Apparently it can't locate a firmware file, yet : # ls -l /lib/firmware/ -rwxr-xr-x1 root root 8192 May 3 07:09 dvb-fe-ds3000.fw Any ideas why this happens? Thanks and best regards, Hamza Ferrag ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Mon, 12 Jul 2010 19:01:51 -0400 Kyle Baker kyleaba...@gmail.com wrote: These do fix the audio problem, but they may not be good for other Sensor OV7660 devices. I am not sure how to identify only my model here, but that may be ideal for a better patch. I wonder if this patch would also be needed for the VX-3000 model? Hi Kyle, Thanks for the patch, but it is more complex. In fact, only the bridge sn9c105 may do audio stream and the sensor ov7660 is used with other bridges (the VX3000 is the same as the VX1000 and contains the sn9c105 and the ov7660). In the new gspca test version (2.9.52), I modified the driver for it checks the audio device. If present, the bandwidth is reduced and for the sn9c105, the bit 0x04 of the GPIO register is always set (I hope that the audio connection is done in the same way by all manufacturer!). May you check it? 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Jul 13 19:00:26 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 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: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-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: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: 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: WARNINGS linux-2.6.35-rc1-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/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 2/2] v4l2: Add lv8093 lens driver
This adds LV8093 Piezo Actuator Lens driver.
This is currently found in tandem with IMX046 sensor.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile |1 +
drivers/media/video/lv8093.c | 614 +
drivers/media/video/lv8093_regs.h | 76 +
include/media/lv8093.h| 40 +++
include/media/v4l2-chip-ident.h |3 +
6 files changed, 742 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/lv8093.c
create mode 100644 drivers/media/video/lv8093_regs.h
create mode 100644 include/media/lv8093.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 10cd7b3..b62adce 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -344,6 +344,14 @@ config VIDEO_IMX046
IMX046 camera. It is currently working with the TI OMAP3
camera controller.
+config VIDEO_LV8093
+ tristate Piezo Actuator Lens driver for LV8093
+ depends on I2C VIDEO_V4L2
+ ---help---
+ This is a Video4Linux2 lens driver for the Sanyo LV8093.
+ It is currently working with the TI OMAP3 camera controller
+ and Sony IMX046 sensor.
+
config VIDEO_SAA7110
tristate Philips SAA7110 video decoder
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 00341cb..50f528c 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
obj-$(CONFIG_VIDEO_IMX046) += imx046.o
+obj-$(CONFIG_VIDEO_LV8093) += lv8093.o
obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o
obj-$(CONFIG_VIDEO_SAA711X) += saa7115.o
obj-$(CONFIG_VIDEO_SAA717X) += saa717x.o
diff --git a/drivers/media/video/lv8093.c b/drivers/media/video/lv8093.c
new file mode 100644
index 000..b0b0fcf
--- /dev/null
+++ b/drivers/media/video/lv8093.c
@@ -0,0 +1,614 @@
+/*
+ * drivers/media/video/lv8093.c
+ *
+ * LV8093 Piezo Motor (LENS) driver
+ *
+ * Copyright (C) 2008-2009 Texas Instruments.
+ * Copyright (C) 2009 Hewlett-Packard.
+ *
+ * This package 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 PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#include linux/mutex.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/cdev.h
+#include linux/device.h
+
+#include media/lv8093.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+
+#include lv8093_regs.h
+
+static struct vcontrol {
+ struct v4l2_queryctrl qc;
+} video_control[] = {
+ {
+ {
+ .id = V4L2_CID_FOCUS_RELATIVE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Lens Relative Position,
+ .minimum = 0,
+ .maximum = 0,
+ .step = LV8093_MAX_RELATIVE_STEP,
+ .default_value = 0,
+ }
+ ,}
+};
+
+static struct i2c_driver lv8093_i2c_driver;
+
+static struct lv8093_lens_settings {
+ u8 reg;
+ u8 val;
+} lens_settings[] = {
+ { /* Set control register */
+ .reg = CAMAF_LV8093_CTL_REG,
+ .val = CAMAF_LV8093_GATE0 |
+ CAMAF_LV8093_ENIN |
+ CAMAF_LV8093_CKSEL_ONE |
+ CAMAF_LV8093_RET2 |
+ CAMAF_LV8093_INIT_OFF,
+ },
+ { /* Specify number of clocks per period */
+ .reg = CAMAF_LV8093_RST_REG,
+ .val = (LV8093_CLK_PER_PERIOD - 1),
+ },
+ { /* Set the GATE_A pulse set value */
+ .reg = CAMAF_LV8093_GTAS_REG,
+ .val = (LV8093_TIME_GATEA + 1),
+ },
+ { /* Set the GATE_B pulse reset value */
+ .reg = CAMAF_LV8093_GTBR_REG,
+ .val = (LV8093_TIME_GATEA + 1 + LV8093_TIME_OFF),
+ },
+ { /* Set the GATE_B pulse set value */
+ .reg = CAMAF_LV8093_GTBS_REG,
+ .val = (LV8093_TIME_GATEA + 1 +
+ LV8093_TIME_OFF + LV8093_TIME_GATEB),
+ },
+ { /* Specific the number of output pulse steps */
+ .reg = CAMAF_LV8093_STP_REG,
+ .val = LV8093_STP,
+ },
+ { /* Set the number of swing back of init sequence performed */
+ .reg = CAMAF_LV8093_MOV_REG,
+ .val = 0,
+ },
+};
+
+/**
+ * find_vctrl - Finds the requested ID in the
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Tue, Jul 13, 2010 at 3:13 PM, Jean-Francois Moine moin...@free.fr wrote: In the new gspca test version (2.9.52), I modified the driver for it checks the audio device. If present, the bandwidth is reduced and for the sn9c105, the bit 0x04 of the GPIO register is always set (I hope that the audio connection is done in the same way by all manufacturer!). I can verify that GSPCA 2.9.52 does indeed work with VX-1000. How long does it take typically for these changes to work their way into the Kernel? I'd love to see this included in the Kernel by the time Ubuntu 10.10 is released so I can stop tweaking webcam settings. On a different note, I've noticed that there is a bug either with Cheese or with the camera drivers after recording video. The problem is that, after I record a video in Cheese, the recording stops and the video is saved, but the record button is now disabled until I reopen the application. I'm curious why this would happen, but I think that more people would notice this bug if it were a Cheese bug. I'm wondering if there is something that isn't transferred or set correctly after ending the video/audio data transfers. Cheese is working with V4L2 well in all other aspects. I have been testing with Ubuntu 10.10, so I will install your latest drivers in Ubuntu 10.04 (stable) to see what happens. I know that on my laptop in Ubuntu 10.04 (where video worked, but audio didn't), the video would save and the button is re-enabled correctly. I'll test this against your latest release to see what happens since Ubuntu 10.04 installs GSPCA 2.7.0 by default. I will let you know of the results soon. And one more question. Is there anyway to give the camera button an action when the camera is not on? In windows, pressing the button would launch a predefined application (Windows Live Messenger), but I would like to write in the ability to open either a buddy list or Cheese or something relevant from the button if possible. Thanks. -- Kyle Baker -- 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] Add interlace support to sh_mobile_ceu_camera.c
Dear Guennadi
our luck, that mplayer (and gstreamer?) ignore returned field value. But
we'll have to fix this in sh_mobile_ceu_camera.
Hmm I understand.
I guess, at first, we need test program for it.
Well, I think, 720p is a little too optimistic for tw9910;) tw9910 works
on migor for me, but not on ecovec, although the chip can be detected. Are
there any modifications necessary to the kernel or to the board to get it
to work? Maybe a jumper or something? I plug in a video signal source in
the video in connector, next to the viceo out one, using the same
cable, so, cabling should work too. But I'm only getting select timeouts
and no interrupts on the CEU.
Hmm.. strange...
No kernel patch is needed to use tw9910 on Ecovec.
Ahh...
Maybe the criminal is dip-switch.
We can not use tw9910 and 2nd camera in same time.
Please check DS2[3] on Ecovec.
It should OFF when you use tw9910.
I wrote dip-switch info on top of
${LINUX}/arch/sh/boards/mach-ecovec24/setup.c
Please check it too.
Best regards
--
Kuninori Morimoto
--
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: Reception issue: DViCO Fusion HDTV DVB-T Dual Express
Thanks Daniel, Can you tell me what kernel version you are using? Also are you using vanilla kernel v4l or chris pascoes tree or the v4l tree for drivers? So I take it you don't get any audio blips throughout the recording ? Any chance of a longer TZAP run as well? Thanks in advance! Cheers D. On 13 July 2010 19:53, Daniel O'Connor dar...@dons.net.au wrote: On 13/07/2010, at 17:24, David Shirley wrote: I am having reception issues with this particular card, the problem manifests itself with missing video frames and popping sounds on the audio streams. As far as I can tell it only some channels do it, Nine and its multiplexes are the worst for it I have the same card an It Works For Me (tm). However I had serious issues with mythtv when I upgraded recently, however mplayer seemed fine and it turned out to be a DB problem (I think it was a bit of voodoo getting it working..) You can see that TZAP every now and reports some unc/ber: crystal:/usr/share/dvb/dvb-t# tzap -a 0 -c 0 Nine Digital HD using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '0' tuning to 191625000 Hz video pid 0x0200, audio pid 0x status 00 | signal 0b28 | snr | ber | unc 12c8 | status 1e | signal b64c | snr dede | ber | unc 13ce | FE_HAS_LOCK [mythtv 19:22] ~ tzap -a 1 Nine HD using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' reading channels from file '/home/myth/.tzap/channels.conf' tuning to 191625000 Hz video pid 0x0201, audio pid 0x status 00 | signal c520 | snr | ber | unc 3691 | status 1e | signal c4a8 | snr | ber | unc 36f0 | FE_HAS_LOCK status 1e | signal c4f0 | snr abab | ber | unc 36f0 | FE_HAS_LOCK status 1e | signal c4e4 | snr abab | ber | unc 36f0 | FE_HAS_LOCK status 1e | signal c4d8 | snr acac | ber | unc 36f0 | FE_HAS_LOCK status 1e | signal c50c | snr | ber | unc 36f0 | FE_HAS_LOCK status 1e | signal c4fc | snr abab | ber 0792 | unc 36f0 | FE_HAS_LOCK status 1e | signal c540 | snr acac | ber 0792 | unc 36f0 | FE_HAS_LOCK Hopefully someone can help or give me instructions on how to debug... Dunno sorry :( However if you need some comparison stuff run let me know :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -- 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] Add interlace support to sh_mobile_ceu_camera.c
Am Mittwoch, den 14.07.2010, 09:12 +0900 schrieb Kuninori Morimoto:
Dear Guennadi
our luck, that mplayer (and gstreamer?) ignore returned field value. But
we'll have to fix this in sh_mobile_ceu_camera.
Hmm I understand.
I guess, at first, we need test program for it.
Well, I think, 720p is a little too optimistic for tw9910;) tw9910 works
on migor for me, but not on ecovec, although the chip can be detected. Are
there any modifications necessary to the kernel or to the board to get it
to work? Maybe a jumper or something? I plug in a video signal source in
the video in connector, next to the viceo out one, using the same
cable, so, cabling should work too. But I'm only getting select timeouts
and no interrupts on the CEU.
Hmm.. strange...
No kernel patch is needed to use tw9910 on Ecovec.
Ahh...
Maybe the criminal is dip-switch.
We can not use tw9910 and 2nd camera in same time.
Please check DS2[3] on Ecovec.
It should OFF when you use tw9910.
I wrote dip-switch info on top of
${LINUX}/arch/sh/boards/mach-ecovec24/setup.c
Please check it too.
Best regards
--
Kuninori Morimoto
Kuninori,
you are well treated and highly honored by all staying in development
with you. For me it is just some glitch on the edges, but very well
noted.
For now, a dip-switch, you must have been abroad somewhere, can't be a
criminal. Or?
http://www.dip-switch.com/?gclid=COjg9Mn86aICFYSdzAodNEcLkQ
Could you eventually agree with that about what a dip-switch is or do I
miss what you mean?
Do you really tell there are still unclear dip-switches in 2010?
If so, please let's know, but then you can't do anything against such in
software, of course.
Cheers,
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Tue, Jul 13, 2010 at 7:59 PM, Kyle Baker kyleaba...@gmail.com wrote: On a different note, I've noticed that there is a bug either with Cheese or with the camera drivers after recording video. The problem is that, after I record a video in Cheese, the recording stops and the video is saved, but the record button is now disabled until I reopen the application. I've tested this on my Ubuntu 10.04 32-bit laptop with both GSPCA 2.7.0 and GSPCA 2.9.52. The results match, Cheese 2.30.1 works as intended. However, I'm using the same version of Cheese on my Ubuntu 10.10 64-bit computer and results are different. I'll keep an eye on this issue and if it doesn't clear up by time of Ubuntu 10.10 release then I'll look back into it. FYI, there is a warning message in the make process that I wanted to bring your attention to. Its not causing problems, but maybe it can be removed? .../gspca-2.9.52/build/jpeg.h:152: warning: ‘jpeg_set_qual’ defined but not used Cheers. -- Kyle Baker -- 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] Add interlace support to sh_mobile_ceu_camera.c
Dear hermann For now, a dip-switch, you must have been abroad somewhere, can't be a criminal. Or? http://www.dip-switch.com/?gclid=COjg9Mn86aICFYSdzAodNEcLkQ Could you eventually agree with that about what a dip-switch is or do I miss what you mean? Do you really tell there are still unclear dip-switches in 2010? If so, please let's know, but then you can't do anything against such in software, of course. I'm so sorry about my stupid English. I should not use the words of criminal. I should say The reason that there are no video output on Ecovec might dip-switch setting issue. DS2[3] should be OFF when you use video Best regards -- Kuninori Morimoto -- 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
