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

2010-01-23 Thread Németh Márton
Jean-Francois Moine írta:
 On Fri, 22 Jan 2010 18:54:46 -0200
 Mauro Carvalho Chehab mche...@infradead.org wrote:
 
 Huh?
 -static int reg_w_buf(struct gspca_dev *gspca_dev,
 +static void reg_w_buf(struct gspca_dev *gspca_dev,
   __u8 index,
   const char *buffer, int len)
  {
 int ret;
  
 +   if (gspca_dev-usb_err  0)
 +   return;

 This is an ugly and non-standard way to report errors in C. Just
 return the error code.
 
 Perhaps, but a code as:
 
   foo(x);
   bar(y);
   bla(z);
   ...
 
 is more readable, smaller and quicker (less MMU switches) than:

What do you mean under MMU switches?

 
   rc = foo(x);
   if (rc  0)
   return rc;
   rc = bar(y);
   if (rc  0)
   return rc;
   rc = bla(z);
   if (rc  0)
   return rc;
   ...
 
 An other way to do it is to use longjump, but I don't think it works in
 the kernel...
 
 Best regards.
 

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


Re: PULL http://jusst.de/hg/stv090x

2010-01-23 Thread Manu Abraham
Hi Oliver,

On Sat, Jan 23, 2010 at 7:09 AM, Oliver Endriss o.endr...@gmx.de wrote:
 Manu Abraham wrote:
 On Fri, Jan 22, 2010 at 11:40 PM, Devin Heitmueller
 dheitmuel...@kernellabs.com wrote:
  Also, the dvb_frontend.c makes calls to i2c_gate_ctrl() at various
  points, so you would need to ensure that none of those occur before
  calling into your driver as there could potentially be a deadlock
  there too.

 Ok, thanks for the pointer. The gate control is never called
 externally in reality. I will wait a little while for this patch to be
 applied.  It removes the exported function and thereby an unnecessary
 dereference.

 http://jusst.de/hg/stv090x/rev/b3d28f5b2b53

 Imho not a good idea, as the frontend thread calls
 - fe-ops.tuner_ops.init
 - fe-ops.tuner_ops.sleep

 If you remove fe-ops.i2c_gate_ctrl, init and sleep will fail,
 because gate_ctrl was never called...


tuner Init is already called within the demodulator control loop: ie, init
I have moved in tuner Sleep likewise.

http://jusst.de/hg/stv090x/rev/5699b0d87a12

I think that would fix the issues at hand ...


Thanks for the pointer,

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


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

2010-01-23 Thread Jean-Francois Moine
On Sat, 23 Jan 2010 09:10:44 +0100
Németh Márton nm...@freemail.hu wrote:

  is more readable, smaller and quicker (less MMU switches) than:
 
 What do you mean under MMU switches?

The MMU has an associative memory which is used in the first step to
translate a logical address (page) to the physical RAM address. Every
time an address is not in this memory, a MMU interrupt occurs. Then, the
system scans the page tables of the process, and either reloads the
associative memory or calls the swap system to bring the page into the physical 
memory.

An associative memory is complex and its complexity grows exponentially
with its size. So, usually, it is rather small. Then, the more the code
is small and the less MMU interrupts occur...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: bt878 card: no sound and only xvideo support in 2.6.31 bttv 0.9.18

2010-01-23 Thread xof
LiM a écrit :
 Leopold Gouverneur napsal(a):
   
 On Thu, Jan 21, 2010 at 09:05:06AM +0100, LiM wrote:
   
 
 Hello,

 i have the same problem as 
 http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/11441
  also with Hercules Smart TV Stereo ..
 works OK audio+video on ..2.6.29-gentoo-r5 + bttv 0.9.17
 but NO AUDIO on linux-2.6.31-gentoo-r6 + bttv 0.9.18

   

 Hi,

 and is any chance it will be working with new version?

 Michal
   
A temporary solution (if you can use a solder iron) is to get audio out
of the (tuner) metal box and inject it at the CD connector on the
motherboard.

See : http://www.genicus.be/?p=592

(It works for me.  There is an audio out pin (AF) on the TDA9801T in the
metal box. lip-sync is not perfect, but, at least, I hear something...)

But, of course, it would be better to make the driver work.

I had the same problem in 2008 when somebody changed tvaudio and I did
not realize I had to specify new options in my /etc/modprobe.d/bttv.conf
file.  I wonder why 'bttv card=100' is not enough to specify the
hardware and what to do with it.  There is an entry 'Hercules Smart TV
Stereo' in bttv-cards.c.  I am not sure what can be done with
autodetecting chips on an unknown board.  I agree, this is probably
complex matter but this mix of specification and autodetection is suspect.

My card is 1540:952b - Hercules Smart TV 2 Stereo.
there is a TDA9801T in the metal box labelled TVF-8533-B/DF
a Conexant Fusion 878A (~compatible Bt878)
a TDA9874AH on the (audio) piggy back
and two other chips (?pic16c54 (a dip-18 labeled 'B05')? and ? a dip-8
with Label 'GI0')

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.31.y.git;a=commitdiff;h=859f0277a6c3ba59b0a5a1eb183f8f6ce661a95d
is difficult to follow as there are changes in i2c handling,
autodetection, v4l and v4l2 architectures,...  I don't know if there is
some documentation about the (reverse engineered) wiring of the board
themselves or is the code 'is/was' the documentation.

The 'Hercules Smart TV' is probably not the only card with a sound
problem after those reorganisations.  I also hope that it is not a 'big
bug' and that it will be back one of these days but (I feel) it is
nearly impossible to help from outside.


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


Re: PULL http://jusst.de/hg/stv090x

2010-01-23 Thread Oliver Endriss
Manu Abraham wrote:
 Hi Oliver,
 
 On Sat, Jan 23, 2010 at 7:09 AM, Oliver Endriss o.endr...@gmx.de wrote:
  Manu Abraham wrote:
  On Fri, Jan 22, 2010 at 11:40 PM, Devin Heitmueller
  dheitmuel...@kernellabs.com wrote:
   Also, the dvb_frontend.c makes calls to i2c_gate_ctrl() at various
   points, so you would need to ensure that none of those occur before
   calling into your driver as there could potentially be a deadlock
   there too.
 
  Ok, thanks for the pointer. The gate control is never called
  externally in reality. I will wait a little while for this patch to be
  applied.  It removes the exported function and thereby an unnecessary
  dereference.
 
  http://jusst.de/hg/stv090x/rev/b3d28f5b2b53
 
  Imho not a good idea, as the frontend thread calls
  - fe-ops.tuner_ops.init
  - fe-ops.tuner_ops.sleep
 
  If you remove fe-ops.i2c_gate_ctrl, init and sleep will fail,
  because gate_ctrl was never called...
 
 
 tuner Init is already called within the demodulator control loop: ie, init
 I have moved in tuner Sleep likewise.
 
 http://jusst.de/hg/stv090x/rev/5699b0d87a12
 
 I think that would fix the issues at hand ...
 
 
 Thanks for the pointer,

+   if (state-config-tuner_init) {
+   if (state-config-tuner_sleep(fe)  0)
+   goto err_gateoff;
+   }
+

s/tuner_init/tuner_sleep


Btw, these NULL initialisations could be removed:
.tuner_init = NULL,
+   .tuner_sleep= NULL,
.tuner_set_mode = NULL,
.tuner_set_frequency= NULL,
.tuner_get_frequency= NULL,

(struct tt1600_stv090x_config is static anyway.)

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: PULL http://jusst.de/hg/stv090x

2010-01-23 Thread Manu Abraham
On Sat, Jan 23, 2010 at 1:58 PM, Oliver Endriss o.endr...@gmx.de wrote:
 Manu Abraham wrote:
 Hi Oliver,

 On Sat, Jan 23, 2010 at 7:09 AM, Oliver Endriss o.endr...@gmx.de wrote:
  Manu Abraham wrote:
  On Fri, Jan 22, 2010 at 11:40 PM, Devin Heitmueller
  dheitmuel...@kernellabs.com wrote:
   Also, the dvb_frontend.c makes calls to i2c_gate_ctrl() at various
   points, so you would need to ensure that none of those occur before
   calling into your driver as there could potentially be a deadlock
   there too.
 
  Ok, thanks for the pointer. The gate control is never called
  externally in reality. I will wait a little while for this patch to be
  applied.  It removes the exported function and thereby an unnecessary
  dereference.
 
  http://jusst.de/hg/stv090x/rev/b3d28f5b2b53
 
  Imho not a good idea, as the frontend thread calls
  - fe-ops.tuner_ops.init
  - fe-ops.tuner_ops.sleep
 
  If you remove fe-ops.i2c_gate_ctrl, init and sleep will fail,
  because gate_ctrl was never called...


 tuner Init is already called within the demodulator control loop: ie, init
 I have moved in tuner Sleep likewise.

 http://jusst.de/hg/stv090x/rev/5699b0d87a12

 I think that would fix the issues at hand ...


 Thanks for the pointer,

 +       if (state-config-tuner_init) {
 +               if (state-config-tuner_sleep(fe)  0)
 +                       goto err_gateoff;
 +       }
 +

 s/tuner_init/tuner_sleep


I noticed that immediately after writing that email, fixed in the next
commit after that, also the gate control has been added in there,
which is also necessary.


 Btw, these NULL initialisations could be removed:
        .tuner_init             = NULL,
 +       .tuner_sleep            = NULL,
        .tuner_set_mode         = NULL,
        .tuner_set_frequency    = NULL,
        .tuner_get_frequency    = NULL,


Ah, ok. I will remove them.

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


Re: PULL http://jusst.de/hg/stv090x

2010-01-23 Thread Manu Abraham
On Sat, Jan 23, 2010 at 5:08 AM, hermann pitton hermann-pit...@arcor.de wrote:
 Hi.

 Am Samstag, den 23.01.2010, 01:23 +0400 schrieb Manu Abraham:
 On Sat, Jan 23, 2010 at 1:14 AM, Mauro Carvalho Chehab
 mche...@infradead.org wrote:
  Devin Heitmueller wrote:
  On Fri, Jan 22, 2010 at 3:22 PM, Manu Abraham abraham.m...@gmail.com 
  wrote:
  On Fri, Jan 22, 2010 at 11:40 PM, Devin Heitmueller
  dheitmuel...@kernellabs.com wrote:
  Also, the dvb_frontend.c makes calls to i2c_gate_ctrl() at various
  points, so you would need to ensure that none of those occur before
  calling into your driver as there could potentially be a deadlock
  there too.
  Ok, thanks for the pointer. The gate control is never called
  externally in reality. I will wait a little while for this patch to be
  applied.  It removes the exported function and thereby an unnecessary
  dereference.
 
  http://jusst.de/hg/stv090x/rev/b3d28f5b2b53
 
  If it never needs to be called externally, then removing it from the
  dvb_frontend_ops does eliminate the risk entirely.  The case I
  frequently see it called from dvb_frontend.c is for powering down the
  tuner when the dvb frontend thread shuts down.
 
  The removal of the external call to the gate function removes the risk that
  an external call, at dvb core, to keep it locked. Yet, the code there is 
  completely
  symetric nowadays.
 
  However, the proper documentation of the lock is needed to avoid the risk
  of some patch to keep the mutex locked.
 
  As, even the initial lock changeset has this problem (later fixed by
  http://jusst.de/hg/stv090x/rev/3a8f35abc0f2), it shows that a good 
  documentation
  is required.
 
  As you've talked about a FSM, the lock itself is a FSM with 2 states. All 
  I'm
  asking is that you document that the lock FSM has changed its state in the 
  name
  of the function that alters the state of the lock.
 

 Sure, of course, i will add some comments into the patch that I have
 queued up, before pull request. Don't worry, be at peace. :-)

 Regards,
 Manu

 Good, seems there is some progress.

 But 1080p was first from satellites only too ;)


Eventually, broadcasters will restrict all good content. Only old
stuff will even be happening with FTA. Even old scrambling systems are
going away.

Broadcasters would transmit protected content in the stream, along
with relevant keys for relevant schema; CI+ is replacing old CI
systems.

CI+ streams would eventually be encrypted; ie, you won't get access to
those streams, The CI+ output will be paired with a CI+ capable
decoder, which will be given it's set of keys.

The decoder will output HDMI with HDCP ..

You can see that vicious circle that's evolving ... Broadcasters and
Media producers like to term it as a war; they don't want users to
capture the streams on a computer eventually; that's another way of
stating it; even if the media has to be Time shifted, that would be
paired with decoder, so eventually the media stays at one place and
doesn't get circulated.


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


Re: bt878 card: no sound and only xvideo support in 2.6.31 bttv 0.9.18

2010-01-23 Thread Alistair Thomas




Xof wrote:
 I had the same problem in 2008 when somebody changed tvaudio and I did
 not realize I had to specify new options in my /etc/modprobe.d/bttv.conf
 file.  I wonder why 'bttv card=100' is not enough to specify the
 hardware and what to do with it.  There is an entry 'Hercules Smart TV
 Stereo' in bttv-cards.c.  I am not sure what can be done with
 autodetecting chips on an unknown board.  I agree, this is probably
 complex matter but this mix of specification and autodetection is suspect.

I agree, auto detection for sound seems not to work too well for BT878 cards.

To get sound I have to set modprobe options:

options tda9887 qss=0
options tuner pal=i

although the card is auto detected:

bttv0: detected: Pinnacle PCTV [card=39], PCI subsystem ID is 11bd:0012
bttv0: using: Pinnacle PCTV Studio/Rave [card=39,autodetected]

Would be great if there was a method to fix this.

Al



  

--
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] soc_camera: match signedness of soc_camera_limit_side()

2010-01-23 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

The parameters of soc_camera_limit_side() are either a pointer to
a structure element from v4l2_rect, or constants. The structure elements
of the v4l2_rect are signed (see linux/videodev2.h) so do the computations
also with signed values.

This will remove the following sparse warning (see make C=1):
 * incorrect type in argument 1 (different signedness)
   expected unsigned int *start
   got signed int *noident

Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 2a50a0a1c951 linux/include/media/soc_camera.h
--- a/linux/include/media/soc_camera.h  Sat Jan 23 00:14:32 2010 -0200
+++ b/linux/include/media/soc_camera.h  Sat Jan 23 10:09:41 2010 +0100
@@ -264,9 +264,8 @@
common_flags;
 }

