Re: [PATCH] Add RGB555X and RGB565X formats to pxa-camera

2009-09-06 Thread Mike Rapoport
Hi Guennadi,

Guennadi Liakhovetski wrote:
 On Mon, 3 Aug 2009, Mike Rapoport wrote:
 
 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?
 As far as I remember I've tried to overlay the captured imagery using pxa
 overlay1. Most probably it's left here after those tries.
 
 Mike, could you, please, verify that those bits are indeed unneeded and 
 provide patch to remove them?

Unfortunately, I don't have the sensor handy at the time :( The one I've used
then is now broken (physically) and there's no replacement for it :(

 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
 

-- 
Sincerely yours,
Mike.

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


Re: Hauppauge HVR 1110 : recognized but doesn't work

2009-09-06 Thread Morvan Le Meut
Seems to be a mythtv issue :
u...@pvr:~$ scan ./fr-lorient
scanning ./fr-lorient
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder 554166000 0 2 9 3 1 0 0
initial transponder 562166000 0 2 9 3 1 0 0
initial transponder 570166000 0 2 9 3 1 0 0
initial transponder 586166000 0 2 9 3 1 0 0
initial transponder 794166000 0 2 9 3 1 0 0
initial transponder 818166000 0 2 9 3 1 0 0
 tune to: 
 554166000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TR 
  
 ANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
WARNING:  tuning failed!!!
 tune to: 
 554166000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TR 
  
 ANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE (tuning failed)
WARNING:  tuning failed!!!
 tune to: 
 562166000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TR 
  
 ANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
WARNING:  tuning failed!!!
 tune to: 
 562166000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TR 
  
 ANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE (tuning failed)
WARNING:  tuning failed!!!
 tune to: 
 570166000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TR 
  
 ANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
WARNING:  tuning failed!!!
 tune to: 
 570166000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TR 
  
 ANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE (tuning failed)
WARNING:  tuning failed!!!
 tune to: 
 586166000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TR 
  
 ANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
WARNING:  tuning failed!!!
 tune to: 
 586166000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TR 
  
 ANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE (tuning failed)
WARNING:  tuning failed!!!
 tune to: 
 794166000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TR 
  
 ANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
Network Name 'F'
0x 0x0501: pmt_pid 0x006e MR5 -- TF1 HD (running)
0x 0x0502: pmt_pid 0x00d2 MR5 -- France 2 HD (running)
0x 0x0503: pmt_pid 0x0136 MR5 -- M6HD (running)
 tune to: 
 818166000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TR 
  
 ANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
0x 0x0301: pmt_pid 0x0500 CNH -- CANAL+ (running)
0x 0x0302: pmt_pid 0x0501 CNH -- CANAL+ CINEMA (running, scrambled)
0x 0x0303: pmt_pid 0x0502 CNH -- CANAL+ SPORT (running)
0x 0x0304: pmt_pid 0x0503 CNH -- PLANETE (running, scrambled)
0x 0x0306: pmt_pid 0x0505 CNH -- TPS STAR (running)
0x 0x03f0: pmt_pid 0x050a CNH -- (null) (running)
0x 0x03f1: pmt_pid 0x050b CNH -- (null) (running)
Network Name 'F'
 tune to: 
 -10:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_1_2:QAM_64:TRANSMIS 
  
 SION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
__tune_to_transponder:1508: ERROR: Setting frontend parameters failed:
22 Invali  d argument
 tune to: 
 -10:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_1_2:QAM_64:TRANSMIS 
  
 SION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
__tune_to_transponder:1508: ERROR: Setting frontend parameters failed:
22 Invali  d argument
dumping lists (10 services)
Done.

i wonder why mythtv can't use that card when the scan utility can.
(yes, i checked what card the scan utility use )
--
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: Hauppauge HVR 1110 : recognized but doesn't work

2009-09-06 Thread Morvan Le Meut
2009/9/5 Morvan Le Meut mlem...@gmail.com:
 ( new subject from my previous ec168 mail )

 got the firmware from http://steventoth.net/linux/hvr1200/

 using the latest code from linuxtv ( which autodetect the card as an HVR1120 )
 seems the problem is firmware uploading ... wrong file ?
 on the card PCB i got :
  67-038 LF
 the DVB part read
 hauppauge 1110
 dvb-t
 67209 LF rev c2F5
 and the chip read Saa7131e/03/G

for those who may need it, here's a full dmesg output and i forgot to
say that this was on a mythbuntu 9.04 ( the other tv card is an
ADS-tech instant tv dvb-t PCI ) :

