Re: soc_camera Client Driver with Multiple I2C Addresses

[Guennadi Liakhovetski]

Hi Charles

(linux-i2c added to cc)

On Mon, 27 Dec 2010, Charles D. Krebs wrote:

> Guennadi,
> 
> I'm developing a driver for a video receiver chip that has register 
> banks on multiple I2C addresses on the same bus.  The data output is 
> parallel and I will be connecting it to the sh host interface.  
> Overall, the device appears to be suitable as a client driver to 
> soc_camera.
> 
> I'm following the model for the MT9T112 driver, and this works just fine 
> for communicating to any one of the device's I2C addresses.
> 
> How would you recommend registering more than one I2C address to an 
> soc_camera client driver?

Honestly - don't know. The soc-camera model for now is pretty simple and 
in some senses restrictive. But in principle, it should be possible to 
code your case within its scope too. One of the possibilities would be to 
register your platform data with one "main" i2c unit / address, and then 
let the sensor register the rest in its probe. Is your chip configuration 
fixed? Always the same number of i2c units with the same addresses? Or can 
it vary? Maybe something like a multi-function device (drivers/mfd) would 
suit your purpose well?

In fact, I think, it shouldn't be too complicated. As suggested above, 
provide (but don't register, just follow other soc-camera platforms) one 
main i2c device in the platform data, register the rest in your main 
probe(), which will call your further probe()s. The easiest would be to 
keep just one soc-camera instance and one v4l2-subdeice, but if you want, 
you can explore the possibility of creating several v4l2-subdevices.

Hope, this helps.

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 0/8] Fix V4L/DVB/RC warnings

[Mauro Carvalho Chehab]

Em 27-12-2010 21:55, Andy Walls escreveu:
> I have hardware for lirc_zilog.  I can look later this week.

That would be great!

> I also have hardware that lirc_i2c handles but not all the hardware it 
> handles.
> 
>  IIRC lirc_i2c is very much like ir-kbd-i2c, so do we need it anymore?  I'm 
> not able to check for myself at the moment.

Both ir-kbd-i2c and lirc_i2c have almost the same features. We need to
double-check if all I2C addresses supported by lirc_i2c are also supported
by ir-kbd-i2c and if all I2C chipsets are supported.

> 
> Regards,
> Andy
> 
> Mauro Carvalho Chehab  wrote:
> 
>>
>> There were several warnings at the subsystem, that were catched with
>> gcc version 4.5.1. All of them are fixed on those patches by a 
>> trivial patch. So, let's fix them ;)
>>
>> Now, the only remaining patches are the ones we want to be there:
>>
>> drivers/staging/lirc/lirc_i2c.c: In function ‘ir_probe’:
>> drivers/staging/lirc/lirc_i2c.c:431:3: warning: ‘id’ is deprecated (declared 
>> at include/linux/i2c.h:356)
>> drivers/staging/lirc/lirc_i2c.c:450:3: warning: ‘id’ is deprecated (declared 
>> at include/linux/i2c.h:356)
>> drivers/staging/lirc/lirc_i2c.c:479:9: warning: ‘id’ is deprecated (declared 
>> at include/linux/i2c.h:356)
>> drivers/staging/lirc/lirc_zilog.c: In function ‘ir_probe’:
>> drivers/staging/lirc/lirc_zilog.c:1199:2: warning: ‘id’ is deprecated 
>> (declared at include/linux/i2c.h:356)
>> drivers/media/video/cx88/cx88-i2c.c: In function ‘cx88_i2c_init’:
>> drivers/media/video/cx88/cx88-i2c.c:149:2: warning: ‘id’ is deprecated 
>> (declared at include/linux/i2c.h:356)
>> drivers/media/video/cx88/cx88-vp3054-i2c.c: In function ‘vp3054_i2c_probe’:
>> drivers/media/video/cx88/cx88-vp3054-i2c.c:128:2: warning: ‘id’ is 
>> deprecated (declared at include/linux/i2c.h:356)
>>
>> They are basically caused by lirc_i2c and lirc_zilog, that still needs
>> to use the legacy .id field at the I2C structs. Somebody with those
>> hardware, please fix it.
>>
>> Thanks,
>> Mauro
>>
>> -
>>
>> Mauro Carvalho Chehab (8):
>>  [media] dmxdev: Fix a compilation warning due to a bad type
>>  [media] radio-wl1273: Fix two warnings
>>  [media] lirc_zilog: Fix a warning
>>  [media] dib7000m/dib7000p: Add support for TRANSMISSION_MODE_4K
>>  [media] gspca: Fix a warning for using len before filling it
>>  [media] stv090x: Fix some compilation warnings
>>  [media] af9013: Fix a compilation warning
>>  [media] streamzap: Fix a compilation warning when compiled builtin
>>
>> drivers/media/dvb/dvb-core/dmxdev.c|4 ++--
>> drivers/media/dvb/frontends/af9013.c   |2 +-
>> drivers/media/dvb/frontends/dib7000m.c |   10 +-
>> drivers/media/dvb/frontends/dib7000p.c |   10 +-
>> drivers/media/dvb/frontends/stv090x.c  |6 +++---
>> drivers/media/radio/radio-wl1273.c |3 +--
>> drivers/media/rc/streamzap.c   |2 +-
>> drivers/media/video/gspca/gspca.c  |2 +-
>> drivers/staging/lirc/lirc_zilog.c  |1 -
>> 9 files changed, 19 insertions(+), 21 deletions(-)
>>
>> -- 
>> 1.7.3.4
>>
>> --
>> 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
> N�r��y���b�X��ǧv�^�)޺{.n�+{���bj)���w*jg����ݢj/���z�ޖ��2�ޙ���&�)ߡ�a�����G���h��j:+v���w�٥

--
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] [media] s5p-fimc: update checking scaling ratio range

[Hyunwoong Kim]

Sylwester Nawrocki wrote:

> -Original Message-
> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
> ow...@vger.kernel.org] On Behalf Of Sylwester Nawrocki
> Sent: Monday, December 27, 2010 7:57 PM
> To: Hyunwoong Kim
> Cc: linux-media@vger.kernel.org; linux-samsung-...@vger.kernel.org
> Subject: Re: [PATCH] [media] s5p-fimc: update checking scaling ratio range
> 
> Hi Hyunwoong,
> 
> On 12/27/2010 10:17 AM, Hyunwoong Kim wrote:
> > Horizontal and vertical scaling range are according to the following
> equations.
> > If (SRC_Width >= 64 x DST_Width) { Exit(-1);  /* Out of Horizontal scale
> range}
> > If (SRC_Height >= 64 x DST_Height) { Exit(-1);  /* Out of Vertical scale
> range}



> > -int fimc_check_scaler_ratio(struct v4l2_rect *r, struct fimc_frame *f);
> > +int fimc_check_scaler_ratio(struct v4l2_rect *s, struct v4l2_rect *d,
> int rot);
> 
> This function always compares 2 width/height pairs, don't you think it
> could
> be better to do something like:
> int fimc_check_scaler_ratio(int sw, int sh, int dw, int dh, int rot);
> considering your changed usage?
> That could let us avoid copying arguments before each function call.

If we use the 5 parameters as you commented, we can avoid copying arguments.
However, according to ATPCS(The ARM-THUMB Procedure Call Standard), 
4 registers from r0 to r3 is used for function's parameters and return
value.
If the number of parameters is more than 4, e.g. 5 parameters.
Four of the parameters are passed by register from r0 to r3. and the fifth
parameter is pushed in stack.
That could affect system performance compared to the case that the number of
parameter is below 4.
So, I think it's the better way to use 3 parameters according to ATPCS.
If you don't agree with my opinion, 
I will send the second patch after modifying the definition of function as
you mentioned.

Thank you for your comment.

> Otherwise looks good to me.
> >  int fimc_set_scaler_info(struct fimc_ctx *ctx);
> >  int fimc_prepare_config(struct fimc_ctx *ctx, u32 flags);
> >  int fimc_prepare_addr(struct fimc_ctx *ctx, struct vb2_buffer *vb,
> 
> Regards,
> --
> Sylwester Nawrocki
> Samsung Poland R&D Center
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" 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

[patch] [media] cx231xx: use bitwise negate instead of logical

[Dan Carpenter]

Bitwise negate was intended here.  INPUT_SEL_MASK is 0x30.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/media/video/cx231xx/cx231xx-avcore.c 
b/drivers/media/video/cx231xx/cx231xx-avcore.c
index d52955c..c53e972 100644
--- a/drivers/media/video/cx231xx/cx231xx-avcore.c
+++ b/drivers/media/video/cx231xx/cx231xx-avcore.c
@@ -274,7 +274,7 @@ int cx231xx_afe_set_input_mux(struct cx231xx *dev, u32 
input_mux)
 
if (ch1_setting != 0) {
status = afe_read_byte(dev, ADC_INPUT_CH1, &value);
-   value &= (!INPUT_SEL_MASK);
+   value &= ~INPUT_SEL_MASK;
value |= (ch1_setting - 1) << 4;
value &= 0xff;
status = afe_write_byte(dev, ADC_INPUT_CH1, value);
@@ -282,7 +282,7 @@ int cx231xx_afe_set_input_mux(struct cx231xx *dev, u32 
input_mux)
 
if (ch2_setting != 0) {
status = afe_read_byte(dev, ADC_INPUT_CH2, &value);
-   value &= (!INPUT_SEL_MASK);
+   value &= ~INPUT_SEL_MASK;
value |= (ch2_setting - 1) << 4;
value &= 0xff;
status = afe_write_byte(dev, ADC_INPUT_CH2, value);
@@ -292,7 +292,7 @@ int cx231xx_afe_set_input_mux(struct cx231xx *dev, u32 
input_mux)
   7 less than the input number */
if (ch3_setting != 0) {
status = afe_read_byte(dev, ADC_INPUT_CH3, &value);
-   value &= (!INPUT_SEL_MASK);
+   value &= ~INPUT_SEL_MASK;
value |= (ch3_setting - 1) << 4;
value &= 0xff;
status = afe_write_byte(dev, ADC_INPUT_CH3, value);
--
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 0/8] Fix V4L/DVB/RC warnings

[Andy Walls]

I have hardware for lirc_zilog.  I can look later this week.
I also have hardware that lirc_i2c handles but not all the hardware it handles.

 IIRC lirc_i2c is very much like ir-kbd-i2c, so do we need it anymore?  I'm not 
able to check for myself at the moment.

Regards,
Andy

Mauro Carvalho Chehab  wrote:

>
>There were several warnings at the subsystem, that were catched with
>gcc version 4.5.1. All of them are fixed on those patches by a 
>trivial patch. So, let's fix them ;)
>
>Now, the only remaining patches are the ones we want to be there:
>
>drivers/staging/lirc/lirc_i2c.c: In function ‘ir_probe’:
>drivers/staging/lirc/lirc_i2c.c:431:3: warning: ‘id’ is deprecated (declared 
>at include/linux/i2c.h:356)
>drivers/staging/lirc/lirc_i2c.c:450:3: warning: ‘id’ is deprecated (declared 
>at include/linux/i2c.h:356)
>drivers/staging/lirc/lirc_i2c.c:479:9: warning: ‘id’ is deprecated (declared 
>at include/linux/i2c.h:356)
>drivers/staging/lirc/lirc_zilog.c: In function ‘ir_probe’:
>drivers/staging/lirc/lirc_zilog.c:1199:2: warning: ‘id’ is deprecated 
>(declared at include/linux/i2c.h:356)
>drivers/media/video/cx88/cx88-i2c.c: In function ‘cx88_i2c_init’:
>drivers/media/video/cx88/cx88-i2c.c:149:2: warning: ‘id’ is deprecated 
>(declared at include/linux/i2c.h:356)
>drivers/media/video/cx88/cx88-vp3054-i2c.c: In function ‘vp3054_i2c_probe’:
>drivers/media/video/cx88/cx88-vp3054-i2c.c:128:2: warning: ‘id’ is deprecated 
>(declared at include/linux/i2c.h:356)
>
>They are basically caused by lirc_i2c and lirc_zilog, that still needs
>to use the legacy .id field at the I2C structs. Somebody with those
>hardware, please fix it.
>
>Thanks,
>Mauro
>
>-
>
>Mauro Carvalho Chehab (8):
>  [media] dmxdev: Fix a compilation warning due to a bad type
>  [media] radio-wl1273: Fix two warnings
>  [media] lirc_zilog: Fix a warning
>  [media] dib7000m/dib7000p: Add support for TRANSMISSION_MODE_4K
>  [media] gspca: Fix a warning for using len before filling it
>  [media] stv090x: Fix some compilation warnings
>  [media] af9013: Fix a compilation warning
>  [media] streamzap: Fix a compilation warning when compiled builtin
>
> drivers/media/dvb/dvb-core/dmxdev.c|4 ++--
> drivers/media/dvb/frontends/af9013.c   |2 +-
> drivers/media/dvb/frontends/dib7000m.c |   10 +-
> drivers/media/dvb/frontends/dib7000p.c |   10 +-
> drivers/media/dvb/frontends/stv090x.c  |6 +++---
> drivers/media/radio/radio-wl1273.c |3 +--
> drivers/media/rc/streamzap.c   |2 +-
> drivers/media/video/gspca/gspca.c  |2 +-
> drivers/staging/lirc/lirc_zilog.c  |1 -
> 9 files changed, 19 insertions(+), 21 deletions(-)
>
>-- 
>1.7.3.4
>
>--
>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: ngene & Satix-S2 dual problems

[Oliver Endriss]

On Sunday 26 December 2010 15:40:15 Ludovic BOUÉ wrote:
> Hi all,
> 
> I have a Satix-S2 Dual and I'm trying to get to work without his CI in a 
> first time. I'm trying ngene-test2 
> from http://linuxtv.org/hg/~endriss/ngene-test2/ under 
> 2.6.32-21-generic.
> 
> It contains too much nodes (extra demuxes, dvrs & nets):
> ...
> Is it connected to this commit 
> (http://linuxtv.org/hg/~endriss/ngene-test2/rev/eb4142f0d0ac) about "Support 
> up to 4 tuners for cineS2 v5, duoflex & mystique v2" ?

Yes.

Please note that this is an experimental repository.
This bug will be fixed before the code will be submitted upstream.
(It is more complicated that it might appear at the first glance.)

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/

--
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: TechnoTrend CT-3650 IR support

[Mauro Carvalho Chehab]

Em 27-12-2010 17:02, David Henningsson escreveu:
> On 2010-12-27 17:51, Mauro Carvalho Chehab wrote:
>> Em 27-12-2010 13:54, David Henningsson escreveu:
>>> On 2010-12-27 10:54, Mauro Carvalho Chehab wrote:
 Em 26-12-2010 17:38, David Henningsson escreveu:
> On 2010-12-26 12:41, Mauro Carvalho Chehab wrote:
>>
> +/* command to poll IR receiver (copied from pctv452e.c) */
> +#define CMD_GET_IR_CODE 0x1b
> +
> +/* IR */
> +static int tt3650_rc_query(struct dvb_usb_device *d)
> +{
> +int ret;
> +u8 rx[9]; /* A CMD_GET_IR_CODE reply is 9 bytes long */
> +ret = ttusb2_msg(d, CMD_GET_IR_CODE, NULL, 0, rx, sizeof(rx));
> +if (ret != 0)
> +return ret;
> +
> +if (rx[8]&   0x01) {

 Maybe (rx[8]&   0x01) == 0 indicates a keyup event. If so, if you map both 
 keydown
 and keyup events, the in-kernel repeat logic will work.
>>>
>>> Hmm. If I should fix keyup events, the most reliable version would probably 
>>> be something like:
>>>
>>> if (rx[8]&  0x01) {
>>>int currentkey = rx[2]; // or (rx[3]<<   8) | rx[2];
>>>if (currentkey == lastkey)
>>>  rc_repeat(lastkey);
>>>else {
>>>  if (lastkey)
>>>rc_keyup(lastkey);
>>>  lastkey = currentkey;
>>>  rc_keydown(currentkey);
>>>}
>>
>> rc_keydown() already handles repeat events (see ir_do_keydown and 
>> rc_keydown, at
>> rc-main.c), so, you don't need it.
>>
>>> }
>>> else if (lastkey) {
>>>rc_keyup(lastkey);
>>>lastkey = 0;
>>> }
>>
>> Yeah, this makes sense, if bit 1 of rx[8] indicates keyup/keydown or repeat.
>>
>> You need to double check if you are not receiving any packet with this bit 
>> unset,
>> when you press and hold a key, as some devices use a bit to just indicate 
>> that
>> the info there is valid or not (a "done" bit).
> 
> As far as I can understand, a value of "1" indicates that a key is currently 
> pressed, and a value of "0" indicates that no key is pressed.

Ok.
> 
>>
>>>
>>> Does this sound reasonable to you?
>>>

> +/* got a "press" event */
> +deb_info("%s: cmd=0x%02x sys=0x%02x\n", __func__, rx[2], rx[3]);
> +rc_keydown(d->rc_dev, rx[2], 0);
> +}

 As you're receiving both command+address, please use the complete code:
  rc_keydown(d->rc_dev, (rx[3]<<   8) | rx[2], 0);
>>>
>>> I've tried this, but it stops working. evtest shows only scancode events, 
>>> so my guess is that this makes it incompatible with RC_MAP_TT_1500, which 
>>> lists only the lower byte.
>>
>> yeah, you'll need either to create another table or to fix it. The better is 
>> to fix
>> the table and to use .scanmask = 0xff at the old drivers. This way, the same 
>> table
>> will work for both the legacy/incomplete get_scancode function and for the 
>> new one.
> 
> Ok. I did a grep for RC_MAP_TT_1500 and found one place only, so I'm 
> attaching two patches that should fix this, feel free to commit them if they 
> look good to you.

They are good. Applied, thanks!

> 
 Also as it is receiving 8 bytes from the device, maybe the IR decoding 
 logic is
 capable of decoding more than just one protocol. Such feature is nice, as 
 it
 allows replacing the original keycode table by a more complete one.
>>>
>>> I've tried dumping all nine bytes but I can't make much out of it as I'm 
>>> unfamiliar with RC protocols and decoders.
>>>
>>> Typical reply is (no key pressed):
>>>
>>> cc 35 0b 15 00 03 00 00 00
>>>
>>> Does this tell you anything?
>>
>> This means nothing to me, but the only way to double check is to test the 
>> device
>> with other remote controllers. On several hardware, it is possible to use
>> RC5 remote controllers as well. As there are some empty (zero) fields, maybe
>> this device also supports RC6 protocols (that have more than 16 bits) and
>> NEC extended (24 bits or 32 bits, on a few variants).
> 
> Ok.
> 
 One of the most interesting features of the new RC code is that it offers
 a sysfs class and some additional logic to allow dynamically change/replace
 the keymaps and keycodes via userspace. The idea is to remove all in-kernel
 keymaps in the future, using, instead, the userspace way, via ir-keytable
 tool, available at:
  http://git.linuxtv.org/v4l-utils.git

 The tool already supports auto-loading the keymap via udev.

 For IR's where we don't know the protocol or that we don't have the full 
 scancode,
 loading the keymap via userspace will not bring any new feature. But, for 
 those
 devices where we can be sure about the protocol and for those that also 
 allow
 using other protocols, users can just replace the device-provided IR with 
 a more
 powerful remote controller with more keys.
>>>
>>> Yeah, that sounds like a really nice feature.
>>>
 So, it would be wonderful if you could identify what's the supported 
 protocol(s)
 inste

[PATCH] [media] dabusb: Move it to staging to be deprecated

[Mauro Carvalho Chehab]

>From cd1b06628baa2cc4780e70922623aac310d890e1 Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab 
Date: Mon, 27 Dec 2010 19:17:12 -0200
Subject: [PATCH] [media] dabusb: Move it to staging to be deprecated

dabusb driver were conceived as an experimental driver for a test
device. The driver never supported any shipped product, and, while
there were some updates on it in 2003, for an ancient product,
those changes were never submitted upstream.

Also, there's no DocBook for its API, nor any upstream discussion.

So, better to remove it, on .39. If later needed, we may rescue it
from git logs. For now, let's move it to staging.

Acked-by: Deti Fliegl 
gned-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 147c92b..81b3ba8 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -92,26 +92,4 @@ source "drivers/media/radio/Kconfig"
 
 source "drivers/media/dvb/Kconfig"
 
-config DAB
-   boolean "DAB adapters"
-   ---help---
- Allow selecting support for Digital Audio Broadcasting (DAB)
- Receiver adapters.
-
-if DAB
-config USB_DABUSB
-   tristate "DABUSB driver"
-   depends on USB
-   ---help---
- A Digital Audio Broadcasting (DAB) Receiver for USB and Linux
- brought to you by the DAB-Team
- .  This driver can be taken
- as an example for URB-based bulk, control, and isochronous
- transactions. URB's are explained in
- .
-
- To compile this driver as a module, choose M here: the
- module will be called dabusb.
-endif # DAB
-
 endif # MEDIA_SUPPORT
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index fd684dd..98825e7 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -121,7 +121,6 @@ obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
 
 obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
 
-obj-$(CONFIG_USB_DABUSB)+= dabusb.o
 obj-$(CONFIG_USB_ZR364XX)   += zr364xx.o
 obj-$(CONFIG_USB_STKWEBCAM) += stkwebcam.o
 
diff --git a/drivers/media/video/dabusb.c b/drivers/media/video/dabusb.c
deleted file mode 100644
index f3e25e9..000
--- a/drivers/media/video/dabusb.c
+++ /dev/null
@@ -1,914 +0,0 @@
-/*/
-
-/*
- *  dabusb.c  --  dab usb driver.
- *
- *  Copyright (C) 1999  Deti Fliegl (d...@fliegl.de)
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- *
- *
- *
- *  $Id: dabusb.c,v 1.54 2000/07/24 21:39:39 deti Exp $
- *
- */
-
-/*/
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "dabusb.h"
-
-/*
- * Version Information
- */
-#define DRIVER_VERSION "v1.54"
-#define DRIVER_AUTHOR "Deti Fliegl, d...@fliegl.de"
-#define DRIVER_DESC "DAB-USB Interface Driver for Linux (c)1999"
-
-/* - */
-
-#ifdef CONFIG_USB_DYNAMIC_MINORS
-#define NRDABUSB 256
-#else
-#define NRDABUSB 4
-#endif
-
-/*---*/
-
-static dabusb_t dabusb[NRDABUSB];
-static int buffers = 256;
-static struct usb_driver dabusb_driver;
-
-/*---*/
-
-static int dabusb_add_buf_tail (pdabusb_t s, struct list_head *dst, struct 
list_head *src)
-{
-   unsigned long flags;
-   struct list_head *tmp;
-   int ret = 0;
-
-   spin_lock_irqsave (&s->lock, flags);
-
-   if (list_empty (src)) {
-   // no elements in source buffer
-   ret = -1;
-   goto err;
-   }
-   tmp = src->next;
-   list_move_tail (tmp, dst);
-
-  err: spin_unlock_irqrestore (&s->lock, flags);
-   return ret;
-}
-/*---*/
-#ifdef DEBUG
-static void dump_urb (struct urb *urb)
-{
-   dbg("urb   :%p", urb);
-   dbg("dev   :%p", urb->dev);
-   dbg("pipe  :%08X", urb->pipe);
-   dbg("status

Re: RFC: removal of dabusb driver from Linux Kernel

[Mauro Carvalho Chehab]

Em 27-12-2010 17:49, Deti Fliegl escreveu:
> Hello,
> 
> sorry for not answering in time. Please feel free to remove this piece of 
> unusable code from the kernel.

Hi Deti,

Thanks for your answer. I'll be moving it to staging and scheduling its removal
on 2.6.39.

If you have instead an update for it for some devices that are/were actually
deployed, please feel free to send us the patches.

Thanks!
Mauro
> 
> Deti
> 
> On 12/27/2010 04:39 PM, Mauro Carvalho Chehab wrote:
>> Hi,
>>
>> I'm responsible for the multimedia support at Linux Kernel. I tried to 
>> contact the
>> authors of the DABUSB driver back in september some time ago without any 
>> luck.
>>
>> We're considering the removal of dabusb driver from Linux Kernel, due to a 
>> few
>> reasons:
>>
>> 1) The driver is for an engineering sample only which was never sold as a 
>> commercial
>> product.
>> 2) The DAB API is completely undocumented and was never reviewed. Should 
>> other DAB
>> drivers ever appear, then I'd rather start from scratch defining an API 
>> then
>> continue this dubious API.
>>
>>  From our research, it seems that a variant of the driver is/where used on 
>> some hardware
>> developed by you and used on some Terratec hardware (Dr Box 1).
>>
>> If we don't have any answer from you, we'll schedule the driver to be 
>> removed from
>> Linux kernel on the next version, as we were unable to identify anyone using 
>> the
>> hardware supported at the kernel driver.
>>
>> Thanks,
>> Mauro
>>
>>
>> Em 19-09-2010 09:06, Mauro Carvalho Chehab escreveu:
>>> Hi Deti and Georg,
>>>
>>> The dabusb driver at the Linux kernel seems to be pretty much unmaintained. 
>>> Since 2006, when I
>>> moved it to /drivers/media, I received no patches from the driver authors. 
>>> All the patches
>>> we've got since then were usual trivial fixes and a few other drivers 
>>> correcting some core
>>> API changes.
>>>
>>> Also, I never found anyone with the hardware, in order to test if the 
>>> driver keeps working.
>>> Is there any commercial hardware using it?
>>>
>>> With the removal of BKL, the driver will need fixes or will likely be 
>>> removed.
>>>
>>> So, if you still care about the driver, please contact me asap. Otherwise, 
>>> I'll move it to
>>> drivers/staging and mark it to die for 2.6.38.
>>>
>>> Thanks,
>>> 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

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

Re: RFC: removal of dabusb driver from Linux Kernel

[Deti Fliegl]

Hello,

sorry for not answering in time. Please feel free to remove this piece 
of unusable code from the kernel.


Deti

On 12/27/2010 04:39 PM, Mauro Carvalho Chehab wrote:

Hi,

I'm responsible for the multimedia support at Linux Kernel. I tried to contact 
the
authors of the DABUSB driver back in september some time ago without any luck.

We're considering the removal of dabusb driver from Linux Kernel, due to a few
reasons:

1) The driver is for an engineering sample only which was never sold as a 
commercial
product.
2) The DAB API is completely undocumented and was never reviewed. Should other 
DAB
drivers ever appear, then I'd rather start from scratch defining an API then
continue this dubious API.

 From our research, it seems that a variant of the driver is/where used on some 
hardware
developed by you and used on some Terratec hardware (Dr Box 1).

If we don't have any answer from you, we'll schedule the driver to be removed 
from
Linux kernel on the next version, as we were unable to identify anyone using the
hardware supported at the kernel driver.

Thanks,
Mauro


Em 19-09-2010 09:06, Mauro Carvalho Chehab escreveu:

Hi Deti and Georg,

The dabusb driver at the Linux kernel seems to be pretty much unmaintained. 
Since 2006, when I
moved it to /drivers/media, I received no patches from the driver authors. All 
the patches
we've got since then were usual trivial fixes and a few other drivers 
correcting some core
API changes.

Also, I never found anyone with the hardware, in order to test if the driver 
keeps working.
Is there any commercial hardware using it?

With the removal of BKL, the driver will need fixes or will likely be removed.

So, if you still care about the driver, please contact me asap. Otherwise, I'll 
move it to
drivers/staging and mark it to die for 2.6.38.

Thanks,
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] DVB: TechnoTrend CT-3650 IR support