-static inline void soc_camera_limit_side(unsigned int *start,
-   unsigned int *length, unsigned int start_min,
-   unsigned int length_min, unsigned int length_max)
+static inline void soc_camera_limit_side(int *start, int *length,
+   int start_min, int length_min, int length_max)
 {
if (*length  length_min)
*length = length_min;
diff -r 2a50a0a1c951 linux/drivers/media/video/rj54n1cb0c.c
--- a/linux/drivers/media/video/rj54n1cb0c.cSat Jan 23 00:14:32 2010 -0200
+++ b/linux/drivers/media/video/rj54n1cb0c.cSat Jan 23 10:09:41 2010 +0100
@@ -555,15 +555,15 @@
return ret;
 }

-static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h,
-  u32 *out_w, u32 *out_h);
+static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h,
+  s32 *out_w, s32 *out_h);

 static int rj54n1_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
 {
struct i2c_client *client = sd-priv;
struct rj54n1 *rj54n1 = to_rj54n1(client);
struct v4l2_rect *rect = a-c;
-   unsigned int dummy = 0, output_w, output_h,
+   int dummy = 0, output_w, output_h,
input_w = rect-width, input_h = rect-height;
int ret;

@@ -638,8 +638,8 @@
  * the output one, updates the window sizes and returns an error or the resize
  * coefficient on success. Note: we only use the Fixed Scaling on this 
camera.
  */
-static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h,
-  u32 *out_w, u32 *out_h)
+static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h,
+  s32 *out_w, s32 *out_h)
 {
struct i2c_client *client = sd-priv;
struct rj54n1 *rj54n1 = to_rj54n1(client);
@@ -1017,7 +1017,7 @@
struct i2c_client *client = sd-priv;
struct rj54n1 *rj54n1 = to_rj54n1(client);
const struct rj54n1_datafmt *fmt;
-   unsigned int output_w, output_h, max_w, max_h,
+   int output_w, output_h, max_w, max_h,
input_w = rj54n1-rect.width, input_h = rj54n1-rect.height;
int ret;


--
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] zoran: remove variable shadowing

2010-01-23 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

The loop counter j is declared twice in function error_handler().
Remove the redundant declaration.