[0.00] BIOS EBDA/lowmem at: 0009f000/0009f000
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.28-11-generic (bui...@palmer) (gcc
version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #42-Ubuntu SMP Fri Apr 17
01:57:59 UTC 2009 (Ubuntu 2.6.28-11.42-generic)
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   NSC Geode by NSC
[0.00]   Cyrix CyrixInstead
[0.00]   Centaur CentaurHauls
[0.00]   Transmeta GenuineTMx86
[0.00]   Transmeta TransmetaCPU
[0.00]   UMC UMC UMC UMC
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009f000 (usable)
[0.00]  BIOS-e820: 0009f000 - 000a (reserved)
[0.00]  BIOS-e820: 000e6000 - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 3ffc (usable)
[0.00]  BIOS-e820: 3ffc - 3ffce000 (ACPI data)
[0.00]  BIOS-e820: 3ffce000 - 3fff (ACPI NVS)
[0.00]  BIOS-e820: 3fff - 3fffe000 (reserved)
[0.00]  BIOS-e820: fec0 - fec01000 (reserved)
[0.00]  BIOS-e820: fee0 - fef0 (reserved)
[0.00]  BIOS-e820: fff0 - 0001 (reserved)
[0.00] DMI present.
[0.00] AMI BIOS detected: BIOS may corrupt low RAM, working it around.
[0.00] last_pfn = 0x3ffc0 max_arch_pfn = 0x10
[0.00] Scanning 0 areas for low memory corruption
[0.00] modified physical RAM map:
[0.00]  modified:  - 0001 (reserved)
[0.00]  modified: 0001 - 0009f000 (usable)
[0.00]  modified: 0009f000 - 000a (reserved)
[0.00]  modified: 000e6000 - 0010 (reserved)
[0.00]  modified: 0010 - 3ffc (usable)
[0.00]  modified: 3ffc - 3ffce000 (ACPI data)
[0.00]  modified: 3ffce000 - 3fff (ACPI NVS)
[0.00]  modified: 3fff - 3fffe000 (reserved)
[0.00]  modified: fec0 - fec01000 (reserved)
[0.00]  modified: fee0 - fef0 (reserved)
[0.00]  modified: fff0 - 0001 (reserved)
[0.00] kernel direct mapping tables up to 373fe000 @ 1-16000
[0.00] RAMDISK: 378b2000 - 37fefe50
[0.00] Allocated new RAMDISK: 00881000 - 00fbee50
[0.00] Move RAMDISK from 378b2000 - 37fefe4f
to 00881000 - 00fbee4f
[0.00] ACPI: RSDP 000FA1F0, 0014 (r0 ACPIAM)
[0.00] ACPI: RSDT 3FFC, 0038 (r1 021709 RSDT1317 20090217
MSFT   97)
[0.00] ACPI: FACP 3FFC0200, 0084 (r1 021709 FACP1317 20090217
MSFT   97)
[0.00] ACPI: DSDT 3FFC04A0, 4880 (r1  1ADKR 1ADKR017   17
INTL 20051117)
[0.00] ACPI: FACS 3FFCE000, 0040
[0.00] ACPI: APIC 3FFC0390, 0080 (r1 021709 APIC1317 20090217
MSFT   97)
[0.00] ACPI: MCFG 3FFC0410, 003C (r1 021709 OEMMCFG  20090217
MSFT   97)
[0.00] ACPI: WDRT 3FFC0450, 0047 (r1 021709 NV-WDRT  20090217
MSFT   97)
[0.00] ACPI: OEMB 3FFCE040, 0071 (r1 021709 OEMB1317 20090217
MSFT   97)
[0.00] ACPI: Local APIC address 0xfee0
[0.00] 139MB HIGHMEM available.
[0.00] 883MB LOWMEM available.
[0.00]   mapped low ram: 0 - 373fe000
[0.00]   low ram:  - 373fe000
[0.00]   bootmap 00012000 - 00018e80
[0.00] (9 early reservations) == bootmem [00 - 00373fe000]
[0.00]   #0 [00 - 001000]   BIOS data page ==
[00 - 001000]
[0.00]   #1 [001000 - 002000]EX TRAMPOLINE ==
[001000 - 002000]
[0.00]   #2 [006000 - 007000]   TRAMPOLINE ==
[006000 - 007000]
[0.00]   #3 [10 - 87c52c]TEXT DATA BSS ==
[10 - 87c52c]
[0.00]   #4 [87d000 - 881000]INIT_PG_TABLE ==
[87d000 - 881000]
[0.00]   #5 [09f000 - 10]BIOS reserved ==
[09f000 - 10]
[0.00]   #6 [01 - 012000]  

Re: Hauppauge HVR 1110 : recognized but doesn't work

2009-09-06 Thread Morvan Le Meut
2009/9/6 Morvan Le Meut mlem...@gmail.com:
 i wonder why mythtv can't use that card when the scan utility can.
 (yes, i checked what card the scan utility use )


confirmed with mplayer, the card works but not with mythtv ( got some
DVB: adapter 0 frontend 0 frequency 4294967286 out of range
(17700..85800) in demsg )
--
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] DVB/V4L: ov511 - export snapshot button through input layer

2009-09-06 Thread Hans de Goede

Hi,

The ov511 driver is a v4l1 driver and is deprecated, all supported webcams
are now supported by the gspca_ov519 driver.

Can you please do a patch to the gspca_ov519 driver instead?

Note that the gspca_sn9c20x driver already has support for input events,
if possible please try to locate common code and move that to gspca.c

Regards,

Hans


On 09/04/2009 07:15 AM, Dmitry Torokhov wrote:

From: Bastien Nocerahad...@hadess.net

Register an input device with one button, and for the supported
OV511 webcams, poll and check whether the snapshot button has been
pressed on each new frame.

[d...@mail.ru: fix freeing of phys, plug into Kconfig, make compile]
Signed-off-by: Bastien Nocerahad...@hadess.net
Signed-off-by: Dmitry Torokhovd...@mail.ru
---

Mauro,

This is something that's been sitting in my queue for quite some
time, please consider applying.

Thanks!

  drivers/media/video/Kconfig |8 +++
  drivers/media/video/ov511.c |  109 +++
  drivers/media/video/ov511.h |8 +++
  3 files changed, 116 insertions(+), 9 deletions(-)


diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index dcf9fa9..42573e0 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -888,6 +888,14 @@ config USB_OV511
  To compile this driver as a module, choose M here: the
  module will be called ov511.

+config USB_OV511_SNAPSHOT_BUTTON
+   bool USB OV511 Snapshot Button support
+   depends on USB_OV511
+   depends on INPUT
+   ---help---
+ Say Y here if you want the driver to report snapshot button through
+ input layer.
+
  config USB_SE401
tristate USB SE401 Camera support
depends on VIDEO_V4L1
diff --git a/drivers/media/video/ov511.c b/drivers/media/video/ov511.c
index 0bc2cf5..484165c 100644
--- a/drivers/media/video/ov511.c
+++ b/drivers/media/video/ov511.c
@@ -44,6 +44,8 @@
  #includeasm/processor.h
  #includelinux/mm.h
  #includelinux/device.h
+#includelinux/input.h
+#includelinux/usb/input.h

  #if defined (__i386__)
#includeasm/cpufeature.h
@@ -92,7 +94,7 @@ static int cams   = 1;
  static int compress;
  static int testpat;
  static int dumppix;
-static int led = 1;
+static int led = 1;
  static int dump_bridge;
  static int dump_sensor;
  static int printph;
