SkyStar HD2 (TwinHan VP-1041/Mantis) S2API support
Hello all,
I'd like to ask for your help. After weeks of research and
deliberation I bought two SkyStar HD2 cards (quite a lot money for
me). It seemed to be working for everybody, BUT I have already spent
two days reading mailing lists, downloading repositories, compiling
drivers, apps, kernels and bending code to make it compile. Please,
does anybody know how to help me?
In short the driver doesn't seem to communicate with the card at all.
It's unable to send DiSEqC commands (not necessary in my case), unable
to tune the tuner, unable to report any signal strength info etc. I
have a dark sense of foreboding about this, because as things stand
now, it seems I'll have to recoup my losses (can't return these cards)
and buy different ones, possibly more expensive. Just these two cost
me half my month's salary. I was so damn sure they'll work - from all
the reports and success stories on the web, even LinuxTV said so. If
you knew my wife... I mean this is going to be a disaster. :(
Drivers tried: http://jusst.de/hg/multiproto,
http://jusst.de/hg/mantis (couldn't make it compile)
Driver used: http://mercurial.intuxication.org/hg/s2-liplianin
Kernels tried w/driver: Debian 2.6.29; Debian 2.6.26; vanilla 2.6.29
DVB apps/utils: 1.1.1+rev1207-4
S2API DVB apps/utils: http://mercurial.intuxication.org/hg/{szap-s2,scan-s2}
lspci -vv:
07:01.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV
PCI Bridge Controller [Ver 1.0] (rev 01)
Subsystem: Device 1ae4:0003
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort+ MAbort- SERR- PERR+ INTx-
Latency: 32 (2000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 19
Region 0: Memory at ec20 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis
Kernel modules: mantis
Boot-up dmesg:
[6.704959] Mantis :07:01.0: PCI INT A - GSI 19 (level, low) - IRQ 19
[6.705100] irq: 19, latency: 32
[6.705101] memory: 0xec20, mmio: 0xf8286000
[6.705183] found a VP-1041 PCI DSS/DVB-S/DVB-S2 device on (07:01.0),
[6.705228] Mantis Rev 1 [1ae4:0003], irq: 19, latency: 32
[6.705261] memory: 0xec20, mmio: 0xf8286000
[6.708020] MAC Address=[00:08:c9:e0:40:6a]
[6.708075] mantis_alloc_buffers (0): DMA=0x35d4 cpu=0xf5d4
size=65536
[6.708128] mantis_alloc_buffers (0): RISC=0x36327000
cpu=0xf6327000 size=1000
[6.708179] DVB: registering new adapter (Mantis dvb adapter)
[7.253355] stb0899_attach: Attaching STB0899
[7.253397] mantis_frontend_init (0): found STB0899 DVB-S/DVB-S2
frontend @0x68
[7.253449] stb6100_attach: Attaching STB6100
[7.253836] LNBx2x attached on addr=8DVB: registering adapter 0
frontend 0 (STB0899 Multistandard)...
[7.253938] mantis_ca_init (0): Registering EN50221 device
[7.254033] mantis_ca_init (0): Registered EN50221 device
[7.254096] mantis_hif_init (0): Adapter(0) Initializing Mantis
Host Interface
Sat cable has 98% signal, Astra 19.2E, working in a TV/STB sitting
right next to the PC. I reconnect the cable from the TV into SkyStar
and try tuning:
birko:~# scan-s2 -v /usr/share/dvb/dvb-s/Astra-19.2E
API major 5, minor 0
ERROR: Cannot open rotor configuration file 'rotor.conf'.
scanning /usr/share/dvb/dvb-s/Astra-19.2E
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder DVB-S 12551500 V 2200 5/6 AUTO AUTO
initial transponder DVB-S2 12551500 V 2200 5/6 AUTO AUTO
-- Using DVB-S
tune to: 12551:vC56S0:S0.0W:22000:
DiSEqC: uncommitted switch pos 0
DiSEqC: switch pos 0, 13V, hiband (index 2)
DVB-S IF freq is 1951500
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
WARNING: tuning failed!!!
-- Using DVB-S2
tune to: 12551:vC56S1:S0.0W:22000:
DiSEqC: uncommitted switch pos 0
DiSEqC: switch pos 0, 13V, hiband (index 2)
DVB-S IF freq is 1951500
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
WARNING: tuning failed!!!
ERROR: initial tuning failed
dumping lists (0 services)
Done.
Meanwhile, this is written to dmesg (repeating):
[43395.935293] stb6100_set_bandwidth: Bandwidth=5161
[43395.943657] stb6100_get_bandwidth: Bandwidth=1000
[43395.970435] stb6100_get_bandwidth: Bandwidth=1000
[43396.062102] stb6100_set_frequency: Frequency=1951500
[43396.070464] stb6100_get_frequency: Frequency=0
[43396.084862] stb6100_get_bandwidth: Bandwidth=1000
[43396.622789] stb6100_set_bandwidth: Bandwidth=5161
[43396.631150]
[PULL] http://linuxtv.org/hg/~anttip/af9015/
Hei Mauro, Please pull from http://linuxtv.org/hg/~anttip/af9015/ for the following: af9015: add new dvb_usb_device_properties entry for upcoming USB IDs af9015: support for AverMedia AVerTV Volar GPS 805 (A805) af9015: support for Conceptronic USB2.0 DVB-T CTVDIGRCU V3.0 Patch series adds support for two new devices. I want patches to the next release candidate of the Kernel 2.6.30 if possible. I didn't find any file from Kernel /Documentation/ which describes what kind of changes are allowed during RC phase, but I have feeling that adding new device IDs is allowed. How about remote tables for new devices? regards Antti -- http://palosaari.fi/ -- 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
ir-kbd-i2c Compile Warnings
Hello all, Fresh clone of V4L this morning running on a fully patched ArchLinux 64-bit system: /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.o /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c: In function 'ir_attach': /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c:429: warning: 'i2c_attach_client' is deprecated (declared at include/linux/i2c.h:434) /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c:468: warning: 'i2c_detach_client' is deprecated (declared at include/linux/i2c.h:435) /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c: In function 'ir_detach': /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c:484: warning: 'i2c_detach_client' is deprecated (declared at include/linux/i2c.h:435) Brandon uname -a Linux sagetv-server 2.6.29-ARCH #1 SMP PREEMPT Wed Apr 8 12:39:28 CEST 2009 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux -- 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: SkyStar HD2 (TwinHan VP-1041/Mantis) S2API support
On Fri, Apr 10, 2009 at 1:30 PM, Dave Lister foc...@gmail.com wrote:
Hello all,
I'd like to ask for your help. After weeks of research and
deliberation I bought two SkyStar HD2 cards (quite a lot money for
me). It seemed to be working for everybody, BUT I have already spent
two days reading mailing lists, downloading repositories, compiling
drivers, apps, kernels and bending code to make it compile. Please,
does anybody know how to help me?
In short the driver doesn't seem to communicate with the card at all.
It's unable to send DiSEqC commands (not necessary in my case), unable
to tune the tuner, unable to report any signal strength info etc. I
have a dark sense of foreboding about this, because as things stand
now, it seems I'll have to recoup my losses (can't return these cards)
and buy different ones, possibly more expensive. Just these two cost
me half my month's salary. I was so damn sure they'll work - from all
the reports and success stories on the web, even LinuxTV said so. If
you knew my wife... I mean this is going to be a disaster. :(
Drivers tried: http://jusst.de/hg/multiproto,
http://jusst.de/hg/mantis (couldn't make it compile)
hmm this seems to work fine with linux 2.6.27 maybe try to downgrade
your kernel?
Markus
Driver used: http://mercurial.intuxication.org/hg/s2-liplianin
Kernels tried w/driver: Debian 2.6.29; Debian 2.6.26; vanilla 2.6.29
DVB apps/utils: 1.1.1+rev1207-4
S2API DVB apps/utils: http://mercurial.intuxication.org/hg/{szap-s2,scan-s2}
lspci -vv:
07:01.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV
PCI Bridge Controller [Ver 1.0] (rev 01)
Subsystem: Device 1ae4:0003
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort+ MAbort- SERR- PERR+ INTx-
Latency: 32 (2000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 19
Region 0: Memory at ec20 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis
Kernel modules: mantis
Boot-up dmesg:
[ 6.704959] Mantis :07:01.0: PCI INT A - GSI 19 (level, low) - IRQ 19
[ 6.705100] irq: 19, latency: 32
[ 6.705101] memory: 0xec20, mmio: 0xf8286000
[ 6.705183] found a VP-1041 PCI DSS/DVB-S/DVB-S2 device on (07:01.0),
[ 6.705228] Mantis Rev 1 [1ae4:0003], irq: 19, latency: 32
[ 6.705261] memory: 0xec20, mmio: 0xf8286000
[ 6.708020] MAC Address=[00:08:c9:e0:40:6a]
[ 6.708075] mantis_alloc_buffers (0): DMA=0x35d4 cpu=0xf5d4
size=65536
[ 6.708128] mantis_alloc_buffers (0): RISC=0x36327000
cpu=0xf6327000 size=1000
[ 6.708179] DVB: registering new adapter (Mantis dvb adapter)
[ 7.253355] stb0899_attach: Attaching STB0899
[ 7.253397] mantis_frontend_init (0): found STB0899 DVB-S/DVB-S2
frontend @0x68
[ 7.253449] stb6100_attach: Attaching STB6100
[ 7.253836] LNBx2x attached on addr=8DVB: registering adapter 0
frontend 0 (STB0899 Multistandard)...
[ 7.253938] mantis_ca_init (0): Registering EN50221 device
[ 7.254033] mantis_ca_init (0): Registered EN50221 device
[ 7.254096] mantis_hif_init (0): Adapter(0) Initializing Mantis
Host Interface
Sat cable has 98% signal, Astra 19.2E, working in a TV/STB sitting
right next to the PC. I reconnect the cable from the TV into SkyStar
and try tuning:
birko:~# scan-s2 -v /usr/share/dvb/dvb-s/Astra-19.2E
API major 5, minor 0
ERROR: Cannot open rotor configuration file 'rotor.conf'.
scanning /usr/share/dvb/dvb-s/Astra-19.2E
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder DVB-S 12551500 V 2200 5/6 AUTO AUTO
initial transponder DVB-S2 12551500 V 2200 5/6 AUTO AUTO
-- Using DVB-S
tune to: 12551:vC56S0:S0.0W:22000:
DiSEqC: uncommitted switch pos 0
DiSEqC: switch pos 0, 13V, hiband (index 2)
DVB-S IF freq is 1951500
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
WARNING: tuning failed!!!
-- Using DVB-S2
tune to: 12551:vC56S1:S0.0W:22000:
DiSEqC: uncommitted switch pos 0
DiSEqC: switch pos 0, 13V, hiband (index 2)
DVB-S IF freq is 1951500
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
tuning status == 0x00
WARNING: tuning failed!!!
ERROR: initial tuning failed
dumping lists (0 services)
Done.
Meanwhile, this is written to dmesg (repeating):
[43395.935293] stb6100_set_bandwidth: Bandwidth=5161
[43395.943657] stb6100_get_bandwidth: Bandwidth=1000
[43395.970435] stb6100_get_bandwidth:
Re: [RFC] White Balance control for digital camera
On Fri, 10 Apr 2009, Dongsoo, Nathaniel Kim wrote: Hello everyone, I'm posting this RFC one more time because it seems to everyone has been forgot this, and I'll be appreciated if any of you who is reading this mailing list give me comment. I don't know much about the topic, and I wish I did. I've got a big question popping up handling white balance with V4L2_CID_WHITE_BALANCE_TEMPERATURE CID. Because in digital camera we generally control over user interface with pre-defined white balance name. I mean, user controls white balance with presets not with kelvin number. I'm very certain that TEMPERATURE CID is needed in many of video capture devices, but also 100% sure that white balance preset control is also necessary for digital cameras. How can we control white balance through preset name with existing V4L2 API? Let's broaden the question to include digital still cameras, which present similar problems. They present data related to this kind of thing, that is obvious. But are there any standard meanings to what is there? Do you know anything about that? Can you help? Two examples: The SQ905 and SQ905C cameras in stillcam mode use an allocation table, which presents on each line some data about the given image. In this line, byte 0 is a one-byte code for pixel dimensions and compression setting. Then some more bytes give the starting and ending locations of the photo in the camera's memory (actually irrelevant and superfluous information, because you can only ask for the photos in sequence, and with a command which has nothing to do with its memory location at all). Then some more bytes obviously have something to do with contrast, brightness, white balance, color balance, and so on. But I have no more idea than the Man in the Moon how those bytes are supposed to be interpreted. The SQ905 gives no such equivalent information while in streaming mode, and so there is nothing at all which could be done with the nonexistent information. But the SQ905C does obviously give such information, in a few bytes in the header of each frame. The MR97310A cameras give similar information in the header of the photo itself (and in this case the camera does the same thing in webcam mode, too). Again, I have no idea either what these mysterious bytes are supposed to mean, and how to use them constructively. I could mention several other examples, too, but these will do for a start. Are there any agreed-upon standards about this kind of thing, in the camera industry? Is there any source of information about it? 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Apr 10 19:00:06 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11445:dba0b6fae413 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-rc1-armv5: ERRORS linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-rc1-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: OK linux-2.6.30-rc1-i686: ERRORS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-rc1-m32r: ERRORS linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29.1-mips: OK linux-2.6.30-rc1-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-rc1-x86_64: ERRORS fw/apps: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc1): OK linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: Kernel 2.6.29 breaks DVB-T ASUSTeK Tiger LNA Hybrid Capture Device
Hi, Am Donnerstag, den 09.04.2009, 02:05 +0100 schrieb Thomas Horsten: Hi Hermann, 2009/4/8 hermann pitton hermann-pit...@arcor.de: does it make any difference too with the current mercurial v4l-dvb ? I did not look any further, since some tones coming currently from above I don't like, more those from Linus after having 800 plus patches. After installing the mercurial drivers and rebooting the symptoms are exactly the same. Another tuner card in the same machine (a Hauppauge Nova-T 500 Dual DVB-T) works fine. If you have any ideas I am willing to experiment to get this to work again. If I have some time over Easter I might try git-dissecting the changes to find the patch that introduced the behaviour but since it is running on quite a big server the turnaround time to reboot and try new modules is about 30 minutes :( scrolled at least over some saa7134 related diffs just, thousands of lines, but no exact catch yet. It seems the i2c gate control of the tda8290 at 0x96 is broken in DVB-T mode open/close related. Correct behavior with current mercurial tuning the tuner at 0xc0. saa7133[0]: i2c xfer: 10 06 [fd quirk] 11 =af saa7133[0]: i2c xfer: 10 06 [fd quirk] 11 =af saa7133[0]: i2c xfer: 10 06 [fd quirk] 11 =af saa7133[0]: i2c xfer: 10 01 [fd quirk] 11 =91 saa7133[0]: i2c xfer: 10 01 91 saa7133[0]: i2c xfer: 10 02 [fd quirk] 11 =1c saa7133[0]: i2c xfer: 10 02 1c saa7133[0]: i2c xfer: 10 03 [fd quirk] 11 =00 saa7133[0]: i2c xfer: 10 03 00 saa7133[0]: i2c xfer: 10 43 [fd quirk] 11 =03 saa7133[0]: i2c xfer: 10 43 03 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 00 2e 70 00 16 14 4b 1c 06 24 00 saa7133[0]: i2c xfer: 96 21 80 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 90 ff 60 00 59 saa7133[0]: i2c xfer: 96 21 80 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 a0 40 saa7133[0]: i2c xfer: 96 21 80 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c1 =09 =a8 saa7133[0]: i2c xfer: 96 21 80 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 c0 99 saa7133[0]: i2c xfer: 96 21 80 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 60 3c saa7133[0]: i2c xfer: 96 21 80 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 30 11 saa7133[0]: i2c xfer: 96 21 80 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 c0 39 saa7133[0]: i2c xfer: 96 21 80 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 50 4f saa7133[0]: i2c xfer: 96 21 80 saa7133[0]: i2c xfer: 96 21 80 saa7133[0]: i2c xfer: 10 01 [fd quirk] 11 =91 saa7133[0]: i2c xfer: 10 01 91 saa7133[0]: i2c xfer: 10 02 [fd quirk] 11 =1c saa7133[0]: i2c xfer: 10 02 1c saa7133[0]: i2c xfer: 10 02 [fd quirk] 11 =1c saa7133[0]: i2c xfer: 10 02 1c saa7133[0]: i2c xfer: 10 03 [fd quirk] 11 =00 saa7133[0]: i2c xfer: 10 03 00 saa7133[0]: i2c xfer: 10 31 54 saa7133[0]: i2c xfer: 10 32 03 On the broken 2.6.29.1 it looks like that. saa7133[0]: i2c xfer: 10 22 [fd quirk] 11 =ff saa7133[0]: i2c xfer: 10 21 [fd quirk] 11 =ff saa7133[0]: i2c xfer: 10 20 [fd quirk] 11 =ff saa7133[0]: i2c xfer: 10 01 [fd quirk] 11 =91 saa7133[0]: i2c xfer: 10 01 91 saa7133[0]: i2c xfer: 10 02 [fd quirk] 11 =1c saa7133[0]: i2c xfer: 10 02 1c saa7133[0]: i2c xfer: 10 03 [fd quirk] 11 =00 saa7133[0]: i2c xfer: 10 03 00 saa7133[0]: i2c xfer: 10 43 [fd quirk] 11 =03 saa7133[0]: i2c xfer: 10 43 03 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 00 32 c0 00 16 5a 5b 1c 06 24 00 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 90 ff 60 00 59 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 a0 40 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c1 =09 =a8 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 c0 99 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 60 3c saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 30 10 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 c0 39 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c0 50 5f saa7133[0]: i2c xfer: 96 21 80 saa7133[0]: i2c xfer: 10 01 [fd quirk] 11 =91 saa7133[0]: i2c xfer: 10 01 91 saa7133[0]: i2c xfer: 10 02 [fd quirk] 11 =1c saa7133[0]: i2c xfer: 10 02 1c saa7133[0]: i2c xfer: 10 02 [fd quirk] 11 =1c saa7133[0]: i2c xfer: 10 02 1c saa7133[0]: i2c xfer: 10 03 [fd quirk] 11 =00 saa7133[0]: i2c xfer: 10 03 00 saa7133[0]: i2c xfer: 10 31 60 saa7133[0]: i2c xfer: 10 32 02 saa7133[0]: i2c xfer: 10 33 aa saa7133[0]: i2c xfer: 10 34 aa saa7133[0]: i2c xfer: 10 35 ab saa7133[0]: i2c xfer: 10 4d 0c saa7133[0]: i2c xfer: 10 4e 00 saa7133[0]: i2c xfer: 10 16 [fd quirk] 11 =a8 saa7133[0]: i2c xfer: 10 16 a8 saa7133[0]: i2c xfer: 10 01 [fd quirk] 11 =91 saa7133[0]: i2c xfer: 10 01 91 saa7133[0]: i2c xfer: 10 02 [fd quirk] 11 =1c saa7133[0]: i2c xfer: 10 02 1c Mauro had a fix during further changes for the
Re: [RFC] White Balance control for digital camera
On Sat, Apr 11, 2009 at 2:39 AM, Theodore Kilgore kilg...@banach.math.auburn.edu wrote: On Fri, 10 Apr 2009, Dongsoo, Nathaniel Kim wrote: Hello everyone, I'm posting this RFC one more time because it seems to everyone has been forgot this, and I'll be appreciated if any of you who is reading this mailing list give me comment. I don't know much about the topic, and I wish I did. I've got a big question popping up handling white balance with V4L2_CID_WHITE_BALANCE_TEMPERATURE CID. Because in digital camera we generally control over user interface with pre-defined white balance name. I mean, user controls white balance with presets not with kelvin number. I'm very certain that TEMPERATURE CID is needed in many of video capture devices, but also 100% sure that white balance preset control is also necessary for digital cameras. How can we control white balance through preset name with existing V4L2 API? Let's broaden the question to include digital still cameras, which present similar problems. They present data related to this kind of thing, that is obvious. But are there any standard meanings to what is there? Do you know anything about that? Can you help? Exactly right, but we need to see this on the top of the user space first. Because there could be several types of camera devices could be handled. I mean, the device that I'm intending to handle is based on I2C device and the digital still camera you issued is totally based on USB communication. That could be different in driver implementation point of view, but user in user space should be using in same manner. And I think I can help to coordinate how to handle them in user space with V4L2 API, but not so much with usb communication with digital still cameras.(but I really want to help indeed) Actually my expertise is totally based on mobile camera devices like camera phone. Even though they are mobile camera modules, they are very close to regular digital camera in performance and quality level now days. Two examples: The SQ905 and SQ905C cameras in stillcam mode use an allocation table, which presents on each line some data about the given image. In this line, byte 0 is a one-byte code for pixel dimensions and compression setting. Then some more bytes give the starting and ending locations of the photo in the camera's memory (actually irrelevant and superfluous information, because you can only ask for the photos in sequence, and with a command which has nothing to do with its memory location at all). Then some more bytes obviously have something to do with contrast, brightness, white balance, color balance, and so on. But I have no more idea than the Man in the Moon how those bytes are supposed to be interpreted. The SQ905 gives no such equivalent information while in streaming mode, and so there is nothing at all which could be done with the nonexistent information. But the SQ905C does obviously give such information, in a few bytes in the header of each frame. As far as I know, SQ905 (is that actually cheez camera?) is a regular digital camera not a mobile camera module, so in that case it could be handled in gspca and totally control through usb_control_msg. And with my experience, I think I can help you if I have any kind of datasheet or user manual for that. But even if I don't have datasheet and don't know which message field means what I'm intending to do, I think it could be possible to make it compatible with the parameters I'm trying to make in v4l2 control. The MR97310A cameras give similar information in the header of the photo itself (and in this case the camera does the same thing in webcam mode, too). Again, I have no idea either what these mysterious bytes are supposed to mean, and how to use them constructively. I could mention several other examples, too, but these will do for a start. OK I've got what you mean. Can I have any information like user manual or datasheet for those SQ and MR devices? If we make a white balance preset api in v4l2, then we should have to implement that functionality in every single camera drivers in v4l2 if those devices are supporting for white balance presets. I want to make this clear that if we have white balance preset api in v4l2, then we can handle every camera device's white balance more user friendly. Thank you for your opinion by the way. Nate Are there any agreed-upon standards about this kind of thing, in the camera industry? Is there any source of information about it? Theodore Kilgore -- DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More
Re: [linux-dvb] SkyStar HD2 (TwinHan VP-1041/Mantis) S2API support
There is a new mantis tree being uploaded at: http://jusst.de/hg/mantis-v4l Please try this tree. The upload should finish within 2 hours and is using DVB api 5 (aka s2api). Cheers -- 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/RFC] soc-camera: Convert to a platform driver
Guennadi Liakhovetski g.liakhovet...@gmx.de writes: On Thu, 9 Apr 2009, Robert Jarzmik wrote: Guennadi Liakhovetski g.liakhovet...@gmx.de writes: Did you enable DEBUG? Looks like one of dev_dbg() had a (yet) invalid device pointer. I'll have to try that too. No, don't think so. I think that calling mclk_get_divisor() too early, when pcdev-soc_host.dev is not set, is the issue here (dev_warn is mclk_get_divisor()). And for the same price, I'll give you another stack :) I'll leave that one up to you, as I'm not really confortable with that type of sequence : if (!icd-dev.parent || to_soc_camera_host(icd-dev.parent)-nr != icd-iface) [ 183.230769] [bf016128] (mt9m111_probe+0xcc/0x298 [mt9m111]) from [c0171a8c] (i2c_device_probe+0x8c/0x9c) [ 183.238108] [c0171a8c] (i2c_device_probe+0x8c/0x9c) from [c014777c] (driver_probe_device+0xa4/0x1a8) [ 183.245424] [c014777c] (driver_probe_device+0xa4/0x1a8) from [c0146a28] (bus_for_each_drv+0x60/0x8c) [ 183.252617] [c0146a28] (bus_for_each_drv+0x60/0x8c) from [c0147994] (device_attach+0x5c/0x74) [ 183.259792] [c0147994] (device_attach+0x5c/0x74) from [c0146994] (bus_attach_device+0x44/0x78) [ 183.266944] [c0146994] (bus_attach_device+0x44/0x78) from [c0145368] (device_add+0x394/0x5ac) [ 183.274084] [c0145368] (device_add+0x394/0x5ac) from [c0172790] (i2c_attach_client+0x80/0x148) [ 183.281228] [c0172790] (i2c_attach_client+0x80/0x148) from [c0172b14] (i2c_new_device+0x6c/0x90) [ 183.288340] [c0172b14] (i2c_new_device+0x6c/0x90) from [bf00ccb8] (soc_camera_probe+0x4c/0x188 [soc_camera]) [ 183.295622] [bf00ccb8] (soc_camera_probe+0x4c/0x188 [soc_camera]) from [c014777c] (driver_probe_device+0xa4/0x1a8) [ 183.302774] [c014777c] (driver_probe_device+0xa4/0x1a8) from [c0146a28] (bus_for_each_drv+0x60/0x8c) [ 183.309863] [c0146a28] (bus_for_each_drv+0x60/0x8c) from [c0147994] (device_attach+0x5c/0x74) [ 183.316902] [c0147994] (device_attach+0x5c/0x74) from [c0146994] (bus_attach_device+0x44/0x78) [ 183.323927] [c0146994] (bus_attach_device+0x44/0x78) from [c0145368] (device_add+0x394/0x5ac) [ 183.330947] [c0145368] (device_add+0x394/0x5ac) from [bf00cb6c] (soc_camera_host_register+0x1a4/0x1ec [soc_camera]) [ 183.337997] [bf00cb6c] (soc_camera_host_register+0x1a4/0x1ec [soc_camera]) from [bf01dc0c] (pxa_camera_probe+0x2e4/0x42c [pxa_camera]) [ 183.345142] [bf01dc0c] (pxa_camera_probe+0x2e4/0x42c [pxa_camera]) from [c014858c] (platform_drv_probe+0x1c/0x24) [ 183.352164] [c014858c] (platform_drv_probe+0x1c/0x24) from [c014777c] (driver_probe_device+0xa4/0x1a8) [ 183.359158] [c014777c] (driver_probe_device+0xa4/0x1a8) from [c0147904] (__driver_attach+0x84/0x88) [ 183.366088] [c0147904] (__driver_attach+0x84/0x88) from [c0146cd8] (bus_for_each_dev+0x54/0x80) [ 183.372983] [c0146cd8] (bus_for_each_dev+0x54/0x80) from [c01472c8] (bus_add_driver+0xa4/0x218) [ 183.379873] [c01472c8] (bus_add_driver+0xa4/0x218) from [c0147b10] (driver_register+0x58/0x138) [ 183.386766] [c0147b10] (driver_register+0x58/0x138) from [c002128c] (do_one_initcall+0x2c/0x180) [ 183.393705] [c002128c] (do_one_initcall+0x2c/0x180) from [c0057514] (sys_init_module+0x88/0x198) [ 183.400650] [c0057514] (sys_init_module+0x88/0x198) from [c0021de0] (ret_fast_syscall+0x0/0x2c) [ 183.407554] Code: e3a03000 e1c53cb8 e2426020 e351 (e5968068) [ 183.411614] ---[ end trace b5c2161a92c2cf9d ]--- 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
Re: [RFC] White Balance control for digital camera
Hello again, I forgot to give you reference about the range of color temperature to handle white balance as preset. Here is the wikipedia reference, I wish I could find better one but by now it seems to be no problem. http://en.wikipedia.org/wiki/Color_temperature#Categorizing_different_lighting Cheers, Nate On Sat, Apr 11, 2009 at 5:44 AM, Dongsoo, Nathaniel Kim dongsoo@gmail.com wrote: On Sat, Apr 11, 2009 at 2:39 AM, Theodore Kilgore kilg...@banach.math.auburn.edu wrote: On Fri, 10 Apr 2009, Dongsoo, Nathaniel Kim wrote: Hello everyone, I'm posting this RFC one more time because it seems to everyone has been forgot this, and I'll be appreciated if any of you who is reading this mailing list give me comment. I don't know much about the topic, and I wish I did. I've got a big question popping up handling white balance with V4L2_CID_WHITE_BALANCE_TEMPERATURE CID. Because in digital camera we generally control over user interface with pre-defined white balance name. I mean, user controls white balance with presets not with kelvin number. I'm very certain that TEMPERATURE CID is needed in many of video capture devices, but also 100% sure that white balance preset control is also necessary for digital cameras. How can we control white balance through preset name with existing V4L2 API? Let's broaden the question to include digital still cameras, which present similar problems. They present data related to this kind of thing, that is obvious. But are there any standard meanings to what is there? Do you know anything about that? Can you help? Exactly right, but we need to see this on the top of the user space first. Because there could be several types of camera devices could be handled. I mean, the device that I'm intending to handle is based on I2C device and the digital still camera you issued is totally based on USB communication. That could be different in driver implementation point of view, but user in user space should be using in same manner. And I think I can help to coordinate how to handle them in user space with V4L2 API, but not so much with usb communication with digital still cameras.(but I really want to help indeed) Actually my expertise is totally based on mobile camera devices like camera phone. Even though they are mobile camera modules, they are very close to regular digital camera in performance and quality level now days. Two examples: The SQ905 and SQ905C cameras in stillcam mode use an allocation table, which presents on each line some data about the given image. In this line, byte 0 is a one-byte code for pixel dimensions and compression setting. Then some more bytes give the starting and ending locations of the photo in the camera's memory (actually irrelevant and superfluous information, because you can only ask for the photos in sequence, and with a command which has nothing to do with its memory location at all). Then some more bytes obviously have something to do with contrast, brightness, white balance, color balance, and so on. But I have no more idea than the Man in the Moon how those bytes are supposed to be interpreted. The SQ905 gives no such equivalent information while in streaming mode, and so there is nothing at all which could be done with the nonexistent information. But the SQ905C does obviously give such information, in a few bytes in the header of each frame. As far as I know, SQ905 (is that actually cheez camera?) is a regular digital camera not a mobile camera module, so in that case it could be handled in gspca and totally control through usb_control_msg. And with my experience, I think I can help you if I have any kind of datasheet or user manual for that. But even if I don't have datasheet and don't know which message field means what I'm intending to do, I think it could be possible to make it compatible with the parameters I'm trying to make in v4l2 control. The MR97310A cameras give similar information in the header of the photo itself (and in this case the camera does the same thing in webcam mode, too). Again, I have no idea either what these mysterious bytes are supposed to mean, and how to use them constructively. I could mention several other examples, too, but these will do for a start. OK I've got what you mean. Can I have any information like user manual or datasheet for those SQ and MR devices? If we make a white balance preset api in v4l2, then we should have to implement that functionality in every single camera drivers in v4l2 if those devices are supporting for white balance presets. I want to make this clear that if we have white balance preset api in v4l2, then we can handle every camera device's white balance more user friendly. Thank you for your opinion by the way. Nate Are there any agreed-upon standards about this kind of thing, in the camera industry? Is there any source of information about it? Theodore Kilgore --
Re: ir-kbd-i2c Compile Warnings
On Fri, Apr 10, 2009 at 10:10 AM, Brandon Jenkins bcjenk...@tvwhere.com wrote: Hello all, Fresh clone of V4L this morning running on a fully patched ArchLinux 64-bit system: /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.o /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c: In function 'ir_attach': /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c:429: warning: 'i2c_attach_client' is deprecated (declared at include/linux/i2c.h:434) /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c:468: warning: 'i2c_detach_client' is deprecated (declared at include/linux/i2c.h:435) /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c: In function 'ir_detach': /root/drivers/v4l-dvb/v4l/ir-kbd-i2c.c:484: warning: 'i2c_detach_client' is deprecated (declared at include/linux/i2c.h:435) Brandon uname -a Linux sagetv-server 2.6.29-ARCH #1 SMP PREEMPT Wed Apr 8 12:39:28 CEST 2009 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux Rolling back to kernel: Linux sagetv-server 2.6.28-ARCH #1 SMP PREEMPT Tue Mar 17 07:22:53 CET 2009 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux Does not produce the same warnings. Thanks, Brandon -- 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] White Balance control for digital camera
On Sat, 11 Apr 2009, Dongsoo, Nathaniel Kim wrote: On Sat, Apr 11, 2009 at 2:39 AM, Theodore Kilgore kilg...@banach.math.auburn.edu wrote: On Fri, 10 Apr 2009, Dongsoo, Nathaniel Kim wrote: Hello everyone, I'm posting this RFC one more time because it seems to everyone has been forgot this, and I'll be appreciated if any of you who is reading this mailing list give me comment. I don't know much about the topic, and I wish I did. I've got a big question popping up handling white balance with V4L2_CID_WHITE_BALANCE_TEMPERATURE CID. Because in digital camera we generally control over user interface with pre-defined white balance name. I mean, user controls white balance with presets not with kelvin number. I'm very certain that TEMPERATURE CID is needed in many of video capture devices, but also 100% sure that white balance preset control is also necessary for digital cameras. How can we control white balance through preset name with existing V4L2 API? Let's broaden the question to include digital still cameras, which present similar problems. They present data related to this kind of thing, that is obvious. But are there any standard meanings to what is there? Do you know anything about that? Can you help? Exactly right, but we need to see this on the top of the user space first. Because there could be several types of camera devices could be handled. I mean, the device that I'm intending to handle is based on I2C device and the digital still camera you issued is totally based on USB communication. That could be different in driver implementation point of view, but user in user space should be using in same manner. And I think I can help to coordinate how to handle them in user space with V4L2 API, but not so much with usb communication with digital still cameras.(but I really want to help indeed) Actually my expertise is totally based on mobile camera devices like camera phone. Even though they are mobile camera modules, they are very close to regular digital camera in performance and quality level now days. Well, I would say of the top of my head that to do things the same way is a good idea, whenever possible. But that would appear to me, then, that libgphoto2 and things related to v4l would have to do these things, which would probably result in some code being incorporated in both places, in the end. Two examples: The SQ905 and SQ905C cameras in stillcam mode use an allocation table, which presents on each line some data about the given image. In this line, byte 0 is a one-byte code for pixel dimensions and compression setting. Then some more bytes give the starting and ending locations of the photo in the camera's memory (actually irrelevant and superfluous information, because you can only ask for the photos in sequence, and with a command which has nothing to do with its memory location at all). Then some more bytes obviously have something to do with contrast, brightness, white balance, color balance, and so on. But I have no more idea than the Man in the Moon how those bytes are supposed to be interpreted. The SQ905 gives no such equivalent information while in streaming mode, and so there is nothing at all which could be done with the nonexistent information. But the SQ905C does obviously give such information, in a few bytes in the header of each frame. As far as I know, SQ905 (is that actually cheez camera?) You know, I really do not know the answer to that. The relation between some of these outfits is very confusing. But what I *think* I know is -- Standard Quality Technology (SQ, or SQ) www.sq.com.tw claims to make the chips, and then a lot of companies sell cameras with those chips. -- CHE-eZ appears to me to be one of the companies which produces cameras, which appears to be an activity of, more or less, putting a plastic case and a decal or stencil logo on the outside of a plastic case containing the electronics which allegedly came from SQ. There are lots of companies that do that, as I said. -- The usb.ids file seems to think that Vendor 0x2770 is some Japanese company called NHL. I think that the usb.ids file is probably not correct and the number belongs to SQ, which actually makes the chips and is not (for example) a mail drop for some other company. But how could I actually know? I don't. What is the real story? Perhaps you can enlighten _me_. .. ... is a regular digital camera not a mobile camera module, so in that case it could be handled in gspca and totally control through usb_control_msg. Well the issue here with the supported SQ cameras is to be able to process better the data that came out of the camera. There is nothing which can be set up through usb_control_msg. These cameras do not have any control settings for changing what goes on inside the camera. The SQ905 cameras, as I said, do not even provide any data other than direct image data, whle streaming (though they do in stillcam mode). So one would not be