This will remove the following sparse warning (see make C=1):
 * symbol 'j' shadows an earlier one

Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 2a50a0a1c951 linux/drivers/media/video/zoran/zoran_device.c
--- a/linux/drivers/media/video/zoran/zoran_device.cSat Jan 23 00:14:32 
2010 -0200
+++ b/linux/drivers/media/video/zoran/zoran_device.cSat Jan 23 10:47:27 
2010 +0100
@@ -1229,7 +1230,7 @@
   u32   astat,
   u32   stat)
 {
-   int i, j;
+   int i;

/* This is JPEG error handling part */
if (zr-codec_mode != BUZ_MODE_MOTION_COMPRESS 
@@ -1280,6 +1281,7 @@
/* Report error */
if (zr36067_debug  1  zr-num_errors = 8) {
long frame;
+   int j;

frame = zr-jpg_pend[zr-jpg_dma_tail  BUZ_MASK_FRAME];
printk(KERN_ERR

--
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] hdpvr-video: cleanup signedness

2010-01-23 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

The fifth parameter of usb_bulk_msg() is a pointer to signed
(see linux/usb.h) so also call this function with pointer to signed.

This will remove the following sparse warning (see make C=1):
 * warning: incorrect type in argument 5 (different signedness)
   expected int *actual_length
   got unsigned int *noident

Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 2a50a0a1c951 linux/drivers/media/video/hdpvr/hdpvr-video.c
--- a/linux/drivers/media/video/hdpvr/hdpvr-video.c Sat Jan 23 00:14:32 
2010 -0200
+++ b/linux/drivers/media/video/hdpvr/hdpvr-video.c Sat Jan 23 11:43:17 
2010 +0100
@@ -302,7 +302,8 @@
 /* function expects dev-io_mutex to be hold by caller */
 static int hdpvr_stop_streaming(struct hdpvr_device *dev)
 {
-   uint actual_length, c = 0;
+   int actual_length;
+   uint c = 0;
u8 *buf;

if (dev-status == STATUS_IDLE)

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


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

2010-01-23 Thread Mauro Carvalho Chehab
Jean-Francois Moine wrote:
 On Sat, 23 Jan 2010 09:10:44 +0100
 Németh Márton nm...@freemail.hu wrote:
 
 is more readable, smaller and quicker (less MMU switches) than:
 What do you mean under MMU switches?
 
 The MMU has an associative memory which is used in the first step to
 translate a logical address (page) to the physical RAM address. Every
 time an address is not in this memory, a MMU interrupt occurs. Then, the
 system scans the page tables of the process, and either reloads the
 associative memory or calls the swap system to bring the page into the 
 physical memory.
 
 An associative memory is complex and its complexity grows exponentially
 with its size. So, usually, it is rather small. Then, the more the code
 is small and the less MMU interrupts occur...

Linux doesn't use swap memory for the kernel. It will be using a physical RAM 
memory
for the entire kernel. So, I don't think MMU applies here.

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


[RFC] Procedures for git push

2010-01-23 Thread Mauro Carvalho Chehab
As already discussed during the -git announcement, one important part is how
we'll handle -git pushes.

So, I'm sending a procedure explaining how should be the new submission process 
for
sending patches via GIT PULL requests.

Feel free to comment and send suggestions to improve it. I intend to add its 
content
to README.patches or to add it as README.git next week, after getting some 
review.

Cheers,
Mauro

---

Mauro Carvalho Chehab mchehab at infradead dot org   Updated on 2010 January 
23


1. KERNEL DEVELOPMENT PROCEDURES FOR UPSTREAM
=

Before starting with the RFC, it is important that people understand how 
upstream
development works.

Kernel development has 2 phases: 

1) a merge window typically with 2 weeks (although Linus is gave some 
indications that he may reduce it on 2.6.34), starting with the release
of a new kernel version;

2) the -rc period, where the Kernel is tested and receive fixes.

The length of the -rc period depends on the number and relevance of the fixes. 
Considering
the recent history, it ranges from -rc6 to -rc8, where each -rc takes one week.

Those are the latest -rc kernels since 2.6.12:
2.6.12-rc6
2.6.13-rc7
2.6.14-rc5
2.6.15-rc7
2.6.16-rc6
2.6.17-rc6
2.6.18-rc7
2.6.19-rc6
2.6.20-rc7
2.6.21-rc7
2.6.22-rc7
2.6.23-rc9
2.6.24-rc8
2.6.25-rc9
2.6.26-rc9
2.6.27-rc9
2.6.28-rc9
2.6.29-rc8
2.6.30-rc8
2.6.31-rc9
2.6.32-rc8

In general, the announcement of a new -rc kernel gives some hints when that -rc 
kernel
may be the last one.

The required procedure, on subsystem trees is that:

a) During -rc period (e.g. latest main kernel available is 2.6.x, the latest 
-rc kernel
is 2.6.[x+1]-rcy):

- fix patches for the -rc kernel (2.6.[x+1]) should be sent upstream, 
being a good idea to send them for some time at linux-next tree, allowing other
people to test it, and check for potential conflicts with the other arch's;

- patches for 2.6.[x+2] should be sent to linux-next.

b) the release of 2.6.[x+1] kernel:
- closes the -rc period and starts the merge window.

c) During the merge window:

- the patch that were added on linux-next during the -rc period
for 2.6.[x+2] should be sent upstream;

- new non-fix patches should be hold until the next -rc period starts,
so, they'll be added on 2.6.[x+3];

- fix patches for 2.6.[x+2] should go to linux-next, wait for a few days
and then send upstream.

d) the release of 2.6.[x+2]-rc1 kernel:

- the merge window has closed. No new features are allowed.

- the patches with new features that arrived during the merge window 
will
be moved to linux-next

So, in other words, as currently x=32, and we are at the -rc period, being that
the latest stable kernel is 2.6.32 and the latest -rc kernel 2.6.33-rc5, we are 
receiving
patches for new features that will be available on kernel 2.6.34. After the 
release
of 2.6.33, new features we receive will be added on 2.6.35.

So, we're always developing features that will be there on the next 2 kernels.

In the specific case of new drivers that don't touch on existing features, it 
could
be possible to send it during the -rc period, but it is safer to assume that 
those
drivers should follow the above procedure, as a later submission may be nacked.

Sometimes, a fix patch corrects a problem that happens also on stable kernels 
(e. g.
on kernel 2.6.x or even 2.6.y, where y  x). In this case, the patch should be 
sent to
sta...@kernel.org, in order to be added on stable kernels.

2. KERNEL DEVELOPMENT PROCEDURES FOR V4L/DVB


That's the RFC on how we should work with -git.

1) fixes and linux-next patches

One of the big problems of our model is that we're using just one tree/branch 
for everything,
with mercurial. This makes hard to send some fix patches for 2.6.[x+1], as they 
may have conflicts
with the patches for 2.6.[x+2]. So, when the conflict is simple to solve, the 
patch is sent as
fixes. Otherwise, it generally is hold to the next cycle. The fix patches 
should be tagged by the
developer with Priority: high on mercurial.

Unfortunately, sometimes people mark the driver with the wrong tag. For 
example, I merged yesterday
a patch marked with high that doesn't apply at the fixes tree. This patch fix 
a regression introduced
by a driver that weren't merged yet, so, the patch were added as normal patch.

How to solve those issues?

Well, basically, we should work with more than one tree (or branch), on 
upstream submission:
a tree/branch with the fix patches;
a tree/branch with the new feature patches.

So, the idea is that we'll use those two -git trees:
http://linuxtv.org/git//v4l-dvb.git - Patches for linux-next
http://linuxtv.org/git//fixes.git

RE: [RFC] Procedures for git push

2010-01-23 Thread Aguirre, Sergio
Hi Mauro,

One small suggestion below.

 
 From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] 
 On Behalf Of Mauro Carvalho Chehab [mche...@redhat.com]
 Sent: Saturday, January 23, 2010 8:33 AM
 To: Linux Media Mailing List
 Subject: [RFC] Procedures for git push

 As already discussed during the -git announcement, one important part is how
 we'll handle -git pushes.

 So, I'm sending a procedure explaining how should be the new submission 
 process for
 sending patches via GIT PULL requests.

 Feel free to comment and send suggestions to improve it. I intend to add its 
 content
 to README.patches or to add it as README.git next week, after getting some 
 review.

 Cheers,
 Mauro

 ---

 Mauro Carvalho Chehab mchehab at infradead dot org   Updated on 2010 
 January 23


 1. KERNEL DEVELOPMENT PROCEDURES FOR UPSTREAM
 =

 Before starting with the RFC, it is important that people understand how 
 upstream
 development works.

 Kernel development has 2 phases:

 1) a merge window typically with 2 weeks (although Linus is gave some
 indications that he may reduce it on 2.6.34), starting with the release
 of a new kernel version;

 2) the -rc period, where the Kernel is tested and receive fixes.

 The length of the -rc period depends on the number and relevance of the 
 fixes. Considering
 the recent history, it ranges from -rc6 to -rc8, where each -rc takes one 
 week.

 Those are the latest -rc kernels since 2.6.12:
 2.6.12-rc6
 2.6.13-rc7
 2.6.14-rc5
 2.6.15-rc7
 2.6.16-rc6
 2.6.17-rc6
 2.6.18-rc7
 2.6.19-rc6
 2.6.20-rc7
 2.6.21-rc7
 2.6.22-rc7
 2.6.23-rc9
 2.6.24-rc8
 2.6.25-rc9
 2.6.26-rc9
 2.6.27-rc9
 2.6.28-rc9
 2.6.29-rc8
 2.6.30-rc8
 2.6.31-rc9
 2.6.32-rc8

 In general, the announcement of a new -rc kernel gives some hints when that 
 -rc kernel
 may be the last one.

 The required procedure, on subsystem trees is that:

 a) During -rc period (e.g. latest main kernel available is 2.6.x, the latest 
 -rc kernel
 is 2.6.[x+1]-rcy):

 - fix patches for the -rc kernel (2.6.[x+1]) should be sent upstream,
 being a good idea to send them for some time at linux-next tree, allowing 
 other
 people to test it, and check for potential conflicts with the other arch's;

 - patches for 2.6.[x+2] should be sent to linux-next.

 b) the release of 2.6.[x+1] kernel:
 - closes the -rc period and starts the merge window.

 c) During the merge window:

 - the patch that were added on linux-next during the -rc period
 for 2.6.[x+2] should be sent upstream;

 - new non-fix patches should be hold until the next -rc period starts,
 so, they'll be added on 2.6.[x+3];

 - fix patches for 2.6.[x+2] should go to linux-next, wait for a few 
 days
 and then send upstream.

 d) the release of 2.6.[x+2]-rc1 kernel:

 - the merge window has closed. No new features are allowed.

 - the patches with new features that arrived during the merge window 
 will
 be moved to linux-next

 So, in other words, as currently x=32, and we are at the -rc period, being 
 that
 the latest stable kernel is 2.6.32 and the latest -rc kernel 2.6.33-rc5, we 
 are receiving
 patches for new features that will be available on kernel 2.6.34. After the 
 release
 of 2.6.33, new features we receive will be added on 2.6.35.

 So, we're always developing features that will be there on the next 2 kernels.

 In the specific case of new drivers that don't touch on existing features, it 
 could
 be possible to send it during the -rc period, but it is safer to assume that 
 those
 drivers should follow the above procedure, as a later submission may be 
 nacked.

 Sometimes, a fix patch corrects a problem that happens also on stable kernels 
 (e. g.
 on kernel 2.6.x or even 2.6.y, where y  x). In this case, the patch should 
 be sent to
 sta...@kernel.org, in order to be added on stable kernels.

 2. KERNEL DEVELOPMENT PROCEDURES FOR V4L/DVB
 

 That's the RFC on how we should work with -git.

 1) fixes and linux-next patches

 One of the big problems of our model is that we're using just one tree/branch 
 for everything,
 with mercurial. This makes hard to send some fix patches for 2.6.[x+1], as 
 they may have conflicts
 with the patches for 2.6.[x+2]. So, when the conflict is simple to solve, the 
 patch is sent as
 fixes. Otherwise, it generally is hold to the next cycle. The fix patches 
 should be tagged by the
 developer with Priority: high on mercurial.

 Unfortunately, sometimes people mark the driver with the wrong tag. For 
 example, I merged yesterday
 a patch marked with high that doesn't apply at the fixes tree. This patch 
 fix a regression introduced
 by a driver that 