@@ -352,6 +354,83 @@ rvfree(void *mem, unsigned long size)

  /**
   *
+ * Input device
+ *
+ **/
+#ifdef CONFIG_USB_OV511_SNAPSHOT_BUTTON
+
+static int ov511_input_init(struct usb_ov511 *ov)
+{
+   struct usb_device *udev = ov-dev;
+   struct input_dev *input;
+   int err = -ENOMEM;
+
+   input = input_allocate_device();
+   if (!input)
+   goto err_out;
+
+   usb_make_path(udev, ov-key_phys, OV511_KEY_PHYS_SIZE);
+   strlcat(ov-key_phys, /input0, OV511_KEY_PHYS_SIZE);
+
+   input-name = OV511 Snapshot Button;
+   input-phys = ov-key_phys;
+   usb_to_input_id(udev,input-id);
+   input-dev.parent =udev-dev;
+
+   __set_bit(EV_KEY, input-evbit);
+   __set_bit(KEY_CAMERA, input-keybit);
+
+   err = input_register_device(input);
+   if (err)
+   goto err_out;
+
+   ov-key_input = input;
+   return 0;
+
+err_out:
+   input_free_device(input);
+   return err;
+}
+
+static void ov511_input_cleanup(struct usb_ov511 *ov)
+{
+   if (ov-key_input) {
+   input_unregister_device(ov-key_input);
+   ov-key_input = NULL;
+   }
+}
+
+static void ov511_input_report_key(struct usb_ov511 *ov)
+{
+   struct input_dev *input = ov-key_input;
+
+   if (input) {
+   input_report_key(input, KEY_CAMERA, 1);
+   input_sync(input);
+   input_report_key(input, KEY_CAMERA, 0);
+   input_sync(input);
+   }
+}
+
+#else
+
+static inline int ov511_input_init(struct usb_ov511 *ov)
+{
+   return 0;
+}
+
+static inline void ov511_input_cleanup(struct usb_ov511 *ov)
+{
+}
+
+static inline void ov511_input_report_key(struct usb_ov511 *ov)
+{
+}
+
+#endif /* CONFIG_USB_OV511_SNAPSHOT_BUTTON */
+
+/**
+ *
   * Register I/O
   *
   **/
@@ -1105,7 +1184,6 @@ ov51x_clear_snapshot(struct usb_ov511 *ov)
}
  }

-#if 0
  /* Checks the status of the snapshot button. Returns 1 if it was pressed since
   * it was last cleared, and zero in all other cases (including errors) */
  static int
@@ -1130,7 +1208,6 @@ ov51x_check_snapshot(struct usb_ov511 *ov)

return status;
  }
-#endif

  /* This does an initial reset of an OmniVision sensor and ensures that I2C
   * is synchronized. Returns0 for failure.
@@ -3149,10 +3226,10 @@ 

Re: [PULL] http://www.kernellabs.com/hg/~stoth/saa7164-merge

2009-09-06 Thread Michael Krufky
On Thu, Sep 3, 2009 at 11:35 PM, Steven Tothst...@kernellabs.com wrote:
 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(-)

After testing this tree on my machine, I have hit some minor build
issues, none of which should prevent Steve's tree from being merged,
although it would be extremely helpful to users for my additional
fixes to be merged when Steve's tree gets merged.

Mauro,  After merging Steve's tree, please pull these additional
fixes, or simply pull Steve's 

[PATCH] Add support for Compro VideoMate E800 (DVB-T part only)

2009-09-06 Thread geroin22




Nothing new, just adding Compro VideoMate E800 (DVB-T part only).
Tested with Ubuntu 9.04 kernel 2.6.28 work well.

diff -Naur a/linux/Documentation/video4linux/CARDLIST.cx23885 
b/linux/Documentation/video4linux/CARDLIST.cx23885
--- a/linux/Documentation/video4linux/CARDLIST.cx23885	2009-09-01 
16:43:46.0 +0300
+++ b/linux/Documentation/video4linux/CARDLIST.cx23885	2009-09-06 
15:37:13.373793025 +0300

@@ -23,3 +23,4 @@
 22 - Mygica X8506 DMB-TH [14f1:8651]
 23 - Magic-Pro ProHDTV Extreme 2 [14f1:8657]
 24 - Hauppauge WinTV-HVR1850 [0070:8541]
+ 25 - Compro VideoMate E800   [1858:e800]
diff -Naur a/linux/drivers/media/video/cx23885/cx23885-cards.c 
b/linux/drivers/media/video/cx23885/cx23885-cards.c
--- a/linux/drivers/media/video/cx23885/cx23885-cards.c	2009-09-01 
16:43:46.0 +0300
+++ b/linux/drivers/media/video/cx23885/cx23885-cards.c	2009-09-06 
15:35:23.434293199 +0300

@@ -211,6 +211,10 @@
.portb  = CX23885_MPEG_ENCODER,
.portc  = CX23885_MPEG_DVB,
},
+[CX23885_BOARD_COMPRO_VIDEOMATE_E800] = {
+   .name   = Compro VideoMate E800,
+   .portc  = CX23885_MPEG_DVB,
+   },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);

@@ -342,6 +346,10 @@
.subvendor = 0x0070,
.subdevice = 0x8541,
.card  = CX23885_BOARD_HAUPPAUGE_HVR1850,
+}, {
+   .subvendor = 0x1858,
+   .subdevice = 0xe800,
+   .card  = CX23885_BOARD_COMPRO_VIDEOMATE_E800,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -537,6 +545,7 @@
case CX23885_BOARD_HAUPPAUGE_HVR1500Q:
case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
+case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
/* Tuner Reset Command */
bitmask = 0x04;
break;
@@ -688,6 +697,7 @@
break;
case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
+case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
/* GPIO-2  xc3028 tuner reset */

/* The following GPIO's are on the internal AVCore (cx25840) */
@@ -912,6 +922,7 @@
case CX23885_BOARD_HAUPPAUGE_HVR1255:
case CX23885_BOARD_HAUPPAUGE_HVR1210:
case CX23885_BOARD_HAUPPAUGE_HVR1850:
+case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
default:
ts2-gen_ctrl_val  = 0xc; /* Serial bus + punctured clock */
ts2-ts_clk_en_val = 0x1; /* Enable TS_CLK */
@@ -928,6 +939,7 @@
case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
+case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
dev-sd_cx25840 = v4l2_i2c_new_subdev(dev-v4l2_dev,
dev-i2c_bus[2].i2c_adap,
cx25840, cx25840, 0x88  1, NULL);
diff -Naur a/linux/drivers/media/video/cx23885/cx23885-dvb.c 
b/linux/drivers/media/video/cx23885/cx23885-dvb.c
--- a/linux/drivers/media/video/cx23885/cx23885-dvb.c	2009-09-01 
16:43:46.0 +0300
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c	2009-09-06 
16:09:17.154602943 +0300

