Re: [PATCH] Add RGB555X and RGB565X formats to pxa-camera
Dne Po 3. srpna 2009 14:31:12 Guennadi Liakhovetski napsal(a):
On Mon, 3 Aug 2009, Eric Miao wrote:
Marek Vasut wrote:
Hi!
Eric, would you mind applying ?
From 4dcbff010e996f4c6e5761b3c19f5d863ab51b39 Mon Sep 17 00:00:00 2001
From: Marek Vasut marek.va...@gmail.com
Date: Mon, 3 Aug 2009 10:27:57 +0200
Subject: [PATCH] Add RGB555X and RGB565X formats to pxa-camera
Those formats are requiered on widely used OmniVision OV96xx cameras.
Those formats are nothing more then endian-swapped RGB555 and RGB565.
Signed-off-by: Marek Vasut marek.va...@gmail.com
Acked-by: Eric Miao eric.y.m...@gmail.com
Guennadi,
Would be better if this gets merged by you, thanks.
Indeed it would, and I do have a couple of questions to this and related
patches:
1. Marek, you're saying, you need these formats for the OV96xx camera. Yre
you using the patch from Stefan Herbrechtsmeier to support ov96xx or some
other?
2. Mike, while reviewing this patch I came across code in
pxa_camera_setup_cicr(), introduced by your earlier patch:
case V4L2_PIX_FMT_RGB555:
cicr1 |= CICR1_RGB_BPP_VAL(1) | CICR1_RGBT_CONV_VAL(2) |
CICR1_TBIT | CICR1_COLOR_SP_VAL(1);
break;
Why are you enabling the RGB to RGBT conversion here unconditionally?
Generally, what are the advantages of configuring CICR1 for a specific RGB
format compared to using just a raw capture? Do I understand it right,
that ATM we are not using any of those features?
Thanks
Guennadi
---
drivers/media/video/pxa_camera.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pxa_camera.c
b/drivers/media/video/pxa_camera.c
index 46e0d8a..de0fc8a 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -1222,6 +1222,8 @@ static int required_buswidth(const struct
soc_camera_data_format *fmt)
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_RGB565:
case V4L2_PIX_FMT_RGB555:
+ case V4L2_PIX_FMT_RGB565X:
+ case V4L2_PIX_FMT_RGB555X:
return 8;
default:
return fmt-depth;
@@ -1260,6 +1262,8 @@ static int pxa_camera_get_formats(struct
soc_camera_device *icd, int idx,
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_RGB565:
case V4L2_PIX_FMT_RGB555:
+ case V4L2_PIX_FMT_RGB565X:
+ case V4L2_PIX_FMT_RGB555X:
formats++;
if (xlate) {
xlate-host_fmt = icd-formats + idx;
---
Guennadi Liakhovetski
What should we do with this patch? Any updates? I spoke to Guennadi and he
thinks it's not a good idea to apply it (as pxaqci doesnt support those
formats). But to my understanding, those formats are endian-swapped versions of
the other ones without X at the end so there shouldnt be a problem with it.
--
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 RGB555X and RGB565X formats to pxa-camera
Dne So 5. září 2009 10:55:55 Guennadi Liakhovetski napsal(a):
On Sat, 5 Sep 2009, Marek Vasut wrote:
drivers/media/video/pxa_camera.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pxa_camera.c
b/drivers/media/video/pxa_camera.c
index 46e0d8a..de0fc8a 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -1222,6 +1222,8 @@ static int required_buswidth(const struct
soc_camera_data_format *fmt)
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_RGB565:
case V4L2_PIX_FMT_RGB555:
+ case V4L2_PIX_FMT_RGB565X:
+ case V4L2_PIX_FMT_RGB555X:
return 8;
default:
return fmt-depth;
@@ -1260,6 +1262,8 @@ static int pxa_camera_get_formats(struct
soc_camera_device *icd, int idx,
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_RGB565:
case V4L2_PIX_FMT_RGB555:
+ case V4L2_PIX_FMT_RGB565X:
+ case V4L2_PIX_FMT_RGB555X:
formats++;
if (xlate) {
xlate-host_fmt = icd-formats + idx;
What should we do with this patch? Any updates? I spoke to Guennadi and
he thinks it's not a good idea to apply it (as pxaqci doesnt support
those formats). But to my understanding, those formats are endian-swapped
versions of the other ones without X at the end so there shouldnt be a
problem with it.
Marek, please, look in PXA270 datasheet. To support a specific pixel
format means, e.g., to be able to process it further, according to this
format's particular colour component ordering. Process further can mean
convert to another format, extract various information from the data
(statistics, etc.)... Now RGB555 looks like (from wikipedia)
15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
R4 R3 R2 R1 R0 G4 G3 G2 G1 G1 B4 B3 B2 B1 B1 --
(Actually, I thought bit 15 was unused, but it doesn't matter for this
discussion.) Now, imagine what happens if you swap the two bytes. I don't
think the PXA will still be able to meaningfully process that format.
Not on the pxa side, but on the camera side -- Bs and Rs swapped in the diagram
above.
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
DVB USB stream parameters
What are preferred BULK stream parameters, .count and .buffersize? for USB2.0? for USB1.1? buffersize, which is URB size, have great effect to system load. For example 512 bytes generates about 10x more wakeups than 5120. It is quite clear that 512 is too small for whole DVB stream. I did some test and looks like all USB2.0 devices I have here allow x512 or x188 sizes. Heinrich Langos did some measurements and results can be seen here: http://www.linuxtv.org/wiki/index.php/User:Hlangos In my understanding we should found some balance between URB size and transferred stream bandwidth. For example DVB-T stream, when common transmission parameters are used, is more than 20Mbit/sec. There is also USB bridge chips which does have two or more different standard frontends needed different stream bandwidths. Should we add new module param for override module default? a800BULK 7x 4096= 28672 af9005 BULK 10x 4096= 40960 USB1.1 BUGFIX: x512=x188 af9015 BULK 6x 3072= 3072 BUGFIX: x512=x188 anysee BULK 8x 512= 4096 ce6230 BULK 6x 512= 3072 cinergyT2 BULK 5x 512= 2560 cxusb BULK 5x 8192= 40960 cxusb BULK 7x 4096= 28672 dib0700 BULK 4x39480=157920 210x188 !!HUGE!! dibusb-mb BULK 7x 4096= 28672 56x512 dibusb-mc BULK 7x 4096= 28672 digitv BULK 7x 4096= 28672 dtt200u BULK 7x 4096= 28672 dtv5100 BULK 8x 4096= 32768 dw2102 BULK 8x 4096= 32768 gl861 BULK 7x 512= 3584 gp8psk BULK 7x 8192= 57344 m920x BULK 8x 512= 4096 m920x BULK 8x16384=131072 256x512 !!HUGE!! nova-t-usb2 BULK 7x 4096= 28672 opera1 BULK 10x 4096= 40960 umt-010 BULK 10x 512= 5120 vp702x BULK 10x 4096= 40960 vp7045 BULK 7x 4096= 28672 au6610 ISOC 5 frames 40 size 942 ttusb2 ISOC 5 frames 4 size 942 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
[PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb for the following changeset: 01/01: cx18: ir-kbd-i2c initialization data should point to a persistent object http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=471784201e1b cx18-i2c.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) I've marked this one a high priority so cx18 users can have working IR input. Thanks go to Dustin Mitchell for reporting the cx18 problem and testing the patch on a 2.6.30 kernel for me. Thanks go to Brian Rogers for pointing out the solution in the context of submitting a patch for a few other drivers. 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
generic question
I installed _all_ dvb-v4l modules after compiling latest source because at the time I couldn't use make menuconfig (didn't have ncurses installed) Is there a way I can retrospectively remove some compiled/installed modules so that I'm only using the ones I need? I only need modules associated with: http://www.linuxtv.org/wiki/index.php/Saa7162_devices#DNTV_PCI_Express_cards Cheers, Jed -- 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: generic question
Actually I just realised... I think when the system reboots it will only load the modules it needs from /lib/modules/[kernel version]/kernel/drivers/media... It won't load everything in that directory into the kernel/memory right? So the only reason one might want to use make menuconfig; is to prevent irrelevant compiled modules ending up in... /lib/modules/[kernel version]/kernel/drivers/media Feel free to correct if this understanding is wrong. Cheers Jed wrote: I installed _all_ dvb-v4l modules after compiling latest source because at the time I couldn't use make menuconfig (didn't have ncurses installed) Is there a way I can retrospectively remove some compiled/installed modules so that I'm only using the ones I need? I only need modules associated with: http://www.linuxtv.org/wiki/index.php/Saa7162_devices#DNTV_PCI_Express_cards Cheers, Jed -- 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
Fwd: [PULL] http://www.kernellabs.com/hg/~stoth/saa7164-merge
Oops, this went to the wrong list. Original Message Subject: [PULL] http://www.kernellabs.com/hg/~stoth/saa7164-merge Date: Thu, 03 Sep 2009 23:35:29 -0400 From: Steven Toth st...@kernellabs.com To: Linux Kernel Mailing List linux-ker...@vger.kernel.org, Mauro Carvalho Chehab mche...@infradead.org Hello Mauro, This patch series adds support for the NXP SAA7164 PCIe A/V bridge used by the Hauppauge HVR-2200 and HVR-2250 series of products. Support is limited to DVB-T / ATSC / QAM digital TV only. The driver has been in development (on and off) for around a year and the KernelLabs saa7164-stable tree (from which this patch set was prepared) has been in testing worldwide since approx May(?) 2009. The project page including links for firmware downloads, MythTV and Wiki instructions is here: http://www.kernellabs.com/blog/?page_id=17 Two general observations with the tree: 1. The driver is a little verbose during initial module load, I need to trim a few lines of debug. 2. During 64bit compile I have one compile time warning to be addressed. Both of these will be resolved shortly and should not stop the driver being merged and made available to a much wider range of testers. So, please pull from http://www.kernellabs.com/hg/~stoth/saa7164-merge - Add the SAA7164 I2C bus identifier - SAA7164: Add support for the NXP SAA7164 silicon - SAA7164: Fix some 32/64bit compile time warnings - SAA7164: Adjust I/F's to the TDA10048 enabling DVB-T lock - SAA7164: Email address change - SAA7164: Remove volatiles for PCI writes (coding style violation) - SAA7164: Increase firmware load tolerance - SAA7164: OOPS avoidance during interrupt handling - SAA7164: Removed spurious I2C errors during driver load with DVB-T boards. - SAA7164: Fix the 88021 definition to work with production boards. - SAA7164: Fixed the missing eeprom parse on a specific board. - SAA7164: Fix IRQ related system hang when firmware is not found. - SAA7164: Fix i2c eeprom read errors during load (some boards). - SAA7164: Ensure we specify I/F's for all bandwidths - SAA7164: Added waitsecs module parameter - SAA7164: Cleanup a printk - SAA7164: Increase the firmware command timeout to avoid firmware errors. - SAA7164: Removed a duplicate call to address any PCI quirks. - SAA7164: IRQ / message timeout related change - SAA7164: Removed spurious debug - SAA7164: HVR2250 changes related to attach time tuner configuration - SAA7164: Remove meaningless if'0 code - SAA7164: Minor i2c assignment cleanup - SAA7164: Ensure the HVR-2200 second tuner is configured in slave mode. - SAA7164: Add support for a new HVR-2250 hardware revision b/linux/Documentation/video4linux/CARDLIST.saa7164 |8 b/linux/drivers/media/video/saa7164/Kconfig | 19 b/linux/drivers/media/video/saa7164/Makefile | 12 b/linux/drivers/media/video/saa7164/saa7164-api.c| 778 + b/linux/drivers/media/video/saa7164/saa7164-buffer.c | 162 ++ b/linux/drivers/media/video/saa7164/saa7164-bus.c| 448 + b/linux/drivers/media/video/saa7164/saa7164-cards.c | 600 +++ b/linux/drivers/media/video/saa7164/saa7164-cmd.c| 529 ++ b/linux/drivers/media/video/saa7164/saa7164-core.c | 797 ++ b/linux/drivers/media/video/saa7164/saa7164-dvb.c| 594 +++ b/linux/drivers/media/video/saa7164/saa7164-fw.c | 632 +++ b/linux/drivers/media/video/saa7164/saa7164-i2c.c| 202 ++ b/linux/drivers/media/video/saa7164/saa7164-reg.h| 183 ++ b/linux/drivers/media/video/saa7164/saa7164-types.h | 287 +++ b/linux/drivers/media/video/saa7164/saa7164.h| 405 + b/v4l/scripts/saa7164.pl | 57 linux/Documentation/video4linux/CARDLIST.saa7164 |5 linux/drivers/media/video/Kconfig|2 linux/drivers/media/video/Makefile |1 linux/drivers/media/video/saa7164/saa7164-api.c |6 linux/drivers/media/video/saa7164/saa7164-buffer.c | 15 linux/drivers/media/video/saa7164/saa7164-bus.c |6 linux/drivers/media/video/saa7164/saa7164-cards.c| 74 linux/drivers/media/video/saa7164/saa7164-cmd.c | 47 linux/drivers/media/video/saa7164/saa7164-core.c | 98 - linux/drivers/media/video/saa7164/saa7164-dvb.c | 70 linux/drivers/media/video/saa7164/saa7164-fw.c | 10 linux/drivers/media/video/saa7164/saa7164.h | 18 linux/include/linux/i2c-id.h |1 v4l/scripts/cardlist |3 v4l/scripts/fix_dvb_customise.pl |3 v4l/versions.txt |1 32 files changed, 5956 insertions(+), 117 deletions(-) Thanks, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a
Re: problem building v4l2-spec from docbook source
Is it possible to create a link on the linuxtv.org website to the latest dvb and v4l spec in pdf? For dvb the v3 is still on the documentation page. Peter Németh Márton wrote: Mauro Carvalho Chehab wrote: Em Thu, 3 Sep 2009 08:54:55 -0300 Mauro Carvalho Chehab mche...@infradead.org escreveu: Em Thu, 03 Sep 2009 07:23:45 +0200 Németh Márton nm...@freemail.hu escreveu: Try to replace Role to role. Maybe it is just another case where you need to use lowercase with some xml engines. Ok, I just added a patch that does this to remote_controllers.sgml: -rowentryemphasis Role=boldMiscelaneous keys/emphasis/entry/row +rowentryemphasis role=boldMiscelaneous keys/emphasis/entry/row changeset: 12615:2b49813f8482 tag: tip user:Mauro Carvalho Chehab mche...@redhat.com date:Thu Sep 03 09:06:34 2009 -0300 summary: v4l2-spec: Fix xmlto compilation with some versions of the tool Please see if this fixes the issue. Thanks, now the make v4l2-spec successfully build the html documentation on my computer. Regards, Márton Németh -- 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
[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:Sat Sep 5 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12615:2b49813f8482 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-armv5: OK linux-2.6.31-rc8-armv5: OK 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-armv5-ixp: OK linux-2.6.31-rc8-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-rc8-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS 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: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc8-i686: OK 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-m32r: OK linux-2.6.31-rc8-m32r: OK linux-2.6.30-mips: ERRORS linux-2.6.31-rc8-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc8-powerpc64: OK linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc8-x86_64: OK sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc8): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-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/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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
Hauppauge HVR 1110 : recognized but doesn't work
( new subject from my previous ec168 mail ) 2009/9/4 hermann pitton hermann-pit...@arcor.de Without knowing the kernel version on your mythbuntu I can't tell anything. For what I know so far, all HVR 1110 variants should be supported with recent v4l-dvb code. We run into some maintenance trouble, because we don't know on which of those are additional LNAs, maybe even different types of LNAs. Currently it looks like that we have some Pinnacle 310i devices broken in favour to have in detail unknown HVR 1110 boards working with LNA support. It would be much better to escape from such and not to add more and more unclear hardware on it. For broken Pinnacle LNA devices are patches to test available to get them back, others still do work unchanged, also to enable antenna voltage for those in need of it is possible. You should try your HVR 1110 variant with recent code and report again with details from dmesg for it, if it still should fail. Cheers, Hermann i managed to get a hold of that card (well 200km to install another tv card, but bough the wrong one so i'm trying that one again.) : uname -a Linux pvr 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux dmesg ( at least what is relevant ) : [ 5.711223] saa7134 :01:09.0: PCI INT A - Link[LNKB] - GSI 18 (level, l ow) - IRQ 18 [ 5.711228] saa7133[0]: found at :01:09.0, rev: 209, irq: 18, latency: 64 , mmio: 0xddeff800 [ 5.711234] saa7133[0]: subsystem: 0070:6707, board: Hauppauge WinTV-HVR1120 DVB-T/Hybrid [card=156,autodetected] [ 5.711278] saa7133[0]: board init: gpio is 4 [ 5.753843] cx88/0: cx2388x v4l2 driver version 0.0.7 loaded [ 5.756179] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded [ 5.809164] psmouse serio1: ID: 00 00 64ACPI: PCI Interrupt Link [LAZA] enabl ed at IRQ 20 [ 5.816518] HDA Intel :00:05.0: PCI INT B - Link[LAZA] - GSI 20 (level, low) - IRQ 20 [ 5.816587] HDA Intel :00:05.0: setting latency timer to 64 [ 5.877483] usb 1-4: reset high speed USB device using ehci_hcd and address 3 [ 5.884015] saa7133[0]: i2c eeprom 00: 70 00 07 67 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 [ 5.884021] saa7133[0]: i2c eeprom 10: ff ff ff 0e ff 20 ff ff ff ff ff ff ff ff ff ff [ 5.884026] saa7133[0]: i2c eeprom 20: 01 40 01 32 32 01 01 33 88 ff 00 b0 ff ff ff ff [ 5.884031] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 5.884037] saa7133[0]: i2c eeprom 40: ff 35 00 c0 96 10 06 32 97 04 00 20 00 ff ff ff [ 5.884042] saa7133[0]: i2c eeprom 50: ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 5.884047] saa7133[0]: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 5.884052] saa7133[0]: i2c eeprom 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 5.884056] saa7133[0]: i2c eeprom 80: 84 09 00 04 20 77 00 40 5c 05 5f f0 73 05 29 00 [ 5.884062] saa7133[0]: i2c eeprom 90: 84 08 00 06 89 06 01 00 95 29 8d 72 07 70 73 09 [ 5.884067] saa7133[0]: i2c eeprom a0: 23 5f 73 0a f4 9b 72 0b 2f 72 0e 01 72 0f 01 72 [ 5.884072] saa7133[0]: i2c eeprom b0: 10 01 72 11 ff 73 13 a2 69 79 29 00 00 00 00 00 [ 5.884078] saa7133[0]: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 5.884083] saa7133[0]: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 5.884088] saa7133[0]: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 5.884093] saa7133[0]: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 5.884101] tveeprom 2-0050: Hauppauge model 67209, rev C2F5, serial# 6227292 [ 5.884103] tveeprom 2-0050: MAC address is 00-0D-FE-5F-05-5C [ 5.884105] tveeprom 2-0050: tuner model is NXP 18271C2 (idx 155, type 54) [ 5.884107] tveeprom 2-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D 1/K) ATSC/DVB Digital (eeprom 0xf4) [ 5.884109] tveeprom 2-0050: audio processor is SAA7131 (idx 41) [ 5.884110] tveeprom 2-0050: decoder processor is SAA7131 (idx 35) [ 5.884112] tveeprom 2-0050: has radio, has IR receiver, has no IR transmitte r [ 5.884114] saa7133[0]: hauppauge eeprom: model=67209 [ 5.956082] tuner 2-004b: chip found @ 0x96 (saa7133[0]) [ 6.009348] phy0: Selected rate control algorithm 'pid' [ 6.036025] tda829x 2-004b: setting tuner address to 60 [ 6.083703] tda18271 2-0060: creating new instance [ 6.132022] TDA18271HD/C2 detected @ 2-0060 [ 6.236015] hda_codec: Unknown model for ALC883, trying auto-probe from BIOS. .. [ 7.464017] tda18271: performing RF tracking filter calibration [ 25.668014] tda18271: RF tracking filter calibration complete [ 25.724014] tda829x 2-004b: type set to tda8290+18271 [ 30.700128] saa7133[0]: registered device video0 [v4l2] [ 30.700168] saa7133[0]: registered device vbi0 [ 30.700202] saa7133[0]: registered device radio0 [
Re: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
Hi Andy, On Sat, 05 Sep 2009 10:13:41 -0400, Andy Walls wrote: Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb for the following changeset: 01/01: cx18: ir-kbd-i2c initialization data should point to a persistent object http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=471784201e1b cx18-i2c.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) I've marked this one a high priority so cx18 users can have working IR input. Thanks go to Dustin Mitchell for reporting the cx18 problem and testing the patch on a 2.6.30 kernel for me. Thanks go to Brian Rogers for pointing out the solution in the context of submitting a patch for a few other drivers. Good catch. Acked-by: Jean Delvare kh...@linux-fr.org As far as I can see, the em28xx and saa7134 drivers have the exact same problem. Is there anyone working on this? -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generic question
The compile install completed without issue then I rebooted but j...@jed-desktop:/var/log$ sudo lsmod Module Size Used by binfmt_misc18572 1 bridge 63776 0 stp11140 1 bridge bnep 22912 2 video 29204 0 output 11648 1 video input_polldev 12688 0 lp 19588 0 snd_hda_intel 557492 4 snd_pcm_oss52352 0 snd_mixer_oss 24960 1 snd_pcm_oss snd_pcm99464 2 snd_hda_intel,snd_pcm_oss snd_seq_dummy 11524 0 snd_seq_oss41984 0 snd_seq_midi 15744 0 snd_rawmidi33920 1 snd_seq_midi snd_seq_midi_event 16512 2 snd_seq_oss,snd_seq_midi snd_seq66272 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_timer 34064 2 snd_pcm,snd_seq iTCO_wdt 21712 0 snd_seq_device 16276 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq pcspkr 11136 0 ppdev 16904 0 iTCO_vendor_support12420 1 iTCO_wdt snd78920 17 snd_hda_intel,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device soundcore 16800 1 snd snd_page_alloc 18704 2 snd_hda_intel,snd_pcm parport_pc 45096 1 parport49584 3 lp,ppdev,parport_pc usbhid 47040 0 intel_agp 39408 0 ohci1394 42164 0 ieee1394 108288 1 ohci1394 r8169 46596 0 mii14464 1 r8169 fbcon 49792 0 tileblit 11264 1 fbcon font 17024 1 fbcon bitblit14464 1 fbcon softcursor 10368 1 bitblit ...Where's the module I need? And this is all that's in /etc/modules... lp rtc udev has not created any devices nodes for DVB V4L: j...@jed-desktop:/var/log$ ls -l /dev/dvb ls: cannot access /dev/dvb: No such file or directory j...@jed-desktop:/var/log$ ls -l /dev/v4l ls: cannot access /dev/v4l: No such file or directory I can't see anything relating to 7162 devices here: http://linuxtv.org/hg/v4l-dvb?cmd=file;file=linux/Documentation/video4linux/CARDLIST.tuner;filenode=-1;style=raw Perhaps the module for 7162 devices is not in the main source tree yet? Admittedly I'm not quite sure what I'm looking for! I've got a copy of various logs from /var/log, many extraneous, but just trying to cover all bases, lemme know I can send! Any advice/help greatly appreciated. Cheers, Jed Jed wrote: Actually I just realised... I think when the system reboots it will only load the modules it needs from /lib/modules/[kernel version]/kernel/drivers/media... It won't load everything in that directory into the kernel/memory right? So the only reason one might want to use make menuconfig; is to prevent irrelevant compiled modules ending up in... /lib/modules/[kernel version]/kernel/drivers/media Feel free to correct if this understanding is wrong. Cheers Jed wrote: I installed _all_ dvb-v4l modules after compiling latest source because at the time I couldn't use make menuconfig (didn't have ncurses installed) Is there a way I can retrospectively remove some compiled/installed modules so that I'm only using the ones I need? I only need modules associated with: http://www.linuxtv.org/wiki/index.php/Saa7162_devices#DNTV_PCI_Express_cards Cheers, Jed -- 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
[PULL] http://udev.netup.ru/hg/v4l-dvb-commits
Mauro, Please pull from http://udev.netup.ru/hg/v4l-dvb-commits for the following changeset: 01/01: Fix gpio mutex in NetUP Dual DVB-S2 CI card. http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=2f1119c624eb cimax2.c | 12 ++-- cx23885-core.c |1 + cx23885.h |1 + 3 files changed, 8 insertions(+), 6 deletions(-) Thanks, Igor -- 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: generic question
I think I know why this was not working... I was using main hg source tree instead of: http://www.jusst.de/hg/saa716x/ My bad, still quite a n00b I guess, but at least I'm learning! :-) I will take it from there Jed wrote: The compile install completed without issue then I rebooted but j...@jed-desktop:/var/log$ sudo lsmod Module Size Used by binfmt_misc18572 1 bridge 63776 0 stp11140 1 bridge bnep 22912 2 video 29204 0 output 11648 1 video input_polldev 12688 0 lp 19588 0 snd_hda_intel 557492 4 snd_pcm_oss52352 0 snd_mixer_oss 24960 1 snd_pcm_oss snd_pcm99464 2 snd_hda_intel,snd_pcm_oss snd_seq_dummy 11524 0 snd_seq_oss41984 0 snd_seq_midi 15744 0 snd_rawmidi33920 1 snd_seq_midi snd_seq_midi_event 16512 2 snd_seq_oss,snd_seq_midi snd_seq66272 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_timer 34064 2 snd_pcm,snd_seq iTCO_wdt 21712 0 snd_seq_device 16276 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq pcspkr 11136 0 ppdev 16904 0 iTCO_vendor_support12420 1 iTCO_wdt snd78920 17 snd_hda_intel,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device soundcore 16800 1 snd snd_page_alloc 18704 2 snd_hda_intel,snd_pcm parport_pc 45096 1 parport49584 3 lp,ppdev,parport_pc usbhid 47040 0 intel_agp 39408 0 ohci1394 42164 0 ieee1394 108288 1 ohci1394 r8169 46596 0 mii14464 1 r8169 fbcon 49792 0 tileblit 11264 1 fbcon font 17024 1 fbcon bitblit14464 1 fbcon softcursor 10368 1 bitblit ...Where's the module I need? And this is all that's in /etc/modules... lp rtc udev has not created any devices nodes for DVB V4L: j...@jed-desktop:/var/log$ ls -l /dev/dvb ls: cannot access /dev/dvb: No such file or directory j...@jed-desktop:/var/log$ ls -l /dev/v4l ls: cannot access /dev/v4l: No such file or directory I can't see anything relating to 7162 devices here: http://linuxtv.org/hg/v4l-dvb?cmd=file;file=linux/Documentation/video4linux/CARDLIST.tuner;filenode=-1;style=raw Perhaps the module for 7162 devices is not in the main source tree yet? Admittedly I'm not quite sure what I'm looking for! I've got a copy of various logs from /var/log, many extraneous, but just trying to cover all bases, lemme know I can send! Any advice/help greatly appreciated. Cheers, Jed Jed wrote: Actually I just realised... I think when the system reboots it will only load the modules it needs from /lib/modules/[kernel version]/kernel/drivers/media... It won't load everything in that directory into the kernel/memory right? So the only reason one might want to use make menuconfig; is to prevent irrelevant compiled modules ending up in... /lib/modules/[kernel version]/kernel/drivers/media Feel free to correct if this understanding is wrong. Cheers Jed wrote: I installed _all_ dvb-v4l modules after compiling latest source because at the time I couldn't use make menuconfig (didn't have ncurses installed) Is there a way I can retrospectively remove some compiled/installed modules so that I'm only using the ones I need? I only need modules associated with: http://www.linuxtv.org/wiki/index.php/Saa7162_devices#DNTV_PCI_Express_cards Cheers, Jed -- 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: SAA716x driver module
Hi, On Wed, Sep 2, 2009 at 10:12 PM, Jedjedi.the...@gmail.com wrote: On Mon, Aug 31, 2009 at 7:26 AM, jedjedi.the...@gmail.com wrote: Can someone please advise if the SAA716x driver module: http://www.linuxtv.org/wiki/index.php/NXP_SAA716x#Driver_Development Is now ready for SAA7162 devices: http://www.linuxtv.org/wiki/index.php/Saa7162_devices AFAIK Manu Abraham's driver is the most developed and it doesn't even tune yet. Actually this appears to suggest otherwise... http://jusst.de/hg/saa716x/ Can anybody comment? Manu preferably! :-D Sorry about the long delay in the reply being out of station, with a large mailbox to be processed. The saa716x driver currently has been tested only on the Technotrend TT S2 6400 Dual DVB-S2 Premium (a card with H.264 Hardware decoder and HDMI output and other nice features) for very basic functionality (tune + stream capture) as of now. A lot of stuff is still pending. Regards, 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] Add RGB555X and RGB565X formats to pxa-camera
On Sat, 5 Sep 2009, Marek Vasut wrote:
Dne So 5. září 2009 10:55:55 Guennadi Liakhovetski napsal(a):
On Sat, 5 Sep 2009, Marek Vasut wrote:
drivers/media/video/pxa_camera.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pxa_camera.c
b/drivers/media/video/pxa_camera.c
index 46e0d8a..de0fc8a 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -1222,6 +1222,8 @@ static int required_buswidth(const struct
soc_camera_data_format *fmt)
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_RGB565:
case V4L2_PIX_FMT_RGB555:
+ case V4L2_PIX_FMT_RGB565X:
+ case V4L2_PIX_FMT_RGB555X:
return 8;
default:
return fmt-depth;
@@ -1260,6 +1262,8 @@ static int pxa_camera_get_formats(struct
soc_camera_device *icd, int idx,
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_RGB565:
case V4L2_PIX_FMT_RGB555:
+ case V4L2_PIX_FMT_RGB565X:
+ case V4L2_PIX_FMT_RGB555X:
formats++;
if (xlate) {
xlate-host_fmt = icd-formats + idx;
What should we do with this patch? Any updates? I spoke to Guennadi and
he thinks it's not a good idea to apply it (as pxaqci doesnt support
those formats). But to my understanding, those formats are endian-swapped
versions of the other ones without X at the end so there shouldnt be a
problem with it.
Marek, please, look in PXA270 datasheet. To support a specific pixel
format means, e.g., to be able to process it further, according to this
format's particular colour component ordering. Process further can mean
convert to another format, extract various information from the data
(statistics, etc.)... Now RGB555 looks like (from wikipedia)
15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
R4 R3 R2 R1 R0 G4 G3 G2 G1 G1 B4 B3 B2 B1 B1 --
(Actually, I thought bit 15 was unused, but it doesn't matter for this
discussion.) Now, imagine what happens if you swap the two bytes. I don't
think the PXA will still be able to meaningfully process that format.
Not on the pxa side, but on the camera side -- Bs and Rs swapped in the
diagram
above.
And then? Are you trying to tell me, that the PXA then swaps them back?...
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: Terratec Cinergy C HD tuning problems
On Wed, Aug 19, 2009 at 11:10 PM, dsjob...@abo.fi wrote: I'm having some problems with my Terratec Cinergy C PCI DVB-C card. ... /var/log/syslog (when tuning stops working): ... kernel: [55168.360122] mantis_ack_wait (0): Slave RACK Fail ! Hi, I have the same problem: Terratec Cinergy HD DVB-C PCI Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01) VP-2040 PCI DVB-C device TDA10023 MythTV chokes after a while because of the error described above. Also, when I use w_scan, it is not able to scan (tune) for new channels. Similar problem is mentioned here: http://thread.gmane.org/gmane.linux.drivers.dvb/47829 These are my bits: s2-liplianin from http://mercurial.intuxication.org/hg/s2-liplianin (03 Jun) kernel-2.6.29.6-217.2.16.fc11.x86_64 Any hints on how to get this working appreciated. Removing and reinserting the mantis module doesn't seem to help for me. -MartinG -- 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 RGB555X and RGB565X formats to pxa-camera
Dne So 5. září 2009 22:19:42 Guennadi Liakhovetski napsal(a):
On Sat, 5 Sep 2009, Marek Vasut wrote:
Dne So 5. září 2009 10:55:55 Guennadi Liakhovetski napsal(a):
On Sat, 5 Sep 2009, Marek Vasut wrote:
drivers/media/video/pxa_camera.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pxa_camera.c
b/drivers/media/video/pxa_camera.c
index 46e0d8a..de0fc8a 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -1222,6 +1222,8 @@ static int required_buswidth(const struct
soc_camera_data_format *fmt)
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_RGB565:
case V4L2_PIX_FMT_RGB555:
+ case V4L2_PIX_FMT_RGB565X:
+ case V4L2_PIX_FMT_RGB555X:
return 8;
default:
return fmt-depth;
@@ -1260,6 +1262,8 @@ static int pxa_camera_get_formats(struct
soc_camera_device *icd, int idx,
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_RGB565:
case V4L2_PIX_FMT_RGB555:
+ case V4L2_PIX_FMT_RGB565X:
+ case V4L2_PIX_FMT_RGB555X:
formats++;
if (xlate) {
xlate-host_fmt = icd-formats + idx;
What should we do with this patch? Any updates? I spoke to Guennadi
and he thinks it's not a good idea to apply it (as pxaqci doesnt
support those formats). But to my understanding, those formats are
endian-swapped versions of the other ones without X at the end so
there shouldnt be a problem with it.
Marek, please, look in PXA270 datasheet. To support a specific pixel
format means, e.g., to be able to process it further, according to this
format's particular colour component ordering. Process further can mean
convert to another format, extract various information from the data
(statistics, etc.)... Now RGB555 looks like (from wikipedia)
15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
R4 R3 R2 R1 R0 G4 G3 G2 G1 G1 B4 B3 B2 B1 B1 --
(Actually, I thought bit 15 was unused, but it doesn't matter for this
discussion.) Now, imagine what happens if you swap the two bytes. I
don't think the PXA will still be able to meaningfully process that
format.
Not on the pxa side, but on the camera side -- Bs and Rs swapped in the
diagram above.
And then? Are you trying to tell me, that the PXA then swaps them back?...
No, the software has to do it then, I'm trying to tell you that it has nothing
to do with PXA (as PXA really doesnt care if the channel is actually blue or
red).
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: [PATCH] Add RGB555X and RGB565X formats to pxa-camera
On Sat, 5 Sep 2009, Marek Vasut wrote: Dne So 5. záÅà 2009 22:19:42 Guennadi Liakhovetski napsal(a): On Sat, 5 Sep 2009, Marek Vasut wrote: Dne So 5. záÅà 2009 10:55:55 Guennadi Liakhovetski napsal(a): Marek, please, look in PXA270 datasheet. To support a specific pixel format means, e.g., to be able to process it further, according to this format's particular colour component ordering. Process further can mean convert to another format, extract various information from the data (statistics, etc.)... Now RGB555 looks like (from wikipedia) 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 R4 R3 R2 R1 R0 G4 G3 G2 G1 G1 B4 B3 B2 B1 B1 -- (Actually, I thought bit 15 was unused, but it doesn't matter for this discussion.) Now, imagine what happens if you swap the two bytes. I don't think the PXA will still be able to meaningfully process that format. Not on the pxa side, but on the camera side -- Bs and Rs swapped in the diagram above. And then? Are you trying to tell me, that the PXA then swaps them back?... No, the software has to do it then, I'm trying to tell you that it has nothing to do with PXA (as PXA really doesnt care if the channel is actually blue or red). Of course it does. I asked you to swap the above two bytes, you would get this: 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 G1 G0 B4 B3 B2 B1 B0 -- R4 R3 R2 R1 R0 G4 G3 G2 and PXA would still inerpret this as R4 R3 R2 R1 R0 G4 G3 G2 G1 G0 B4 B3 B2 B1 B0 -- i.e., it would take bits R2 R1 R0 G4 G3 for blue, bits B1 B0 -- R4 R3 for green, and bits G1 G0 B4 B3 B2 as red. Which, as you see, makes no sense. That's why I'm saying, that it doesn't support this format, and we can only pass it through as raw data. 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: [PATCH] Add RGB555X and RGB565X formats to pxa-camera
Dne Ne 6. září 2009 00:05:14 Guennadi Liakhovetski napsal(a): On Sat, 5 Sep 2009, Marek Vasut wrote: Dne So 5. záÅà 2009 22:19:42 Guennadi Liakhovetski napsal(a): On Sat, 5 Sep 2009, Marek Vasut wrote: Dne So 5. záÅà 2009 10:55:55 Guennadi Liakhovetski napsal(a): Marek, please, look in PXA270 datasheet. To support a specific pixel format means, e.g., to be able to process it further, according to this format's particular colour component ordering. Process further can mean convert to another format, extract various information from the data (statistics, etc.)... Now RGB555 looks like (from wikipedia) 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 R4 R3 R2 R1 R0 G4 G3 G2 G1 G1 B4 B3 B2 B1 B1 -- (Actually, I thought bit 15 was unused, but it doesn't matter for this discussion.) Now, imagine what happens if you swap the two bytes. I don't think the PXA will still be able to meaningfully process that format. Not on the pxa side, but on the camera side -- Bs and Rs swapped in the diagram above. And then? Are you trying to tell me, that the PXA then swaps them back?... No, the software has to do it then, I'm trying to tell you that it has nothing to do with PXA (as PXA really doesnt care if the channel is actually blue or red). Of course it does. I asked you to swap the above two bytes, you would get this: 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 G1 G0 B4 B3 B2 B1 B0 -- R4 R3 R2 R1 R0 G4 G3 G2 and PXA would still inerpret this as R4 R3 R2 R1 R0 G4 G3 G2 G1 G0 B4 B3 B2 B1 B0 -- i.e., it would take bits R2 R1 R0 G4 G3 for blue, bits B1 B0 -- R4 R3 for green, and bits G1 G0 B4 B3 B2 as red. Which, as you see, makes no sense. That's why I'm saying, that it doesn't support this format, and we can only pass it through as raw data. Ah damn, I see what you mean. What the camera does is it swaps the RED and BLUE channel: 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 B4 B3 B2 B1 B0 G4 G3 G2 G1 G1 R4 R3 R2 R1 R1 -- so it's more a BGR555/565 then. I had to patch fswebcam for this. Sorry for the confusion. 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