Re: New Hauppauge HVR-2200 Revision?

2010-01-23 Thread Steven Toth
 I'm a confused by 8940 because this isn't listed in the hcw89.inf file on
 the CD that shipped with the product (driver version 7.6.1.27118).  They
 list 8900, 8901, 8980, 8991, 8993, 89A0, and 89A1.  I downloaded the latest
 drivers from the website (7.6.27.27223) and this adds 8951 and 8953, but
 still not 8940.

 The firmware shipped with 7.6.1.27118 is the same as is available on your
 website, although they have updated it for 7.6.27.27223.

 If there is any other information that would be helpful please let me know.

Does this actually work under windows? It sounds like the driver
doesn't support it?

Regards,

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


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

2010-01-23 Thread Németh Márton
Mauro Carvalho Chehab írta:
 Jean-Francois Moine wrote:
 On Sat, 23 Jan 2010 09:10:44 +0100
 Németh Márton nm...@freemail.hu wrote:

 is more readable, smaller and quicker (less MMU switches) than:
 What do you mean under MMU switches?
 The MMU has an associative memory which is used in the first step to
 translate a logical address (page) to the physical RAM address. Every
 time an address is not in this memory, a MMU interrupt occurs. Then, the
 system scans the page tables of the process, and either reloads the
 associative memory or calls the swap system to bring the page into the 
 physical memory.

 An associative memory is complex and its complexity grows exponentially
 with its size. So, usually, it is rather small. Then, the more the code
 is small and the less MMU interrupts occur...
 
 Linux doesn't use swap memory for the kernel. It will be using a physical RAM 
 memory
 for the entire kernel. So, I don't think MMU applies here.

As far as I can understand the description is about the cache. The cache is the 
storage
area which is usually small and speeds up RAM access.

Regards,

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


New Hauppauge HVR-2200 Revision?

2010-01-23 Thread Francis Barber

Hello Steven,

Firstly, thanks for writing the drivers for HVR-2200.  I'd would be 
delighted if you have some time help me get my hardware supported.  I 
bought an HVR-2200 today. I built the latest from 
http://linuxtv.org/hg/v4l-dvb/, but the device is not yet known:


[15596.718263] CORE saa7164[0]: subsystem: 0070:8940, board: Unknown 
[card=0,autodetected]
[15596.718270] saa7164[0]/0: found at :03:00.0, rev: 129, irq: 19, 
latency: 0, mmio: 0xfe80


I'm a confused by 8940 because this isn't listed in the hcw89.inf file 
on the CD that shipped with the product (driver version 7.6.1.27118).  
They list 8900, 8901, 8980, 8991, 8993, 89A0, and 89A1.  I downloaded 
the latest drivers from the website (7.6.27.27223) and this adds 8951 
and 8953, but still not 8940.


The firmware shipped with 7.6.1.27118 is the same as is available on 
your website, although they have updated it for 7.6.27.27223.


Some details available by looking at the card:
- WinTV-HVR-2200 DVB-T, MULTI-PAL, 89619 LF, REV D3F2.
- Has two NXP TDA10048HN, POS963, 00 01, EPD09322.
- NXP SAA7064E/3, P1A571.00, 07, ESD09372Y.
- SAMSUNG 916 that someone seems to have written on with pencil (?!) so 
I can't read it properly.

- Made in Indonesia 2009/08/20.

If there is any other information that would be helpful please let me know.

Many thanks,
Frank.

--
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] Procedures for git push

2010-01-23 Thread Mauro Carvalho Chehab
Aguirre, Sergio wrote:

 At the email, please always send a summary of what's being send. Such 
 summary is produced by
 this commands:
 git diff -M --stat --summary $ORIGIN `git branch |grep ^\*|cut -b3-`
 echo
 git log --pretty=short $ORIGIN..|git shortlog

 where $ORIGIN is the commit hash of the tree before your patches.
 
 Either that, or you can use following command:
 
 http://www.kernel.org/pub/software/scm/git/docs/git-request-pull.html

Good tip! I wrote the above commands based on my own submit script, that were 
written before
this command being added on -git ;)

I've updated the procedure to reflect this change.

In order to be easier for people to view the new version, I've added it at our 
wiki:
http://linuxtv.org/wiki/index.php/Maintaining_Git_trees

I did one or two cosmetic changes there also, and I added an useful information 
on how to submit
a fix patch that should also be applied at -stable.

For those that are sending contributions, I ask to not directly update the wiki 
(except if the
changes are cosmetic only) but send first an email about the proposed changes 
at this thread,
to allow a better review of the proposed changes.

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


Re: PULL http://jusst.de/hg/stv090x

2010-01-23 Thread Andreas Regel

Hi Manu,

Am 22.01.2010 21:22, schrieb Manu Abraham:

On Fri, Jan 22, 2010 at 11:40 PM, Devin Heitmueller
dheitmuel...@kernellabs.com  wrote:

Also, the dvb_frontend.c makes calls to i2c_gate_ctrl() at various
points, so you would need to ensure that none of those occur before
calling into your driver as there could potentially be a deadlock
there too.


Ok, thanks for the pointer. The gate control is never called
externally in reality. I will wait a little while for this patch to be
applied.  It removes the exported function and thereby an unnecessary
dereference.

http://jusst.de/hg/stv090x/rev/b3d28f5b2b53


There is one call to the gate control function from stv6110x_attach. 
This is needed to set up the clock output divider to the correct value 
before the demodulators clock is configured.


This could be solved by calling tuner_init before setting up the master 
clock in stv090x_init but that only helps on single tuner devices. On 
dual tuner devices you can only open the adapter that works with the 
second tuner. Then you will have the case that the master clock is set 
without having the clock output divider of first tuner initialized to 
the correct value.


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


Re: PULL http://jusst.de/hg/stv090x

2010-01-23 Thread Manu Abraham
Hi Andreas,

On Sat, Jan 23, 2010 at 9:50 PM, Andreas Regel andreas.re...@gmx.de wrote:
 Hi Manu,

 Am 22.01.2010 21:22, schrieb Manu Abraham:

 On Fri, Jan 22, 2010 at 11:40 PM, Devin Heitmueller
 dheitmuel...@kernellabs.com  wrote:

 Also, the dvb_frontend.c makes calls to i2c_gate_ctrl() at various
 points, so you would need to ensure that none of those occur before
 calling into your driver as there could potentially be a deadlock
 there too.

 Ok, thanks for the pointer. The gate control is never called
 externally in reality. I will wait a little while for this patch to be
 applied.  It removes the exported function and thereby an unnecessary
 dereference.

 http://jusst.de/hg/stv090x/rev/b3d28f5b2b53

 There is one call to the gate control function from stv6110x_attach. This is
 needed to set up the clock output divider to the correct value before the
 demodulators clock is configured.

 This could be solved by calling tuner_init before setting up the master
 clock in stv090x_init but that only helps on single tuner devices. On dual
 tuner devices you can only open the adapter that works with the second
 tuner. Then you will have the case that the master clock is set without
 having the clock output divider of first tuner initialized to the correct
 value.

Thinking of which, maybe it would be better to attach the tuner_attach
within the stv090x_attach(). That could solve the issue, AFAICT. What
do you say ?

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


Re: PULL http://jusst.de/hg/stv090x

2010-01-23 Thread Manu Abraham
On Sat, Jan 23, 2010 at 10:07 PM, Manu Abraham abraham.m...@gmail.com wrote:
 Hi Andreas,

 On Sat, Jan 23, 2010 at 9:50 PM, Andreas Regel andreas.re...@gmx.de wrote:
 Hi Manu,

 Am 22.01.2010 21:22, schrieb Manu Abraham:

 On Fri, Jan 22, 2010 at 11:40 PM, Devin Heitmueller
 dheitmuel...@kernellabs.com  wrote:

 Also, the dvb_frontend.c makes calls to i2c_gate_ctrl() at various
 points, so you would need to ensure that none of those occur before
 calling into your driver as there could potentially be a deadlock
 there too.

 Ok, thanks for the pointer. The gate control is never called
 externally in reality. I will wait a little while for this patch to be
 applied.  It removes the exported function and thereby an unnecessary
 dereference.

 http://jusst.de/hg/stv090x/rev/b3d28f5b2b53

 There is one call to the gate control function from stv6110x_attach. This is
 needed to set up the clock output divider to the correct value before the
 demodulators clock is configured.

 This could be solved by calling tuner_init before setting up the master
 clock in stv090x_init but that only helps on single tuner devices. On dual
 tuner devices you can only open the adapter that works with the second
 tuner. Then you will have the case that the master clock is set without
 having the clock output divider of first tuner initialized to the correct
 value.

 Thinking of which, maybe it would be better to attach the tuner_attach
 within the stv090x_attach(). That could solve the issue, AFAICT. What
 do you say ?