@@ -744,6 +744,7 @@
}
case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
+case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
i2c_bus = dev-i2c_bus[0];

fe0-dvb.frontend = dvb_attach(zl10353_attach,
diff -Naur a/linux/drivers/media/video/cx23885/cx23885.h 
b/linux/drivers/media/video/cx23885/cx23885.h
--- a/linux/drivers/media/video/cx23885/cx23885.h	2009-09-01 
16:43:46.0 +0300
+++ b/linux/drivers/media/video/cx23885/cx23885.h	2009-09-06 
15:36:40.229792022 +0300

@@ -79,6 +79,7 @@
#define CX23885_BOARD_MYGICA_X8506 22
#define CX23885_BOARD_MAGICPRO_PROHDTVE2   23
#define CX23885_BOARD_HAUPPAUGE_HVR185024
+#define CX23885_BOARD_COMPRO_VIDEOMATE_E80025

#define GPIO_0 0x0001
#define GPIO_1 0x0002


--
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 support for Compro VideoMate E800 (DVB-T part only)

2009-09-06 Thread Alex Deucher
On Sun, Sep 6, 2009 at 11:33 AM, geroin22geroi...@yandex.ru wrote:



 Nothing new, just adding Compro VideoMate E800 (DVB-T part only).
 Tested with Ubuntu 9.04 kernel 2.6.28 work well.


Please add your Signed-off-by.

 diff -Naur a/linux/Documentation/video4linux/CARDLIST.cx23885
 b/linux/Documentation/video4linux/CARDLIST.cx23885
 --- a/linux/Documentation/video4linux/CARDLIST.cx23885  2009-09-01
 16:43:46.0 +0300
 +++ b/linux/Documentation/video4linux/CARDLIST.cx23885  2009-09-06
 15:37:13.373793025 +0300
 @@ -23,3 +23,4 @@
  22 - Mygica X8506 DMB-TH                                 [14f1:8651]
  23 - Magic-Pro ProHDTV Extreme 2                         [14f1:8657]
  24 - Hauppauge WinTV-HVR1850                             [0070:8541]
 + 25 - Compro VideoMate E800                               [1858:e800]
 diff -Naur a/linux/drivers/media/video/cx23885/cx23885-cards.c
 b/linux/drivers/media/video/cx23885/cx23885-cards.c
 --- a/linux/drivers/media/video/cx23885/cx23885-cards.c 2009-09-01
 16:43:46.0 +0300
 +++ b/linux/drivers/media/video/cx23885/cx23885-cards.c 2009-09-06
 15:35:23.434293199 +0300
 @@ -211,6 +211,10 @@
                .portb          = CX23885_MPEG_ENCODER,
                .portc          = CX23885_MPEG_DVB,
        },
 +        [CX23885_BOARD_COMPRO_VIDEOMATE_E800] = {
 +               .name           = Compro VideoMate E800,
 +               .portc          = CX23885_MPEG_DVB,
 +       },
 };
 const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);

 @@ -342,6 +346,10 @@
                .subvendor = 0x0070,
                .subdevice = 0x8541,
                .card      = CX23885_BOARD_HAUPPAUGE_HVR1850,
 +        }, {
 +               .subvendor = 0x1858,
 +               .subdevice = 0xe800,
 +               .card      = CX23885_BOARD_COMPRO_VIDEOMATE_E800,
        },
 };
 const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
 @@ -537,6 +545,7 @@
        case CX23885_BOARD_HAUPPAUGE_HVR1500Q:
        case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
        case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
 +        case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
                /* Tuner Reset Command */
                bitmask = 0x04;
                break;
 @@ -688,6 +697,7 @@
                break;
        case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
        case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
 +        case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
                /* GPIO-2  xc3028 tuner reset */

                /* The following GPIO's are on the internal AVCore (cx25840)
 */
 @@ -912,6 +922,7 @@
        case CX23885_BOARD_HAUPPAUGE_HVR1255:
        case CX23885_BOARD_HAUPPAUGE_HVR1210:
        case CX23885_BOARD_HAUPPAUGE_HVR1850:
 +        case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
        default:
                ts2-gen_ctrl_val  = 0xc; /* Serial bus + punctured clock */
                ts2-ts_clk_en_val = 0x1; /* Enable TS_CLK */
 @@ -928,6 +939,7 @@
        case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
        case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
        case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
 +        case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
                dev-sd_cx25840 = v4l2_i2c_new_subdev(dev-v4l2_dev,
                                dev-i2c_bus[2].i2c_adap,
                                cx25840, cx25840, 0x88  1, NULL);
 diff -Naur a/linux/drivers/media/video/cx23885/cx23885-dvb.c
 b/linux/drivers/media/video/cx23885/cx23885-dvb.c
 --- a/linux/drivers/media/video/cx23885/cx23885-dvb.c   2009-09-01
 16:43:46.0 +0300
 +++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c   2009-09-06
 16:09:17.154602943 +0300
 @@ -744,6 +744,7 @@
        }
        case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
        case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
 +        case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
                i2c_bus = dev-i2c_bus[0];

                fe0-dvb.frontend = dvb_attach(zl10353_attach,
 diff -Naur a/linux/drivers/media/video/cx23885/cx23885.h
 b/linux/drivers/media/video/cx23885/cx23885.h
 --- a/linux/drivers/media/video/cx23885/cx23885.h       2009-09-01
 16:43:46.0 +0300
 +++ b/linux/drivers/media/video/cx23885/cx23885.h       2009-09-06
 15:36:40.229792022 +0300
 @@ -79,6 +79,7 @@
 #define CX23885_BOARD_MYGICA_X8506             22
 #define CX23885_BOARD_MAGICPRO_PROHDTVE2       23
 #define CX23885_BOARD_HAUPPAUGE_HVR1850        24
 +#define CX23885_BOARD_COMPRO_VIDEOMATE_E800    25

 #define GPIO_0 0x0001
 #define GPIO_1 0x0002


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

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


Re: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb

2009-09-06 Thread Andy Walls
On Sat, 2009-09-05 at 20:46 +0200, Jean Delvare wrote:
 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.

Jean,

 Good catch.

Well I can take very little credit: a user reported a cx18 problem on
the ivtv-users list, and I saw the solution pop up on the LMML for
em28xx and saa7134.


 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?

Not me.  (I don't have a 2.6.30 kernel setup yet.)

Brain Rogers submitted a patch to the LMML and LKML on 4 Sep 09.

Have a look:

http://patchwork.kernel.org/patch/45707/

(The patch does not have V4L2 backward comptability stuff.)

Regards,
Andy

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


Re: [PATCH] Add RGB555X and RGB565X formats to pxa-camera

2009-09-06 Thread Marek Vasut
Dne Ne 6. září 2009 18:52:55 Guennadi Liakhovetski napsal(a):
 On Sun, 6 Sep 2009, Marek Vasut wrote:
  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.

 Ok, this is, of course, something different. In this case you, probably,
 could deceive the PXA to handle blue as red and the other way round, but
 still, I would prefer not to do that. Hence my suggestion remains - pass
 these formats as raw data.

Which is bogus from the camera point of view.

 The only case when you might want to put the PXA into RGB555 mode, while
 feeding BGR555 to it, is you want to use the QCI to set the transparency
 bit for you. But we currently do not support this any way, not in a
 configurable way at least. You would need to implement some sort of a
 global (one-bit) alpha control for pxa_camera to use this. Any need for
 this?

 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: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb

2009-09-06 Thread Jean Delvare
On Sun, 06 Sep 2009 12:31:24 -0400, Andy Walls wrote:
 On Sat, 2009-09-05 at 20:46 +0200, Jean Delvare wrote:
  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.
 
 Jean,
 
  Good catch.
 
 Well I can take very little credit: a user reported a cx18 problem on
 the ivtv-users list, and I saw the solution pop up on the LMML for
 em28xx and saa7134.
 
 
  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?
 
 Not me.  (I don't have a 2.6.30 kernel setup yet.)
 
 Brain Rogers submitted a patch to the LMML and LKML on 4 Sep 09.
 
 Have a look:
 
 http://patchwork.kernel.org/patch/45707/
 
 (The patch does not have V4L2 backward comptability stuff.)

OK, very good then.

-- 
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: [PATCH] Add support for Compro VideoMate E800 (DVB-T part only)

2009-09-06 Thread geroin22

Alex Deucher пишет:

On Sun, Sep 6, 2009 at 11:33 AM, geroin22geroi...@yandex.ru wrote:
  


Nothing new, just adding Compro VideoMate E800 (DVB-T part only).
Tested with Ubuntu 9.04 kernel 2.6.28 work well.




Please add your Signed-off-by.

  

diff -Naur a/linux/Documentation/video4linux/CARDLIST.cx23885
b/linux/Documentation/video4linux/CARDLIST.cx23885
--- a/linux/Documentation/video4linux/CARDLIST.cx23885  2009-09-01
16:43:46.0 +0300
+++ b/linux/Documentation/video4linux/CARDLIST.cx23885  2009-09-06
15:37:13.373793025 +0300
@@ -23,3 +23,4 @@
 22 - Mygica X8506 DMB-TH [14f1:8651]
 23 - Magic-Pro ProHDTV Extreme 2 [14f1:8657]
 24 - Hauppauge WinTV-HVR1850 [0070:8541]
+ 25 - Compro VideoMate E800   [1858:e800]
diff -Naur a/linux/drivers/media/video/cx23885/cx23885-cards.c
b/linux/drivers/media/video/cx23885/cx23885-cards.c
--- a/linux/drivers/media/video/cx23885/cx23885-cards.c 2009-09-01
16:43:46.0 +0300
+++ b/linux/drivers/media/video/cx23885/cx23885-cards.c 2009-09-06
15:35:23.434293199 +0300
@@ -211,6 +211,10 @@
   .portb  = CX23885_MPEG_ENCODER,
   .portc  = CX23885_MPEG_DVB,
   },
+[CX23885_BOARD_COMPRO_VIDEOMATE_E800] = {
+   .name   = Compro VideoMate E800,
+   .portc  = CX23885_MPEG_DVB,
+   },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);

@@ -342,6 +346,10 @@
   .subvendor = 0x0070,
   .subdevice = 0x8541,
   .card  = CX23885_BOARD_HAUPPAUGE_HVR1850,
+}, {
+   .subvendor = 0x1858,
+   .subdevice = 0xe800,
+   .card  = CX23885_BOARD_COMPRO_VIDEOMATE_E800,
   },
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -537,6 +545,7 @@
   case CX23885_BOARD_HAUPPAUGE_HVR1500Q:
   case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
   case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
