Re: [PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
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
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/
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
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
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
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
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
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()
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
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
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/
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
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
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?
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/
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?
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
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
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
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
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
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
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/
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)
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
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
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
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
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?
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?
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
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
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?
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?
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
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
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
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: CI USB
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