OR

Another option will be to attach the tuner prior to the demodulator,
without the clock configuration in the tuner attach (clk configuartion
would be another function ptr), attach the demodulator, run clock
configuration...

I think this might be a bit more cleaner than attaching the tuner
within the demodulator_attach() ... ?


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


Re: PULL http://jusst.de/hg/stv090x

2010-01-23 Thread Andreas Regel

Hi Manu,

Am 23.01.2010 19:32, schrieb Manu Abraham:

On Sat, Jan 23, 2010 at 10:07 PM, Manu Abrahamabraham.m...@gmail.com  wrote:

Hi Andreas,

On Sat, Jan 23, 2010 at 9:50 PM, Andreas Regelandreas.re...@gmx.de  wrote:

Hi Manu,

Am 22.01.2010 21:22, schrieb Manu Abraham:


On Fri, Jan 22, 2010 at 11:40 PM, Devin Heitmueller
dheitmuel...@kernellabs.comwrote:


Also, the dvb_frontend.c makes calls to i2c_gate_ctrl() at various
points, so you would need to ensure that none of those occur before
calling into your driver as there could potentially be a deadlock
there too.


Ok, thanks for the pointer. The gate control is never called
externally in reality. I will wait a little while for this patch to be
applied.  It removes the exported function and thereby an unnecessary
dereference.

http://jusst.de/hg/stv090x/rev/b3d28f5b2b53


There is one call to the gate control function from stv6110x_attach. This is
needed to set up the clock output divider to the correct value before the
demodulators clock is configured.

This could be solved by calling tuner_init before setting up the master
clock in stv090x_init but that only helps on single tuner devices. On dual
tuner devices you can only open the adapter that works with the second
tuner. Then you will have the case that the master clock is set without
having the clock output divider of first tuner initialized to the correct
value.


Thinking of which, maybe it would be better to attach the tuner_attach
within the stv090x_attach(). That could solve the issue, AFAICT. What
do you say ?


OR

Another option will be to attach the tuner prior to the demodulator,
without the clock configuration in the tuner attach (clk configuartion
would be another function ptr), attach the demodulator, run clock
configuration...

I think this might be a bit more cleaner than attaching the tuner
within the demodulator_attach() ... ?


as there already is a function pointer interface for tuner control, I 
would prefer the second approach.


Shall I prepare a patch for it or do you want to?

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


Re: PULL http://jusst.de/hg/stv090x

2010-01-23 Thread Manu Abraham
On Sat, Jan 23, 2010 at 10:46 PM, Andreas Regel andreas.re...@gmx.de wrote:
 Hi Manu,

 Am 23.01.2010 19:32, schrieb Manu Abraham:

 On Sat, Jan 23, 2010 at 10:07 PM, Manu Abrahamabraham.m...@gmail.com
  wrote:

 Hi Andreas,

 On Sat, Jan 23, 2010 at 9:50 PM, Andreas Regelandreas.re...@gmx.de
  wrote:

 Hi Manu,

 Am 22.01.2010 21:22, schrieb Manu Abraham:

 On Fri, Jan 22, 2010 at 11:40 PM, Devin Heitmueller
 dheitmuel...@kernellabs.com    wrote:

 Also, the dvb_frontend.c makes calls to i2c_gate_ctrl() at various
 points, so you would need to ensure that none of those occur before
 calling into your driver as there could potentially be a deadlock
 there too.

 Ok, thanks for the pointer. The gate control is never called
 externally in reality. I will wait a little while for this patch to be
 applied.  It removes the exported function and thereby an unnecessary
 dereference.

 http://jusst.de/hg/stv090x/rev/b3d28f5b2b53

 There is one call to the gate control function from stv6110x_attach.
 This is
 needed to set up the clock output divider to the correct value before
 the
 demodulators clock is configured.

 This could be solved by calling tuner_init before setting up the master
 clock in stv090x_init but that only helps on single tuner devices. On
 dual
 tuner devices you can only open the adapter that works with the second
 tuner. Then you will have the case that the master clock is set without
 having the clock output divider of first tuner initialized to the
 correct
 value.

 Thinking of which, maybe it would be better to attach the tuner_attach
 within the stv090x_attach(). That could solve the issue, AFAICT. What
 do you say ?

 OR

 Another option will be to attach the tuner prior to the demodulator,
 without the clock configuration in the tuner attach (clk configuartion
 would be another function ptr), attach the demodulator, run clock
 configuration...

 I think this might be a bit more cleaner than attaching the tuner
 within the demodulator_attach() ... ?

 as there already is a function pointer interface for tuner control, I would
 prefer the second approach.


I started up on it, but if you would like to send a patch, I am happy
that way too...

 Shall I prepare a patch for it or do you want to?

Either is fine with me.


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


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

2010-01-23 Thread Jean-Francois Moine
On Sat, 23 Jan 2010 12:05:19 -0200
Mauro Carvalho Chehab mche...@redhat.com wrote:

  An associative memory is complex and its complexity grows
  exponentially with its size. So, usually, it is rather small. Then,
  the more the code is small and the less MMU interrupts occur...  
 
 Linux doesn't use swap memory for the kernel. It will be using a
 physical RAM memory for the entire kernel. So, I don't think MMU
 applies here.

Well, it is a long time since I did not program an embedded system!
In the last one, the cpu was a PowerPC maybe 603 or similar.
I retrieved the MMU sequence I was talking about in the linux kernel.
The associative memory is called the TLB. In the file

arch/powerpc/kernel/head_32.S

you may see the treatment of the tlb interrupts (InstructionTLBMiss,
DataLoadTLBMiss and DataStoreTLBMiss). Such interrupts occur at the
lowest level, even when the cpu is running in the kernel state.

These interrupts are different from page faults which occur when a
memory page is not mapped, and, hopefully, the kernel code is always
mapped...

Cheers.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: technisat cablestar hd2, 2.6.33-rc5, no remote (VP2040)

2010-01-23 Thread Aljaž Prusnik
Hi Manu,

I'm sorry to bother you with this one, but I'd really like to know if
there's something I'm doing wrong or is there something more I can
provide on this one. Below are some results from the newest kernel RC,
while sometime back I also posted some more debug info. 

I just noticed that someone else also reported the same problem:
http://www.spinics.net/lists/linux-media/msg14332.html


Thanks in advance for any info.

Regards,
Aljaz



On pet, 2010-01-22 at 21:57 +0100, Aljaž Prusnik wrote:
 Hi!
 
 I tried 2.6.33-rc5 kernel hoping to get the remote working, but it's the
 same behaviour as in my previous posts. TV reception works, however
 there's no VP2040 to be noticed anywhere in the logs.
 
 The device used to be detected like this:
 
 I: Bus=0001 Vendor= Product= Version=0001
 N: Name=Mantis VP-2040 IR Receiver
 P: Phys=pci-:03:06.0/ir0
 S: Sysfs=/devices/virtual/input/input5
 U: Uniq=
 H: Handlers=kbd event5
 B: EV=13
 B: KEY=108fc330 2842041 0 200018000 21804801
 9e96c0 ffc
 
 
 but now, this does not happen anymore. Any ideas?
 
 Below are some outputs of the current situation:
 
 mantis modules:
 
 $ lsmod | grep mantis
 mantis 14728  0 
 mantis_core23909  18 mantis
 ir_common  26893  1 mantis_core
 ir_core 3906  2 mantis_core,ir_common
 mb86a1616598  1 mantis
 tda100214822  1 mantis
 tda100235823  1 mantis
 zl10353 5893  1 mantis
 stv0299 7860  1 mantis
 dvb_core   77233  2 mantis_core,stv0299
 
 
 devices (no mantis 2040 anywhere):
 
 $ cat /proc/bus/input/devices
 I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
 N: Name=AT Translated Set 2 keyboard
 P: Phys=isa0060/serio0/input0
 S: Sysfs=/devices/platform/i8042/serio0/input/input0
 U: Uniq=
 H: Handlers=kbd event0 
 B: EV=120013
 B: KEY=40200 3803078f800d001 fedfffef fffe
 B: MSC=10
 B: LED=7
 
 I: Bus=0019 Vendor= Product=0001 Version=
 N: Name=Power Button
 P: Phys=PNP0C0C/button/input0
 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
 U: Uniq=
 H: Handlers=kbd event1 
 B: EV=3
 B: KEY=10 0
 
 I: Bus=0019 Vendor= Product=0001 Version=
 N: Name=Power Button
 P: Phys=LNXPWRBN/button/input0
 S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
 U: Uniq=
 H: Handlers=kbd event2 
 B: EV=3
 B: KEY=10 0
 
 I: Bus=0010 Vendor=001f Product=0001 Version=0100
 N: Name=PC Speaker
 P: Phys=isa0061/input0
 S: Sysfs=/devices/platform/pcspkr/input/input3
 U: Uniq=
 H: Handlers=kbd event3 
 B: EV=40001
 B: SND=6
 
 I: Bus=0003 Vendor=03f0 Product=041d Version=0110
 N: Name=Hewlett-Packard HP USB Travel Mouse
 P: Phys=usb-:00:12.1-1/input0
 S: Sysfs=/devices/pci:00/:00:12.1/usb4/4-1/4-1:1.0/input/input4
 U: Uniq=
 H: Handlers=mouse0 event4 
 B: EV=17
 B: KEY=7 0 0 0 0
 B: REL=103
 B: MSC=10
 
 I: Bus=0001 Vendor=10ec Product=0887 Version=0001
 N: Name=HDA Digital PCBeep
 P: Phys=card0/codec#0/beep0
 S: Sysfs=/devices/pci:00/:00:14.2/input/input5
 U: Uniq=
 H: Handlers=kbd event5 
 B: EV=40001
 B: SND=6
 
 
 Regards,
 Aljaz Prusnik



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


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

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