+case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
   /* Tuner Reset Command */
   bitmask = 0x04;
   break;
@@ -688,6 +697,7 @@
   break;
   case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
   case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
+case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
   /* GPIO-2  xc3028 tuner reset */

   /* The following GPIO's are on the internal AVCore (cx25840)
*/
@@ -912,6 +922,7 @@
   case CX23885_BOARD_HAUPPAUGE_HVR1255:
   case CX23885_BOARD_HAUPPAUGE_HVR1210:
   case CX23885_BOARD_HAUPPAUGE_HVR1850:
+case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
   default:
   ts2-gen_ctrl_val  = 0xc; /* Serial bus + punctured clock */
   ts2-ts_clk_en_val = 0x1; /* Enable TS_CLK */
@@ -928,6 +939,7 @@
   case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
   case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
   case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
+case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
   dev-sd_cx25840 = v4l2_i2c_new_subdev(dev-v4l2_dev,
   dev-i2c_bus[2].i2c_adap,
   cx25840, cx25840, 0x88  1, NULL);
diff -Naur a/linux/drivers/media/video/cx23885/cx23885-dvb.c
b/linux/drivers/media/video/cx23885/cx23885-dvb.c
--- a/linux/drivers/media/video/cx23885/cx23885-dvb.c   2009-09-01
16:43:46.0 +0300
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c   2009-09-06
16:09:17.154602943 +0300
@@ -744,6 +744,7 @@
   }
   case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
   case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