[David Henningsson]

On 2010-12-27 17:51, Mauro Carvalho Chehab wrote:

Em 27-12-2010 13:54, David Henningsson escreveu:

On 2010-12-27 10:54, Mauro Carvalho Chehab wrote:

Em 26-12-2010 17:38, David Henningsson escreveu:

On 2010-12-26 12:41, Mauro Carvalho Chehab wrote:



+/* command to poll IR receiver (copied from pctv452e.c) */
+#define CMD_GET_IR_CODE 0x1b
+
+/* IR */
+static int tt3650_rc_query(struct dvb_usb_device *d)
+{
+int ret;
+u8 rx[9]; /* A CMD_GET_IR_CODE reply is 9 bytes long */
+ret = ttusb2_msg(d, CMD_GET_IR_CODE, NULL, 0, rx, sizeof(rx));
+if (ret != 0)
+return ret;
+
+if (rx[8]&   0x01) {


Maybe (rx[8]&   0x01) == 0 indicates a keyup event. If so, if you map both 
keydown
and keyup events, the in-kernel repeat logic will work.


Hmm. If I should fix keyup events, the most reliable version would probably be 
something like:

if (rx[8]&  0x01) {
   int currentkey = rx[2]; // or (rx[3]<<   8) | rx[2];
   if (currentkey == lastkey)
 rc_repeat(lastkey);
   else {
 if (lastkey)
   rc_keyup(lastkey);
 lastkey = currentkey;
 rc_keydown(currentkey);
   }


rc_keydown() already handles repeat events (see ir_do_keydown and rc_keydown, at
rc-main.c), so, you don't need it.


}
else if (lastkey) {
   rc_keyup(lastkey);
   lastkey = 0;
}


Yeah, this makes sense, if bit 1 of rx[8] indicates keyup/keydown or repeat.

You need to double check if you are not receiving any packet with this bit 
unset,
when you press and hold a key, as some devices use a bit to just indicate that
the info there is valid or not (a "done" bit).


As far as I can understand, a value of "1" indicates that a key is 
currently pressed, and a value of "0" indicates that no key is pressed.






Does this sound reasonable to you?




+/* got a "press" event */
+deb_info("%s: cmd=0x%02x sys=0x%02x\n", __func__, rx[2], rx[3]);
+rc_keydown(d->rc_dev, rx[2], 0);
+}


As you're receiving both command+address, please use the complete code:
 rc_keydown(d->rc_dev, (rx[3]<<   8) | rx[2], 0);


I've tried this, but it stops working. evtest shows only scancode events, so my 
guess is that this makes it incompatible with RC_MAP_TT_1500, which lists only 
the lower byte.


yeah, you'll need either to create another table or to fix it. The better is to 
fix
the table and to use .scanmask = 0xff at the old drivers. This way, the same 
table
will work for both the legacy/incomplete get_scancode function and for the new 
one.


Ok. I did a grep for RC_MAP_TT_1500 and found one place only, so I'm 
attaching two patches that should fix this, feel free to commit them if 
they look good to you.



Also as it is receiving 8 bytes from the device, maybe the IR decoding logic is
capable of decoding more than just one protocol. Such feature is nice, as it
allows replacing the original keycode table by a more complete one.


I've tried dumping all nine bytes but I can't make much out of it as I'm 
unfamiliar with RC protocols and decoders.

Typical reply is (no key pressed):

cc 35 0b 15 00 03 00 00 00

Does this tell you anything?


This means nothing to me, but the only way to double check is to test the device
with other remote controllers. On several hardware, it is possible to use
RC5 remote controllers as well. As there are some empty (zero) fields, maybe
this device also supports RC6 protocols (that have more than 16 bits) and
NEC extended (24 bits or 32 bits, on a few variants).


Ok.


One of the most interesting features of the new RC code is that it offers
a sysfs class and some additional logic to allow dynamically change/replace
the keymaps and keycodes via userspace. The idea is to remove all in-kernel
keymaps in the future, using, instead, the userspace way, via ir-keytable
tool, available at:
 http://git.linuxtv.org/v4l-utils.git

The tool already supports auto-loading the keymap via udev.

For IR's where we don't know the protocol or that we don't have the full 
scancode,
loading the keymap via userspace will not bring any new feature. But, for those
devices where we can be sure about the protocol and for those that also allow
using other protocols, users can just replace the device-provided IR with a more
powerful remote controller with more keys.


Yeah, that sounds like a really nice feature.


So, it would be wonderful if you could identify what's the supported protocol(s)
instead of using RC_TYPE_UNKNOWN. You can double check the protocol if you have
with you another RC device that supports raw decoding. The rc-core internal 
decoders
will tell you what protocol was used to decode a keycode, if you enable debug.


I don't have any such RC receiver device. I do have a Logitech Harmony 525, so 
I tried pointing that one towards the CT 3650, but CMD_GET_IR_CODE didn't 
change for any of the devices I've currently told my Harmony to emulate.

So I don't really see how I can help further in this case?


I don't have a Logitech Harmony, so I'm not sure about it. Maybe J

[cron job] v4l-dvb daily build: WARNINGS

[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:Mon Dec 27 19:00:30 CET 2010
git master:   59365d136d205cc20fe666ca7f89b1c5001b0d5a
git media-master: gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2

The V4L-DVB specification from this daily build is here:

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

Re: [PATCH] DVB: TechnoTrend CT-3650 IR support

[Mauro Carvalho Chehab]

Em 27-12-2010 13:54, David Henningsson escreveu:
> On 2010-12-27 10:54, Mauro Carvalho Chehab wrote:
>> Em 26-12-2010 17:38, David Henningsson escreveu:
>>> On 2010-12-26 12:41, Mauro Carvalho Chehab wrote:

>>> +/* command to poll IR receiver (copied from pctv452e.c) */
>>> +#define CMD_GET_IR_CODE 0x1b
>>> +
>>> +/* IR */
>>> +static int tt3650_rc_query(struct dvb_usb_device *d)
>>> +{
>>> +int ret;
>>> +u8 rx[9]; /* A CMD_GET_IR_CODE reply is 9 bytes long */
>>> +ret = ttusb2_msg(d, CMD_GET_IR_CODE, NULL, 0, rx, sizeof(rx));
>>> +if (ret != 0)
>>> +return ret;
>>> +
>>> +if (rx[8]&  0x01) {
>>
>> Maybe (rx[8]&  0x01) == 0 indicates a keyup event. If so, if you map both 
>> keydown
>> and keyup events, the in-kernel repeat logic will work.
> 
> Hmm. If I should fix keyup events, the most reliable version would probably 
> be something like:
> 
> if (rx[8] & 0x01) {
>   int currentkey = rx[2]; // or (rx[3]<<  8) | rx[2];
>   if (currentkey == lastkey)
> rc_repeat(lastkey);
>   else {
> if (lastkey)
>   rc_keyup(lastkey);
> lastkey = currentkey;
> rc_keydown(currentkey);
>   }

rc_keydown() already handles repeat events (see ir_do_keydown and rc_keydown, at
rc-main.c), so, you don't need it.

> }
> else if (lastkey) {
>   rc_keyup(lastkey);
>   lastkey = 0;
> }

Yeah, this makes sense, if bit 1 of rx[8] indicates keyup/keydown or repeat.

You need to double check if you are not receiving any packet with this bit 
unset,
when you press and hold a key, as some devices use a bit to just indicate that
the info there is valid or not (a "done" bit).

> 
> Does this sound reasonable to you?
> 
>>
>>> +/* got a "press" event */
>>> +deb_info("%s: cmd=0x%02x sys=0x%02x\n", __func__, rx[2], rx[3]);
>>> +rc_keydown(d->rc_dev, rx[2], 0);
>>> +}
>>
>> As you're receiving both command+address, please use the complete code:
>> rc_keydown(d->rc_dev, (rx[3]<<  8) | rx[2], 0);
> 
> I've tried this, but it stops working. evtest shows only scancode events, so 
> my guess is that this makes it incompatible with RC_MAP_TT_1500, which lists 
> only the lower byte.

yeah, you'll need either to create another table or to fix it. The better is to 
fix
the table and to use .scanmask = 0xff at the old drivers. This way, the same 
table
will work for both the legacy/incomplete get_scancode function and for the new 
one.

>> Also as it is receiving 8 bytes from the device, maybe the IR decoding logic 
>> is
>> capable of decoding more than just one protocol. Such feature is nice, as it
>> allows replacing the original keycode table by a more complete one.
> 
> I've tried dumping all nine bytes but I can't make much out of it as I'm 
> unfamiliar with RC protocols and decoders.
> 
> Typical reply is (no key pressed):
> 
> cc 35 0b 15 00 03 00 00 00
> 
> Does this tell you anything?

This means nothing to me, but the only way to double check is to test the device
with other remote controllers. On several hardware, it is possible to use
RC5 remote controllers as well. As there are some empty (zero) fields, maybe
this device also supports RC6 protocols (that have more than 16 bits) and
NEC extended (24 bits or 32 bits, on a few variants).

>> One of the most interesting features of the new RC code is that it offers
>> a sysfs class and some additional logic to allow dynamically change/replace
>> the keymaps and keycodes via userspace. The idea is to remove all in-kernel
>> keymaps in the future, using, instead, the userspace way, via ir-keytable
>> tool, available at:
>> http://git.linuxtv.org/v4l-utils.git
>>
>> The tool already supports auto-loading the keymap via udev.
>>
>> For IR's where we don't know the protocol or that we don't have the full 
>> scancode,
>> loading the keymap via userspace will not bring any new feature. But, for 
>> those
>> devices where we can be sure about the protocol and for those that also allow
>> using other protocols, users can just replace the device-provided IR with a 
>> more
>> powerful remote controller with more keys.
> 
> Yeah, that sounds like a really nice feature.
> 
>> So, it would be wonderful if you could identify what's the supported 
>> protocol(s)
>> instead of using RC_TYPE_UNKNOWN. You can double check the protocol if you 
>> have
>> with you another RC device that supports raw decoding. The rc-core internal 
>> decoders
>> will tell you what protocol was used to decode a keycode, if you enable 
>> debug.
> 
> I don't have any such RC receiver device. I do have a Logitech Harmony 525, 
> so I tried pointing that one towards the CT 3650, but CMD_GET_IR_CODE didn't 
> change for any of the devices I've currently told my Harmony to emulate.
> 
> So I don't really see how I can help further in this case?
> 

I don't have a Logitech Harmony, so I'm not sure about it. Maybe Jarod may have 
some
info about it.

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the bo

[PATCH 0/8] Fix V4L/DVB/RC warnings

[Mauro Carvalho Chehab]

There were several warnings at the subsystem, that were catched with
gcc version 4.5.1. All of them are fixed on those patches by a 
trivial patch. So, let's fix them ;)

Now, the only remaining patches are the ones we want to be there:

drivers/staging/lirc/lirc_i2c.c: In function ‘ir_probe’:
drivers/staging/lirc/lirc_i2c.c:431:3: warning: ‘id’ is deprecated (declared at 
include/linux/i2c.h:356)
drivers/staging/lirc/lirc_i2c.c:450:3: warning: ‘id’ is deprecated (declared at 
include/linux/i2c.h:356)
drivers/staging/lirc/lirc_i2c.c:479:9: warning: ‘id’ is deprecated (declared at 
include/linux/i2c.h:356)
drivers/staging/lirc/lirc_zilog.c: In function ‘ir_probe’:
drivers/staging/lirc/lirc_zilog.c:1199:2: warning: ‘id’ is deprecated (declared 
at include/linux/i2c.h:356)
drivers/media/video/cx88/cx88-i2c.c: In function ‘cx88_i2c_init’:
drivers/media/video/cx88/cx88-i2c.c:149:2: warning: ‘id’ is deprecated 
(declared at include/linux/i2c.h:356)
drivers/media/video/cx88/cx88-vp3054-i2c.c: In function ‘vp3054_i2c_probe’:
drivers/media/video/cx88/cx88-vp3054-i2c.c:128:2: warning: ‘id’ is deprecated 
(declared at include/linux/i2c.h:356)

They are basically caused by lirc_i2c and lirc_zilog, that still needs
to use the legacy .id field at the I2C structs. Somebody with those
hardware, please fix it.

Thanks,
Mauro

-

Mauro Carvalho Chehab (8):
  [media] dmxdev: Fix a compilation warning due to a bad type
  [media] radio-wl1273: Fix two warnings
  [media] lirc_zilog: Fix a warning
  [media] dib7000m/dib7000p: Add support for TRANSMISSION_MODE_4K
  [media] gspca: Fix a warning for using len before filling it
  [media] stv090x: Fix some compilation warnings
  [media] af9013: Fix a compilation warning
  [media] streamzap: Fix a compilation warning when compiled builtin

 drivers/media/dvb/dvb-core/dmxdev.c|4 ++--
 drivers/media/dvb/frontends/af9013.c   |2 +-
 drivers/media/dvb/frontends/dib7000m.c |   10 +-
 drivers/media/dvb/frontends/dib7000p.c |   10 +-
 drivers/media/dvb/frontends/stv090x.c  |6 +++---
 drivers/media/radio/radio-wl1273.c |3 +--
 drivers/media/rc/streamzap.c   |2 +-
 drivers/media/video/gspca/gspca.c  |2 +-
 drivers/staging/lirc/lirc_zilog.c  |1 -
 9 files changed, 19 insertions(+), 21 deletions(-)

-- 
1.7.3.4

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

[PATCH 1/8] [media] dmxdev: Fix a compilation warning due to a bad type

[Mauro Carvalho Chehab]

drivers/media/dvb/dvb-core/dmxdev.c: In function ‘dvb_dmxdev_start_feed’:
drivers/media/dvb/dvb-core/dmxdev.c:583:13: warning: comparison between ‘enum 
dmx_ts_pes’ and ‘enum ’

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/dvb/dvb-core/dmxdev.c 
b/drivers/media/dvb/dvb-core/dmxdev.c
index ad1f61d..e4b5c03 100644
--- a/drivers/media/dvb/dvb-core/dmxdev.c
+++ b/drivers/media/dvb/dvb-core/dmxdev.c
@@ -572,13 +572,13 @@ static int dvb_dmxdev_start_feed(struct dmxdev *dmxdev,
dmx_output_t otype;
int ret;
int ts_type;
-   enum dmx_ts_pes ts_pes;
+   dmx_pes_type_t ts_pes;
struct dmx_ts_feed *tsfeed;
 
feed->ts = NULL;
otype = para->output;
 
-   ts_pes = (enum dmx_ts_pes)para->pes_type;
+   ts_pes = para->pes_type;
 
if (ts_pes < DMX_PES_OTHER)
ts_type = TS_DECODER;
-- 
1.7.3.4


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

[PATCH 2/8] [media] radio-wl1273: Fix two warnings

[Mauro Carvalho Chehab]

drivers/media/radio/radio-wl1273.c: In function 
‘wl1273_fm_upload_firmware_patch’:
drivers/media/radio/radio-wl1273.c:675:2: warning: ‘n’ may be used 
uninitialized in this function
drivers/media/radio/radio-wl1273.c:675:2: warning: ‘i’ may be used 
uninitialized in this function

Those vars are never initialized, and the debug message makes no sense, as it
will show just two random values.

Cc: Matti J. Aaltonen 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/radio/radio-wl1273.c 
b/drivers/media/radio/radio-wl1273.c
index 1813790..dd6bd36 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -645,7 +645,7 @@ static int wl1273_fm_upload_firmware_patch(struct 
wl1273_device *radio)
const char *fw_name = "radio-wl1273-fw.bin";
struct device *dev = radio->dev;
__u8 *ptr;
-   int i, n, r;
+   int r;
 
dev_dbg(dev, "%s:\n", __func__);
 
@@ -672,7 +672,6 @@ static int wl1273_fm_upload_firmware_patch(struct 
wl1273_device *radio)
/* ignore possible error here */
wl1273_fm_write_cmd(core, WL1273_RESET, 0);
 
-   dev_dbg(dev, "n: %d, i: %d\n", n, i);
dev_dbg(dev, "%s - download OK, r: %d\n", __func__, r);
 out:
release_firmware(fw_p);
-- 
1.7.3.4


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

[PATCH 3/8] [media] lirc_zilog: Fix a warning

[Mauro Carvalho Chehab]

drivers/staging/lirc/lirc_zilog.c: In function ‘send_code’:
drivers/staging/lirc/lirc_zilog.c:886:1: warning: label ‘done’ defined but not 
used

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/staging/lirc/lirc_zilog.c 
b/drivers/staging/lirc/lirc_zilog.c
index f0076eb..52be6de 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -883,7 +883,6 @@ static int send_code(struct IR *ir, unsigned int code, 
unsigned int key)
return -EFAULT;
}
 
-done:
/* Oh good, it worked */
dprintk("sent code %u, key %u\n", code, key);
return 0;
-- 
1.7.3.4


--
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 1/9] media: Changes in include/linux/videodev2.h for MFC 5.1

[Kamil Debski]

Hi Hans,

> -Original Message-
> From: Hans Verkuil [mailto:hverk...@xs4all.nl]
> Sent: 22 December 2010 13:42
> To: Jeongtae Park
> Cc: linux-media@vger.kernel.org; linux-samsung-...@vger.kernel.org;
> k.deb...@samsung.com; jaeryul...@samsung.com; kgene@samsung.com;
> ben-li...@fluff.org; jonghun@samsung.com
> Subject: Re: [PATCH 1/9] media: Changes in include/linux/videodev2.h
> for MFC 5.1


 
> >  #define V4L2_PIX_FMT_DV   v4l2_fourcc('d', 'v', 's', 'd') /*
> 1394  */
> >  #define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /*
> MPEG-1/2/4*/
> >
> > +
> > +#define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /*
> H264*/
> > +#define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /*
> H263*/
> > +#define V4L2_PIX_FMT_MPEG12   v4l2_fourcc('M', 'P', '1', '2') /*
> MPEG-1/2  */
> > +#define V4L2_PIX_FMT_MPEG4v4l2_fourcc('M', 'P', 'G', '4') /*
> MPEG-4  */
> > +#define V4L2_PIX_FMT_DIVX v4l2_fourcc('D', 'I', 'V', 'X') /*
> DivX  */
> > +#define V4L2_PIX_FMT_DIVX3v4l2_fourcc('D', 'I', 'V', '3') /*
> DivX 3.11  */
> > +#define V4L2_PIX_FMT_DIVX4v4l2_fourcc('D', 'I', 'V', '4') /*
> DivX 4.12  */
> > +#define V4L2_PIX_FMT_DIVX500v4l2_fourcc('D', 'X', '5', '2') /*
> DivX 5.00 - 5.02  */
> > +#define V4L2_PIX_FMT_DIVX503v4l2_fourcc('D', 'X', '5', '3') /*
> DivX 5.03 - x  */
> > +#define V4L2_PIX_FMT_XVID v4l2_fourcc('X', 'V', 'I', 'D') /*
> Xvid */
> > +#define V4L2_PIX_FMT_VC1  v4l2_fourcc('V', 'C', '1', 'A') /* VC-
> 1 */
> > +#define V4L2_PIX_FMT_VC1_RCV  v4l2_fourcc('V', 'C', '1', 'R') /*
> VC-1 RCV */
> 
> What do these formats describe? Are these container formats or the
> actual
> compressed video stream that is normally packaged inside a container?

Apart from VC-1 RCV those are elementary streams. If I understand correctly 
RCV is a simple semi-container that contains necessary information to play
the ES. I have asked a person from HW team if all those fourccs are
necessary.
I am waiting for reply.

The idea was to have a fourcc for each supported codec (by this I mean the
elementary stream).

> 
> > +
> > +
> >  /*  Vendor-specific formats   */
> >  #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /*
> cpia1 YUV */
> >  #define V4L2_PIX_FMT_WNVA v4l2_fourcc('W', 'N', 'V', 'A') /*
> Winnov hw compress */
> > @@ -1009,6 +1034,7 @@ struct v4l2_ext_controls {
> >  #define V4L2_CTRL_CLASS_MPEG 0x0099/* MPEG-compression
> controls */
> >  #define V4L2_CTRL_CLASS_CAMERA 0x009a  /* Camera class
> controls */
> >  #define V4L2_CTRL_CLASS_FM_TX 0x009b   /* FM Modulator control
> class */
> > +#define V4L2_CTRL_CLASS_CODEC 0x009c   /* Codec control class
> */
> >
> >  #define V4L2_CTRL_ID_MASK(0x0fff)
> >  #define V4L2_CTRL_ID2CLASS(id)((id) & 0x0fffUL)
> > @@ -1342,6 +1368,150 @@ enum
> v4l2_mpeg_cx2341x_video_median_filter_type {
> >  #define V4L2_CID_MPEG_CX2341X_VIDEO_CHROMA_MEDIAN_FILTER_TOP
>   (V4L2_CID_MPEG_CX2341X_BASE+10)
> >  #define V4L2_CID_MPEG_CX2341X_STREAM_INSERT_NAV_PACKETS
>   (V4L2_CID_MPEG_CX2341X_BASE+11)
> >
> > +/* For codecs */
> > +#define V4L2_CID_CODEC_BASE
(V4L2_CTRL_CLASS_CODEC
> | 0x900)
> > +#define V4L2_CID_CODEC_CLASS
(V4L2_CTRL_CLASS_CODEC
> | 1)
> > +
> > +/* For decoding */
> > +#define V4L2_CID_CODEC_LOOP_FILTER_MPEG4_ENABLE
>   (V4L2_CID_CODEC_BASE + 110)
> > +#define V4L2_CID_CODEC_DISPLAY_DELAY   (V4L2_CID_CODEC_BASE
+
> 137)
> > +#define V4L2_CID_CODEC_REQ_NUM_BUFS(V4L2_CID_CODEC_BASE
+
> 140)
> > +#define V4L2_CID_CODEC_SLICE_INTERFACE (V4L2_CID_CODEC_BASE
+
> 141)
> > +#define V4L2_CID_CODEC_PACKED_PB   (V4L2_CID_CODEC_BASE + 142)
> 
> ??? Weird CODEC_BASE offsets?
> 
> Are all these codec controls above general? I.e., applicable to any
> codec? What
> do they mean?

My mistake - I forgot to tidy up the offsets. It is difficult for me to
say which of those controls are MFC specific as I have little experience
with other codecs. 

Currently PACKED_PB has been replaced with a simple mechanism that can
detect
if the stream has packed PB frames. You can read more about such streams
here:
http://itsjustonesandzeros.blogspot.com/2007/01/what-is-packed-bitstream.htm
l
First approach required the application to set if the stream contained
packed-PB
Frames. Now the driver detects it the stream contains packed-PB frames.
Another
approach would require the stream parser to detect those frames and divide
them
into two buffers queued to MFC.

DISPLAY_DELAY is a number of frames that should be decoded before the first
frame is
returned to the application. It is valid for H264 streams.

REQ_NUM_BUFS is the minimum number of CAPTURE buffers required for MFC
decoder to work.
This is a read-only control, by reading this value the application can
adjust count when
doing REQBUFS. If the application needs 3 dequeued CAPTURE buffers for
processing it
should set count when d

[PATCH 4/8] [media] dib7000m/dib7000p: Add support for TRANSMISSION_MODE_4K

[Mauro Carvalho Chehab]

Fixes several warnings:

drivers/media/dvb/frontends/dib7000m.c: In function ‘dib7000m_set_channel’:
drivers/media/dvb/frontends/dib7000m.c:808:3: warning: case value ‘255’ not in 
enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000m.c:869:3: warning: case value ‘255’ not in 
enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000m.c: In function ‘dib7000m_tune’:
drivers/media/dvb/frontends/dib7000m.c:1023:3: warning: case value ‘255’ not in 
enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000m.c:1033:3: warning: case value ‘255’ not in 
enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000m.c:1043:3: warning: case value ‘255’ not in 
enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000p.c: In function ‘dib7000p_set_channel’:
drivers/media/dvb/frontends/dib7000p.c:720:3: warning: case value ‘255’ not in 
enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000p.c:773:3: warning: case value ‘255’ not in 
enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000p.c: In function ‘dib7000p_tune’:
drivers/media/dvb/frontends/dib7000p.c:997:3: warning: case value ‘255’ not in 
enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000p.c:1007:3: warning: case value ‘255’ not in 
enumerated type ‘fe_transmit_mode_t’
drivers/media/dvb/frontends/dib7000p.c:1017:3: warning: case value ‘255’ not in 
enumerated type ‘fe_transmit_mode_t’

The drivers were prepared to support 4K carriers, but as the define were added
later, they were using a "magic" value of 255.

Cc: Patrick Boettcher 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/dvb/frontends/dib7000m.c 
b/drivers/media/dvb/frontends/dib7000m.c
index 0f09fd3..c7f5ccf 100644
--- a/drivers/media/dvb/frontends/dib7000m.c
+++ b/drivers/media/dvb/frontends/dib7000m.c
@@ -805,7 +805,7 @@ static void dib7000m_set_channel(struct dib7000m_state 
*state, struct dvb_fronte
value = 0;
switch (ch->u.ofdm.transmission_mode) {
case TRANSMISSION_MODE_2K: value |= (0 << 7); break;
-   case /* 4K MODE */ 255: value |= (2 << 7); break;
+   case TRANSMISSION_MODE_4K: value |= (2 << 7); break;
default:
case TRANSMISSION_MODE_8K: value |= (1 << 7); break;
}
@@ -866,7 +866,7 @@ static void dib7000m_set_channel(struct dib7000m_state 
*state, struct dvb_fronte
/* P_dvsy_sync_wait */
switch (ch->u.ofdm.transmission_mode) {
case TRANSMISSION_MODE_8K: value = 256; break;
-   case /* 4K MODE */ 255: value = 128; break;
+   case TRANSMISSION_MODE_4K: value = 128; break;
case TRANSMISSION_MODE_2K:
default: value = 64; break;
}
@@ -1020,7 +1020,7 @@ static int dib7000m_tune(struct dvb_frontend *demod, 
struct dvb_frontend_paramet
value = (6 << 8) | 0x80;
switch (ch->u.ofdm.transmission_mode) {
case TRANSMISSION_MODE_2K: value |= (7 << 12); break;
-   case /* 4K MODE */ 255: value |= (8 << 12); break;
+   case TRANSMISSION_MODE_4K: value |= (8 << 12); break;
default:
case TRANSMISSION_MODE_8K: value |= (9 << 12); break;
}
@@ -1030,7 +1030,7 @@ static int dib7000m_tune(struct dvb_frontend *demod, 
struct dvb_frontend_paramet
value = (0 << 4);
switch (ch->u.ofdm.transmission_mode) {
case TRANSMISSION_MODE_2K: value |= 0x6; break;
-   case /* 4K MODE */ 255: value |= 0x7; break;
+   case TRANSMISSION_MODE_4K: value |= 0x7; break;
default:
case TRANSMISSION_MODE_8K: value |= 0x8; break;
}
@@ -1040,7 +1040,7 @@ static int dib7000m_tune(struct dvb_frontend *demod, 
struct dvb_frontend_paramet
value = (0 << 4);
switch (ch->u.ofdm.transmission_mode) {
case TRANSMISSION_MODE_2K: value |= 0x6; break;
-   case /* 4K MODE */ 255: value |= 0x7; break;
+   case TRANSMISSION_MODE_4K: value |= 0x7; break;
default:
case TRANSMISSION_MODE_8K: value |= 0x8; break;
}
diff --git a/drivers/media/dvb/frontends/dib7000p.c 
b/drivers/media/dvb/frontends/dib7000p.c
index 3aed0d4..6aa02cb 100644
--- a/drivers/media/dvb/frontends/dib7000p.c
+++ b/drivers/media/dvb/frontends/dib7000p.c
@@ -717,7 +717,7 @@ static void dib7000p_set_channel(struct dib7000p_state 
*state, struct dvb_fronte
value = 0;
switch (ch->u.ofdm.transmission_mode) {
case TRANSMISSION_MODE_2K: value |= (0 << 7); break;
-   case /* 4K MODE */ 255: value |= (2 << 7); break;
+   case TRANSMISSION_MODE_4K: value |= (2 << 7); break;
default:
case TRANSMISSION_MODE_8K: value |= (1 << 7); break;
}
@@ -770,7 +770,7 @@ static void dib7000p_set

[PATCH 5/8] [media] gspca: Fix a warning for using len before filling it

[Mauro Carvalho Chehab]

The check for status errors is now before the check for len. That's
ok. However, the error printk's for the status error prints the URB
length. This generates this error:

drivers/media/video/gspca/gspca.c: In function ‘fill_frame’:
drivers/media/video/gspca/gspca.c:305:9: warning: ‘len’ may be used 
uninitialized in this function

The fix is as simple as moving the len init to happen before the checks.

Cc: Jean-François Moine 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/video/gspca/gspca.c 
b/drivers/media/video/gspca/gspca.c
index 92b5dfb..80b31eb 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -318,6 +318,7 @@ static void fill_frame(struct gspca_dev *gspca_dev,
}
pkt_scan = gspca_dev->sd_desc->pkt_scan;
for (i = 0; i < urb->number_of_packets; i++) {
+   len = urb->iso_frame_desc[i].actual_length;
 
/* check the packet status and length */
st = urb->iso_frame_desc[i].status;
@@ -327,7 +328,6 @@ static void fill_frame(struct gspca_dev *gspca_dev,
gspca_dev->last_packet_type = DISCARD_PACKET;
continue;
}
-   len = urb->iso_frame_desc[i].actual_length;
if (len == 0) {
if (gspca_dev->empty_packet == 0)
gspca_dev->empty_packet = 1;
-- 
1.7.3.4


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

[PATCH 6/8] [media] stv090x: Fix some compilation warnings

[Mauro Carvalho Chehab]

A few typos at the driver are causing the following warnings:

drivers/media/dvb/frontends/stv090x.c: In function ‘stv090x_start_search’:
drivers/media/dvb/frontends/stv090x.c:1486:27: warning: comparison between 
‘enum stv090x_search’ and ‘enum stv090x_delsys’
drivers/media/dvb/frontends/stv090x.c:1487:24: warning: comparison between 
‘enum stv090x_search’ and ‘enum stv090x_delsys’
drivers/media/dvb/frontends/stv090x.c: In function ‘stv090x_optimize_track’:
drivers/media/dvb/frontends/stv090x.c:2943:2: warning: case value ‘4’ not in 
enumerated type ‘enum stv090x_delsys’

The first two are due to the lack of using the delsys types
STV090x_DVBS1/STV090x_DSS
instead of
STV090x_SEARCH_DVBS1/STV090x_SEARCH_DSS

The second one is due to the usage of STV090x_UNKNOWN (enum stv090x_modulation)
instead of STV090x_ERROR (enum stv090x_delsys).

Cc: Manu Abraham 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/dvb/frontends/stv090x.c 
b/drivers/media/dvb/frontends/stv090x.c
index 425e7a4..4e0fc2c 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -1483,8 +1483,8 @@ static int stv090x_start_search(struct stv090x_state 
*state)
if (STV090x_WRITE_DEMOD(state, FFECFG, 0x41) < 0)
goto err;
 
-   if ((state->search_mode == STV090x_DVBS1)   ||
-   (state->search_mode == STV090x_DSS) ||
+   if ((state->search_mode == STV090x_SEARCH_DVBS1)||
+   (state->search_mode == STV090x_SEARCH_DSS)  ||
(state->search_mode == STV090x_SEARCH_AUTO)) {
 
if (STV090x_WRITE_DEMOD(state, VITSCALE, 0x82) < 0)
@@ -2940,7 +2940,7 @@ static int stv090x_optimize_track(struct stv090x_state 
*state)
STV090x_WRITE_DEMOD(state, ERRCTRL1, 0x67); /* PER */
break;
 
-   case STV090x_UNKNOWN:
+   case STV090x_ERROR:
default:
reg = STV090x_READ_DEMOD(state, DMDCFGMD);
STV090x_SETFIELD_Px(reg, DVBS1_ENABLE_FIELD, 1);
-- 
1.7.3.4


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

[PATCH 7/8] [media] af9013: Fix a compilation warning

[Mauro Carvalho Chehab]

drivers/media/dvb/frontends/af9013.c: In function 
‘af9013_update_signal_strength.clone.0’:
drivers/media/dvb/frontends/af9013.c:967:6: warning: ‘ret’ may be used 
uninitialized in this function

Cc: Antti Palosaari 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/dvb/frontends/af9013.c 
b/drivers/media/dvb/frontends/af9013.c
index e2a95c0..ce22205 100644
--- a/drivers/media/dvb/frontends/af9013.c
+++ b/drivers/media/dvb/frontends/af9013.c
@@ -964,7 +964,7 @@ error:
 static int af9013_update_signal_strength(struct dvb_frontend *fe)
 {
struct af9013_state *state = fe->demodulator_priv;
-   int ret;
+   int ret = 0;
u8 rf_gain, if_gain;
int signal_strength;
 
-- 
1.7.3.4


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

OMAP3 ISP and tvp5151 driver.

[Enric Balletbò i Serra]

Hello all,

I'm new on media and camera, I try to use the OMAP3 ISP driver on
OMAP3530 with media framework. I've a TVP5151 connected on ISP port
though the parallel interface on own custom board

   Against which repository/branch should I start the development ?
   Should I port tvp5150 driver to new tvp5151 device and new media
framework ? Any driver as reference ?

Hopefully, somebody can give me some tips. Thanks

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

[PATCH 8/8] [media] streamzap: Fix a compilation warning when compiled builtin

[Mauro Carvalho Chehab]

drivers/media/rc/streamzap.c: In function ‘streamzap_probe’:
drivers/media/rc/streamzap.c:460:2: warning: statement with no effect

Cc: Jarod Wilson 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/rc/streamzap.c b/drivers/media/rc/streamzap.c
index 7f82f55..6e2911c 100644
--- a/drivers/media/rc/streamzap.c
+++ b/drivers/media/rc/streamzap.c
@@ -73,7 +73,7 @@ MODULE_DEVICE_TABLE(usb, streamzap_table);
 #ifdef CONFIG_IR_RC5_SZ_DECODER_MODULE
 #define load_rc5_sz_decode()request_module("ir-rc5-sz-decoder")
 #else
-#define load_rc5_sz_decode()0
+#define load_rc5_sz_decode(){}
 #endif
 
 enum StreamzapDecoderState {
-- 
1.7.3.4

--
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: TechnoTrend CT-3650 IR support

[David Henningsson]

On 2010-12-27 10:54, Mauro Carvalho Chehab wrote:

Em 26-12-2010 17:38, David Henningsson escreveu:

On 2010-12-26 12:41, Mauro Carvalho Chehab wrote:

Hi David,

Em 26-12-2010 07:14, David Henningsson escreveu:

Hi Linux-media,

As a spare time project I bought myself a TT CT-3650, to see if I could get it 
working. Waling Dijkstra did write a IR&   CI patch for this model half a year 
ago, so I was hopeful. (Reference: 
http://www.mail-archive.com/linux-media@vger.kernel.org/msg19860.html )

Having tested the patch, the IR is working (tested all keys via the "evtest" 
tool), however descrambling is NOT working.

Waling's patch was reviewed but never merged. So I have taken the IR part of 
the patch, cleaned it up a little, and hopefully this part is ready for merging 
now. Patch is against linux-2.6.git.


Could you please rebase it to work with the rc_core support? I suspect that you
based it on a kernel older than .36, as the dvb_usb rc struct changed.


Ok, I have now done this, but I'm not completely satisfied, perhaps you can 
help out a little? I'm new to IR/RC stuff,
but I feel I'm missing correct "repeat" functionality, i e, if you keep a key 
pressed it appears as separate key presses
with whatever interval set as .rc_interval. (This was probably a problem with 
the old patch as well.) Is there any
support for this is rc_core?


 From your decode logic, I suspect that the IR hardware decoder has its own 
logic for repeat.
In this case, there's not much you can do, as it probably uses a very high time 
for repeat.


I'm attaching a temporary patch (just for review) so you know what I'm talking 
about.


The better is to base it over the latest V4L/DVB/RC development git, available 
at:
 http://git.linuxtv.org/media_tree.git


Ok. I was probably confused with this entry: 
http://linuxtv.org/news.php?entry=2010-01-19.mchehab
telling me to base it on v4l-dvb.git, which is not updated for four months. 
However, http://git.linuxtv.org/ correctly lists the media_tree.git as the 
repository of choice.


Ah... yeah, old news;)


Thanks for the review!


Em 26-12-2010 17:38, David Henningsson escreveu:

 From 8c42121a08c5dabbd1a943cc1e5726ed99f0d957 Mon Sep 17 00:00:00 2001
From: David Henningsson
Date: Sun, 26 Dec 2010 14:23:58 +0100
Subject: [PATCH] DVB: IR support for CT-3650

Signed-off-by: David Henningsson
---
  drivers/media/dvb/dvb-usb/ttusb2.c |   28 
  1 files changed, 28 insertions(+), 0 deletions(-)
  mode change 100644 =>  100755 debian/rules

diff --git a/debian/rules b/debian/rules
old mode 100644
new mode 100755
diff --git a/drivers/media/dvb/dvb-usb/ttusb2.c 
b/drivers/media/dvb/dvb-usb/ttusb2.c
index a6de489..ded8a4b 100644
--- a/drivers/media/dvb/dvb-usb/ttusb2.c
+++ b/drivers/media/dvb/dvb-usb/ttusb2.c
@@ -128,6 +128,27 @@ static struct i2c_algorithm ttusb2_i2c_algo = {
.functionality = ttusb2_i2c_func,
  };

+/* command to poll IR receiver (copied from pctv452e.c) */
+#define CMD_GET_IR_CODE 0x1b
+
+/* IR */
+static int tt3650_rc_query(struct dvb_usb_device *d)
+{
+   int ret;
+   u8 rx[9]; /* A CMD_GET_IR_CODE reply is 9 bytes long */
+   ret = ttusb2_msg(d, CMD_GET_IR_CODE, NULL, 0, rx, sizeof(rx));
+   if (ret != 0)
+   return ret;
+
+   if (rx[8]&  0x01) {


Maybe (rx[8]&  0x01) == 0 indicates a keyup event. If so, if you map both 
keydown
and keyup events, the in-kernel repeat logic will work.


Hmm. If I should fix keyup events, the most reliable version would 
probably be something like:


if (rx[8] & 0x01) {
  int currentkey = rx[2]; // or (rx[3]<<  8) | rx[2];
  if (currentkey == lastkey)
rc_repeat(lastkey);
  else {
if (lastkey)
  rc_keyup(lastkey);
lastkey = currentkey;
rc_keydown(currentkey);
  }
}
else if (lastkey) {
  rc_keyup(lastkey);
  lastkey = 0;
}

Does this sound reasonable to you?




+   /* got a "press" event */
+   deb_info("%s: cmd=0x%02x sys=0x%02x\n", __func__, rx[2], rx[3]);
+   rc_keydown(d->rc_dev, rx[2], 0);
+   }


As you're receiving both command+address, please use the complete code:
rc_keydown(d->rc_dev, (rx[3]<<  8) | rx[2], 0);


I've tried this, but it stops working. evtest shows only scancode 
events, so my guess is that this makes it incompatible with 
RC_MAP_TT_1500, which lists only the lower byte.



Also as it is receiving 8 bytes from the device, maybe the IR decoding logic is
capable of decoding more than just one protocol. Such feature is nice, as it
allows replacing the original keycode table by a more complete one.


I've tried dumping all nine bytes but I can't make much out of it as I'm 
unfamiliar with RC protocols and decoders.


Typical reply is (no key pressed):

cc 35 0b 15 00 03 00 00 00

Does this tell you anything?


One of the most interesting features of the new RC code is that it offers
a sysfs class and some additional logic to allow dynamically change/replace
the keymaps and key

Re: [PATCH 3/6] Documentation/ioctl/ioctl-number.txt: Remove some now freed ioctl ranges

[Mauro Carvalho Chehab]

Em 27-12-2010 13:08, Hans Verkuil escreveu:
> On Monday, December 27, 2010 15:02:05 Mauro Carvalho Chehab wrote:
>> Em 27-12-2010 11:23, Hans Verkuil escreveu:
>>> On Monday, December 27, 2010 14:03:03 Mauro Carvalho Chehab wrote:
 Em 27-12-2010 10:01, Hans Verkuil escreveu:
> On Monday, December 27, 2010 12:38:39 Mauro Carvalho Chehab wrote:
>> The V4L1 removal patches removed a few ioctls. Update it at the docspace.
>>
>> Signed-off-by: Mauro Carvalho Chehab 
>>
>> diff --git a/Documentation/ioctl/ioctl-number.txt 
>> b/Documentation/ioctl/ioctl-number.txt
>> index 63ffd78..49d7f00 100644
>> --- a/Documentation/ioctl/ioctl-number.txt
>> +++ b/Documentation/ioctl/ioctl-number.txt
>> @@ -260,14 +260,11 @@ Code  Seq#(hex)Include FileComments
>>  't' 80-8F   linux/isdn_ppp.h
>>  't' 90  linux/toshiba.h
>>  'u' 00-1F   linux/smb_fs.h  gone
>> -'v' all linux/videodev.hconflict!
>>  'v' 00-1F   linux/ext2_fs.h conflict!
>>  'v' 00-1F   linux/fs.h  conflict!
>>  'v' 00-0F   linux/sonypi.h  conflict!
>> -'v' C0-CF   drivers/media/video/ov511.h conflict!
>>  'v' C0-DF   media/pwc-ioctl.h   conflict!
>>  'v' C0-FF   linux/meye.hconflict!
>> -'v' C0-CF   drivers/media/video/zoran/zoran.h   conflict!
>>  'v' D0-DF   drivers/media/video/cpia2/cpia2dev.hconflict!
>>  'w' all CERN SCI driver
>>  'y' 00-1F   packet based user level 
>> communications
>>
>
> There is also a line for media/ovcamchip.h in this file that can be 
> removed.

 Ok, I'll do that.

> The media/rds.h line can also be removed (this is kernel internal only).

 There are two rds.h, related to V4L:
 ./include/linux/rds.h
>>>
>>> Not related to V4L, this is something from Oracle. It is this header that 
>>> is public,
>>> not the media/rds.h header.
>>
>> Ah, ok.
>>
 ./include/media/rds.h

 One of them is at the public api:

 include/linux/Kbuild:header-y += rds.h

 Btw, that's weird:

 $ git grep RDS_CMD_OPEN
 drivers/media/video/saa6588.c:case RDS_CMD_OPEN:
 include/media/rds.h:#define RDS_CMD_OPEN  _IOW('R',1,int)

 as saa6588 is a subdev.

 IMO, we should remove or rename the internal header first.
>>>
>>> media/rds.h should be renamed to media/saa6588.h. It is also included in
>>> drivers/media/radio/si470x/radio-si470x.h, but that's obsolete and can be
>>> removed.
>>
>> The rds file were the old RDS API, before we add it at V4L2. We should, 
>> instead,
>> convert saa6588 to use the new way, and remove the legacy stuff.
> 
> No, this was never the RDS API. It is the saa6588 kernel-internal API.
> There is nothing wrong with it, except for the fact that the name suggests
> that this is a generic RDS API, when in fact it is saa6588 specific.
> 
> Ditto for media/bt819.h.

 There are also some issues there related to videodev2 stuff.

 I prefer to apply the path as-is (just removing the ovcamchip.h) and,
 on some later cleanup, check and fix the remaining stuff.
>>>
>>> I can make a patch fixing the rds.h header usage. It's all internal stuff
>>> and the weird naming is just historical and should be changed.
>>
>> It would be nice if you can do it.
> 
> Will do.
> 
>>
>
> All other patches in this series:
>
> Reviewed-by: Hans Verkuil 

 Thanks!
>
> BTW, it is probably also a good idea to move the dabusb driver to staging 
> and
> mark it for removal in 2.6.39.

 Not sure about that. I don't see any good reason to remove dabusb driver, 
 as
 nobody reported that it is broken.
>>>
>>> Nobody has the hardware :-)
>>
>> This is too strong :) Are you absolutely sure that there's absolutely nobody 
>> in
>> the World with that hardware? ;)
> 
> I did some digging and found out the following:
> 
> The hardware in question was only an engineering sample which was later 
> licensed
> to Terratec for their 'Dr Box 1' product.
> 
> See:
> 
> http://www.baycom.de/wiki/index.php/Products::dabusbhw
> http://www.baycom.de/wiki/index.php/Products::dabusb
> 
> The authors of the driver seemed to have developed the driver a bit more. The
> latest source I've been able to find it here:
> 
> http://www.baycom.de/download/dabusb/beta/dabusb-linux-i386.tgz
> 
> The driver in the kernel only supports the engineering samples. The newer 
> driver
> on baycom.de also supports the Terratec product (which is no longer sold 
> either).
> 
>>> I know you have asked the authors about a possible removal of this driver a 
>>> few
>>> months ago. Did you get any reply from them?
>>
>> Nope.
> 
> You should try again, but use their baycom email:
> 
> http://www.baycom.de/wiki/index.php/Conta

Re: RFC: removal of dabusb driver from Linux Kernel

[Mauro Carvalho Chehab]

Hi,

I'm responsible for the multimedia support at Linux Kernel. I tried to contact 
the
authors of the DABUSB driver back in september some time ago without any luck.

We're considering the removal of dabusb driver from Linux Kernel, due to a few
reasons:

1) The driver is for an engineering sample only which was never sold as a 
commercial
   product.
2) The DAB API is completely undocumented and was never reviewed. Should other 
DAB
   drivers ever appear, then I'd rather start from scratch defining an API then
   continue this dubious API.

>From our research, it seems that a variant of the driver is/where used on some 
>hardware
developed by you and used on some Terratec hardware (Dr Box 1).

If we don't have any answer from you, we'll schedule the driver to be removed 
from
Linux kernel on the next version, as we were unable to identify anyone using 
the 
hardware supported at the kernel driver.

Thanks,
Mauro


Em 19-09-2010 09:06, Mauro Carvalho Chehab escreveu:
> Hi Deti and Georg,
> 
> The dabusb driver at the Linux kernel seems to be pretty much unmaintained. 
> Since 2006, when I
> moved it to /drivers/media, I received no patches from the driver authors. 
> All the patches
> we've got since then were usual trivial fixes and a few other drivers 
> correcting some core
> API changes.
> 
> Also, I never found anyone with the hardware, in order to test if the driver 
> keeps working.
> Is there any commercial hardware using it?
> 
> With the removal of BKL, the driver will need fixes or will likely be 
> removed. 
> 
> So, if you still care about the driver, please contact me asap. Otherwise, 
> I'll move it to
> drivers/staging and mark it to die for 2.6.38.
> 
> Thanks,
> 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

[GIT PATCHES FOR 2.6.38] rds.h and bt819.h fixes

[Hans Verkuil]

The following changes since commit 0ccbb0642d57b7d8b044ecf6d6529b186591c1ce:
  Mauro Carvalho Chehab (1):
feature_removal_schedule.txt: mark VIDIOC_*_OLD ioctls to die

are available in the git repository at:

  ssh://linuxtv.org/git/hverkuil/media_tree.git rds

Hans Verkuil (2):
  saa6588: rename rds.h to saa6588.h
  bt819: the ioctls in the header are internal to the kernel.

 Documentation/ioctl/ioctl-number.txt|2 --
 drivers/media/radio/si470x/radio-si470x.h   |1 -
 drivers/media/video/bt8xx/bttv-driver.c |   14 +++---
 drivers/media/video/saa6588.c   |   14 +++---
 drivers/media/video/saa7134/saa7134-video.c |   14 +++---
 include/media/bt819.h   |5 -
 include/media/{rds.h => saa6588.h}  |   18 --
 7 files changed, 33 insertions(+), 35 deletions(-)
 rename include/media/{rds.h => saa6588.h} (76%)

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

Re: [PATCH 3/6] Documentation/ioctl/ioctl-number.txt: Remove some now freed ioctl ranges

[Hans Verkuil]

On Monday, December 27, 2010 15:02:05 Mauro Carvalho Chehab wrote:
> Em 27-12-2010 11:23, Hans Verkuil escreveu:
> > On Monday, December 27, 2010 14:03:03 Mauro Carvalho Chehab wrote:
> >> Em 27-12-2010 10:01, Hans Verkuil escreveu:
> >>> On Monday, December 27, 2010 12:38:39 Mauro Carvalho Chehab wrote:
>  The V4L1 removal patches removed a few ioctls. Update it at the docspace.
> 
>  Signed-off-by: Mauro Carvalho Chehab 
> 
>  diff --git a/Documentation/ioctl/ioctl-number.txt 
>  b/Documentation/ioctl/ioctl-number.txt
>  index 63ffd78..49d7f00 100644
>  --- a/Documentation/ioctl/ioctl-number.txt
>  +++ b/Documentation/ioctl/ioctl-number.txt
>  @@ -260,14 +260,11 @@ Code  Seq#(hex)Include FileComments
>   't' 80-8F   linux/isdn_ppp.h
>   't' 90  linux/toshiba.h
>   'u' 00-1F   linux/smb_fs.h  gone
>  -'v' all linux/videodev.hconflict!
>   'v' 00-1F   linux/ext2_fs.h conflict!
>   'v' 00-1F   linux/fs.h  conflict!
>   'v' 00-0F   linux/sonypi.h  conflict!
>  -'v' C0-CF   drivers/media/video/ov511.h conflict!
>   'v' C0-DF   media/pwc-ioctl.h   conflict!
>   'v' C0-FF   linux/meye.hconflict!
>  -'v' C0-CF   drivers/media/video/zoran/zoran.h   conflict!
>   'v' D0-DF   drivers/media/video/cpia2/cpia2dev.hconflict!
>   'w' all CERN SCI driver
>   'y' 00-1F   packet based user level 
>  communications
> 
> >>>
> >>> There is also a line for media/ovcamchip.h in this file that can be 
> >>> removed.
> >>
> >> Ok, I'll do that.
> >>
> >>> The media/rds.h line can also be removed (this is kernel internal only).
> >>
> >> There are two rds.h, related to V4L:
> >> ./include/linux/rds.h
> > 
> > Not related to V4L, this is something from Oracle. It is this header that 
> > is public,
> > not the media/rds.h header.
> 
> Ah, ok.
> 
> >> ./include/media/rds.h
> >>
> >> One of them is at the public api:
> >>
> >> include/linux/Kbuild:header-y += rds.h
> >>
> >> Btw, that's weird:
> >>
> >> $ git grep RDS_CMD_OPEN
> >> drivers/media/video/saa6588.c:case RDS_CMD_OPEN:
> >> include/media/rds.h:#define RDS_CMD_OPEN  _IOW('R',1,int)
> >>
> >> as saa6588 is a subdev.
> >>
> >> IMO, we should remove or rename the internal header first.
> > 
> > media/rds.h should be renamed to media/saa6588.h. It is also included in
> > drivers/media/radio/si470x/radio-si470x.h, but that's obsolete and can be
> > removed.
> 
> The rds file were the old RDS API, before we add it at V4L2. We should, 
> instead,
> convert saa6588 to use the new way, and remove the legacy stuff.

No, this was never the RDS API. It is the saa6588 kernel-internal API.
There is nothing wrong with it, except for the fact that the name suggests
that this is a generic RDS API, when in fact it is saa6588 specific.

> >>> Ditto for media/bt819.h.
> >>
> >> There are also some issues there related to videodev2 stuff.
> >>
> >> I prefer to apply the path as-is (just removing the ovcamchip.h) and,
> >> on some later cleanup, check and fix the remaining stuff.
> > 
> > I can make a patch fixing the rds.h header usage. It's all internal stuff
> > and the weird naming is just historical and should be changed.
> 
> It would be nice if you can do it.

Will do.

> 
> >>>
> >>> All other patches in this series:
> >>>
> >>> Reviewed-by: Hans Verkuil 
> >>
> >> Thanks!
> >>>
> >>> BTW, it is probably also a good idea to move the dabusb driver to staging 
> >>> and
> >>> mark it for removal in 2.6.39.
> >>
> >> Not sure about that. I don't see any good reason to remove dabusb driver, 
> >> as
> >> nobody reported that it is broken.
> > 
> > Nobody has the hardware :-)
> 
> This is too strong :) Are you absolutely sure that there's absolutely nobody 
> in
> the World with that hardware? ;)

I did some digging and found out the following:

The hardware in question was only an engineering sample which was later licensed
to Terratec for their 'Dr Box 1' product.

See:

http://www.baycom.de/wiki/index.php/Products::dabusbhw
http://www.baycom.de/wiki/index.php/Products::dabusb

The authors of the driver seemed to have developed the driver a bit more. The
latest source I've been able to find it here:

http://www.baycom.de/download/dabusb/beta/dabusb-linux-i386.tgz

The driver in the kernel only supports the engineering samples. The newer driver
on baycom.de also supports the Terratec product (which is no longer sold 
either).

> > I know you have asked the authors about a possible removal of this driver a 
> > few
> > months ago. Did you get any reply from them?
> 
> Nope.

You should try again, but use their baycom email:

http://www.baycom.de/wiki/index.php/Contact
 
> > It seems to be a demonstration driver only and I've never seen anyone with 
> > the
> > hardware.
> 
> It seems s

[PATCH] [media] staging/lirc: Fix compilation when LIRC=m

[Mauro Carvalho Chehab]

drivers/staging/lirc/lirc_bt829.c:141: undefined reference to 
`lirc_register_driver'
drivers/built-in.o:(.rodata+0x20f68): undefined reference to `lirc_dev_fop_read'
drivers/built-in.o:(.rodata+0x20f7c): undefined reference to `lirc_dev_fop_poll'
drivers/built-in.o:(.rodata+0x20f8c): undefined reference to `lirc_dev_fop_open'
drivers/built-in.o:(.rodata+0x20f94): undefined reference to 
`lirc_dev_fop_close'
drivers/built-in.o:(.rodata+0x21030): undefined reference to `lirc_dev_fop_open'
drivers/built-in.o:(.rodata+0x21038): undefined reference to 
`lirc_dev_fop_close'

This happens when .config is like:
CONFIG_LIRC=m
CONFIG_IR_LIRC_CODEC=m
CONFIG_LIRC_STAGING=y
CONFIG_LIRC_BT829=y

Don't allow that.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/staging/lirc/Kconfig b/drivers/staging/lirc/Kconfig
index fa790db..be97f7b 100644
--- a/drivers/staging/lirc/Kconfig
+++ b/drivers/staging/lirc/Kconfig
@@ -14,26 +14,26 @@ if LIRC_STAGING
 
 config LIRC_BT829
 tristate "BT829 based hardware"
-   depends on LIRC_STAGING && PCI
+   depends on LIRC && PCI
help
  Driver for the IR interface on BT829-based hardware
 
 config LIRC_I2C
tristate "I2C Based IR Receivers"
-   depends on LIRC_STAGING && I2C
+   depends on LIRC && I2C
help
  Driver for I2C-based IR receivers, such as those commonly
  found onboard Hauppauge PVR-150/250/350 video capture cards
 
 config LIRC_IGORPLUGUSB
tristate "Igor Cesko's USB IR Receiver"
-   depends on LIRC_STAGING && USB
+   depends on LIRC && USB
help
  Driver for Igor Cesko's USB IR Receiver
 
 config LIRC_IMON
tristate "Legacy SoundGraph iMON Receiver and Display"
-   depends on LIRC_STAGING && USB
+   depends on LIRC && USB
help
  Driver for the original SoundGraph iMON IR Receiver and Display
 
@@ -41,31 +41,31 @@ config LIRC_IMON
 
 config LIRC_IT87
tristate "ITE IT87XX CIR Port Receiver"
-   depends on LIRC_STAGING && PNP
+   depends on LIRC && PNP
help
  Driver for the ITE IT87xx IR Receiver
 
 config LIRC_ITE8709
tristate "ITE8709 CIR Port Receiver"
-   depends on LIRC_STAGING && PNP
+   depends on LIRC && PNP
help
  Driver for the ITE8709 IR Receiver
 
 config LIRC_PARALLEL
tristate "Homebrew Parallel Port Receiver"
-   depends on LIRC_STAGING && PARPORT
+   depends on LIRC && PARPORT
help
  Driver for Homebrew Parallel Port Receivers
 
 config LIRC_SASEM
tristate "Sasem USB IR Remote"
-   depends on LIRC_STAGING && USB
+   depends on LIRC && USB
help
  Driver for the Sasem OnAir Remocon-V or Dign HV5 HTPC IR/VFD Module
 
 config LIRC_SERIAL
tristate "Homebrew Serial Port Receiver"
-   depends on LIRC_STAGING
+   depends on LIRC
help
  Driver for Homebrew Serial Port Receivers
 
@@ -78,19 +78,19 @@ config LIRC_SERIAL_TRANSMITTER
 
 config LIRC_SIR
tristate "Built-in SIR IrDA port"
-   depends on LIRC_STAGING
+   depends on LIRC
help
  Driver for the SIR IrDA port
 
 config LIRC_TTUSBIR
tristate "Technotrend USB IR Receiver"
-   depends on LIRC_STAGING && USB
+   depends on LIRC && USB
help
  Driver for the Technotrend USB IR Receiver
 
 config LIRC_ZILOG
tristate "Zilog/Hauppauge IR Transmitter"
-   depends on LIRC_STAGING && I2C
+   depends on LIRC && I2C
help
  Driver for the Zilog/Hauppauge IR Transmitter, found on
  PVR-150/500, HVR-1200/1250/1700/1800, HD-PVR and other cards
--
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 0/6] V4L1 cleanups and videodev.h removal

[Mauro Carvalho Chehab]

Em 27-12-2010 10:45, Hans Verkuil escreveu:
> On Monday, December 27, 2010 13:33:52 Mauro Carvalho Chehab wrote:
>> Em 27-12-2010 10:21, Hans Verkuil escreveu:
>>> On Monday, December 27, 2010 12:38:48 Mauro Carvalho Chehab wrote:
 Now that all hard work to remove V4L1 happened, it doesn't make
 sense on keeping videodev.h just because of two obsoleted drivers.
>>>
>>> Perhaps it is also time to mark the videodev2.h _OLD ioctls for removal in
>>> 2.6.39?
>>>
>>> If we are getting rid of old stuff anyway, then this will also be a nice
>>> cleanup.
>>>
>>> Perhaps we can even delete it without marking it for removal. After all,
>>> removing it will only affect binaries compiled against a *really* old kernel
>>> (I suspect 2.5.something). Anything that has been recompiled will 
>>> automatically
>>> use the correct ioctls.
>>
>> We can't just remove the _OLD, as they're used internally, in order to handle
>> those old binaries. I think that not all come from 2.5 times. So, the better 
>> is to
>> mark them to be removed for .39.
> 
> I double checked and they were introduced in 2.6.2 except for CROPCAP_OLD 
> which
> was introduced in 2.6.6.

Thanks for the research.
> 
> Do you want me to mark them for removal or will you?

I did it. Just sent to the ML. I'm basically with my hands tight, as kernel's 
Patchwork
is not working today, so I have some time to do some basic cleanup, while 
waiting for
someone to restart patchwork service.

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

[PATCH] feature_removal_schedule.txt: mark VIDIOC_*_OLD ioctls to die

[Mauro Carvalho Chehab]

There are some old broken definitions of ioctl's, where the
read/write arguments were marked wrong. The last one were added
on 2.6.6 kernel. Remove them, in order to cleanup some
copy_from_user/copy_to_user logic done inside V4L core.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index e348b7e..f2742e1 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -112,6 +112,27 @@ Who:   Mauro Carvalho Chehab 
 
 ---
 
+What:  Video4Linux: Remove obsolete ioctl's
+When:  kernel 2.6.39
+Files: include/media/videodev2.h
+Why:   Some ioctl's were defined wrong on 2.6.2 and 2.6.6, using the wrong
+   type of R/W arguments. They were fixed, but the old ioctl names are
+   still there, maintained to avoid breaking binary compatibility:
+ #define VIDIOC_OVERLAY_OLD_IOWR('V', 14, int)
+ #define VIDIOC_S_PARM_OLD _IOW('V', 22, struct v4l2_streamparm)
+ #define VIDIOC_S_CTRL_OLD _IOW('V', 28, struct v4l2_control)
+ #define VIDIOC_G_AUDIO_OLD_IOWR('V', 33, struct v4l2_audio)
+ #define VIDIOC_G_AUDOUT_OLD   _IOWR('V', 49, struct v4l2_audioout)
+ #define VIDIOC_CROPCAP_OLD_IOR('V', 58, struct v4l2_cropcap)
+   There's no sense on preserving those forever, as it is very doubtful
+   that someone would try to use a such old binary with a modern kernel.
+   Removing them will allow us to remove some magic done at the V4L ioctl
+   handler.
+
+Who:   Mauro Carvalho Chehab 
+
+---
+
 What:  sys_sysctl
 When:  September 2010
 Option: CONFIG_SYSCTL_SYSCALL
--
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 3/6] Documentation/ioctl/ioctl-number.txt: Remove some now freed ioctl ranges

[Mauro Carvalho Chehab]

Em 27-12-2010 11:23, Hans Verkuil escreveu:
> On Monday, December 27, 2010 14:03:03 Mauro Carvalho Chehab wrote:
>> Em 27-12-2010 10:01, Hans Verkuil escreveu:
>>> On Monday, December 27, 2010 12:38:39 Mauro Carvalho Chehab wrote:
 The V4L1 removal patches removed a few ioctls. Update it at the docspace.

 Signed-off-by: Mauro Carvalho Chehab 

 diff --git a/Documentation/ioctl/ioctl-number.txt 
 b/Documentation/ioctl/ioctl-number.txt
 index 63ffd78..49d7f00 100644
 --- a/Documentation/ioctl/ioctl-number.txt
 +++ b/Documentation/ioctl/ioctl-number.txt
 @@ -260,14 +260,11 @@ Code  Seq#(hex)  Include FileComments
  't'   80-8F   linux/isdn_ppp.h
  't'   90  linux/toshiba.h
  'u'   00-1F   linux/smb_fs.h  gone
 -'v'   all linux/videodev.hconflict!
  'v'   00-1F   linux/ext2_fs.h conflict!
  'v'   00-1F   linux/fs.h  conflict!
  'v'   00-0F   linux/sonypi.h  conflict!
 -'v'   C0-CF   drivers/media/video/ov511.h conflict!
  'v'   C0-DF   media/pwc-ioctl.h   conflict!
  'v'   C0-FF   linux/meye.hconflict!
 -'v'   C0-CF   drivers/media/video/zoran/zoran.h   conflict!
  'v'   D0-DF   drivers/media/video/cpia2/cpia2dev.hconflict!
  'w'   all CERN SCI driver
  'y'   00-1F   packet based user level 
 communications

>>>
>>> There is also a line for media/ovcamchip.h in this file that can be removed.
>>
>> Ok, I'll do that.
>>
>>> The media/rds.h line can also be removed (this is kernel internal only).
>>
>> There are two rds.h, related to V4L:
>> ./include/linux/rds.h
> 
> Not related to V4L, this is something from Oracle. It is this header that is 
> public,
> not the media/rds.h header.

Ah, ok.

>> ./include/media/rds.h
>>
>> One of them is at the public api:
>>
>> include/linux/Kbuild:header-y += rds.h
>>
>> Btw, that's weird:
>>
>> $ git grep RDS_CMD_OPEN
>> drivers/media/video/saa6588.c:case RDS_CMD_OPEN:
>> include/media/rds.h:#define RDS_CMD_OPEN  _IOW('R',1,int)
>>
>> as saa6588 is a subdev.
>>
>> IMO, we should remove or rename the internal header first.
> 
> media/rds.h should be renamed to media/saa6588.h. It is also included in
> drivers/media/radio/si470x/radio-si470x.h, but that's obsolete and can be
> removed.

The rds file were the old RDS API, before we add it at V4L2. We should, instead,
convert saa6588 to use the new way, and remove the legacy stuff.

>>> Ditto for media/bt819.h.
>>
>> There are also some issues there related to videodev2 stuff.
>>
>> I prefer to apply the path as-is (just removing the ovcamchip.h) and,
>> on some later cleanup, check and fix the remaining stuff.
> 
> I can make a patch fixing the rds.h header usage. It's all internal stuff
> and the weird naming is just historical and should be changed.

It would be nice if you can do it.

>>>
>>> All other patches in this series:
>>>
>>> Reviewed-by: Hans Verkuil 
>>
>> Thanks!
>>>
>>> BTW, it is probably also a good idea to move the dabusb driver to staging 
>>> and
>>> mark it for removal in 2.6.39.
>>
>> Not sure about that. I don't see any good reason to remove dabusb driver, as
>> nobody reported that it is broken.
> 
> Nobody has the hardware :-)

This is too strong :) Are you absolutely sure that there's absolutely nobody in
the World with that hardware? ;)
> 
> I know you have asked the authors about a possible removal of this driver a 
> few
> months ago. Did you get any reply from them?

Nope.

> It seems to be a demonstration driver only and I've never seen anyone with the
> hardware.

It seems so, but I can't see any technical reason for its removal. The BKL fix 
were
applied on it, as someone wrote a patch for it.

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: em28xx: Terratec Grabby no sound

[Florian Klink]

Hi Mauro,

with the help of Bernd Spaeth, I finally managed to get the Terratec 
Grabby

working by using

mplayer -v -tv
driver=v4l2:input=0:device=/dev/video1:alsa:adevice=hw.2,0:audiorate=48000:forceaudio:immediatemode=0
tv://

and your patch

diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index e7efb4b..6e80376 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -1621,11 +1621,11 @@ struct em28xx_board em28xx_boards[] = {
 .input = { {
 .type = EM28XX_VMUX_COMPOSITE1,
 .vmux = SAA7115_COMPOSITE0,
- .amux = EM28XX_AMUX_VIDEO2,
+ .amux = EM28XX_AMUX_LINE_IN,
 }, {
 .type = EM28XX_VMUX_SVIDEO,
 .vmux = SAA7115_SVIDEO3,
- .amux = EM28XX_AMUX_VIDEO2,
+ .amux = EM28XX_AMUX_LINE_IN,
 } },
 },
 [EM2860_BOARD_TERRATEC_AV350] = {

Working video and audio!

I wasn't able to test it with s-video, only composite.

But I think it's still safe to commit the patch, because s-video is 
only

another video input, the audio output stays the same.

Florian

On Tue, 09 Nov 2010 08:56:32 -0200, Mauro Carvalho Chehab wrote:


Em 26-10-2010 10:58, Florian Klink escreveu:

Hi,


The sound comes from alsa device. Several em28xx types provide
standard USB audio. So, snd-usb-audio handles it. That's why you 
need

alsa:adevice=hw.2,0:forceaudio at mplayer.

... but thats my problem. sound doesn't appear inside mplayer, even
with the command line options set to use the "external" alsa device.
However, "arecord -D hw:2,0 -r 32000 -c 2 -f S16_LE | aplay -" plays
the sound, but only before mplayer tried to access the sound card
Have you tried my patch? If you're using 
alsa:adevice=hw.2,0:forceaudio
at mplayer, you should not be running arecord/aplay. You need to use 
one

solution or the other.


When trying to play sound with arecord again after mplayer tried to
access it, I have to re-plug the card to get it playing sound over
arecord again, video only seems to not break it. There is no error
message or something in arecord when it's not playing anything, just
silence and the same command line output. Is there maybe anything 
with

the sample format S16_LE or something that confuses mplayer/the
driver/whatever? Strange problem... mplayer output (mplayer -v -tv

driver=v4l2:input=0:device=/dev/video1:alsa:adevice=hw.2,0:forceaudio
tv://): http://pastebin.com/yTV300iG [1] Florian -- To unsubscribe 
from

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

-- To unsubscribe from this list: send the line "unsubscribe
linux-media" in the body of a message to majord...@vger.kernel.org 
[4]

More majordomo info at http://vger.kernel.org/majordomo-info.html [5]



Links:
--
[1] http://pastebin.com/yTV300iG
[2] mailto:majord...@vger.kernel.org
[3] http://vger.kernel.org/majordomo-info.html
[4] mailto:majord...@vger.kernel.org
[5] 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

Hauppauge Nova-T Stick 3 Issues

[Ray Kinsella]

Hi all,

I recently purchased a Hauppauge Nova-T USB DVB-T receiver and have
been having trouble getting it to work.
I read through the Wiki page
(http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-Stick)
for this device and followed the instructions but still no luck.

Most of the time the frontend will fail to attach (as show below), on
the rare occasions when the frontend does attach it will hang when I
try to scan for channels.
In both cases the driver complains of I2C read/write failures.
I am using the latest from code from the V4L-DVB backports repository
with a 2.6.35 Kernel (Mythubuntu 10.10)

Any advice on what to try?

r...@pvr:~$ uname -a
Linux pvr 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC
2010 i686 GNU/Linux

r...@pvr:~$ lsusb
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
...
Bus 001 Device 004: ID 2040:7070 Hauppauge Nova-T Stick 3
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

r...@pvr:~$ dmesg
[   18.492014] usb 1-4: new high speed USB device using ehci_hcd and address 4
[   18.653158] WARNING: You're using an experimental version of the
DVB stack. As the driver
[   18.653160]  is backported to an older kernel, it doesn't
offer enough quality for
[   18.653161]  its usage in production.
[   18.653161]  Use it with care.
[   18.667402] dib0700: loaded with support for 14 different device-types
[   18.667425] check for cold 10b8 1e14
[   18.667426] check for cold 10b8 1e78
[   18.667427] check for cold 2040 7050
[   18.667428] check for cold 2040 7060
[   18.667430] check for cold 7ca a807
[   18.667431] check for cold 7ca b808
[   18.667432] check for cold 185b 1e78
[   18.667433] check for cold 185b 1e80
[   18.667434] check for cold 1584 6003
[   18.667436] check for cold 413 6f00
[   18.667437] check for cold 413 6f01
[   18.667438] check for cold 7ca b568
[   18.667439] check for cold 1044 7001
[   18.667440] check for cold 2040 9941
[   18.667441] check for cold 2040 9950
[   18.667443] check for cold 2304 22c
[   18.667444] check for cold ccd 5a
[   18.667445] check for cold 2040 9580
[   18.667446] check for cold 10b8 1ef0
[   18.667447] check for cold 1164 1e8c
[   18.667448] check for cold b05 171f
[   18.667450] check for cold 1164 1edc
[   18.667451] check for cold ccd 62
[   18.667452] check for cold 10b8 1ebc
[   18.667453] check for cold 2304 228
[   18.667454] check for cold 5d8 810f
[   18.667456] check for cold b05 173f
[   18.667457] check for cold 2040 7070
[   18.667565] FW GET_VERSION length: -32
[   18.667567] cold: 1
[   18.667568] dvb-usb: found a 'Hauppauge Nova-T Stick' in cold
state, will try to load a firmware
[   18.674300] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw'
[   18.875965] dib0700: firmware started successfully.
[   24.376079] dvb-usb: found a 'Hauppauge Nova-T Stick' in warm state.
[   24.376086] power control: 1
[   24.376129] dvb-usb: will pass the complete MPEG2 transport stream
to the software demuxer.
[   24.376546] DVB: registering new adapter (Hauppauge Nova-T Stick)
[   74.424074] ep 0 read error (status = -110)
[   74.424079] I2C read failed on address 0x40
[   84.424148] ep 0 read error (status = -110)
[   84.424151] I2C read failed on address 0x09
[   84.424157] dib0700: stk7070p_frontend_attach:
dib7000p_i2c_enumeration failed.  Cannot continue
[   84.424159]
[   84.424162] dvb-usb: no frontend was attached by 'Hauppauge Nova-T Stick'
[   84.424166] power control: 0
[   84.424168] dvb-usb: Hauppauge Nova-T Stick successfully
initialized and connected.
[   89.424093] Firmware version: 0, -1941421839, 0x100, 1348026105
[   94.424065] dib0700: ir protocol setup failed
[   94.424104] usbcore: registered new interface driver dvb_usb_dib0700


r...@pvr:~$ cat /etc/modprobe.d/options.conf
options dvb_usb_dib0700 force_lna_activation=1 debug=1
options dvb_usb disable_rc_polling=1 debug=1
options dvb_core debug=1

r...@pvr:~$ lsmod
Module  Size  Used by
dvb_usb_dib070056317  0
dib7000p   16176  1 dvb_usb_dib0700
dib00901  1 dvb_usb_dib0700
dib7000m   13132  1 dvb_usb_dib0700
dib0070 7766  1 dvb_usb_dib0700
dvb_usb17643  1 dvb_usb_dib0700
dib800025510  1 dvb_usb_dib0700
dvb_core   86744  3 dib7000p,dvb_usb,dib8000
dib3000mc  11200  1 dvb_usb_dib0700
dibx000_common  3112  4 dib7000p,dib7000m,dib8000,dib3000mc
usbhid 36882  0
hid67742  1 usbhid
...

Thanks

Ray Kinsella
--
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 3/6] Documentation/ioctl/ioctl-number.txt: Remove some now freed ioctl ranges

[Hans Verkuil]

On Monday, December 27, 2010 14:03:03 Mauro Carvalho Chehab wrote:
> Em 27-12-2010 10:01, Hans Verkuil escreveu:
> > On Monday, December 27, 2010 12:38:39 Mauro Carvalho Chehab wrote:
> >> The V4L1 removal patches removed a few ioctls. Update it at the docspace.
> >>
> >> Signed-off-by: Mauro Carvalho Chehab 
> >>
> >> diff --git a/Documentation/ioctl/ioctl-number.txt 
> >> b/Documentation/ioctl/ioctl-number.txt
> >> index 63ffd78..49d7f00 100644
> >> --- a/Documentation/ioctl/ioctl-number.txt
> >> +++ b/Documentation/ioctl/ioctl-number.txt
> >> @@ -260,14 +260,11 @@ Code  Seq#(hex)  Include FileComments
> >>  't'   80-8F   linux/isdn_ppp.h
> >>  't'   90  linux/toshiba.h
> >>  'u'   00-1F   linux/smb_fs.h  gone
> >> -'v'   all linux/videodev.hconflict!
> >>  'v'   00-1F   linux/ext2_fs.h conflict!
> >>  'v'   00-1F   linux/fs.h  conflict!
> >>  'v'   00-0F   linux/sonypi.h  conflict!
> >> -'v'   C0-CF   drivers/media/video/ov511.h conflict!
> >>  'v'   C0-DF   media/pwc-ioctl.h   conflict!
> >>  'v'   C0-FF   linux/meye.hconflict!
> >> -'v'   C0-CF   drivers/media/video/zoran/zoran.h   conflict!
> >>  'v'   D0-DF   drivers/media/video/cpia2/cpia2dev.hconflict!
> >>  'w'   all CERN SCI driver
> >>  'y'   00-1F   packet based user level 
> >> communications
> >>
> > 
> > There is also a line for media/ovcamchip.h in this file that can be removed.
> 
> Ok, I'll do that.
> 
> > The media/rds.h line can also be removed (this is kernel internal only).
> 
> There are two rds.h, related to V4L:
> ./include/linux/rds.h

Not related to V4L, this is something from Oracle. It is this header that is 
public,
not the media/rds.h header.

> ./include/media/rds.h
> 
> One of them is at the public api:
> 
> include/linux/Kbuild:header-y += rds.h
> 
> Btw, that's weird:
> 
> $ git grep RDS_CMD_OPEN
> drivers/media/video/saa6588.c:case RDS_CMD_OPEN:
> include/media/rds.h:#define RDS_CMD_OPEN  _IOW('R',1,int)
> 
> as saa6588 is a subdev.
> 
> IMO, we should remove or rename the internal header first.

media/rds.h should be renamed to media/saa6588.h. It is also included in
drivers/media/radio/si470x/radio-si470x.h, but that's obsolete and can be
removed.
 
> > Ditto for media/bt819.h.
> 
> There are also some issues there related to videodev2 stuff.
> 
> I prefer to apply the path as-is (just removing the ovcamchip.h) and,
> on some later cleanup, check and fix the remaining stuff.

I can make a patch fixing the rds.h header usage. It's all internal stuff
and the weird naming is just historical and should be changed.

> > 
> > All other patches in this series:
> > 
> > Reviewed-by: Hans Verkuil 
> 
> Thanks!
> > 
> > BTW, it is probably also a good idea to move the dabusb driver to staging 
> > and
> > mark it for removal in 2.6.39.
> 
> Not sure about that. I don't see any good reason to remove dabusb driver, as
> nobody reported that it is broken.

Nobody has the hardware :-)

I know you have asked the authors about a possible removal of this driver a few
months ago. Did you get any reply from them?

It seems to be a demonstration driver only and I've never seen anyone with the
hardware.

Regards,

Hans

> > 
> > Regards,
> > 
> > Hans
> > 
> 
> --
> 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
> 

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

Re: [PATCH 3/6] Documentation/ioctl/ioctl-number.txt: Remove some now freed ioctl ranges

[Mauro Carvalho Chehab]

Em 27-12-2010 10:01, Hans Verkuil escreveu:
> On Monday, December 27, 2010 12:38:39 Mauro Carvalho Chehab wrote:
>> The V4L1 removal patches removed a few ioctls. Update it at the docspace.
>>
>> Signed-off-by: Mauro Carvalho Chehab 
>>

Reviewed version, removing also ovcamchip.h.

Cheers,
Mauro


commit 49962bb3d96c7b174198dc6fe7103426512ac2aa
Author: Mauro Carvalho Chehab 
Date:   Mon Dec 27 09:13:12 2010 -0200

Documentation/ioctl/ioctl-number.txt: Remove some now freed ioctl ranges

The V4L1 removal patches removed a few ioctls. Update it at the docspace.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index 63ffd78..b2400d7 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -260,14 +260,11 @@ Code  Seq#(hex)   Include FileComments
 't'80-8F   linux/isdn_ppp.h
 't'90  linux/toshiba.h
 'u'00-1F   linux/smb_fs.h  gone
-'v'all linux/videodev.hconflict!
 'v'00-1F   linux/ext2_fs.h conflict!
 'v'00-1F   linux/fs.h  conflict!
 'v'00-0F   linux/sonypi.h  conflict!
-'v'C0-CF   drivers/media/video/ov511.h conflict!
 'v'C0-DF   media/pwc-ioctl.h   conflict!
 'v'C0-FF   linux/meye.hconflict!
-'v'C0-CF   drivers/media/video/zoran/zoran.h   conflict!
 'v'D0-DF   drivers/media/video/cpia2/cpia2dev.hconflict!
 'w'all CERN SCI driver
 'y'00-1F   packet based user level communications
@@ -278,7 +275,6 @@ Code  Seq#(hex) Include FileComments

 'z'10-4F   drivers/s390/crypto/zcrypt_api.hconflict!
 0x80   00-1F   linux/fb.h
-0x88   00-3F   media/ovcamchip.h
 0x89   00-06   arch/x86/include/asm/sockios.h
 0x89   0B-DF   linux/sockios.h
 0x89   E0-EF   linux/sockios.h SIOCPROTOPRIVATE range

--
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 3/6] Documentation/ioctl/ioctl-number.txt: Remove some now freed ioctl ranges

[Mauro Carvalho Chehab]

Em 27-12-2010 10:01, Hans Verkuil escreveu:
> On Monday, December 27, 2010 12:38:39 Mauro Carvalho Chehab wrote:
>> The V4L1 removal patches removed a few ioctls. Update it at the docspace.
>>
>> Signed-off-by: Mauro Carvalho Chehab 
>>
>> diff --git a/Documentation/ioctl/ioctl-number.txt 
>> b/Documentation/ioctl/ioctl-number.txt
>> index 63ffd78..49d7f00 100644
>> --- a/Documentation/ioctl/ioctl-number.txt
>> +++ b/Documentation/ioctl/ioctl-number.txt
>> @@ -260,14 +260,11 @@ Code  Seq#(hex)Include FileComments
>>  't' 80-8F   linux/isdn_ppp.h
>>  't' 90  linux/toshiba.h
>>  'u' 00-1F   linux/smb_fs.h  gone
>> -'v' all linux/videodev.hconflict!
>>  'v' 00-1F   linux/ext2_fs.h conflict!
>>  'v' 00-1F   linux/fs.h  conflict!
>>  'v' 00-0F   linux/sonypi.h  conflict!
>> -'v' C0-CF   drivers/media/video/ov511.h conflict!
>>  'v' C0-DF   media/pwc-ioctl.h   conflict!
>>  'v' C0-FF   linux/meye.hconflict!
>> -'v' C0-CF   drivers/media/video/zoran/zoran.h   conflict!
>>  'v' D0-DF   drivers/media/video/cpia2/cpia2dev.hconflict!
>>  'w' all CERN SCI driver
>>  'y' 00-1F   packet based user level communications
>>
> 
> There is also a line for media/ovcamchip.h in this file that can be removed.

Ok, I'll do that.

> The media/rds.h line can also be removed (this is kernel internal only).

There are two rds.h, related to V4L:
./include/linux/rds.h
./include/media/rds.h

One of them is at the public api:

include/linux/Kbuild:header-y += rds.h

Btw, that's weird:

$ git grep RDS_CMD_OPEN
drivers/media/video/saa6588.c:case RDS_CMD_OPEN:
include/media/rds.h:#define RDS_CMD_OPEN  _IOW('R',1,int)

as saa6588 is a subdev.

IMO, we should remove or rename the internal header first.

> Ditto for media/bt819.h.

There are also some issues there related to videodev2 stuff.

I prefer to apply the path as-is (just removing the ovcamchip.h) and,
on some later cleanup, check and fix the remaining stuff.
> 
> All other patches in this series:
> 
> Reviewed-by: Hans Verkuil 

Thanks!
> 
> BTW, it is probably also a good idea to move the dabusb driver to staging and
> mark it for removal in 2.6.39.

Not sure about that. I don't see any good reason to remove dabusb driver, as
nobody reported that it is broken.
> 
> Regards,
> 
>   Hans
> 

--
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 0/6] V4L1 cleanups and videodev.h removal

[Hans Verkuil]

On Monday, December 27, 2010 13:33:52 Mauro Carvalho Chehab wrote:
> Em 27-12-2010 10:21, Hans Verkuil escreveu:
> > On Monday, December 27, 2010 12:38:48 Mauro Carvalho Chehab wrote:
> >> Now that all hard work to remove V4L1 happened, it doesn't make
> >> sense on keeping videodev.h just because of two obsoleted drivers.
> > 
> > Perhaps it is also time to mark the videodev2.h _OLD ioctls for removal in
> > 2.6.39?
> > 
> > If we are getting rid of old stuff anyway, then this will also be a nice
> > cleanup.
> > 
> > Perhaps we can even delete it without marking it for removal. After all,
> > removing it will only affect binaries compiled against a *really* old kernel
> > (I suspect 2.5.something). Anything that has been recompiled will 
> > automatically
> > use the correct ioctls.
> 
> We can't just remove the _OLD, as they're used internally, in order to handle
> those old binaries. I think that not all come from 2.5 times. So, the better 
> is to
> mark them to be removed for .39.

I double checked and they were introduced in 2.6.2 except for CROPCAP_OLD which
was introduced in 2.6.6.

Do you want me to mark them for removal or will you?

Regards,

Hans

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

Re: [PATCH 0/6] V4L1 cleanups and videodev.h removal

[Mauro Carvalho Chehab]

Em 27-12-2010 10:21, Hans Verkuil escreveu:
> On Monday, December 27, 2010 12:38:48 Mauro Carvalho Chehab wrote:
>> Now that all hard work to remove V4L1 happened, it doesn't make
>> sense on keeping videodev.h just because of two obsoleted drivers.
> 
> Perhaps it is also time to mark the videodev2.h _OLD ioctls for removal in
> 2.6.39?
> 
> If we are getting rid of old stuff anyway, then this will also be a nice
> cleanup.
> 
> Perhaps we can even delete it without marking it for removal. After all,
> removing it will only affect binaries compiled against a *really* old kernel
> (I suspect 2.5.something). Anything that has been recompiled will 
> automatically
> use the correct ioctls.

We can't just remove the _OLD, as they're used internally, in order to handle
those old binaries. I think that not all come from 2.5 times. So, the better is 
to
mark them to be removed for .39.

> 
> Regards,
> 
>   Hans
> 

--
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 0/6] V4L1 cleanups and videodev.h removal

[Hans Verkuil]

On Monday, December 27, 2010 12:38:48 Mauro Carvalho Chehab wrote:
> Now that all hard work to remove V4L1 happened, it doesn't make
> sense on keeping videodev.h just because of two obsoleted drivers.

Perhaps it is also time to mark the videodev2.h _OLD ioctls for removal in
2.6.39?

If we are getting rid of old stuff anyway, then this will also be a nice
cleanup.

Perhaps we can even delete it without marking it for removal. After all,
removing it will only affect binaries compiled against a *really* old kernel
(I suspect 2.5.something). Anything that has been recompiled will automatically
use the correct ioctls.

Regards,

Hans

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

Re: ngene & Satix-S2 dual problems

[Andre]

On 27 Dec 2010, at 11:12, Ludovic BOUE wrote:

> Hi,
> 
> About the CI part, from what I’ve read, it seems that the stream must be get 
> from
> dvr0, than passed to sec0. And the final decrypted stream must be read
> from sec0.
> 
> I use Mumudvb and will not be able to handle this setup.

I hadn't found mumudvb before, interesting software, thanks.

The mumudvb pages on scrambled channels makes some suggestions, sounds like 
sasc-ng would be a better fit for this type of software, it's much more stable 
than a year ago too!

The rest I don't know about.

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

Re: RFC: V4L2 driver for Qualcomm MSM camera.

[Mauro Carvalho Chehab]

Em 24-12-2010 09:19, Hans Verkuil escreveu:
> Good to hear from Qualcomm!
> 
> I've made some comments below:
> 
> On Thursday, December 23, 2010 20:38:04 Shuzhen Wang wrote:
>> Hello, 
>>
>> This is the architecture overview we put together for Qualcomm MSM camera
>> support in linux-media tree. Your comments are very much appreciated!
>>
>>
>> Introduction
>> 
>>
>> This is the video4linux driver for Qualcomm MSM (Mobile Station Modem)
>> camera.
>>
>> The driver supports video and camera functionality on Qualcomm MSM SoC.
>> It supports camera sensors provided by OEMs with parallel/MIPI
>> interfaces, and operates in continuous streaming, snapshot, or video
>> recording modes.
>>
>> Hardware description
>> 
>>
>> MSM camera hardware contains the following components:
>> 1. One or more camera sensors controlled via I2C bus, and data outputs
>> on AXI or MIPI bus.
>> 2. Video Front End (VFE) core is an image signal processing hardware
>> pipeline that takes the sensor output, does the necessary processing,
>> and outputs to a buffer for V4L2 application. VFE is clocked by PCLK
>> (pixel clock) from the sensor.
>>
>> Software description
>> 
>>
>> The driver encapsulates the low-level hardware management and aligns
>> the interface to V4L2 driver framework. There is also a user space
>> camera service daemon which handles events from driver and changes
>> settings accordingly.
>>
>> During boot-up, the sensor is probed for and if the probe succeeds
>> /dev/video0 and /dev/msm_camera/config0 device nodes are created. The
>> /dev/video0 node is used for video buffer allocation in the kernel and for
>> receiving V4L2 ioctls for controlling the camera hardware (VFE, sensors).
>> The /dev/msm_camera/config0 node is used for sending commands and other
>> statistics available from the hardware to the camera service daemon. Note
>> that if more than one camera sensor is detected, there will be /dev/video1
>> and /dev/msm_camera/config1 device nodes created as well.
> 
> Does config control the sensor or the main msm subsystem? Or both?
> 
>>
>> Design
>> ==
>>
>> For MSM camera IC, significant portion of image processing and optimization
>> codes are proprietary, so they cannot sit in kernel space. This plays an
>> important role when making design decisions.
>>
>> Our design is to have a light-weighted kernel driver, and put the
>> proprietary code in a user space daemon. The daemon polls on events
>> from /dev/msm_camera/config0 device in the form of v4l2_event. The events
>> could either be asynchronous (generated by the hardware), or synchronous
>> (control command from the application). Based on the events it receives,
>> the daemon will send appropriate control commands to the hardware.
>>
>>+-+++
>>| Application || Service Daemon |
>>+-+++ User Space
>>  ..
>>+--+  Kernel Space
>>|V4L2  |
>>+--+
>>+-+ ++ +---+
>>| VFE/ISP | | Sensor | | Flash |
>>+-+ ++ +---+
> 
> Just to repeat what I have discussed with Qualcomm before (so that everyone 
> knows):
> I have no problem with proprietary code as long as:
> 
> 1) the hardware and driver APIs are clearly documented allowing someone else 
> to
> make their own algorithms.
> 
> 2) the initial state of the hardware as set up by the driver is good enough to
> capture video in normal lighting conditions. In other words: the daemon 
> should not
> be needed for testing the driver. I compare this with cheap webcams that often
> need software white balancing to get a decent picture. They still work without
> that, but the picture simply doesn't look very good.
> 
> We also discussed the daemon in the past. The idea was that it should be 
> called
> from libv4l2. Is this still the plan?
> 
>> Power Management
>> 
>>
>> None at this point.
>>
>> SMP/multi-core
>> ==
>>
>> Mutex is used for synchronization of threads accessing the driver
>> simultaneously. Between hardware interrupt handler and threads,
>> we use spinlock to make sure locking is done properly.
> 
> Take a look at the new core-assisted locking scheme implemented for 2.6.37.
> This might simplify your driver. Just FYI.
>  
>> Security
>> 
>>
>> None.
>>
>> Interface
>> =
>>
>> The driver uses V4L2 API for user kernel interaction. Refer to
>> http://v4l2spec.bytesex.org/spec-single/v4l2.html.
> 
> That's really, really old. This is much more up to date:
> 
> http://linuxtv.org/downloads/v4l-dvb-apis/
> 
> And the very latest build every day is always available here:
> 
> http://www.xs4all.nl/~hverkuil/spec/media.html
>>
>> Between camera service daemon and the driver, 

Re: [PATCH 3/6] Documentation/ioctl/ioctl-number.txt: Remove some now freed ioctl ranges

[Hans Verkuil]

On Monday, December 27, 2010 12:38:39 Mauro Carvalho Chehab wrote:
> The V4L1 removal patches removed a few ioctls. Update it at the docspace.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> 
> diff --git a/Documentation/ioctl/ioctl-number.txt 
> b/Documentation/ioctl/ioctl-number.txt
> index 63ffd78..49d7f00 100644
> --- a/Documentation/ioctl/ioctl-number.txt
> +++ b/Documentation/ioctl/ioctl-number.txt
> @@ -260,14 +260,11 @@ Code  Seq#(hex) Include FileComments
>  't'  80-8F   linux/isdn_ppp.h
>  't'  90  linux/toshiba.h
>  'u'  00-1F   linux/smb_fs.h  gone
> -'v'  all linux/videodev.hconflict!
>  'v'  00-1F   linux/ext2_fs.h conflict!
>  'v'  00-1F   linux/fs.h  conflict!
>  'v'  00-0F   linux/sonypi.h  conflict!
> -'v'  C0-CF   drivers/media/video/ov511.h conflict!
>  'v'  C0-DF   media/pwc-ioctl.h   conflict!
>  'v'  C0-FF   linux/meye.hconflict!
> -'v'  C0-CF   drivers/media/video/zoran/zoran.h   conflict!
>  'v'  D0-DF   drivers/media/video/cpia2/cpia2dev.hconflict!
>  'w'  all CERN SCI driver
>  'y'  00-1F   packet based user level communications
> 

There is also a line for media/ovcamchip.h in this file that can be removed.
The media/rds.h line can also be removed (this is kernel internal only).
Ditto for media/bt819.h.

All other patches in this series:

Reviewed-by: Hans Verkuil 

BTW, it is probably also a good idea to move the dabusb driver to staging and
mark it for removal in 2.6.39.

Regards,

Hans

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

Re: ir-core: nec protocol problem

[Mauro Carvalho Chehab]

Em 26-12-2010 15:54, Mariusz Białończyk escreveu:
> Hello,
> Maybe you could give me some tip for issue i found with ir-core.
> I am using cx88 chipset for ir-decoding.
> The problem is that sometimes the key is wrong handled (especially
> when the remote is long from the receiver), for instance:
> I am pressing "1" on remote, then after some time i am pressing
> "2" but instead i've got repeat key of "1" again.
> When looking at debug logs i can see that "key startup sequence"
> is omitted and only a back of ir code (the repeat) is handled
> as a repeat. Maybe I'm not clear, so i'll try to explain like this:
> As far as I know pressing the buttons on remote with NEC protocol
> generates two things:
> 1. key code (I'll call it "code header")
> 2. repeat code
> 
> And the problem is when ir-core is receiving it like this:
> 1. key code of "1"
> 2. repeat code
> 3. key code of "2" - this is wrong decoded
> 4. repeat code - and here it repeats "1", not "2"
> 
> I think it's a problem with NEC protocol. My point is that
> it should NOT do "repeat code" in case when "code header" was not
> decoded, and especially if the repeat code is after some period of
> time after the "key header" (and even after ir_keyup event).
> In the other words - I think it is better to have no event instead
> of wrong repeat key event (which i does *NOT* press), at least I
> know than, that I need to press the key again.
> I am attaching you debug logs with comments inside.
> What do you think about it? Maybe it is fixed now? (i am using
> 2.6.36 kernel with one patch which ported my cx88 driver to
> ir-core).

We can't simply discard the repeat code due to some non-decoded stuff,
as it can be some noise, caused, for example, by a fluorescent bulb or
by the sunlight.

That's said, it actually makes sense to have some timeout event that
will disable key repeats if they are not close enough to an IR keydown.

At a first glance, it makes sense to use the ir_keyup timeout also to 
disable the IR repeat for the NEC protocol.

Feel free to propose a patch for it.

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: Hauppauge HVR-2200 analog

[Julian Scheel]

Hi Steve,

Am 14.12.2010 20:51, schrieb Steven Toth:

On 12/14/10 12:23 PM, Julian Scheel wrote:

Is there any reason, why the additional card-information found here:
http://www.kernellabs.com/hg/~stoth/saa7164-dev/
is not yet in the kernel tree?

PAL encoder support is broken in the current tree and it currently getting my
love and attention. Point me at the specific boards you think are missing and
I'll also add these to my todo list, they'll likely get merged at the same time


Any progress on this? If you need any assistance please let me know.

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

[PATCH 2/6] [media] V4L1 removal: Remove linux/videodev.h

[Mauro Carvalho Chehab]

There's no sense on keeping it on 2.6.38, as nobody is using it
anymore, at the kernel tree, and installing it at the userspace
API.

As two deprecated drivers still need it, move it to their internal
directories.

Signed-off-by: Mauro Carvalho Chehab 

 create mode 100644 drivers/staging/se401/videodev.h
 create mode 100644 drivers/staging/usbvideo/videodev.h
 delete mode 100644 include/linux/videodev.h
 delete mode 100644 include/media/ovcamchip.h

diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index d66ed2b..e348b7e 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -97,23 +97,6 @@ Who: Pavel Machek 
 
 ---
 
-What:  Video4Linux API 1 ioctls and from Video devices.
-When:  kernel 2.6.39
-Files: include/linux/videodev.h
-Check: include/linux/videodev.h
-Why:   V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6
-   series. The old API have lots of drawbacks and don't provide enough
-   means to work with all video and audio standards. The newer API is
-   already available on the main drivers and should be used instead.
-
-   The userspace libv4l1 library can convert V4L1 calls to V4L2. This
-   replaces the kernel V4L1 compatibility module which was removed in
-   2.6.38. The last V4L1 drivers will either be converted to V4L2 or
-   removed for 2.6.39 at which point the V4L1 API will cease to exist.
-Who:   Mauro Carvalho Chehab 
-

-
 What:  Video4Linux obsolete drivers using V4L1 API
 When:  kernel 2.6.39
 Files: drivers/staging/se401/* drivers/staging/usbvideo/*
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c 
b/drivers/media/video/v4l2-compat-ioctl32.c
index 8ac89ad..38c4b3c 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -15,7 +15,6 @@
 
 #include 
 #define __OLD_VIDIOC_ /* To allow fixing old calls*/
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/staging/se401/se401.h b/drivers/staging/se401/se401.h
index bf7d2e9..2758f47 100644
--- a/drivers/staging/se401/se401.h
+++ b/drivers/staging/se401/se401.h
@@ -3,7 +3,7 @@
 #define __LINUX_se401_H
 
 #include 
-#include 
+#include "videodev.h"
 #include 
 #include 
 #include 
diff --git a/drivers/staging/se401/videodev.h b/drivers/staging/se401/videodev.h
new file mode 100644
index 000..f11efbe
--- /dev/null
+++ b/drivers/staging/se401/videodev.h
@@ -0,0 +1,318 @@
+/*
+ * Video for Linux version 1 - OBSOLETE
+ *
+ * Header file for v4l1 drivers and applications, for
+ * Linux kernels 2.2.x or 2.4.x.
+ *
+ * Provides header for legacy drivers and applications
+ *
+ * See http://linuxtv.org for more info
+ *
+ */
+#ifndef __LINUX_VIDEODEV_H
+#define __LINUX_VIDEODEV_H
+
+#include 
+#include 
+#include 
+
+#define VID_TYPE_CAPTURE   1   /* Can capture */
+#define VID_TYPE_TUNER 2   /* Can tune */
+#define VID_TYPE_TELETEXT  4   /* Does teletext */
+#define VID_TYPE_OVERLAY   8   /* Overlay onto frame buffer */
+#define VID_TYPE_CHROMAKEY 16  /* Overlay by chromakey */
+#define VID_TYPE_CLIPPING  32  /* Can clip */
+#define VID_TYPE_FRAMERAM  64  /* Uses the frame buffer memory */
+#define VID_TYPE_SCALES128 /* Scalable */
+#define VID_TYPE_MONOCHROME256 /* Monochrome only */
+#define VID_TYPE_SUBCAPTURE512 /* Can capture subareas of the image */
+#define VID_TYPE_MPEG_DECODER  1024/* Can decode MPEG streams */
+#define VID_TYPE_MPEG_ENCODER  2048/* Can encode MPEG streams */
+#define VID_TYPE_MJPEG_DECODER 4096/* Can decode MJPEG streams */
+#define VID_TYPE_MJPEG_ENCODER 8192/* Can encode MJPEG streams */
+
+struct video_capability
+{
+   char name[32];
+   int type;
+   int channels;   /* Num channels */
+   int audios; /* Num audio devices */
+   int maxwidth;   /* Supported width */
+   int maxheight;  /* And height */
+   int minwidth;   /* Supported width */
+   int minheight;  /* And height */
+};
+
+
+struct video_channel
+{
+   int channel;
+   char name[32];
+   int tuners;
+   __u32  flags;
+#define VIDEO_VC_TUNER 1   /* Channel has a tuner */
+#define VIDEO_VC_AUDIO 2   /* Channel has audio */
+   __u16  type;
+#define VIDEO_TYPE_TV  1
+#define VIDEO_TYPE_CAMERA  2
+   __u16 norm; /* Norm set by channel */
+};
+
+struct video_tuner
+{
+   int tuner;
+   char name[32];
+   unsigned long rangelow, rangehigh;  /* Tuner range */
+   __u32 flags;
+#define VIDEO_TUNER_PAL1
+#define VIDEO_TUNER_NTSC   2
+#define VIDEO_TUNER_SECAM  4
+#define VIDEO_TUNER_LOW8   /* Uses KHz not MHz */
+#define VIDEO_TUNER_NORM   16  /* Tuner can set norm */
+#define VID

[PATCH 3/6] Documentation/ioctl/ioctl-number.txt: Remove some now freed ioctl ranges

[Mauro Carvalho Chehab]

The V4L1 removal patches removed a few ioctls. Update it at the docspace.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index 63ffd78..49d7f00 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -260,14 +260,11 @@ Code  Seq#(hex)   Include FileComments
 't'80-8F   linux/isdn_ppp.h
 't'90  linux/toshiba.h
 'u'00-1F   linux/smb_fs.h  gone
-'v'all linux/videodev.hconflict!
 'v'00-1F   linux/ext2_fs.h conflict!
 'v'00-1F   linux/fs.h  conflict!
 'v'00-0F   linux/sonypi.h  conflict!
-'v'C0-CF   drivers/media/video/ov511.h conflict!
 'v'C0-DF   media/pwc-ioctl.h   conflict!
 'v'C0-FF   linux/meye.hconflict!
-'v'C0-CF   drivers/media/video/zoran/zoran.h   conflict!
 'v'D0-DF   drivers/media/video/cpia2/cpia2dev.hconflict!
 'w'all CERN SCI driver
 'y'00-1F   packet based user level communications
-- 
1.7.3.4


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

[PATCH 4/6] [media] Fix videodev.h references at the V4L DocBook

[Mauro Carvalho Chehab]

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/v4l/func-ioctl.xml 
b/Documentation/DocBook/v4l/func-ioctl.xml
index 00f9690..b60fd37 100644
--- a/Documentation/DocBook/v4l/func-ioctl.xml
+++ b/Documentation/DocBook/v4l/func-ioctl.xml
@@ -34,8 +34,7 @@
   
request

- V4L2 ioctl request code as defined in the videodev.h header file, for example
+ V4L2 ioctl request code as defined in the 
videodev2.h header file, for example
 VIDIOC_QUERYCAP.

   
@@ -57,7 +56,7 @@ file descriptor. An ioctl request has 
encoded
 in it whether the argument is an input, output or read/write
 parameter, and the size of the argument argp in
 bytes. Macros and defines specifying V4L2 ioctl requests are located
-in the videodev.h header file.
+in the videodev2.h header file.
 Applications should use their own copy, not include the version in the
 kernel sources on the system they compile on. All V4L2 ioctl requests,
 their respective function and parameters are specified in 
 
 In V4L2 each format has an identifier which looks like
-PIX_FMT_XXX, defined in the videodev.h header file. These identifiers
+PIX_FMT_XXX, defined in the 
videodev2.h
+header file. These identifiers
 represent four character codes
 which are also listed below, however they are not the same as those
 used in the Windows world.
-- 
1.7.3.4


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

[PATCH 5/6] [media] Remove the old V4L1 v4lgrab.c file

[Mauro Carvalho Chehab]

This example file uses the old V4L1 API. It also doesn't use libv4l.
So, it is completely obsolete. A good example already exists at
v4l-utils (v4l2grab.c):
http://git.linuxtv.org/v4l-utils.git

Signed-off-by: Mauro Carvalho Chehab 

 delete mode 100644 Documentation/video4linux/v4lgrab.c

diff --git a/Documentation/video4linux/v4lgrab.c 
b/Documentation/video4linux/v4lgrab.c
deleted file mode 100644
index c8ded17..000
--- a/Documentation/video4linux/v4lgrab.c
+++ /dev/null
@@ -1,201 +0,0 @@
-/* Simple Video4Linux image grabber. */
-/*
- * Video4Linux Driver Test/Example Framegrabbing Program
- *
- * Compile with:
- * gcc -s -Wall -Wstrict-prototypes v4lgrab.c -o v4lgrab
- * Use as:
- * v4lgrab >image.ppm
- *
- * Copyright (C) 1998-05-03, Phil Blundell 
- * Copied from http://www.tazenda.demon.co.uk/phil/vgrabber.c
- * with minor modifications (Dave Forrest, dr...@virginia.edu).
- *
- *
- * For some cameras you may need to pre-load libv4l to perform
- * the necessary decompression, e.g.:
- *
- * export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so
- * ./v4lgrab >image.ppm
- *
- * see http://hansdegoede.livejournal.com/3636.html for details.
- *
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#define VIDEO_DEV "/dev/video0"
-
-/* Stole this from tvset.c */
-
-#define READ_VIDEO_PIXEL(buf, format, depth, r, g, b)   \
-{   \
-   switch (format) \
-   {   \
-   case VIDEO_PALETTE_GREY:\
-   switch (depth)  \
-   {   \
-   case 4: \
-   case 6: \
-   case 8: \
-   (r) = (g) = (b) = (*buf++ << 8);\
-   break;  \
-   \
-   case 16:\
-   (r) = (g) = (b) =   \
-   *((unsigned short *) buf);  
\
-   buf += 2;   \
-   break;  \
-   }   \
-   break;  \
-   \
-   \
-   case VIDEO_PALETTE_RGB565:  \
-   {   \
-   unsigned short tmp = *(unsigned short *)buf;\
-   (r) = tmp&0xF800;   \
-   (g) = (tmp<<5)&0xFC00;  \
-   (b) = (tmp<<11)&0xF800; \
-   buf += 2;   \
-   }   \
-   break;  \
-   \
-   case VIDEO_PALETTE_RGB555:  \
-   (r) = (buf[0]&0xF8)<<8; \
-   (g) = ((buf[0] << 5 | buf[1] >> 3)&0xF8)<<8;\
-   (b) = ((buf[1] << 2 ) & 0xF8)<<8;   \
-   buf += 2;   \
-   break;  \
-   \
-   case VIDEO_PALETTE_RGB24:   \
-   (r) = buf[0] << 8; (g) = buf[1] << 8;   \
-   (b) = buf[2] << 8;  \
-   buf += 3;   \
-   break;  \
-   \
-   default:\
-   fprintf(stderr, \
-   "Format %d not yet supported\n",\
-   

[PATCH 6/6] [media] omap_vout: Remove an obsolete comment

[Mauro Carvalho Chehab]

This comment mentions a field that doesn't exist, and talks about
videodev.h that got removed. So, it doesn't make any sense to keep
it.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index 15f8793..83de97a 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2230,7 +2230,6 @@ static int __init omap_vout_setup_video_data(struct 
omap_vout_device *vout)
 
strlcpy(vfd->name, VOUT_NAME, sizeof(vfd->name));
 
-   /* need to register for a VID_HARDWARE_* ID in videodev.h */
vfd->fops = &omap_vout_fops;
vfd->v4l2_dev = &vout->vid_dev->v4l2_dev;
mutex_init(&vout->lock);
-- 
1.7.3.4

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

[PATCH 0/6] V4L1 cleanups and videodev.h removal

[Mauro Carvalho Chehab]

Now that all hard work to remove V4L1 happened, it doesn't make
sense on keeping videodev.h just because of two obsoleted drivers.

Let's just remove this thing and copy it to the two staging drivers
that still needs it.

While here, fix the remaining bits that were hit by:
$ git grep videodev.h

After this series, the only places where videodev.h will show will be
at the V4L2 DocBook document that describes the migration (compat.xml)
and 3 drivers at staging: the two deprecated drivers and a very messy
driver for a few easycap boards that has its own internal copy of
videodev.h.

Mauro Carvalho Chehab (6):
  [media] Remove VIDEO_V4L1 Kconfig option
  [media] V4L1 removal: Remove linux/videodev.h
  Documentation/ioctl/ioctl-number.txt: Remove some now freed ioctl
ranges
  [media] Fix videodev.h references at the V4L DocBook
  [media] Remove the old V4L1 v4lgrab.c file
  [media] omap_vout: Remove an obsolete comment

 Documentation/DocBook/v4l/func-ioctl.xml   |5 +-
 Documentation/DocBook/v4l/pixfmt.xml   |4 +-
 Documentation/feature-removal-schedule.txt |   17 --
 Documentation/ioctl/ioctl-number.txt   |3 -
 Documentation/video4linux/v4lgrab.c|  201 -
 drivers/media/Kconfig  |   14 --
 drivers/media/video/Kconfig|5 -
 drivers/media/video/omap/omap_vout.c   |1 -
 drivers/media/video/v4l2-compat-ioctl32.c  |1 -
 drivers/staging/se401/Kconfig  |2 +-
 drivers/staging/se401/se401.h  |2 +-
 drivers/staging/se401/videodev.h   |  318 +++
 drivers/staging/usbvideo/Kconfig   |2 +-
 drivers/staging/usbvideo/usbvideo.h|2 +-
 drivers/staging/usbvideo/vicam.c   |2 +-
 drivers/staging/usbvideo/videodev.h|  318 +++
 fs/compat_ioctl.c  |2 +-
 include/linux/Kbuild   |1 -
 include/linux/videodev.h   |  322 
 include/media/ovcamchip.h  |   90 
 20 files changed, 646 insertions(+), 666 deletions(-)
 delete mode 100644 Documentation/video4linux/v4lgrab.c
 create mode 100644 drivers/staging/se401/videodev.h
 create mode 100644 drivers/staging/usbvideo/videodev.h
 delete mode 100644 include/linux/videodev.h
 delete mode 100644 include/media/ovcamchip.h

-- 
1.7.3.4

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

[PATCH 1/6] [media] Remove VIDEO_V4L1 Kconfig option

[Mauro Carvalho Chehab]

There's no sense on keeping VIDEO_V4L1 Kconfig option just because of
two deprecated drivers moved to staging scheduled to die on 2.6.39.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 9ea1a6d..147c92b 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -40,20 +40,6 @@ config VIDEO_V4L2_COMMON
depends on (I2C || I2C=n) && VIDEO_DEV
default (I2C || I2C=n) && VIDEO_DEV
 
-config VIDEO_ALLOW_V4L1
-   bool "Enable Video For Linux API 1 (DEPRECATED)"
-   depends on VIDEO_DEV && VIDEO_V4L2_COMMON
-   default VIDEO_DEV && VIDEO_V4L2_COMMON
-   ---help---
- Enables drivers based on the legacy V4L1 API.
-
- This api were developed to be used at Kernel 2.2 and 2.4, but
- lacks support for several video standards. There are several
- drivers at kernel that still depends on it.
-
- If you are unsure as to whether this is required, answer Y.
-
-
 #
 # DVB Core
 #
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index b7b7b59..5116b4d 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -7,11 +7,6 @@ config VIDEO_V4L2
depends on VIDEO_DEV && VIDEO_V4L2_COMMON
default VIDEO_DEV && VIDEO_V4L2_COMMON
 
-config VIDEO_V4L1
-   tristate
-   depends on VIDEO_DEV && VIDEO_V4L2_COMMON && VIDEO_ALLOW_V4L1
-   default VIDEO_DEV && VIDEO_V4L2_COMMON && VIDEO_ALLOW_V4L1
-
 config VIDEOBUF_GEN
tristate
 
diff --git a/drivers/staging/se401/Kconfig b/drivers/staging/se401/Kconfig
index 586fc04..ee7313e 100644
--- a/drivers/staging/se401/Kconfig
+++ b/drivers/staging/se401/Kconfig
@@ -1,6 +1,6 @@
 config USB_SE401
tristate "USB SE401 Camera support (DEPRECATED)"
-   depends on VIDEO_V4L1
+   depends on VIDEO_DEV && VIDEO_V4L2_COMMON
---help---
  Say Y here if you want to connect this type of camera to your
  computer's USB port. See 
diff --git a/drivers/staging/usbvideo/Kconfig b/drivers/staging/usbvideo/Kconfig
index aae863e..d9fc867 100644
--- a/drivers/staging/usbvideo/Kconfig
+++ b/drivers/staging/usbvideo/Kconfig
@@ -3,7 +3,7 @@ config VIDEO_USBVIDEO
 
 config USB_VICAM
tristate "USB 3com HomeConnect (aka vicam) support (DEPRECATED)"
-   depends on VIDEO_V4L1 && EXPERIMENTAL
+   depends on VIDEO_DEV && VIDEO_V4L2_COMMON
select VIDEO_USBVIDEO
---help---
  Say Y here if you have 3com homeconnect camera (vicam).
diff --git a/include/linux/videodev.h b/include/linux/videodev.h
index 8a7aead..f11efbe 100644
--- a/include/linux/videodev.h
+++ b/include/linux/videodev.h
@@ -16,8 +16,6 @@
 #include 
 #include 
 
-#if defined(CONFIG_VIDEO_V4L1) || defined(CONFIG_VIDEO_V4L1_MODULE) || 
!defined(__KERNEL__)
-
 #define VID_TYPE_CAPTURE   1   /* Can capture */
 #define VID_TYPE_TUNER 2   /* Can tune */
 #define VID_TYPE_TELETEXT  4   /* Does teletext */
@@ -311,8 +309,6 @@ struct video_code
 #define VID_PLAY_RESET 13
 #define VID_PLAY_END_MARK  14
 
-#endif /* CONFIG_VIDEO_V4L1 */
-
 #endif /* __LINUX_VIDEODEV_H */
 
 /*
-- 
1.7.3.4


--
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] [media] s5p-fimc: update checking scaling ratio range

[Sylwester Nawrocki]

Hi Hyunwoong,

On 12/27/2010 10:17 AM, Hyunwoong Kim wrote:
> Horizontal and vertical scaling range are according to the following 
> equations.
> If (SRC_Width >= 64 x DST_Width) { Exit(-1);  /* Out of Horizontal scale 
> range}
> If (SRC_Height >= 64 x DST_Height) { Exit(-1);  /* Out of Vertical scale 
> range}
> 
> fimc_check_scaler_ratio() is used to check if horizontal and vertical
> scale range are valid or not. To use fimc_check_scaler_ratio,
> source and destination format should be set by VIDIOC_S_FMT.
> And in case of scaling up, it doesn't have to check the scale range.
> 
> Reviewed-by: Jonghun Han 
> Signed-off-by: Hyunwoong Kim 
> ---
> This patch is depended on Hyunwoong Kim's last patch.
> - [PATCH v2] [media] s5p-fimc: Configure scaler registers depending on FIMC 
> version
> 
>  drivers/media/video/s5p-fimc/fimc-capture.c |5 ++-
>  drivers/media/video/s5p-fimc/fimc-core.c|   66 
> +++
>  drivers/media/video/s5p-fimc/fimc-core.h|2 +-
>  3 files changed, 52 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c 
> b/drivers/media/video/s5p-fimc/fimc-capture.c
> index b1cb937..078e5ab 100644
> --- a/drivers/media/video/s5p-fimc/fimc-capture.c
> +++ b/drivers/media/video/s5p-fimc/fimc-capture.c
> @@ -744,6 +744,7 @@ static int fimc_cap_s_crop(struct file *file, void *fh,
>   struct fimc_frame *f;
>   struct fimc_ctx *ctx = file->private_data;
>   struct fimc_dev *fimc = ctx->fimc_dev;
> + struct v4l2_rect r;
>   int ret = -EINVAL;
>  
>   if (fimc_capture_active(fimc))
> @@ -761,7 +762,9 @@ static int fimc_cap_s_crop(struct file *file, void *fh,
>  
>   f = &ctx->s_frame;
>   /* Check for the pixel scaling ratio when cropping input image. */
> - ret = fimc_check_scaler_ratio(&cr->c, &ctx->d_frame);
> + r.width = ctx->d_frame.width;
> + r.height = ctx->d_frame.height;
> + ret = fimc_check_scaler_ratio(&cr->c, &r,  ctx->rotation);
>   if (ret) {
>   v4l2_err(&fimc->vid_cap.v4l2_dev, "Out of the scaler range");
>   return ret;
> diff --git a/drivers/media/video/s5p-fimc/fimc-core.c 
> b/drivers/media/video/s5p-fimc/fimc-core.c
> index 2b65961..cc5c28f 100644
> --- a/drivers/media/video/s5p-fimc/fimc-core.c
> +++ b/drivers/media/video/s5p-fimc/fimc-core.c
> @@ -198,24 +198,24 @@ static struct v4l2_queryctrl *get_ctrl(int id)
>   return NULL;
>  }
>  
> -int fimc_check_scaler_ratio(struct v4l2_rect *r, struct fimc_frame *f)
> +int fimc_check_scaler_ratio(struct v4l2_rect *s, struct v4l2_rect *d, int 
> rot)
>  {
> - if (r->width > f->width) {
> - if (f->width > (r->width * SCALER_MAX_HRATIO))
> - return -EINVAL;
> - } else {
> - if ((f->width * SCALER_MAX_HRATIO) < r->width)
> - return -EINVAL;
> - }
> + int tx, ty, sx, sy;
>  
> - if (r->height > f->height) {
> - if (f->height > (r->height * SCALER_MAX_VRATIO))
> - return -EINVAL;
> + sx = s->width;
> + sy = s->height;
> +
> + if (rot == 90 || rot == 270) {
> + ty = d->width;
> + tx = d->height;
>   } else {
> - if ((f->height * SCALER_MAX_VRATIO) < r->height)
> - return -EINVAL;
> + tx = d->width;
> + ty = d->height;
>   }
>  
> + if ((sx >= SCALER_MAX_HRATIO * tx) || (sy >= SCALER_MAX_VRATIO * ty))
> + return -EINVAL;
> +
>   return 0;
>  }
>  
> @@ -1062,7 +1062,9 @@ int fimc_s_ctrl(struct fimc_ctx *ctx, struct 
> v4l2_control *ctrl)
>  {
>   struct samsung_fimc_variant *variant = ctx->fimc_dev->variant;
>   struct fimc_dev *fimc = ctx->fimc_dev;
> + struct v4l2_rect s, d;
>   unsigned long flags;
> + int ret = 0;
>  
>   if (ctx->rotation != 0 &&
>   (ctrl->id == V4L2_CID_HFLIP || ctrl->id == V4L2_CID_VFLIP)) {
> @@ -1089,6 +1091,21 @@ int fimc_s_ctrl(struct fimc_ctx *ctx, struct 
> v4l2_control *ctrl)
>   break;
>  
>   case V4L2_CID_ROTATE:
> + if (!(~ctx->state & (FIMC_DST_FMT | FIMC_SRC_FMT))) {
> + s.width = ctx->s_frame.width;
> + s.height = ctx->s_frame.height;
> +
> + d.width = ctx->d_frame.width;
> + d.height = ctx->d_frame.height;
> +
> + ret = fimc_check_scaler_ratio(&s, &d, ctrl->value);
> + if (ret) {
> + v4l2_err(&fimc->m2m.v4l2_dev, "Out of scaler 
> range");
> + spin_unlock_irqrestore(&ctx->slock, flags);
> + return -EINVAL;
> + }
> + }
> +
>   /* Check for the output rotator availability */
>   if ((ctrl->value == 90 || ctrl->value == 270) &&
>   (ctx->in_path == FIMC_DMA && !variant->has_out_rot)) {
> @@ -122

Re: [PATCH] dma_declare_coherent_memory: push ioremap() up to caller

[Janusz Krzysztofik]

Sunday 26 December 2010 18:45:00 Guennadi Liakhovetski wrote:
> On Sat, 25 Dec 2010, Janusz Krzysztofik wrote:
>
> [snip]
>
> > > Passing the virtual address allows the API to become much more
> > > flexible. Not only that, it allows it to be used on ARM, rather
> > > than becoming (as it currently stands) prohibited on ARM.
> > >
> > > I believe that putting ioremap() inside this API was the wrong
> > > thing to do, and moving it outside makes the API much more
> > > flexible and usable. It's something I still fully support.
> >
> > Thanks, this is what I was missing, having my point of view rather
> > my machine centric, with not much wider experience. I'll quote your
> > argumentation in next iteration of this patch if required.
>
> AFAIU, this patch is similar to the previous two attempts:
>
> http://www.spinics.net/lists/linux-sh/msg05482.html
> and
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructur
>e/22271
>
> but is even more intrusive, because those two previous attempts added
> new functions, whereas this one is modifying an existing one. Both
> those two attempts have been NACKed by FUJITA Tomonori, btw, he is 
> not on the otherwise extensive CC list for this patch.

Hi Guennadi,
I composed that extensive CC list based on what I was able to find in 
MAINTAINERS for any files being modified, additionally adding Catalin 
Marinas as one of the idea promoters. FUJITA Tomonori's name was not 
specified there, nor was he mentioned as an author of any of those 
files. Adding him per your advice.

NB, the rationale quoted above is provided by courtesy of Russell King, 
and not of my authoriship, as it may look like at a first glance from 
your snip result.

Thanks,
Janusz
--
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: TechnoTrend CT-3650 IR support

[Mauro Carvalho Chehab]

Em 26-12-2010 17:38, David Henningsson escreveu:
> On 2010-12-26 12:41, Mauro Carvalho Chehab wrote:
>> Hi David,
>>
>> Em 26-12-2010 07:14, David Henningsson escreveu:
>>> Hi Linux-media,
>>>
>>> As a spare time project I bought myself a TT CT-3650, to see if I could get 
>>> it working. Waling Dijkstra did write a IR&  CI patch for this model half a 
>>> year ago, so I was hopeful. (Reference: 
>>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg19860.html )
>>>
>>> Having tested the patch, the IR is working (tested all keys via the 
>>> "evtest" tool), however descrambling is NOT working.
>>>
>>> Waling's patch was reviewed but never merged. So I have taken the IR part 
>>> of the patch, cleaned it up a little, and hopefully this part is ready for 
>>> merging now. Patch is against linux-2.6.git.
>>
>> Could you please rebase it to work with the rc_core support? I suspect that 
>> you
>> based it on a kernel older than .36, as the dvb_usb rc struct changed.
> 
> Ok, I have now done this, but I'm not completely satisfied, perhaps you can 
> help out a little? I'm new to IR/RC stuff, 
> but I feel I'm missing correct "repeat" functionality, i e, if you keep a key 
> pressed it appears as separate key presses
> with whatever interval set as .rc_interval. (This was probably a problem with 
> the old patch as well.) Is there any
> support for this is rc_core?

>From your decode logic, I suspect that the IR hardware decoder has its own 
>logic for repeat.
In this case, there's not much you can do, as it probably uses a very high time 
for repeat.

> I'm attaching a temporary patch (just for review) so you know what I'm 
> talking about.
> 
>> The better is to base it over the latest V4L/DVB/RC development git, 
>> available at:
>> http://git.linuxtv.org/media_tree.git
> 
> Ok. I was probably confused with this entry: 
> http://linuxtv.org/news.php?entry=2010-01-19.mchehab
> telling me to base it on v4l-dvb.git, which is not updated for four months. 
> However, http://git.linuxtv.org/ correctly lists the media_tree.git as the 
> repository of choice.

Ah... yeah, old news;)

> Thanks for the review!
> 
Em 26-12-2010 17:38, David Henningsson escreveu:
> From 8c42121a08c5dabbd1a943cc1e5726ed99f0d957 Mon Sep 17 00:00:00 2001
> From: David Henningsson 
> Date: Sun, 26 Dec 2010 14:23:58 +0100
> Subject: [PATCH] DVB: IR support for CT-3650
> 
> Signed-off-by: David Henningsson 
> ---
>  drivers/media/dvb/dvb-usb/ttusb2.c |   28 
>  1 files changed, 28 insertions(+), 0 deletions(-)
>  mode change 100644 => 100755 debian/rules
> 
> diff --git a/debian/rules b/debian/rules
> old mode 100644
> new mode 100755
> diff --git a/drivers/media/dvb/dvb-usb/ttusb2.c 
> b/drivers/media/dvb/dvb-usb/ttusb2.c
> index a6de489..ded8a4b 100644
> --- a/drivers/media/dvb/dvb-usb/ttusb2.c
> +++ b/drivers/media/dvb/dvb-usb/ttusb2.c
> @@ -128,6 +128,27 @@ static struct i2c_algorithm ttusb2_i2c_algo = {
>   .functionality = ttusb2_i2c_func,
>  };
>  
> +/* command to poll IR receiver (copied from pctv452e.c) */
> +#define CMD_GET_IR_CODE 0x1b
> +
> +/* IR */
> +static int tt3650_rc_query(struct dvb_usb_device *d)
> +{
> + int ret;
> + u8 rx[9]; /* A CMD_GET_IR_CODE reply is 9 bytes long */
> + ret = ttusb2_msg(d, CMD_GET_IR_CODE, NULL, 0, rx, sizeof(rx));
> + if (ret != 0)
> + return ret;
> +
> + if (rx[8] & 0x01) {

Maybe (rx[8] & 0x01) == 0 indicates a keyup event. If so, if you map both 
keydown
and keyup events, the in-kernel repeat logic will work.

> + /* got a "press" event */
> + deb_info("%s: cmd=0x%02x sys=0x%02x\n", __func__, rx[2], rx[3]);
> + rc_keydown(d->rc_dev, rx[2], 0);
> + }

As you're receiving both command+address, please use the complete code:
rc_keydown(d->rc_dev, (rx[3] << 8) | rx[2], 0);


Also as it is receiving 8 bytes from the device, maybe the IR decoding logic is 
capable of decoding more than just one protocol. Such feature is nice, as it
allows replacing the original keycode table by a more complete one.

One of the most interesting features of the new RC code is that it offers
a sysfs class and some additional logic to allow dynamically change/replace
the keymaps and keycodes via userspace. The idea is to remove all in-kernel
keymaps in the future, using, instead, the userspace way, via ir-keytable
tool, available at:
http://git.linuxtv.org/v4l-utils.git

The tool already supports auto-loading the keymap via udev.

For IR's where we don't know the protocol or that we don't have the full 
scancode,
loading the keymap via userspace will not bring any new feature. But, for those
devices where we can be sure about the protocol and for those that also allow
using other protocols, users can just replace the device-provided IR with a more
powerful remote controller with more keys.

So, it would be wonderful if you could identify what's the supported protocol(s)
instead of using 

[PATCH] [media] s5p-fimc: update checking scaling ratio range

[Hyunwoong Kim]

Horizontal and vertical scaling range are according to the following equations.
If (SRC_Width >= 64 x DST_Width) { Exit(-1);  /* Out of Horizontal scale range}
If (SRC_Height >= 64 x DST_Height) { Exit(-1);  /* Out of Vertical scale range}

fimc_check_scaler_ratio() is used to check if horizontal and vertical
scale range are valid or not. To use fimc_check_scaler_ratio,
source and destination format should be set by VIDIOC_S_FMT.
And in case of scaling up, it doesn't have to check the scale range.

Reviewed-by: Jonghun Han 
Signed-off-by: Hyunwoong Kim 
---
This patch is depended on Hyunwoong Kim's last patch.
- [PATCH v2] [media] s5p-fimc: Configure scaler registers depending on FIMC 
version

 drivers/media/video/s5p-fimc/fimc-capture.c |5 ++-
 drivers/media/video/s5p-fimc/fimc-core.c|   66 +++
 drivers/media/video/s5p-fimc/fimc-core.h|2 +-
 3 files changed, 52 insertions(+), 21 deletions(-)

diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c 
b/drivers/media/video/s5p-fimc/fimc-capture.c
index b1cb937..078e5ab 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -744,6 +744,7 @@ static int fimc_cap_s_crop(struct file *file, void *fh,
struct fimc_frame *f;
struct fimc_ctx *ctx = file->private_data;
struct fimc_dev *fimc = ctx->fimc_dev;
+   struct v4l2_rect r;
int ret = -EINVAL;
 
if (fimc_capture_active(fimc))
@@ -761,7 +762,9 @@ static int fimc_cap_s_crop(struct file *file, void *fh,
 
f = &ctx->s_frame;
/* Check for the pixel scaling ratio when cropping input image. */
-   ret = fimc_check_scaler_ratio(&cr->c, &ctx->d_frame);
+   r.width = ctx->d_frame.width;
+   r.height = ctx->d_frame.height;
+   ret = fimc_check_scaler_ratio(&cr->c, &r,  ctx->rotation);
if (ret) {
v4l2_err(&fimc->vid_cap.v4l2_dev, "Out of the scaler range");
return ret;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c 
b/drivers/media/video/s5p-fimc/fimc-core.c
index 2b65961..cc5c28f 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -198,24 +198,24 @@ static struct v4l2_queryctrl *get_ctrl(int id)
return NULL;
 }
 
-int fimc_check_scaler_ratio(struct v4l2_rect *r, struct fimc_frame *f)
+int fimc_check_scaler_ratio(struct v4l2_rect *s, struct v4l2_rect *d, int rot)
 {
-   if (r->width > f->width) {
-   if (f->width > (r->width * SCALER_MAX_HRATIO))
-   return -EINVAL;
-   } else {
-   if ((f->width * SCALER_MAX_HRATIO) < r->width)
-   return -EINVAL;
-   }
+   int tx, ty, sx, sy;
 
-   if (r->height > f->height) {
-   if (f->height > (r->height * SCALER_MAX_VRATIO))
-   return -EINVAL;
+   sx = s->width;
+   sy = s->height;
+
+   if (rot == 90 || rot == 270) {
+   ty = d->width;
+   tx = d->height;
} else {
-   if ((f->height * SCALER_MAX_VRATIO) < r->height)
-   return -EINVAL;
+   tx = d->width;
+   ty = d->height;
}
 
+   if ((sx >= SCALER_MAX_HRATIO * tx) || (sy >= SCALER_MAX_VRATIO * ty))
+   return -EINVAL;
+
return 0;
 }
 
@@ -1062,7 +1062,9 @@ int fimc_s_ctrl(struct fimc_ctx *ctx, struct v4l2_control 
*ctrl)
 {
struct samsung_fimc_variant *variant = ctx->fimc_dev->variant;
struct fimc_dev *fimc = ctx->fimc_dev;
+   struct v4l2_rect s, d;
unsigned long flags;
+   int ret = 0;
 
if (ctx->rotation != 0 &&
(ctrl->id == V4L2_CID_HFLIP || ctrl->id == V4L2_CID_VFLIP)) {
@@ -1089,6 +1091,21 @@ int fimc_s_ctrl(struct fimc_ctx *ctx, struct 
v4l2_control *ctrl)
break;
 
case V4L2_CID_ROTATE:
+   if (!(~ctx->state & (FIMC_DST_FMT | FIMC_SRC_FMT))) {
+   s.width = ctx->s_frame.width;
+   s.height = ctx->s_frame.height;
+
+   d.width = ctx->d_frame.width;
+   d.height = ctx->d_frame.height;
+
+   ret = fimc_check_scaler_ratio(&s, &d, ctrl->value);
+   if (ret) {
+   v4l2_err(&fimc->m2m.v4l2_dev, "Out of scaler 
range");
+   spin_unlock_irqrestore(&ctx->slock, flags);
+   return -EINVAL;
+   }
+   }
+
/* Check for the output rotator availability */
if ((ctrl->value == 90 || ctrl->value == 270) &&
(ctx->in_path == FIMC_DMA && !variant->has_out_rot)) {
@@ -1227,6 +1244,7 @@ static int fimc_m2m_s_crop(struct file *file, void *fh, 
struct v4l2_crop *cr)
struct fimc_dev *fimc = ctx->fimc_dev;
unsigned long flags;
struct fimc_fra

Re: ngene & Satix-S2 dual problems

[Andre]

On 26 Dec 2010, at 14:40, Ludovic BOUÉ wrote:

> Hi all,
> 
> I have a Satix-S2 Dual and I'm trying to get to work without his CI in a 
> first time. I'm trying ngene-test2 
> from http://linuxtv.org/hg/~endriss/ngene-test2/ under 
> 2.6.32-21-generic.
> 
> It contains too much nodes (extra demuxes, dvrs & nets):

Yes, if you read this thread back you will see why and that it doesn't prevent 
anything working.

> was working with stable driver dans 1.5 firmware.

Again back in the thread you will see that with the in kernel driver (I 
hesitate to use the description stable) there is a serious problem when both 
tuners are in use, this work in progress driver fixes that problem.

The extra nodes are a pain, especially when you have a lot of tuners in one 
machine but tuners that stop working mid recording are much more of a pain!

Andre--
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 7/9] media: MFC: Add MFC v5.1 V4L2 driver

[Jonghun Han]

My review also imply Kamil's original patch.

Jeongtae Park wrote:
> Multi Format Codec v5.1 is a module available on S5PC110 and S5PC210
> Samsung SoCs. Hardware is capable of handling a range of video codecs
> and this driver provides V4L2 interface for video decoding & encoding.
> 
> Reviewed-by: Peter Oh 
> Signed-off-by: Jeongtae Park 
> ---


> +
> +/* Display status */
> +#define S5P_FIMV_DEC_STATUS_DECODING_ONLY0
> +#define S5P_FIMV_DEC_STATUS_DECODING_DISPLAY 1
> +#define S5P_FIMV_DEC_STATUS_DISPLAY_ONLY 2
> +#define S5P_FIMV_DEC_STATUS_DECODING_EMPTY   3
> +#define S5P_FIMV_DEC_STATUS_DECODING_STATUS_MASK 7
> +#define S5P_FIMV_DEC_STATUS_PROGRESSIVE  (0<<3)
> +#define S5P_FIMV_DEC_STATUS_INTERLACE(1<<3)
> +#define S5P_FIMV_DEC_STATUS_INTERLACE_MASK   (1<<3)
> +#define S5P_FIMV_DEC_STATUS_CRC_NUMBER_TWO   (0<<4)
> +#define S5P_FIMV_DEC_STATUS_CRC_NUMBER_FOUR  (1<<4)
> +#define S5P_FIMV_DEC_STATUS_CRC_NUMBER_MASK  (1<<4)
> +#define S5P_FIMV_DEC_STATUS_CRC_GENERATED(1<<5)
> +#define S5P_FIMV_DEC_STATUS_CRC_NOT_GENERATED(0<<5)
> +#define S5P_FIMV_DEC_STATUS_CRC_MASK (1<<5)


Use like (0 << 3), (1 << 3) ...



> +/* Enumerate format */
> +static int vidioc_enum_fmt(struct v4l2_fmtdesc *f, bool mplane, bool out,
> + enum s5p_mfc_node_type
> node)
> +{
> + struct s5p_mfc_fmt *fmt;
> + int i, j = 0;
> +
> + if (node == MFCNODE_INVALID)
> + return 0;
> +
> + for (i = 0; i < ARRAY_SIZE(formats); ++i) {
> + if (mplane && formats[i].num_planes == 1)
> + continue;
> + else if (!mplane && formats[i].num_planes > 1)
> + continue;
> + if (node == MFCNODE_DECODER) {
> + if (out && formats[i].type != MFC_FMT_DEC)
> + continue;
> + else if (!out && formats[i].type != MFC_FMT_RAW)
> + continue;
> + } else if (node == MFCNODE_ENCODER) {
> + if (out && formats[i].type != MFC_FMT_RAW)
> + continue;
> + else if (!out && formats[i].type != MFC_FMT_ENC)
> + continue;
> + }
> +
> + if (j == f->index) {
> + fmt = &formats[i];
> + strlcpy(f->description, fmt->name,
> + sizeof(f->description));
> + f->pixelformat = fmt->fourcc;
> +
> + return 0;
> + }
> +
> + ++j;
> + }
> +
> + return -EINVAL;
> +}
> +

At a glance, no needed to use j variable.
if (i == f->index) instead of if (j == f->index)



> +/* Get format */
> +static int vidioc_g_fmt(struct file *file, void *priv, struct v4l2_format
*f)
> +{
> + struct s5p_mfc_ctx *ctx = priv;
> +
> + mfc_debug_enter();
> + mfc_debug("f->type = %d ctx->state = %d\n", f->type, ctx->state);
> + if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE &&
> + ctx->state == MFCINST_GOT_INST) {
> + /* If the MFC is parsing the header,
> +  * so wait until it is finished */
> + s5p_mfc_clean_ctx_int_flags(ctx);
> + s5p_mfc_wait_for_done_ctx(ctx,
> S5P_FIMV_R2H_CMD_SEQ_DONE_RET,
> + 1);
> + }
> + if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE &&
> + ctx->state >= MFCINST_HEAD_PARSED &&
> + ctx->state <= MFCINST_ABORT) {
> + /* This is run on CAPTURE (deocde output) */
> + /* Width and height are set to the dimensions
> +of the movie, the buffer is bigger and
> +further processing stages should crop to this
> +rectangle. */
> + f->fmt.pix_mp.width = ctx->buf_width;
> + f->fmt.pix_mp.height = ctx->buf_height;
> + f->fmt.pix_mp.field = V4L2_FIELD_NONE;
> + f->fmt.pix_mp.num_planes = 2;
> + /* Set pixelformat to the format in which MFC
> +outputs the decoded frame */
> + f->fmt.pix_mp.pixelformat = V4L2_PIX_FMT_NV12MT;
> + f->fmt.pix_mp.plane_fmt[0].bytesperline = ctx->buf_width;
> + f->fmt.pix_mp.plane_fmt[0].sizeimage = ctx->luma_size;
> + f->fmt.pix_mp.plane_fmt[1].bytesperline = ctx->buf_width;
> + f->fmt.pix_mp.plane_fmt[1].sizeimage = ctx->chroma_size;
> + } else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> + /* This is run on OUTPUT
> +The buffer contains compressed image
> +so width and height have no meaning */
> + f->fmt.pix_mp.width = 1;
> + f->fmt.pix_mp.height = 1;
> +