Results of the daily build of v4l-dvb:

date:Sat Jan 23 19:00:07 CET 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14050:2a50a0a1c951
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.30-armv5: OK
linux-2.6.31-armv5: OK
linux-2.6.32-armv5: OK
linux-2.6.33-rc2-armv5: OK
linux-2.6.32-armv5-davinci: WARNINGS
linux-2.6.33-rc2-armv5-davinci: WARNINGS
linux-2.6.30-armv5-ixp: WARNINGS
linux-2.6.31-armv5-ixp: WARNINGS
linux-2.6.32-armv5-ixp: WARNINGS
linux-2.6.33-rc2-armv5-ixp: WARNINGS
linux-2.6.30-armv5-omap2: WARNINGS
linux-2.6.31-armv5-omap2: WARNINGS
linux-2.6.32-armv5-omap2: WARNINGS
linux-2.6.33-rc2-armv5-omap2: WARNINGS
linux-2.6.22.19-i686: WARNINGS
linux-2.6.23.12-i686: WARNINGS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.11-i686: WARNINGS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: WARNINGS
linux-2.6.28-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-i686: WARNINGS
linux-2.6.31-i686: WARNINGS
linux-2.6.32-i686: WARNINGS
linux-2.6.33-rc2-i686: WARNINGS
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-m32r: OK
linux-2.6.33-rc2-m32r: OK
linux-2.6.30-mips: WARNINGS
linux-2.6.31-mips: WARNINGS
linux-2.6.32-mips: WARNINGS
linux-2.6.33-rc2-mips: WARNINGS
linux-2.6.30-powerpc64: ERRORS
linux-2.6.31-powerpc64: ERRORS
linux-2.6.32-powerpc64: ERRORS
linux-2.6.33-rc2-powerpc64: ERRORS
linux-2.6.22.19-x86_64: WARNINGS
linux-2.6.23.12-x86_64: WARNINGS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.11-x86_64: WARNINGS
linux-2.6.26-x86_64: WARNINGS
linux-2.6.27-x86_64: WARNINGS
linux-2.6.28-x86_64: WARNINGS
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30-x86_64: WARNINGS
linux-2.6.31-x86_64: WARNINGS
linux-2.6.32-x86_64: WARNINGS
linux-2.6.33-rc2-x86_64: WARNINGS
spec: OK
sparse (linux-2.6.32): ERRORS
sparse (linux-2.6.33-rc2): ERRORS
linux-2.6.16.61-i686: OK
linux-2.6.17.14-i686: OK
linux-2.6.18.8-i686: OK
linux-2.6.19.5-i686: OK
linux-2.6.20.21-i686: WARNINGS
linux-2.6.21.7-i686: WARNINGS
linux-2.6.16.61-x86_64: OK
linux-2.6.17.14-x86_64: WARNINGS
linux-2.6.18.8-x86_64: WARNINGS
linux-2.6.19.5-x86_64: WARNINGS
linux-2.6.20.21-x86_64: WARNINGS
linux-2.6.21.7-x86_64: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The 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: [ANNOUNCE] git tree repositories libv4l

2010-01-23 Thread Hans de Goede

Hi all,

On 01/21/2010 08:34 AM, Hans Verkuil wrote:

On Thursday 21 January 2010 03:46:05 Brandon Philips wrote:

On 00:07 Thu 21 Jan 2010, Mauro Carvalho Chehab wrote:

Brandon Philips wrote:

On 19:50 Wed 20 Jan 2010, Hans de Goede wrote:

On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote:

As we're discussing about having a separate tree for v4l2-apps,
maybe the better is to port it to -git (in a way that we can
preserve the log history).


I have a small script I used to convert the history of libv4l to
git. Let me know when we are ready to drop them from the hg tree
and I can do the conversion and post the result for review.

This is the result from the script for just libv4l:
  http://ifup.org/git/?p=libv4l.git;a=summary


Seems fine, but we need to import the entire v4l2-apps.


Yes, I know. I will run the script over v4l2-apps to generate a git
repo once v4l2-apps is ready to be dropped from v4l-dvb mercurial and
we figure out the directory layout.

Doing it before is just a waste of time since they will get out of
sync.


Also, I suggest we call the repo v4lutils? In the spirit of
usbutils, pciutils, etc.


Hmm... as dvb package is called as dvb-utils, it seems more logical to call it
v4l2-utils, but v4l2utils would equally work.


Yes, that is fine.


IMO, the better is to use v4l2 instead of just v4l, to avoid causing
any mess with the old v4l applications provided with xawtv.


The problem I saw was that libv4l1 will be in v4l2-utils. I don't care
either way though.

So here is how I see v4l-utils.git being laid out based on what others
have said:

  libv4l1/
  libv4l2/
  libv4lconvert/
  test/
  v4l2-dbg/
  contrib/
   qv4l2-qt3/
   qv4l2-qt4/
   cx25821/
   etc... everything else


Hmm. I think I would prefer to have a structure like this:

lib/
libv4l1/
libv4l2/
libv4lconvert/
utils/
v4l2-dbg
v4l2-ctl
cx18-ctl
ivtv-ctl
contrib/
test/
everything else

And everything in lib and utils can be packaged by distros, while contrib
is not packaged.



+1 for this directory layout.

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: [ANNOUNCE] git tree repositories libv4l

2010-01-23 Thread Hans de Goede

Hi,

On 01/21/2010 08:23 AM, Hans Verkuil wrote:




snip


Yes, but, as we have also non-c code, some rules there don't apply.
For example the rationale for not using // comments don't apply to c++,
since it is there since the first definition.


Most apps are already in 'kernel' style. The main exception being libv4l.



Ack,