+case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
   i2c_bus = dev-i2c_bus[0];

   fe0-dvb.frontend = dvb_attach(zl10353_attach,
diff -Naur a/linux/drivers/media/video/cx23885/cx23885.h
b/linux/drivers/media/video/cx23885/cx23885.h
--- a/linux/drivers/media/video/cx23885/cx23885.h   2009-09-01
16:43:46.0 +0300
+++ b/linux/drivers/media/video/cx23885/cx23885.h   2009-09-06
15:36:40.229792022 +0300
@@ -79,6 +79,7 @@
#define CX23885_BOARD_MYGICA_X8506 22
#define CX23885_BOARD_MAGICPRO_PROHDTVE2   23
#define CX23885_BOARD_HAUPPAUGE_HVR185024
+#define CX23885_BOARD_COMPRO_VIDEOMATE_E80025

#define GPIO_0 0x0001
#define GPIO_1 0x0002


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




  


Signed-off-by: Vladimir Geroy geroi...@yandex.ru


diff -Naur a/linux/Documentation/video4linux/CARDLIST.cx23885 
b/linux/Documentation/video4linux/CARDLIST.cx23885
--- a/linux/Documentation/video4linux/CARDLIST.cx23885  2009-09-01 
16:43:46.0 +0300
+++ b/linux/Documentation/video4linux/CARDLIST.cx23885  2009-09-06 

Re: [PATCH] Add RGB555X and RGB565X formats to pxa-camera

2009-09-06 Thread Guennadi Liakhovetski
On Sun, 6 Sep 2009, Marek Vasut wrote:

 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.

Ok, this is, of course, something different. In this case you, probably, 
could deceive the PXA to handle blue as red and the other way round, but 
still, I would prefer not to do that. Hence my suggestion remains - pass 
these formats as raw data.

The only case when you might want to put the PXA into RGB555 mode, while 
feeding BGR555 to it, is you want to use the QCI to set the transparency 
bit for you. But we currently do not support this any way, not in a 
configurable way at least. You would need to implement some sort of a 
global (one-bit) alpha control for pxa_camera to use this. Any need for 
this?

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

2009-09-06 Thread Guennadi Liakhovetski
On Sun, 6 Sep 2009, Marek Vasut wrote:

 Dne Ne 6. září 2009 18:52:55 Guennadi Liakhovetski napsal(a):
  On Sun, 6 Sep 2009, Marek Vasut wrote:
   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.
 
  Ok, this is, of course, something different. In this case you, probably,
  could deceive the PXA to handle blue as red and the other way round, but
  still, I would prefer not to do that. Hence my suggestion remains - pass
  these formats as raw data.
 
 Which is bogus from the camera point of view.

Not at all. This just means: the subdevice provides a pixel format, that 
the bridge (PXA) knows nothing specific about, but it can just pass it 
one-to-one (as raw data) to the user - don't see anything bogus in this. 
Different bridges have support for different pixel colour formats, but, I 
think, all bridges can pass data as raw (pass-through). Some bridges can 
_only_ do this, so, this is actually the default video-capture mode.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

2009-09-06 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Sun Sep  6 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/Sunday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.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: Azurewave AD-CP400 (Twinhan VP-2040 DVB-C)

2009-09-06 Thread MartinG
On Wed, Aug 26, 2009 at 6:21 PM, Magnus Nilssonmag...@upcore.net wrote:
 Nevermind this for the time being...all is pointing to open-sasc-ng being
 the culprit here...

Just to add a datapoint - I have the same problem: I can't seem to
successfully scan for channels. I've taken open-sasc-ng out of the
equation by simply not loading the loopback device and scan directly
on the true frontend.
These are my bits:
Terratec Cinergy C HD PCI
kernel 2.6.29.6-217.2.16.fc11.x86_64
s2-liplianin from http://mercurial.intuxication.org/hg/s2-liplianin
Currently:
changeset:   12465:096aa4559b71
tag: tip
user:Igor M. Liplianin liplia...@me.by
date:Sat Sep 05 20:26:33 2009 +0300

dmesg when modprobe mantis
Sep  6 22:33:52 localhost kernel: Mantis :04:00.0: PCI INT A -
GSI 16 (level, low) - IRQ 16
Sep  6 22:33:52 localhost kernel: irq: 16, latency: 64
Sep  6 22:33:52 localhost kernel: memory: 0xfdfff000, mmio: 0xc20023906000
Sep  6 22:33:52 localhost kernel: found a VP-2040 PCI DVB-C device on (04:00.0),
Sep  6 22:33:52 localhost kernel:Mantis Rev 1 [153b:1178], irq:
16, latency: 64
Sep  6 22:33:52 localhost kernel:memory: 0xfdfff000, mmio:
0xc20023906000
Sep  6 22:33:52 localhost kernel:MAC Address=[00:08:ca:1d:bd:a6]
Sep  6 22:33:52 localhost kernel: mantis_alloc_buffers (0):
DMA=0xcc0d cpu=0x8800cc0d size=65536
Sep  6 22:33:52 localhost kernel: mantis_alloc_buffers (0):
RISC=0xa85ce000 cpu=0x8800a85ce000 size=1000
Sep  6 22:33:52 localhost kernel: DVB: registering new adapter (Mantis
dvb adapter)
Sep  6 22:33:52 localhost kernel: mantis_frontend_init (0): Probing
for CU1216 (DVB-C)
Sep  6 22:33:52 localhost kernel: TDA10023: i2c-addr = 0x0c, id = 0x7d
Sep  6 22:33:52 localhost kernel: mantis_frontend_init (0): found
Philips CU1216 DVB-C frontend (TDA10023) @ 0x0c
Sep  6 22:33:52 localhost kernel: mantis_frontend_init (0): Mantis
DVB-C Philips CU1216 frontend attach success
Sep  6 22:33:52 localhost kernel: DVB: registering adapter 0 frontend
0 (Philips TDA10023 DVB-C)...
Sep  6 22:33:52 localhost kernel: mantis_ca_init (0): Registering EN50221 device
Sep  6 22:33:52 localhost kernel: mantis_ca_init (0): Registered EN50221 device
Sep  6 22:33:52 localhost kernel: mantis_hif_init (0): Adapter(0)
Initializing Mantis Host Interface
Sep  6 22:33:52 localhost kernel: input: Mantis VP-2040 IR Receiver as
/devices/virtual/input/input11
Sep  6 22:33:53 localhost kernel: Mantis VP-2040 IR Receiver: unknown
key: key=0x00 raw=0x00 down=1
Sep  6 22:33:53 localhost kernel: Mantis VP-2040 IR Receiver: unknown
key: key=0x00 raw=0x00 down=0

lspci -v
04:00.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV
PCI Bridge Controller [Ver 1.0] (rev 01)
Subsystem: TERRATEC Electronic GmbH Device 1178
Flags: bus master, medium devsel, latency 64, IRQ 16
Memory at fdfff000 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis
Kernel modules: mantis

I have also tried the mantis module from v4l-dvb without success. The
card is then recognized as TDA10021 instead of TDA10023, just as you
describe.

Typically, I have to do modprobe -r mantis;modprobe mantis right
before I try to scan (with w_scan, scandvb og mythtv) in order to get
any channels at all. But the joy doesn't last for long, and I get
stuff like
kernel: mantis_ack_wait (0): Slave RACK Fail !
in /var/log/messages.

I guess the problems mentioned in the following post are related:
 Subject: Terratec Cinergy C HD tuning problems
 Date: 2009-08-19 21:10:56 GMT

Hope we can find a solution to this!

best,
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: problem building v4l2-spec from docbook source

2009-09-06 Thread Mauro Carvalho Chehab
Em Sat, 05 Sep 2009 18:54:27 +0100
Peter Brouwer pb.mailli...@googlemail.com escreveu:

 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.

The pdf version of V4L2 spec is currently broken: several tables and graphics
don't fit at the page size. If you (or someone else) is interested on fixing
it, I'll add a pointer at linuxtv.org  for the updated version, and improve the
script to auto-generate it.

In the case of the DVB spec, the version of the current document is version 3.
Patrick's ISDB-T patch series are increasing version to 5.1, but there are
still some missing parts when comparing with the current API.

In order to make easier for people to maintain the DVB API and to allow people
of just using just one language and document generation tools, I've converted 
the
DVB API specs to DocBook as well. I'll add it to the tree soon. It is yet a
work undergoing, but it would be nice if people could review it and improve.
After having some review and porting the ISDB-T changes to it, IMO, the better
is to deprecate the LaTex version using the DocBooc version one instead.



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


Fusion HDTV Dual Digital Express - NSW Australia

2009-09-06 Thread Alex Ferrara
I bought several of these cards over a year ago thinking that they  
worked under Linux, but I found that while the cards seem to work  
flawlessly for some people, in some geographic locations, they don't  
work for me in Goulburn NSW pointing to Mt Gray.


I have a mythtv backend with 2 x Dvico Dual Digital 4 PCI cards and  
they are working perfectly, but the Dual Express cards will not tune  
all transports. It seems that Prime and TEN hardly get enough signal  
to tune.


I have done some tests, and under Windows with MCE the cards work  
perfectly using the same antenna


I've heard that these cards have some sort of pre-amp that isn't  
getting turned on in Linux. This might be part of the issue. I have  
tried increasing signal amplification, but that degrades the other  
signals that are working ok without the extra amp.


If anyone can shed some light, I would be very appreciative

aF
--
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-1200 - CX23885 - S-Video capture

2009-09-06 Thread Lars Boegild Thomsen
I have been struggling with Linux drivers for the above mentioned card. 
Doing an lspci -v reports:

03:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI
Video and Audio Decoder (rev 02)
Subsystem: Hauppauge computer works Inc. Device 71d3
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at ef80 (64-bit, non-prefetchable) [size=2M]
Capabilities: [40] Express Endpoint, MSI 00
Capabilities: [80] Power Management version 2
Capabilities: [90] Vital Product Data
Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [100] Advanced Error Reporting
Capabilities: [200] Virtual Channel ?
Kernel driver in use: cx23885
Kernel modules: cx23885

I have been googling a lot and I am somewhat confused if the current drivers
supports video capture on the S-Video connector.  Most mailing list entries
say that only digital capture is possible, however I did notice some
changes in the cx23885-cards.c:

[CX23885_BOARD_HAUPPAUGE_HVR1200] = {
.name   = Hauppauge WinTV-HVR1200,
.portc  = CX23885_MPEG_DVB,
.input  = {{
.type   = CX23885_VMUX_TELEVISION,
.vmux   = 0,
.gpio0  = 0xff00,
}, {
.type   = CX23885_VMUX_DEBUG,
.vmux   = 0,
.gpio0  = 0xff01,
}, {
.type   = CX23885_VMUX_COMPOSITE1,
.vmux   = 1,
.gpio0  = 0xff02,
}, {
.type   = CX23885_VMUX_SVIDEO,
.vmux   = 2,
.gpio0  = 0xff02,
} },
},

Which sort of indicates that the driver is aware of the connector.  Can
anybody help me what is the current status of this driver/card combination?

So - in short - I am currently only interested in capturing analog video from 
the s-video connector (it comes from a satbox).  Is that in any way possible 
with this card?

--
Lars


signature.asc
Description: This is a digitally signed message part.


Re: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb

2009-09-06 Thread Mauro Carvalho Chehab
Em Sat, 5 Sep 2009 20:46:12 +0200
Jean Delvare kh...@linux-fr.org escreveu:


 As far as I can see, the em28xx and saa7134 drivers have the exact same
 problem. Is there anyone working on this?

I tested it here with an em28xx device and I got the trouble. I've committed a
patch fixing it with this driver, with a different strategy, using dynamic
memory. I did a similar patch for saa7134, although I can't test it ATM. Tests 
with
saa7134 devices with i2c keyboards are welcome.



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


Re: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb

2009-09-06 Thread Mauro Carvalho Chehab
Em Sat, 05 Sep 2009 10:13:41 -0400
Andy Walls awa...@radix.net escreveu:

 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.

Please, submit a latter patch fixing this issue:

/home/v4l/master/v4l/cx18-i2c.c: In function 'cx18_i2c_new_ir':
/home/v4l/master/v4l/cx18-i2c.c:122: warning: assignment discards qualifiers 
from pointer target typ



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


Re: [PATCH] Add RGB555X and RGB565X formats to pxa-camera

2009-09-06 Thread Marek Vasut
Dne Ne 6. září 2009 20:15:17 Guennadi Liakhovetski napsal(a):
 On Sun, 6 Sep 2009, Marek Vasut wrote:
  Dne Ne 6. září 2009 18:52:55 Guennadi Liakhovetski napsal(a):
   On Sun, 6 Sep 2009, Marek Vasut wrote:
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.
  
   Ok, this is, of course, something different. In this case you,
   probably, could deceive the PXA to handle blue as red and the other way
   round, but still, I would prefer not to do that. Hence my suggestion
   remains - pass these formats as raw data.
 
  Which is bogus from the camera point of view.

 Not at all. This just means: the subdevice provides a pixel format, that
 the bridge (PXA) knows nothing specific about, but it can just pass it
 one-to-one (as raw data) to the user - don't see anything bogus in this.
 Different bridges have support for different pixel colour formats, but, I
 think, all bridges can pass data as raw (pass-through). Some bridges can
 _only_ do this, so, this is actually the default video-capture mode.

But then you'll have to tell your software how to process the raw data (in what 
format they are). If there was this RGB565X passthrough support, the software 
could at least check if you are not forcing it to process nonsense.

 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


[PULL] http://kernellabs.com/hg/~mkrufky/tda18271-standby

2009-09-06 Thread Michael Krufky
Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/tda18271-standby

for the following changesets:

- tda18271: add support for additional low-power standby modes
- tda18271: add debug to show which standby mode is in use
- tda18271: add new standby mode: slave tuner output / loop thru on
- tda18271: change output feature configuration to a bitmask
- tda18271: move tda18271_sleep directly below tda18271_init
- tda18271: move small_i2c assignment to the state config block
- tda18271: ensure that configuration options are set for multiple instances
- tda18271: improve error log in function tda18271_write_regs
- tda18271: fix comments and make tda18271_agc debug less verbose
- merge: ~mkrufky/tda18271
- saa7134: disable tda18271 slave tuner output / loop thru in standby mode
- pvrusb2: disable tda18271 slave tuner output / loop thru in standby mode
- cx23885: disable tda18271 slave tuner output / loop thru in standby mode

 common/tuners/tda18271-common.c |6
 common/tuners/tda18271-fe.c |  226 +---
 common/tuners/tda18271-priv.h   |   22 +
 common/tuners/tda18271.h|   55 +++-
 video/cx23885/cx23885-dvb.c |4
 video/pvrusb2/pvrusb2-devattr.c |2
 video/saa7134/saa7134-dvb.c |1
 7 files changed, 218 insertions(+), 98 deletions(-)