which in hind sight may not have been the best choice (I have no personal
coding style, I'm used to adjusting my style to what ever the project
I'm working on uses).

Still I would like to keep libv4l as an exception, re-indenting it is
not going to do it any good (I did my best to keep lines within 80
chars, but moving to tabs as indent will ruin this, and there are quite
a few nasty nested if cases in there).

snip

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: CI USB

2010-01-23 Thread Konstantin Dimitrov
On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote:
 On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote:
 HoP wrote:

 I don't know the details into the USB device, but each of those CAM's
 have bandwidth limits on them and they vary from one CAM to the other.
 Also, there is a limit on the number of simultaneous PID's that which
 you can decrypt.

 Some allow only 1 PID, some allow 3. Those are the basic CAM's for
 home usage.The most expensive CAM's allow a maximum of 24 PID's. But


 You, of course, ment number of descramblers not PIDS because it is evident
 that getting TV service descrambled, you need as minimum 2 PIDS for A/V.

 Anyway, it is very good note. Users, in general, don't know about it.


 If it is using a CI+ plus chip (I heard from someone that it is a CI+
 chip inside) :
 http://www.smardtv.com/index.php?page=ciplus

 After reading the CI+ specifications, I doubt that it can be supported
 under Linux with open source support, without a paired decoder
 hardware or software decoder. A paired open source software decoder
 seems highly unlikely, as the output of the CI+ module is eventually
 an encrypted stream which can be descrambled with the relevant keys.
 The TS is not supposed to be stored on disk, or that's what the whole
 concept is for CI+

 http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf

 See pages 7, 8 , 12, 15

 It could be possible to pair a software decoder with a key and hence
 under Windows, but under Linux I would really doubt it, if it happens
 to be a CI+ chip

at least in Windows Hauppage WinTV-CI USB (which is OEM version of
SmartDTV USB CI) allows you to capture the decrypted stream to your
hard drive (i've just tested it).

so, i can't see a reason why even if it has CI+ chip inside same
functionally as in Windows can't be provided in Linux if someone
developed a driver.


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

--
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: New Hauppauge HVR-2200 Revision?

2010-01-23 Thread Francis Barber

On 23/01/2010 11:00 PM, Steven Toth wrote:

I'm a confused by 8940 because this isn't listed in the hcw89.inf file on
the CD that shipped with the product (driver version 7.6.1.27118).  They
list 8900, 8901, 8980, 8991, 8993, 89A0, and 89A1.  I downloaded the latest
drivers from the website (7.6.27.27223) and this adds 8951 and 8953, but
still not 8940.

The firmware shipped with 7.6.1.27118 is the same as is available on your
website, although they have updated it for 7.6.27.27223.
 
   

If there is any other information that would be helpful please let me know.
 

Does this actually work under windows? It sounds like the driver
doesn't support it?

Regards,

   


As expected, the card didn't work in Windows with either of those driver 
versions.  However, hauppauge.com has different drivers to 
hauppauge.co.uk!  The latest HVR2250 drivers from hauppauge.com, version 
7.6.27.27323, include 8940 in the inf file.  This version installs fine 
on Windows.


Regards,
Frank.
--
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: New Hauppauge HVR-2200 Revision?

2010-01-23 Thread Steven Toth
I put some new patches into the saa7164-stable earlier today. These
will probably help.

www.kernellabs.com/hg/saa7164-stable

Let me know.

Regards,

- Steve

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

On Sat, Jan 23, 2010 at 6:17 PM, Francis Barber
fed...@barber-family.id.au wrote:
 On 23/01/2010 11:00 PM, Steven Toth wrote:

 I'm a confused by 8940 because this isn't listed in the hcw89.inf file on
 the CD that shipped with the product (driver version 7.6.1.27118).  They
 list 8900, 8901, 8980, 8991, 8993, 89A0, and 89A1.  I downloaded the
 latest
 drivers from the website (7.6.27.27223) and this adds 8951 and 8953, but
 still not 8940.

 The firmware shipped with 7.6.1.27118 is the same as is available on your
 website, although they have updated it for 7.6.27.27223.




 If there is any other information that would be helpful please let me
 know.


 Does this actually work under windows? It sounds like the driver
 doesn't support it?

 Regards,



 As expected, the card didn't work in Windows with either of those driver
 versions.  However, hauppauge.com has different drivers to hauppauge.co.uk!
  The latest HVR2250 drivers from hauppauge.com, version 7.6.27.27323,
 include 8940 in the inf file.  This version installs fine on Windows.

 Regards,
 Frank.

--
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: CI USB

2010-01-23 Thread Manu Abraham
On Sun, Jan 24, 2010 at 1:45 AM, Konstantin Dimitrov
kosio.dimit...@gmail.com wrote:
 On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote:
 On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk 
 wrote:
 HoP wrote:

 I don't know the details into the USB device, but each of those CAM's
 have bandwidth limits on them and they vary from one CAM to the other.
 Also, there is a limit on the number of simultaneous PID's that which
 you can decrypt.

 Some allow only 1 PID, some allow 3. Those are the basic CAM's for
 home usage.The most expensive CAM's allow a maximum of 24 PID's. But


 You, of course, ment number of descramblers not PIDS because it is evident
 that getting TV service descrambled, you need as minimum 2 PIDS for A/V.

 Anyway, it is very good note. Users, in general, don't know about it.


 If it is using a CI+ plus chip (I heard from someone that it is a CI+
 chip inside) :
 http://www.smardtv.com/index.php?page=ciplus

 After reading the CI+ specifications, I doubt that it can be supported
 under Linux with open source support, without a paired decoder
 hardware or software decoder. A paired open source software decoder
 seems highly unlikely, as the output of the CI+ module is eventually
 an encrypted stream which can be descrambled with the relevant keys.
 The TS is not supposed to be stored on disk, or that's what the whole
 concept is for CI+

 http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf

 See pages 7, 8 , 12, 15

 It could be possible to pair a software decoder with a key and hence
 under Windows, but under Linux I would really doubt it, if it happens
 to be a CI+ chip

 at least in Windows Hauppage WinTV-CI USB (which is OEM version of
 SmartDTV USB CI) allows you to capture the decrypted stream to your
 hard drive (i've just tested it).


Maybe it is not CI+ itself in the first place


 so, i can't see a reason why even if it has CI+ chip inside same
 functionally as in Windows can't be provided in Linux if someone
 developed a driver.


It would be interesting to know what chips the hardware has  ...

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


[PATCH] sq905c: remove unused variable

2010-01-23 Thread Douglas Schilling Landgraf
Removed unused variable.

Signed-off-by: Douglas Schilling Landgraf dougsl...@redhat.com

Thanks,
Douglas


patch-sq905c.diff
Description: Binary data


Re: New Hauppauge HVR-2200 Revision?

2010-01-23 Thread Francis Barber

On 24/01/2010 7:29 AM, Steven Toth wrote:

I put some new patches into the saa7164-stable earlier today. These
will probably help.

www.kernellabs.com/hg/saa7164-stable

Let me know.

Regards,

- Steve

   

Thanks, I will give this a try later today.

Presumably I should use the firmware from version 7.6.27.27323 (although 
there doesn't seem to be any firmware corresponding to dvb-fe-tda10048 
with this download)?


Regards,
Frank.
--
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: New Hauppauge HVR-2200 Revision?

2010-01-23 Thread Steven Toth
http://www.kernellabs.com/blog/?page_id=17

Firmware links from here.

- Steve

On Sat, Jan 23, 2010 at 7:03 PM, Francis Barber
fed...@barber-family.id.au wrote:
 On 24/01/2010 7:29 AM, Steven Toth wrote:

 I put some new patches into the saa7164-stable earlier today. These
 will probably help.

 www.kernellabs.com/hg/saa7164-stable

 Let me know.

 Regards,

 - Steve



 Thanks, I will give this a try later today.

 Presumably I should use the firmware from version 7.6.27.27323 (although
 there doesn't seem to be any firmware corresponding to dvb-fe-tda10048 with
 this download)?

 Regards,
 Frank.




-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
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: [ANNOUNCE] git tree repositories libv4l

2010-01-23 Thread Mauro Carvalho Chehab
Hans de Goede wrote:
 Hi,
 
 On 01/21/2010 08:23 AM, Hans Verkuil wrote:

 
 snip
 
 Yes, but, as we have also non-c code, some rules there don't apply.
 For example the rationale for not using // comments don't apply to c++,
 since it is there since the first definition.

 Most apps are already in 'kernel' style. The main exception being libv4l.

Well... they are close to kernel style, but if you run checkpatch over
all files there, I'm sure you'll see lots of violations.

 
 Ack,
 
 which in hind sight may not have been the best choice (I have no personal
 coding style, I'm used to adjusting my style to what ever the project
 I'm working on uses).
 
 Still I would like to keep libv4l as an exception,

If we're adopting one CodingStyle, this should be done for everything, otherwise
it makes no sense to standardize.

 re-indenting it is
 not going to do it any good (I did my best to keep lines within 80
 chars, but moving to tabs as indent will ruin this, and there are quite
 a few nasty nested if cases in there).

The 80 chars limit is nowadays a soft simit. There are even some discussions 
from
people that the resulting code of people sending patches that just avoids the 
limit
is worse than before.

The idea behind this limit is that lines of code with more than 80 chars is an 
indication
that the code is more complex than it needs to be. So, the logic there may 
re-implemented
on a better way.

Just for fun, I ran this indent command (with kernel CodingStyle, except for 
the 80 chars
limit), over v4l2-apps/libv4l/libv4l2:

indent -npro -kr -i8 -ts8 -sob  -ss -ncs -cp1  -l260 *.c

Except for one or two things, the resulting code seems a way better. Yet, as 
pointed by
Brandon, some manual work is needed to fix some parts of the result, as the 
indent is not
perfect.

Again for fun, I ran a checkpatch over the resulting code, removing all 
warnings due
to 80 cols (see enclosed). I think the troubles with the goto labels were 
introduced by
indent.

---

From my side, it would be better to use the same CodingStyle also at v4l2-apps,
since this makes easier for people to contribute on both kernel and userspace. 
Also, 
I can read the code faster when it uses the Kernel CodingStyle.

Yet, not all checkpatch warnings apply to userspace, as some are specific to 
usage
of kernel deprecated functions. That's said, by using an style close to the 
kernel one,
it is easy to remove from checkpatch the warnings that won't apply to userspace.


Cheers,
Mauro

-

/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '   if ((result = 
SYS_IOCTL(devices[index].fd, VIDIOC_REQBUFS, req))  0) {':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:102: ERROR: do not use 
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '   if 
((result = SYS_IOCTL(devices[index].fd, VIDIOC_STREAMON, type))) {':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:193: ERROR: do not use 
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '   if ((result = 
SYS_IOCTL(devices[index].fd, VIDIOC_QBUF, buf))) {':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:238: ERROR: do not use 
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '   if ((result = 
v4l2_map_buffers(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:255: ERROR: do not use 
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '   if 
((result = SYS_IOCTL(devices[index].fd, VIDIOC_DQBUF, buf))) {':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:259: ERROR: do not use 
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '   }':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:287: warning: braces {} are 
not necessary for single statement blocks
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '   }':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:338: warning: braces {} are 
not necessary for single statement blocks
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '   if ((result = 
v4l2_request_read_buffers(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:377: ERROR: do not use 
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '   if ((result = 
v4l2_map_buffers(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:380: ERROR: do not use 
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '   if ((result = 
v4l2_queue_read_buffers(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:383: ERROR: do not use 
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '   if ((result = 
v4l2_streamoff(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:395: ERROR: do not use 
assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '   if 

Re: PULL http://jusst.de/hg/stv090x

2010-01-23 Thread hermann pitton
Hi,

Am Samstag, den 23.01.2010, 15:25 +0400 schrieb Manu Abraham:
 On Sat, Jan 23, 2010 at 5:08 AM, hermann pitton hermann-pit...@arcor.de 
 wrote:
  Hi.
 
  Am Samstag, den 23.01.2010, 01:23 +0400 schrieb Manu Abraham:
  On Sat, Jan 23, 2010 at 1:14 AM, Mauro Carvalho Chehab
  mche...@infradead.org wrote:
   Devin Heitmueller wrote:
   On Fri, Jan 22, 2010 at 3:22 PM, Manu Abraham abraham.m...@gmail.com 
   wrote:
   On Fri, Jan 22, 2010 at 11:40 PM, Devin Heitmueller
   dheitmuel...@kernellabs.com wrote:
   Also, the dvb_frontend.c makes calls to i2c_gate_ctrl() at various
   points, so you would need to ensure that none of those occur before
   calling into your driver as there could potentially be a deadlock
   there too.
   Ok, thanks for the pointer. The gate control is never called
   externally in reality. I will wait a little while for this patch to be
   applied.  It removes the exported function and thereby an unnecessary
   dereference.
  
   http://jusst.de/hg/stv090x/rev/b3d28f5b2b53
  
   If it never needs to be called externally, then removing it from the
   dvb_frontend_ops does eliminate the risk entirely.  The case I
   frequently see it called from dvb_frontend.c is for powering down the
   tuner when the dvb frontend thread shuts down.
  
   The removal of the external call to the gate function removes the risk 
   that
   an external call, at dvb core, to keep it locked. Yet, the code there is 
   completely
   symetric nowadays.
  
   However, the proper documentation of the lock is needed to avoid the risk
   of some patch to keep the mutex locked.
  
   As, even the initial lock changeset has this problem (later fixed by
   http://jusst.de/hg/stv090x/rev/3a8f35abc0f2), it shows that a good 
   documentation
   is required.
  
   As you've talked about a FSM, the lock itself is a FSM with 2 states. 
   All I'm
   asking is that you document that the lock FSM has changed its state in 
   the name
   of the function that alters the state of the lock.
  
 
  Sure, of course, i will add some comments into the patch that I have
  queued up, before pull request. Don't worry, be at peace. :-)
 
  Regards,
  Manu
 
  Good, seems there is some progress.
 
  But 1080p was first from satellites only too ;)
 
 
 Eventually, broadcasters will restrict all good content. Only old
 stuff will even be happening with FTA. Even old scrambling systems are
 going away.
 
 Broadcasters would transmit protected content in the stream, along
 with relevant keys for relevant schema; CI+ is replacing old CI
 systems.
 
 CI+ streams would eventually be encrypted; ie, you won't get access to
 those streams, The CI+ output will be paired with a CI+ capable
 decoder, which will be given it's set of keys.
 
 The decoder will output HDMI with HDCP ..
 
 You can see that vicious circle that's evolving ... Broadcasters and
 Media producers like to term it as a war; they don't want users to
 capture the streams on a computer eventually; that's another way of
 stating it; even if the media has to be Time shifted, that would be
 paired with decoder, so eventually the media stays at one place and
 doesn't get circulated.
 
 
 Regards,
 Manu

yes, you are totally right, serious problems with lots of implications.

We are also already excluded from HD content becoming available on
demand over IP, because of missing DRM.

All the private/commercial broadcasters switched over to HD+ and CI+
right now here in Germany. So you don't come any further even with the
new S2 cards.

Given that, isn't it better to buy blu(e)-ray disks for the little HD
content you are really interested in and have 1080p?

If I'm not outdated on it again, likely possible, you can exchange legal
disks legally with others. Should be much cheaper than to have such a
jukebox in your living room you have to feed again and again, even for
the same content, if you ever want to see it one more time.

I won't buy any such + stuff to watch soap operas in some sort of HD and
some other stuff on lowest levels they have, not even be able to skip
the endless commercials in between.

Cheers,
Hermann




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


Re: [PATCH] sq905c: remove unused variable

2010-01-23 Thread Theodore Kilgore



On Sat, 23 Jan 2010, Douglas Schilling Landgraf wrote:


Removed unused variable.

Signed-off-by: Douglas Schilling Landgraf dougsl...@redhat.com

Thanks,
Douglas



Douglas,

Thanks for your sharp eyes.

However, I _think_ that this particular problem may have already been 
fixed, recently if not some time before. In particular, recent changes 
have been done in the version of sq905c.c which lives in the gspca tree of 
Hans de Goede. I am working off his tree these days because we have been 
doing a number of things together, and thus the changes there to sq905c.c 
have been done by a patch from here.


These changes were done in order to add a couple of new cameras and to 
change the way to decide whether the camera is a VGA or a CIF camera. The 
determination of this by USB Product number does not always work, and one 
needs to read an ID string from the camera in order to learn it better. 
Who bought the camera which has the wrong resolution setting associated 
with its USB Product number? Hans de Goede.


It appears to me that this patch is not relevant to that most recent 
version of sq905c.c. At least, it does not fit here, which is where it 
appears it is supposed to fit:


/* This function is called at probe time just before sd_init */
static int sd_config(struct gspca_dev *gspca_dev,
const struct usb_device_id *id)
{
struct cam *cam = gspca_dev-cam;
struct sd *dev = (struct sd *) gspca_dev;
int ret;

PDEBUG(D_PROBE,
SQ9050 camera detected


If everyone else is agreeable, I would propose that the recent changes to 
sq905c.c should simply be pulled, and that is the best solution to the 
problem.


Hans, can you confirm all of this?


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


Re: New Hauppauge HVR-2200 Revision?

2010-01-23 Thread Francis Barber

On 24/01/2010 8:18 AM, Steven Toth wrote:

http://www.kernellabs.com/blog/?page_id=17

Firmware links from here.

- Steve

On Sat, Jan 23, 2010 at 7:03 PM, Francis Barber
fed...@barber-family.id.au  wrote:
   

On 24/01/2010 7:29 AM, Steven Toth wrote:
 

I put some new patches into the saa7164-stable earlier today. These
will probably help.

www.kernellabs.com/hg/saa7164-stable

Let me know.

Regards,

- Steve


   

Thanks, I will give this a try later today.

Presumably I should use the firmware from version 7.6.27.27323 (although
there doesn't seem to be any firmware corresponding to dvb-fe-tda10048 with
this download)?

Regards,
Frank.

 


Using a03ea24beafc from www.kernellabs.com/hg/saa7164-stable pretty 
well, thanks very much for working on this quickly!  As an aside, I'm 
interested as to why I should use the firmware from the older drivers.


The only problem with it now is that when I tune HD channels tzap 
consistently reports unc, for example:


status 1f | signal fefe | snr 00f6 | ber 000f | unc 006a | 
FE_HAS_LOCK
status 1f | signal fefe | snr 00f6 | ber 000e | unc 006a | 
FE_HAS_LOCK
status 1f | signal fefe | snr 00f6 | ber 0012 | unc 006a | 
FE_HAS_LOCK


I can't see any problems when watching the channels, however (ie, the 
picture looks fine).


Thanks again,
Frank.
--
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: CI USB

2010-01-23 Thread Konstantin Dimitrov
On Sun, Jan 24, 2010 at 1:43 AM, Manu Abraham abraham.m...@gmail.com wrote:
 On Sun, Jan 24, 2010 at 1:45 AM, Konstantin Dimitrov
 kosio.dimit...@gmail.com wrote:
 On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote:
 On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk 
 wrote:
 HoP wrote:

 I don't know the details into the USB device, but each of those CAM's
 have bandwidth limits on them and they vary from one CAM to the other.
 Also, there is a limit on the number of simultaneous PID's that which
 you can decrypt.

 Some allow only 1 PID, some allow 3. Those are the basic CAM's for
 home usage.The most expensive CAM's allow a maximum of 24 PID's. But


 You, of course, ment number of descramblers not PIDS because it is evident
 that getting TV service descrambled, you need as minimum 2 PIDS for A/V.

 Anyway, it is very good note. Users, in general, don't know about it.


 If it is using a CI+ plus chip (I heard from someone that it is a CI+
 chip inside) :
 http://www.smardtv.com/index.php?page=ciplus

 After reading the CI+ specifications, I doubt that it can be supported
 under Linux with open source support, without a paired decoder
 hardware or software decoder. A paired open source software decoder
 seems highly unlikely, as the output of the CI+ module is eventually
 an encrypted stream which can be descrambled with the relevant keys.
 The TS is not supposed to be stored on disk, or that's what the whole
 concept is for CI+

 http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf

 See pages 7, 8 , 12, 15

 It could be possible to pair a software decoder with a key and hence
 under Windows, but under Linux I would really doubt it, if it happens
 to be a CI+ chip

 at least in Windows Hauppage WinTV-CI USB (which is OEM version of
 SmartDTV USB CI) allows you to capture the decrypted stream to your
 hard drive (i've just tested it).


 Maybe it is not CI+ itself in the first place


 so, i can't see a reason why even if it has CI+ chip inside same
 functionally as in Windows can't be provided in Linux if someone
 developed a driver.


 It would be interesting to know what chips the hardware has  ...

i can confirm the information here:

* http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-CI

and it contains:

* an FX2 from Cypress (CY7C68013A) and a FPGA (Actel Proasic-plus, APA075-F)

also, i can confirm that firmware extractor here:

http://www.bsc-bvba.be/linux/dvb/

is correct at least for A2 hardware (but A1 hardware is no longer in
production anyway), because a long time ago i verified with spying the
USB traffic what firmware is uploaded in Windows for A2 hardware and
informed Luc Brosens and he fixed his firmware extractor tool.

however, it seems that the main problem as it's mentioned by Luc
Brosens is why firmware upload fails in Linux, because according to
Steven Toth words:

* http://www.linuxtv.org/pipermail/linux-dvb/2008-April/025284.html

* I also looked at the USB traffic on the current Hauppauge driver, with a
* cam inserted and decryption happening. The protocol appears pretty simple.

after the firmware is uploaded is easy to figure out how to send
commands to the device.


 Regards,
 Manu

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