Cheers,

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


Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

2009-09-06 Thread Mauro Carvalho Chehab
Em Fri, 4 Sep 2009 14:05:31 -0400
Michael Krufky mkru...@kernellabs.com escreveu:

 Mauro,
 
 This fix should really go to Linus before 2.6.31 is released, if
 possible.  It also should be backported to stable, but I need it in
 Linus' tree before it will be accepted into -stable.
 
 Do you think you can slip this in before the weekend?  As I
 understand, Linus plans to release 2.6.31 on Saturday, September 5th.
 
 If you dont have time for it, please let me know and I will send it in myself.
 

This patch doesn't apply upstream:

$ patch -p1 -i 12613.patch
patching file drivers/media/video/cx25840/cx25840-firmware.c
Hunk #5 FAILED at 107.
1 out of 5 hunks FAILED -- saving rejects to file 
drivers/media/video/cx25840/cx25840-firmware.c.re



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


Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

2009-09-06 Thread Michael Krufky
On Mon, Sep 7, 2009 at 1:10 AM, Mauro Carvalho
Chehabmche...@infradead.org wrote:
 Em Fri, 4 Sep 2009 14:05:31 -0400
 Michael Krufky mkru...@kernellabs.com escreveu:

 Mauro,

 This fix should really go to Linus before 2.6.31 is released, if
 possible.  It also should be backported to stable, but I need it in
 Linus' tree before it will be accepted into -stable.

 Do you think you can slip this in before the weekend?  As I
 understand, Linus plans to release 2.6.31 on Saturday, September 5th.

 If you dont have time for it, please let me know and I will send it in 
 myself.


 This patch doesn't apply upstream:

 $ patch -p1 -i 12613.patch
 patching file drivers/media/video/cx25840/cx25840-firmware.c
 Hunk #5 FAILED at 107.
 1 out of 5 hunks FAILED -- saving rejects to file 
 drivers/media/video/cx25840/cx25840-firmware.c.re


OK, this is going to need a manual backport.  This does fix an issue
in 2.6.31, and actually affects all kernels since the appearance of
the cx23885 driver, but I can wait until you push it to Linus in the
2.6.32 merge window, then I'll backport  test it for -stable.

Thanks  regards,

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


Re: [PULL] soc-camera: fix compile breakage

2009-09-06 Thread Mauro Carvalho Chehab
Em Fri, 4 Sep 2009 21:46:09 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu:

 Hi Mauro
 
 Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb
 
 for the following changeset:
 
 01/01: SH: fix ap325rxa compilation breakage
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=375955bfb282
 
 
  board-ap325rxa.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 This is the breakage we just discussed on IRC. The guilty commit in your 
 git-tree is [1]. However, the slight problem with this is, that that 
 single bad line is also modified by [2]. So, the best fix would be to 
 merge [1], the respective (very first) hunk of [2] and this patch.

OK, I did your recommended procedure, rebasing the patches and fixing a
conflict with the last one.

I'll be updating my linux-next upstream soon.
 
 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/
 
 [1]
 http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=commitdiff;h=5400a6bf7de5cd4fbd0c55274a79662709d171eb
 
 [2]
 http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=commitdiff;h=c43c68f839af76f27afc9cbac495dfd5e458649e
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html




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