BUG: cx23885_video_register() uninitialized value passed to v4l2_subdev_call()
Hi all, A potential bug is found in cx23885_video_register(). A tuner_setup struct is passed to v4l2_subdev_call(), but that struct is not fully initialized, especially for tuner_callback member, and eventually tuner_s_type_addr() copy that wrong pointer. It would particularly cause seg. fault for xc5000 tuner for analog frontend when it calls fe->callback at xc5000_TunerReset(). Regards, David T.L. Wong -- 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: [2.6.31] ir-kbd-i2c oops.
Hi Andy, On Wed, 30 Sep 2009 19:42:46 -0400, Andy Walls wrote: > On Wed, 2009-09-30 at 12:57 +0200, Jean Delvare wrote: > > Not sure why you look at address 0x83e? The stack trace says +0x64. As > > function ir_input_init() starts at 0x800, the oops address would be > > 0x864, which is: > > > > 864:f0 0f ab 31 lock bts %esi,(%rcx) > > > > If my disassembler skills are still worth anything, this corresponds to > > the set_bit instruction in: > > > > for (i = 0; i < IR_KEYTAB_SIZE; i++) > > set_bit(ir->ir_codes[i], dev->keybit); > > > > in the source code. This suggests that ir->ir_codes is smaller than > > expected (sounds unlikely as this array is included in struct > > ir_input_state) or dev->keybit isn't large enough (sounds unlikely as > > well, it should be large enough to contain 0x300 bits while ir keycodes > > are all below 0x100.) So most probably something went wrong before and > > we're only noticing now. > > Jean, > > You should be aware that the type of ir_codes changed recently from > > IR_KEYTAB_TYPE > > to > > struct ir_scancode_table * > > > I'm not sure if it is the problem here, but it may be prudent to check > that there's no mismatch between the module and the structure > definitions being pulled in via "#include" (maybe by stopping gcc after > the preprocessing with -E ). Thanks for the hint. As far as I can see, this change is new in kernel 2.6.32-rc1. In 2.6.31, which is where Pawel reported the issue, we still have IR_KEYTAB_TYPE. Pawel, are you by any chance mixing kernel drivers of different sources? Best would be to provide the output of rpm -qf and modinfo for all related kernel modules: rpm -qf /lib/modules/$(uname -r)/kernel/drivers/media/video/ir-kbd-i2c.ko rpm -qf /lib/modules/$(uname -r)/kernel/drivers/media/common/ir-common.ko rpm -qf /lib/modules/$(uname -r)/kernel/drivers/media/video/saa7134/saa7134.ko modinfo ir-kbd-i2c modinfo ir-common modinfo saa7134 Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.31] ir-kbd-i2c oops.
Dnia 01-10-2009 o 12:06:09 Jean Delvare napisał(a): I'm not sure if it is the problem here, but it may be prudent to check that there's no mismatch between the module and the structure definitions being pulled in via "#include" (maybe by stopping gcc after the preprocessing with -E ). Thanks for the hint. As far as I can see, this change is new in kernel 2.6.32-rc1. In 2.6.31, which is where Pawel reported the issue, we still have IR_KEYTAB_TYPE. Pawel, are you by any chance mixing kernel drivers of different sources? everything is under control. i've two separated builds: - 2.6.31 from git with debugging patch. - vendor kernel from rpms. both kernels have separated initrd images for easy booting/testing. -- 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: [2.6.31] ir-kbd-i2c oops.
On Thu, 01 Oct 2009 12:17:20 +0200, Paweł Sikora wrote: > Dnia 01-10-2009 o 12:06:09 Jean Delvare napisał(a): > > >> I'm not sure if it is the problem here, but it may be prudent to check > >> that there's no mismatch between the module and the structure > >> definitions being pulled in via "#include" (maybe by stopping gcc after > >> the preprocessing with -E ). > > > > Thanks for the hint. As far as I can see, this change is new in kernel > > 2.6.32-rc1. In 2.6.31, which is where Pawel reported the issue, we > > still have IR_KEYTAB_TYPE. > > > > Pawel, are you by any chance mixing kernel drivers of different > > sources? > > everything is under control. i've two separated builds: > - 2.6.31 from git with debugging patch. > - vendor kernel from rpms. > both kernels have separated initrd images for easy booting/testing. And both have the problem you reported? -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.31] ir-kbd-i2c oops.
Dnia 01-10-2009 o 12:42:10 Jean Delvare napisał(a): On Thu, 01 Oct 2009 12:17:20 +0200, Paweł Sikora wrote: Dnia 01-10-2009 o 12:06:09 Jean Delvare napisał(a): >> I'm not sure if it is the problem here, but it may be prudent to check >> that there's no mismatch between the module and the structure >> definitions being pulled in via "#include" (maybe by stopping gcc after >> the preprocessing with -E ). > > Thanks for the hint. As far as I can see, this change is new in kernel > 2.6.32-rc1. In 2.6.31, which is where Pawel reported the issue, we > still have IR_KEYTAB_TYPE. > > Pawel, are you by any chance mixing kernel drivers of different > sources? everything is under control. i've two separated builds: - 2.6.31 from git with debugging patch. - vendor kernel from rpms. both kernels have separated initrd images for easy booting/testing. And both have the problem you reported? yes and this is expected because vendor kernel is based od 2.6.31. -- 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: [2.6.31] ir-kbd-i2c oops.
On Wed, 30 Sep 2009 19:52:07 -0400, Andy Walls wrote:
> On Wed, 2009-09-30 at 18:22 +0200, Paweł Sikora wrote:
> > [ 11.701267] ir_probe: addr=0x47
> > [ 11.701271] ir_probe: [before override] ir_codes=(null), name=SAA713x
> > remote, get_key=(null)
> > [ 11.701273] ir_probe: [after override] ir_codes=814edde0,
> > name=-q, get_key=81479204
> > [ 11.701276] ir_input_init: dev=880227177000, ir=880221186018,
> > ir_type=99, ir_codes=814edde0
> > [ 11.701278] ir_input_init: [i=0] Setting bit 1768059695 of dev->keybit
>
> 1768059695 = 0x6962732f = 'ibs/'
>
> That doesn't seem right for ir->ir_codes[0] ...
You're right. And name=-q doesn't seem right either. So it would seem
that saa7134-input is passing garbage over to ir_input_init()... or the
data is corrupted meanwhile.
Pawel, please give a try to the following patch. Please keep the debug
patches apply too, in case we need additional info.
drivers/media/video/saa7134/saa7134-input.c | 41 +--
drivers/media/video/saa7134/saa7134.h |3 +
2 files changed, 23 insertions(+), 21 deletions(-)
--- linux-2.6.31.orig/drivers/media/video/saa7134/saa7134-input.c
2009-09-10 10:08:22.0 +0200
+++ linux-2.6.31/drivers/media/video/saa7134/saa7134-input.c2009-10-01
13:38:38.0 +0200
@@ -685,7 +685,6 @@ void saa7134_input_fini(struct saa7134_d
void saa7134_probe_i2c_ir(struct saa7134_dev *dev)
{
struct i2c_board_info info;
- struct IR_i2c_init_data init_data;
const unsigned short addr_list[] = {
0x7a, 0x47, 0x71, 0x2d,
I2C_CLIENT_END
@@ -706,30 +705,30 @@ void saa7134_probe_i2c_ir(struct saa7134
}
memset(&info, 0, sizeof(struct i2c_board_info));
- memset(&init_data, 0, sizeof(struct IR_i2c_init_data));
+ memset(&dev->ir_init_data, 0, sizeof(struct IR_i2c_init_data));
strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
switch (dev->board) {
case SAA7134_BOARD_PINNACLE_PCTV_110i:
case SAA7134_BOARD_PINNACLE_PCTV_310i:
- init_data.name = "Pinnacle PCTV";
+ dev->ir_init_data.name = "Pinnacle PCTV";
if (pinnacle_remote == 0) {
- init_data.get_key = get_key_pinnacle_color;
- init_data.ir_codes = ir_codes_pinnacle_color;
+ dev->ir_init_data.get_key = get_key_pinnacle_color;
+ dev->ir_init_data.ir_codes = ir_codes_pinnacle_color;
} else {
- init_data.get_key = get_key_pinnacle_grey;
- init_data.ir_codes = ir_codes_pinnacle_grey;
+ dev->ir_init_data.get_key = get_key_pinnacle_grey;
+ dev->ir_init_data.ir_codes = ir_codes_pinnacle_grey;
}
break;
case SAA7134_BOARD_UPMOST_PURPLE_TV:
- init_data.name = "Purple TV";
- init_data.get_key = get_key_purpletv;
- init_data.ir_codes = ir_codes_purpletv;
+ dev->ir_init_data.name = "Purple TV";
+ dev->ir_init_data.get_key = get_key_purpletv;
+ dev->ir_init_data.ir_codes = ir_codes_purpletv;
break;
case SAA7134_BOARD_MSI_TVATANYWHERE_PLUS:
- init_data.name = "MSI t...@nywhere Plus";
- init_data.get_key = get_key_msi_tvanywhere_plus;
- init_data.ir_codes = ir_codes_msi_tvanywhere_plus;
+ dev->ir_init_data.name = "MSI t...@nywhere Plus";
+ dev->ir_init_data.get_key = get_key_msi_tvanywhere_plus;
+ dev->ir_init_data.ir_codes = ir_codes_msi_tvanywhere_plus;
info.addr = 0x30;
/* MSI t...@nywhere Plus controller doesn't seem to
respond to probes unless we read something from
@@ -741,9 +740,9 @@ void saa7134_probe_i2c_ir(struct saa7134
(1 == rc) ? "yes" : "no");
break;
case SAA7134_BOARD_HAUPPAUGE_HVR1110:
- init_data.name = "HVR 1110";
- init_data.get_key = get_key_hvr1110;
- init_data.ir_codes = ir_codes_hauppauge_new;
+ dev->ir_init_data.name = "HVR 1110";
+ dev->ir_init_data.get_key = get_key_hvr1110;
+ dev->ir_init_data.ir_codes = ir_codes_hauppauge_new;
break;
case SAA7134_BOARD_BEHOLD_607FM_MK3:
case SAA7134_BOARD_BEHOLD_607FM_MK5:
@@ -757,9 +756,9 @@ void saa7134_probe_i2c_ir(struct saa7134
case SAA7134_BOARD_BEHOLD_M63:
case SAA7134_BOARD_BEHOLD_M6_EXTRA:
case SAA7134_BOARD_BEHOLD_H6:
- init_data.name = "BeholdTV";
- init_data.get_key = get_key_beholdm6xx;
- init_data.ir_codes = ir_codes_behold;
+ dev->ir_init_data.name = "BeholdTV";
+ dev->ir_init_data.get
dqbuf in blocking mode
Hi all,
I was wondering how acceptable is to requeue a buffer in a dqbuf call
if the videbuf_dqbuf returns error?
See, here's our current omap3 camera dqbuf function code:
static int vidioc_dqbuf(struct file *file, void *fh, struct v4l2_buffer *b)
{
struct omap34xxcam_fh *ofh = fh;
int rval;
videobuf_dqbuf_again:
rval = videobuf_dqbuf(&ofh->vbq, b, file->f_flags & O_NONBLOCK);
/*
* This is a hack. We don't want to show -EIO to the user
* space. Requeue the buffer and try again if we're not doing
* this in non-blocking mode.
*/
if (rval == -EIO) {
videobuf_qbuf(&ofh->vbq, b);
if (!(file->f_flags & O_NONBLOCK))
goto videobuf_dqbuf_again;
/*
* We don't have a videobuf_buffer now --- maybe next
* time...
*/
rval = -EAGAIN;
}
return rval;
}
Is anything wrong with doing this? Or perhaphs something better to do?
Regards,
Sergio--
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: Race in gspca main or missing lock in stv06xx subdriver?
2009/9/15 Jean-Francois Moine : > On Mon, 14 Sep 2009 11:17:57 -0400 > James Blanford wrote: > >> Howdy folks, >> >> I have my old quickcam express webcam working, with HDCS1000 >> sensor, 046d:840. It's clearly throwing away every other frame. What >> seems to be happening is, while the last packet of the previous frame >> is being analyzed by the subdriver, the first packet of the next frame >> is assigned to the current frame buffer. By the time that packet is >> analysed and sent back to the main driver, it's frame buffer has been >> completely filled and marked as "DONE." The entire frame is then >> marked for "DISCARD." This does _not_ happen with all cams using this >> subdriver. >> >> Here's a little patch, supplied only to help illustrate the problem, >> that allows for the full, expected frame rate of the webcam. What it >> does is wait until the very last moment to assign a frame buffer to >> any packet, but the last. I also threw in a few printks so I can see >> where failure takes place without wading through a swamp of debug >> output. > [snip] >> It works, at least until there is any disruption to the stream, such >> as an exposure change, and then something gets out of sync and it >> starts throwing out every other frame again. It shows that the driver >> framework and USB bus is capable of handling the full frame rate. >> >> I'll keep looking for an actual solution, but there is a lot I don't >> understand. Any suggestions or ideas would be appreciated. Several >> questions come to mind. Why bother assigning a frame buffer with >> get_i_frame, before it's needed? What purpose has frame_wait, when >> it's not called until the frame is completed and the buffer is marked >> as "DONE." Why are there five, fr_i fr_q fr_o fr_queue index , buffer >> indexing counters? I'm sure I don't understand all the different >> tasks this driver has to handle and all the different hardware it has >> to deal with. But I would be surprised if my cam is the only one >> this is happening with. > > Hi James, > > I think you may have found a big problem, and this one should exist in > all drivers! > > As I understood, you say that the URB completion routine (isoc_irq) may > be run many times at the same time. > > With gspca, the problem is critical: the frame queue is managed without > any lock thanks to a circular buffer list (the pointers fr_i, fr_q and > fr_o). This mechanism works well when there are only one producer > (interrupt) and one consumer (application) (and to answer the question, > get_i_frame can be called anywere in the interrupt function because the > application is not running). Then, if there may be many producers... > > For other drivers, the problem remains: the image fragments could be > received out of order. > > How is this possible? Looking at some kernel documents, I found that > the URB completion routine is called from the bottom-half entity (thus, > not under hardware interrupt). A bottom-half may be a tasklet or a soft > irq. There may be only one active tasklet at a time, while there may be > many softirqs running (on the interrupt CPU). It seems that we are in > the last case, and I could not find any mean to change that. > > Then, to fix this problem, I see only one solution: have a private > tasklet to do the video streaming, as this is done for some bulk > transfer... > > Cheers. Hi Jean-Francois, Are you currently working on anything addressing this issue or do we need some further discussion? Best regards, Erik > > -- > 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 > -- 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: dqbuf in blocking mode
Hi Sergio,
On Thursday 01 October 2009 13:56:19 Aguirre Rodriguez, Sergio Alberto wrote:
> Hi all,
>
> I was wondering how acceptable is to requeue a buffer in a dqbuf call
> if the videbuf_dqbuf returns error?
>
> See, here's our current omap3 camera dqbuf function code:
>
> static int vidioc_dqbuf(struct file *file, void *fh, struct v4l2_buffer *b)
> {
> struct omap34xxcam_fh *ofh = fh;
> int rval;
>
> videobuf_dqbuf_again:
> rval = videobuf_dqbuf(&ofh->vbq, b, file->f_flags & O_NONBLOCK);
>
> /*
>* This is a hack. We don't want to show -EIO to the user
>* space. Requeue the buffer and try again if we're not doing
>* this in non-blocking mode.
>*/
If I'm not mistaken videobuf_dqbuf() only returns -EIO if the buffer state is
VIDEOBUF_ERROR. This is the direct result of either
- videobuf_queue_cancel() being called, or
- the device driver marking the buffer as erroneous because of a (possibly
transient) device error
In the first case VIDIOC_DQBUF should in my opinion return with an error. In
the second case things are not that clear. A transient error could be hidden
from the application, or, if returned to the application through -EIO,
shouldn't be treated as a fatal error. Non-transient errors should result in
the application stopping video streaming.
Unfortunately there V4L2 API doesn't offer a way to find out if the error is
transient or fatal:
"EIOVIDIOC_DQBUF failed due to an internal error. Can also indicate
temporary problems like signal loss. Note the driver might dequeue an (empty)
buffer despite returning an error, or even stop capturing."
-EIO can mean many different things that need to be handled differently by
applications. I especially hate the "the driver might dequeue an (empty)
buffer despite returning an error".
Drivers should always or never dequeue a buffer when an error occurs, not
sometimes. The problem is for the application to recognize the difference
between a transient and a fatal error in a backward-compatible way.
> if (rval == -EIO) {
> videobuf_qbuf(&ofh->vbq, b);
> if (!(file->f_flags & O_NONBLOCK))
> goto videobuf_dqbuf_again;
> /*
>* We don't have a videobuf_buffer now --- maybe next
>* time...
>*/
> rval = -EAGAIN;
> }
>
> return rval;
> }
>
> Is anything wrong with doing this? Or perhaphs something better to do?
--
Regards,
Laurent Pinchart
--
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: BUG: cx23885_video_register() uninitialized value passed to v4l2_subdev_call()
On 10/1/09 3:06 AM, David T. L. Wong wrote: Hi all, A potential bug is found in cx23885_video_register(). A tuner_setup struct is passed to v4l2_subdev_call(), but that struct is not fully initialized, especially for tuner_callback member, and eventually tuner_s_type_addr() copy that wrong pointer. It would particularly cause seg. fault for xc5000 tuner for analog frontend when it calls fe->callback at xc5000_TunerReset(). Thanks for raising this. I also discovered this last Saturday. I have a patch for this which I expect to merge shortly. Regards, Steve -- 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
status of google group created for working on Media controller?
Hi, In the plumbers conference, a Google group was setup to share ideas/patches during development of media controller framework. But I have not any email regarding the same. Could someone tell me what is the current status of this group and add me to the group based on my below information? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.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: status of google group created for working on Media controller?
Hi Murali, > -Original Message- > From: linux-media-ow...@vger.kernel.org > [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of > Karicheri, Muralidharan > Sent: Thursday, October 01, 2009 8:46 AM > To: linux-media@vger.kernel.org > Subject: status of google group created for working on Media > controller? > > Hi, > > In the plumbers conference, a Google group was setup to share > ideas/patches during development of media controller > framework. But I have not any email regarding the same. Could > someone tell me what is the current status of this group and > add me to the group based on my below information? Guru should add you to the group. Nothing has been yet discussed there though. Regards, Sergio > > Murali Karicheri > Software Design Engineer > Texas Instruments Inc. > Germantown, MD 20874 > email: m-kariche...@ti.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 > > -- 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: status of google group created for working on Media controller?
Sergio, Thanks.. Guru, Could you add me to the group? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com >-Original Message- >From: Aguirre Rodriguez, Sergio Alberto >Sent: Thursday, October 01, 2009 11:10 AM >To: Karicheri, Muralidharan; linux-media@vger.kernel.org >Cc: Nagendra, Gururaj >Subject: RE: status of google group created for working on Media >controller? > >Hi Murali, > >> -Original Message- >> From: linux-media-ow...@vger.kernel.org >> [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of >> Karicheri, Muralidharan >> Sent: Thursday, October 01, 2009 8:46 AM >> To: linux-media@vger.kernel.org >> Subject: status of google group created for working on Media >> controller? >> >> Hi, >> >> In the plumbers conference, a Google group was setup to share >> ideas/patches during development of media controller >> framework. But I have not any email regarding the same. Could >> someone tell me what is the current status of this group and >> add me to the group based on my below information? > >Guru should add you to the group. > >Nothing has been yet discussed there though. > >Regards, >Sergio >> >> Murali Karicheri >> Software Design Engineer >> Texas Instruments Inc. >> Germantown, MD 20874 >> email: m-kariche...@ti.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 >> >> -- 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: status of google group created for working on Media controller?
Murali, Please send a subscribe request to linux...@googlegroups.com Let's make progress from where we left off at Linux Plumbers Conf using MC mailing list. Thanks, - Guru -Original Message- From: Aguirre Rodriguez, Sergio Alberto [mailto:saagui...@ti.com] Sent: Thursday, October 01, 2009 8:10 AM To: Karicheri, Muralidharan; linux-media@vger.kernel.org Cc: Nagendra, Gururaj Subject: RE: status of google group created for working on Media controller? Hi Murali, > -Original Message- > From: linux-media-ow...@vger.kernel.org > [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of > Karicheri, Muralidharan > Sent: Thursday, October 01, 2009 8:46 AM > To: linux-media@vger.kernel.org > Subject: status of google group created for working on Media > controller? > > Hi, > > In the plumbers conference, a Google group was setup to share > ideas/patches during development of media controller > framework. But I have not any email regarding the same. Could > someone tell me what is the current status of this group and > add me to the group based on my below information? Guru should add you to the group. Nothing has been yet discussed there though. Regards, Sergio > > Murali Karicheri > Software Design Engineer > Texas Instruments Inc. > Germantown, MD 20874 > email: m-kariche...@ti.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 > > -- 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: status of google group created for working on Media controller?
Hi, On Thu, Oct 1, 2009 at 6:13 PM, Nagendra, Gururaj wrote: > Murali, > Please send a subscribe request to linux...@googlegroups.com > Let's make progress from where we left off at Linux Plumbers Conf using MC > mailing list. > I would like to join this one too, what is needed for the subscription email? The last one I sent just returned. Best Regards, Markus -- 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: dqbuf in blocking mode
Hi Laurent,
> -Original Message-
> From: linux-media-ow...@vger.kernel.org
> [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of
> Laurent Pinchart
> Sent: Thursday, October 01, 2009 8:34 AM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: Linux Media Mailing List
> Subject: Re: dqbuf in blocking mode
>
> Hi Sergio,
>
> On Thursday 01 October 2009 13:56:19 Aguirre Rodriguez,
> Sergio Alberto wrote:
> > Hi all,
> >
> > I was wondering how acceptable is to requeue a buffer in a
> dqbuf call
> > if the videbuf_dqbuf returns error?
> >
> > See, here's our current omap3 camera dqbuf function code:
> >
> > static int vidioc_dqbuf(struct file *file, void *fh, struct
> v4l2_buffer *b)
> > {
> > struct omap34xxcam_fh *ofh = fh;
> > int rval;
> >
> > videobuf_dqbuf_again:
> > rval = videobuf_dqbuf(&ofh->vbq, b, file->f_flags & O_NONBLOCK);
> >
> > /*
> > * This is a hack. We don't want to show -EIO to the user
> > * space. Requeue the buffer and try again if we're not doing
> > * this in non-blocking mode.
> > */
>
> If I'm not mistaken videobuf_dqbuf() only returns -EIO if the
> buffer state is
> VIDEOBUF_ERROR. This is the direct result of either
>
> - videobuf_queue_cancel() being called, or
> - the device driver marking the buffer as erroneous because
> of a (possibly
> transient) device error
>
> In the first case VIDIOC_DQBUF should in my opinion return
> with an error. In
> the second case things are not that clear. A transient error
> could be hidden
> from the application, or, if returned to the application
> through -EIO,
> shouldn't be treated as a fatal error. Non-transient errors
> should result in
> the application stopping video streaming.
>
> Unfortunately there V4L2 API doesn't offer a way to find out
> if the error is
> transient or fatal:
>
> "EIO VIDIOC_DQBUF failed due to an internal error.
> Can also indicate
> temporary problems like signal loss. Note the driver might
> dequeue an (empty)
> buffer despite returning an error, or even stop capturing."
>
> -EIO can mean many different things that need to be handled
> differently by
> applications. I especially hate the "the driver might dequeue
> an (empty)
> buffer despite returning an error".
>
> Drivers should always or never dequeue a buffer when an error
> occurs, not
> sometimes. The problem is for the application to recognize
> the difference
> between a transient and a fatal error in a backward-compatible way.
I think there are 2 different problems we are talking about here.
Problem #1: Incomplete DQBUF communication from driver to userspace.
(which is what you're talking about)
Problem #2: Should an internal requeue of a failed buffer be allowed?
About #1, I agree with all your points.
But about #2, I'm not sure what's your stand on it... Most probably you're
thinking that it is acceptable to lock the call _just_ if its a transient error,
therefore depending on solving problem #1 first.
What are your toughts on this?
Regards,
Sergio
>
> > if (rval == -EIO) {
> > videobuf_qbuf(&ofh->vbq, b);
> > if (!(file->f_flags & O_NONBLOCK))
> > goto videobuf_dqbuf_again;
> > /*
> > * We don't have a videobuf_buffer now --- maybe next
> > * time...
> > */
> > rval = -EAGAIN;
> > }
> >
> > return rval;
> > }
> >
> > Is anything wrong with doing this? Or perhaphs something
> better to do?
>
> --
> Regards,
>
> Laurent Pinchart
> --
> 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: status of google group created for working on Media controller?
Gururaj, Can you reply with a sample email to do the subscription? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com >-Original Message- >From: Nagendra, Gururaj [mailto:gururaj.nagen...@intel.com] >Sent: Thursday, October 01, 2009 12:13 PM >To: Aguirre Rodriguez, Sergio Alberto; Karicheri, Muralidharan; linux- >me...@vger.kernel.org >Subject: RE: status of google group created for working on Media >controller? > >Murali, >Please send a subscribe request to linux...@googlegroups.com >Let's make progress from where we left off at Linux Plumbers Conf using MC >mailing list. > >Thanks, >- Guru > >-Original Message- >From: Aguirre Rodriguez, Sergio Alberto [mailto:saagui...@ti.com] >Sent: Thursday, October 01, 2009 8:10 AM >To: Karicheri, Muralidharan; linux-media@vger.kernel.org >Cc: Nagendra, Gururaj >Subject: RE: status of google group created for working on Media >controller? > >Hi Murali, > >> -Original Message- >> From: linux-media-ow...@vger.kernel.org >> [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of >> Karicheri, Muralidharan >> Sent: Thursday, October 01, 2009 8:46 AM >> To: linux-media@vger.kernel.org >> Subject: status of google group created for working on Media >> controller? >> >> Hi, >> >> In the plumbers conference, a Google group was setup to share >> ideas/patches during development of media controller >> framework. But I have not any email regarding the same. Could >> someone tell me what is the current status of this group and >> add me to the group based on my below information? > >Guru should add you to the group. > >Nothing has been yet discussed there though. > >Regards, >Sergio >> >> Murali Karicheri >> Software Design Engineer >> Texas Instruments Inc. >> Germantown, MD 20874 >> email: m-kariche...@ti.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 >> >> -- 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
Osprey 230
Hi, I'm testing an Osprey 230 but I have problems with Audio acquisition. with the standard bttv driver the audio is flickering and seems at wrong sample rate (the voice of mickey mouse...) , after the compile v4l the sound is totally mute. I tried to compile the source from http://linuxtv.org/hg/~mchehab/osprey and from http://linuxtv.org/hg/~tap/osprey but I have some problems: from ~tap repo I have this errors: li...@lidia-test:~/osprey$ make make -C /home/lidia/osprey/v4l make[1]: Entering directory `/home/lidia/osprey/v4l' creating symbolic links... Kernel build directory is /lib/modules/2.6.27-7-generic/build make -C /lib/modules/2.6.27-7-generic/build SUBDIRS=/home/lidia/osprey/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.27-7-generic' CC [M] /home/lidia/osprey/v4l/bttv-driver.o In file included from /home/lidia/osprey/v4l/bttv-driver.c:40: /home/lidia/osprey/v4l/bttvp.h:94:1: warning: "clamp" redefined In file included from include/asm/system.h:10, from include/asm/processor.h:17, from include/linux/prefetch.h:14, from include/linux/list.h:6, from include/linux/module.h:9, from /home/lidia/osprey/v4l/bttv-driver.c:32: include/linux/kernel.h:376:1: warning: this is the location of the previous definition /home/lidia/osprey/v4l/bttv-driver.c: In function 'show_card': /home/lidia/osprey/v4l/bttv-driver.c:177: error: incompatible type for argument 1 of 'dev_get_drvdata' /home/lidia/osprey/v4l/bttv-driver.c: In function 'bttv_switch_overlay': /home/lidia/osprey/v4l/bttv-driver.c:1777: error: 'STATE_DONE' undeclared (first use in this function) /home/lidia/osprey/v4l/bttv-driver.c:1777: error: (Each undeclared identifier is reported only once /home/lidia/osprey/v4l/bttv-driver.c:1777: error: for each function it appears in.) /home/lidia/osprey/v4l/bttv-driver.c: In function 'bttv_prepare_buffer': /home/lidia/osprey/v4l/bttv-driver.c:1888: error: 'STATE_NEEDS_INIT' undeclared (first use in this function) /home/lidia/osprey/v4l/bttv-driver.c:1898: error: 'STATE_PREPARED' undeclared (first use in this function) /home/lidia/osprey/v4l/bttv-driver.c: In function 'buffer_queue': /home/lidia/osprey/v4l/bttv-driver.c:1937: error: 'STATE_QUEUED' undeclared (first use in this function) /home/lidia/osprey/v4l/bttv-driver.c: In function 'bttv_common_ioctls': /home/lidia/osprey/v4l/bttv-driver.c:2115: error: implicit declaration of function 'v4l2_video_std_construct' /home/lidia/osprey/v4l/bttv-driver.c: In function 'setup_window': /home/lidia/osprey/v4l/bttv-driver.c:2610: error: 'struct videobuf_queue' has no member named 'lock' /home/lidia/osprey/v4l/bttv-driver.c:2627: error: implicit declaration of function 'videobuf_pci_alloc' /home/lidia/osprey/v4l/bttv-driver.c:2627: warning: assignment makes pointer from integer without a cast /home/lidia/osprey/v4l/bttv-driver.c:2632: error: 'struct videobuf_queue' has no member named 'lock' /home/lidia/osprey/v4l/bttv-driver.c: In function 'bttv_s_fmt': /home/lidia/osprey/v4l/bttv-driver.c:2813: error: 'struct videobuf_queue' has no member named 'lock' /home/lidia/osprey/v4l/bttv-driver.c:2822: error: 'struct videobuf_queue' has no member named 'lock' /home/lidia/osprey/v4l/bttv-driver.c: In function 'bttv_do_ioctl': /home/lidia/osprey/v4l/bttv-driver.c:2851: error: implicit declaration of function 'v4l_print_ioctl' /home/lidia/osprey/v4l/bttv-driver.c:2924: error: 'struct videobuf_queue' has no member named 'lock' /home/lidia/osprey/v4l/bttv-driver.c:2951: error: 'struct videobuf_queue' has no member named 'lock' /home/lidia/osprey/v4l/bttv-driver.c:3025: error: 'struct videobuf_queue' has no member named 'lock' /home/lidia/osprey/v4l/bttv-driver.c:3063: error: 'struct videobuf_queue' has no member named 'lock' /home/lidia/osprey/v4l/bttv-driver.c:3086: error: 'struct videobuf_queue' has no member named 'lock' /home/lidia/osprey/v4l/bttv-driver.c:3089: warning: assignment makes pointer from integer without a cast /home/lidia/osprey/v4l/bttv-driver.c:3098: error: 'struct videobuf_queue' has no member named 'lock' /home/lidia/osprey/v4l/bttv-driver.c:3107: error: 'struct videobuf_queue' has no member named 'lock' /home/lidia/osprey/v4l/bttv-driver.c:3119: error: 'struct videobuf_queue' has no member named 'lock' /home/lidia/osprey/v4l/bttv-driver.c:3137: error: 'struct videobuf_queue' has no member named 'lock' /home/lidia/osprey/v4l/bttv-driver.c:3144: error: 'STATE_QUEUED' undeclared (first use in this function) /home/lidia/osprey/v4l/bttv-driver.c:3145: error: 'STATE_ACTIVE' undeclared (first use in this function) /home/lidia/osprey/v4l/bttv-driver.c:3162: error: 'struct videobuf_queue' has no member named 'lock' /home/lidia/osprey/v4l/bttv-driver.c:3173: error: 'struct videobuf_queue' has no member named 'lock' /home/lidia/osprey/v4l/bttv-driver.c:3182: error: 'STATE_ERROR' undeclared (first use in this function) /home/lidia/osprey/v4l/bttv-driver.c
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Oct 1 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13044:6b7617d4a0be gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29.1-armv5-ixp: ERRORS linux-2.6.30-armv5-ixp: ERRORS linux-2.6.31-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29.1-powerpc64: ERRORS linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS sparse (linux-2.6.31): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to make my device work with linux?
On Thu, Oct 1, 2009 at 2:38 PM, Wellington Terumi Uemura wrote: > Hello everyone! > > I've a ISDB-Tb device from TBS-Tech that doesn't work with linux yet, > it uses this chip sets: > http://www.linuxtv.org/wiki/index.php/TBS_USB_ISDB-T_Stick > > Tuner - NXP TDA18271HD > Demodulator - Fujitsu_MB86A16 > USB interface - Cypress Semiconductor EZ-USB FX2LP CY7C68013A > Other - Shenzen First-Rank Technology T24C02A EEPROM 256 x 8 (2K bits) > > Using information available on the internet I've dumped the required > firmware from the driver files using dd: > http://www.4shared.com/file/136823880/6c2d23d9/TBS-Techfw.html > > As the linuxtv wiki shows, linux detect the device but to make it work > I think is a hole different issue because is not just place the > firmware in to the right place, the kernel have to know what to do > with it and how to interface with the device. I was playing with > fx2pipe trying to load the firmware and program returns that there is > no device connected to any USB ports and I don't know if this is the > right tool to play with. > > I hope to find some light on this issue. > > Thank you. For a first step, I'd recommend to read up on using USB sniffers to capture the windows driver traffic. The drivers for the FX2 parts tend to be relatively easy to sniff. We already have a linux driver for the TDA18271, I *think* there is a driver available for that Fujitsu demod but it's not in the v4l-dvb master repository. Support for ISDB-T was recently added to dvb-core, so many of the major parts are available... Unfortunately, to bring up the device driver to completion probably wont be as easy as you might hope, but the best place to start is a sniffed usb driver log. It might actually be an easier task to simply find a device based on the dib8000 that Patrick Boettcher recently added ISDB-T support for. Other than that, I'm not sure if anybody here has the expertise to help you support your hardware without having a stick of their own to play with as well. Good Luck, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Aver A700 : "frequency out of range"
Hello, I have: - Debian Lenny (dual booted with Windows XP) - Linux kernel 2.6.30 (from backports.org) - An AverMedia DVB-S Pro A700 card (not hybrid) - a satellite dish set to Astra 28.2E (in Ireland) With Windows XP I can view TV all right. With Linux, I tried tuning with me-tv and scan, in both cases using files for Astra 28.2E. Both cause a similar failure - can not set frequency. The most coherent messages are in dmesg: [ 96.950097] DVB: adapter 0 frontend 0 frequency 11709400 out of range (95..215) (and lots of this - for every attempt to set the frequency). Here are the lines from dmesg during boot up time, relevant for the card: [ 10.363711] Linux video capture interface: v2.00 [ 10.413266] saa7130/34: v4l2 driver version 0.2.15 loaded [ 10.41] saa7134 :00:0a.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 [ 10.413344] saa7133[0]: found at :00:0a.0, rev: 209, irq: 19, latency: 32, mmio: 0xeb024000 [ 10.413356] saa7133[0]: subsystem: 1461:a7a1, board: Avermedia DVB-S Pro A700 [card=140,autodetected] [ 10.413388] saa7133[0]: board init: gpio is 202f600 [ 10.413402] IRQ 19/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 10.564525] saa7133[0]: i2c eeprom 00: 61 14 a1 a7 ff ff ff ff ff ff ff ff ff ff ff ff [ 10.564547] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.564568] saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.564588] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.564608] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.564627] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.564646] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.564665] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.564684] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.564703] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.564722] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.564741] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.564760] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.564780] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.564799] saa7133[0]: i2c eeprom e0: 00 01 81 b0 3e 3f ff ff ff ff ff ff ff ff ff ff [ 10.564818] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.580356] saa7133[0]: registered device video0 [v4l2] [ 10.580400] saa7133[0]: registered device vbi0 [ 10.791137] dvb_init() allocating 1 frontend [ 10.938187] Intel ICH :00:02.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18 [ 11.012527] zl10036_attach: tuner initialization (Zarlink ZL10036 addr=0x60) ok [ 11.012534] DVB: registering new adapter (saa7133[0]) [ 11.012540] DVB: registering adapter 0 frontend 0 (Zarlink ZL10313 DVB-S)... [ 11.213808] saa7134 ALSA driver for DMA sound loaded [ 11.213825] IRQ 19/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 11.213859] saa7133[0]/alsa: saa7133[0] at 0xeb024000 irq 19 registered as card -1 What do I need to do in orer to get the card to work under Linux? (I can apply patches/build kernel or libraries if needed). -- Yours, Mikhail Ramendik -- 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: How to make my device work with linux?
I was looking around to find that there is a driver for that Fujitsu MB86A16 inside the "Linux Mantis Driver" project, Fujitsu MB86A16 DVB-S/DSS DC Receiver driver made by Manu Abraham http://www.verbraak.org/wiki/index.php/Linux_Mantis_driver. I've done a few tests with usbsnoop and other tools but USB sniffer doesn't see any valid command, jut a bunch of bytes that makes no sense: http://www.isely.net/pvrusb2/firmware.html#FX2 I will try my luck compiling that Fujitsu driver, but my best guess is that without a proper I/O from that FX2 it will end up with nothing at all. Thank you. > For a first step, I'd recommend to read up on using USB sniffers to > capture the windows driver traffic. The drivers for the FX2 parts > tend to be relatively easy to sniff. We already have a linux driver > for the TDA18271, I *think* there is a driver available for that > Fujitsu demod but it's not in the v4l-dvb master repository. [snip] -- 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: How to make my device work with linux?
On Thu, 1 Oct 2009, Wellington Terumi Uemura wrote: > I was looking around to find that there is a driver for that Fujitsu > MB86A16 inside the "Linux Mantis Driver" project, Fujitsu MB86A16 > DVB-S/DSS DC Receiver driver made by Manu Abraham > http://www.verbraak.org/wiki/index.php/Linux_Mantis_driver. > > I've done a few tests with usbsnoop and other tools but USB sniffer > doesn't see any valid command, jut a bunch of bytes that makes no > sense: > http://www.isely.net/pvrusb2/firmware.html#FX2 What you've pointed at here is a page that describes using a trick with the pvrusb2 driver to suck an image of the FX2 firmware out of the FX2 processor itself. That won't work in your case however since it requires that the pvrusb2 driver already be talking to the chip. The procedure documented at that link is really about firmware extraction not reverse-engineering the data link protocol between the FX2 and the host. > > I will try my luck compiling that Fujitsu driver, but my best guess is > that without a proper I/O from that FX2 it will end up with nothing at > all. It's that data link protocol that you need to understand. Please realize that the FX2 is "just" an 8051 microcontroller which happens to have a fairly interesting USB device interface resident on the same silicon. Beyond that, the chip's behavior is really up to whatever the firmware does. For pvrusb2-driven devices that firmware's behavior is pretty well understood. That driver also benefits from the fact that essentially all USB hosted analog (and some hybrid) capture cards with an mpeg encoder and an FX2 all are derivations from a reference design by a single vendor. That reference design included "reference firmware", which each manufacturer of course tweaked a bit. For that reason, all those different devices tend to implement a similar enough data link protocol that the pvrusb2 driver can handle them all with the same implementation. The problem is, we don't know if any of that is true for your device. You are dealing with a digital-only capture device so it can't be based on that same reference design. It is entirely sensible that the FX2 firmware was set up in that case with similar requirements in mind so the result *might* be similar in behavior. But it really isn't known. So when you scan documentation for other drivers (e.g. pvrusb2) you must really look at it all with a rather large helping of scepticism. Mike Krufky mentions a driver for the TDA18271 and he's right. There is one - because the pvrusb2 driver also relies on that when driving an HVR-1950 capture device which happens to use that same part. But that isn't "the" driver you need. What you need is a bridge driver that can implement the host side of the data link protocol implemented by your device's FX2. That is what the pvrusb2 driver does for the capture devices it handles. With the proper bridge driver set up, then the TDA18271 sub-device driver can ride over that data link to establish communications with its hardware in the device. THEN you'll be on the way to having something working. I know that none of the about is the answer you're looking for. But perhaps it will lead you in the right direction. It is entirely possible that there is another bridge driver out there which can handle this part, but I can't help you there. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: How to make my device work with linux?
It's not the answer that I was looking for but looks like the thing is much more complex than just compile and run drivers, this gives me another perspective, like a dead end. Thank you Mike. 2009/10/1 Mike Isely : > I know that none of the about is the answer you're looking for. But > perhaps it will lead you in the right direction. It is entirely > possible that there is another bridge driver out there which can handle > this part, but I can't help you there. -- 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: How to make my device work with linux?
On Thu, Oct 1, 2009 at 6:03 PM, Wellington Terumi Uemura wrote: > It's not the answer that I was looking for but looks like the thing is > much more complex than just compile and run drivers, this gives me > another perspective, like a dead end. > > Thank you Mike. Well, it's certainly possible to get it to work if you're willing to make the investment. It's just one of those situations where you realize quickly that you're going to have to be prepared to do *way* more work than just adding a new board profile. Just because there are drivers for the chips on your device doesn't mean that it is trivial to get working. Cheers, Devin -- Devin J. Heitmueller - 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: How to make my device work with linux?
On Thu, 1 Oct 2009, Devin Heitmueller wrote: > On Thu, Oct 1, 2009 at 6:03 PM, Wellington Terumi Uemura > wrote: > > It's not the answer that I was looking for but looks like the thing is > > much more complex than just compile and run drivers, this gives me > > another perspective, like a dead end. > > > > Thank you Mike. > > Well, it's certainly possible to get it to work if you're willing to > make the investment. It's just one of those situations where you > realize quickly that you're going to have to be prepared to do *way* > more work than just adding a new board profile. Just because there > are drivers for the chips on your device doesn't mean that it is > trivial to get working. > > Cheers, > > Devin > And actually I wasn't intending on totally discouraging you either. But you do need to see the perspective of what you're trying to do otherwise you may just get frustrated. Things aren't hopeless. The cxusb module in DVB might be something you should look at. I guess it depends on how deep you wish to dive here. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: How to make my device work with linux?
I'm up for the challenge, I just need the right tools (software) and information so I can report valid information back to a developer to finish it. My real intention was to do something like that, I know is impossible to a developer to program something without the device in hands and I'm willing to help out the best way I can. Doing that I also help the community not just by asking something, but to give something back. If the price to do that is to stay up acquiring data, info, for the benefit of the community, I go for it. I know that things are not simple as that, device drivers need to know how to communicate and how to deal with the information that it get back. What is the price that I have to pay? 2009/10/1 Devin Heitmueller : > Well, it's certainly possible to get it to work if you're willing to > make the investment. It's just one of those situations where you > realize quickly that you're going to have to be prepared to do *way* > more work than just adding a new board profile. Just because there > are drivers for the chips on your device doesn't mean that it is > trivial to get working. > > Cheers, > > Devin -- 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: How to make my device work with linux?
To tell you the truth, I think is a bad habit that come from MAME emulator, you know. You knew that the driver is there and you just need to add the right information to get it working, now I see that I was wrong :D I will take a look inside the cxusb and see what I can pull off from that. Thank you Mike! 2009/10/1 Mike Isely : > And actually I wasn't intending on totally discouraging you either. > But you do need to see the perspective of what you're trying to do > otherwise you may just get frustrated. > > Things aren't hopeless. The cxusb module in DVB might be something you > should look at. I guess it depends on how deep you wish to dive here. -- 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: Aver A700 : "frequency out of range"
I found that while these lines are generated by me-tv and possibly dvbscan, scan actually works. And the results of scan are accepted as channels.conf by me-tv , after an iconv conversion to utf-8 (whatever). And me-tv WORKS! So, the end result: these messages somehow mean "use scan". Google did not help - so I hope it will help the next person hitting this problem as they will find this in the archives :) Yours, Mikhail Ramendik 2009/10/1 Mikhail Ramendik : > Hello, > > I have: > > - Debian Lenny (dual booted with Windows XP) > - Linux kernel 2.6.30 (from backports.org) > - An AverMedia DVB-S Pro A700 card (not hybrid) > - a satellite dish set to Astra 28.2E (in Ireland) > > With Windows XP I can view TV all right. > > With Linux, I tried tuning with me-tv and scan, in both cases using > files for Astra 28.2E. Both cause a similar failure - can not set > frequency. The most coherent messages are in dmesg: > > [ 96.950097] DVB: adapter 0 frontend 0 frequency 11709400 out of > range (95..215) > > (and lots of this - for every attempt to set the frequency). > > Here are the lines from dmesg during boot up time, relevant for the card: > > [ 10.363711] Linux video capture interface: v2.00 > [ 10.413266] saa7130/34: v4l2 driver version 0.2.15 loaded > [ 10.41] saa7134 :00:0a.0: PCI INT A -> GSI 19 (level, low) -> IRQ > 19 > [ 10.413344] saa7133[0]: found at :00:0a.0, rev: 209, irq: 19, > latency: 32, mmio: 0xeb024000 > [ 10.413356] saa7133[0]: subsystem: 1461:a7a1, board: Avermedia > DVB-S Pro A700 [card=140,autodetected] > [ 10.413388] saa7133[0]: board init: gpio is 202f600 > [ 10.413402] IRQ 19/saa7133[0]: IRQF_DISABLED is not guaranteed on shared > IRQs > [ 10.564525] saa7133[0]: i2c eeprom 00: 61 14 a1 a7 ff ff ff ff ff > ff ff ff ff ff ff ff > [ 10.564547] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff > [ 10.564568] saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff > [ 10.564588] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff > [ 10.564608] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff > [ 10.564627] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff > [ 10.564646] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff > [ 10.564665] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff > [ 10.564684] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff > [ 10.564703] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff > [ 10.564722] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff > [ 10.564741] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff > [ 10.564760] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff > [ 10.564780] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff > [ 10.564799] saa7133[0]: i2c eeprom e0: 00 01 81 b0 3e 3f ff ff ff > ff ff ff ff ff ff ff > [ 10.564818] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff > [ 10.580356] saa7133[0]: registered device video0 [v4l2] > [ 10.580400] saa7133[0]: registered device vbi0 > [ 10.791137] dvb_init() allocating 1 frontend > [ 10.938187] Intel ICH :00:02.7: PCI INT C -> GSI 18 (level, > low) -> IRQ 18 > [ 11.012527] zl10036_attach: tuner initialization (Zarlink ZL10036 > addr=0x60) ok > [ 11.012534] DVB: registering new adapter (saa7133[0]) > [ 11.012540] DVB: registering adapter 0 frontend 0 (Zarlink ZL10313 > DVB-S)... > [ 11.213808] saa7134 ALSA driver for DMA sound loaded > [ 11.213825] IRQ 19/saa7133[0]: IRQF_DISABLED is not guaranteed on shared > IRQs > [ 11.213859] saa7133[0]/alsa: saa7133[0] at 0xeb024000 irq 19 > registered as card -1 > > What do I need to do in orer to get the card to work under Linux? > > (I can apply patches/build kernel or libraries if needed). > > -- > Yours, Mikhail Ramendik > -- Yours, Mikhail Ramendik -- 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
[126/136] saa7134: ir-kbd-i2c init data needs a persistent object
2.6.31-stable review patch. If anyone has any objections, please let us know.
--
From: Brian Rogers
commit 7aedd5ec87686c557d48584d69ad880c11a0984d upstream.
Tested on MSI t...@nywhere Plus.
Original commit message:
ir-kbd-i2c's ir_probe() function can be called much later (i.e. at
ir-kbd-i2c module load), than the lifetime of a struct IR_i2c_init_data
allocated off of the stack in cx18_i2c_new_ir() at registration time.
Make sure we pass a pointer to a persistent IR_i2c_init_data object at
i2c registration time.
Thanks to Brian Rogers, Dustin Mitchell, Andy Walls and Jean Delvare to
rise this question.
Before this patch, if ir-kbd-i2c were probed after SAA7134, trash data
were used.
Compile tested only, but the patch is identical to em28xx one. So, it
should work properly.
Original-patch-by: Mauro Carvalho Chehab
Signed-off-by: Mauro Carvalho Chehab
[br...@xyzw.org: backported for 2.6.31]
Signed-off-by: Brian Rogers
Signed-off-by: Greg Kroah-Hartman
---
drivers/media/video/saa7134/saa7134-input.c | 56 +---
drivers/media/video/saa7134/saa7134.h |4 ++
2 files changed, 31 insertions(+), 29 deletions(-)
--- a/drivers/media/video/saa7134/saa7134.h
+++ b/drivers/media/video/saa7134/saa7134.h
@@ -584,6 +584,10 @@ struct saa7134_dev {
intnosignal;
unsigned int insuspend;
+ /* I2C keyboard data */
+ struct i2c_board_info info;
+ struct IR_i2c_init_datainit_data;
+
/* SAA7134_MPEG_* */
struct saa7134_ts ts;
struct saa7134_dmaqueuets_q;
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -684,8 +684,6 @@ void saa7134_input_fini(struct saa7134_d
void saa7134_probe_i2c_ir(struct saa7134_dev *dev)
{
- struct i2c_board_info info;
- struct IR_i2c_init_data init_data;
const unsigned short addr_list[] = {
0x7a, 0x47, 0x71, 0x2d,
I2C_CLIENT_END
@@ -705,32 +703,32 @@ void saa7134_probe_i2c_ir(struct saa7134
return;
}
- memset(&info, 0, sizeof(struct i2c_board_info));
- memset(&init_data, 0, sizeof(struct IR_i2c_init_data));
- strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
+ memset(&dev->info, 0, sizeof(dev->info));
+ memset(&dev->init_data, 0, sizeof(dev->init_data));
+ strlcpy(dev->info.type, "ir_video", I2C_NAME_SIZE);
switch (dev->board) {
case SAA7134_BOARD_PINNACLE_PCTV_110i:
case SAA7134_BOARD_PINNACLE_PCTV_310i:
- init_data.name = "Pinnacle PCTV";
+ dev->init_data.name = "Pinnacle PCTV";
if (pinnacle_remote == 0) {
- init_data.get_key = get_key_pinnacle_color;
- init_data.ir_codes = ir_codes_pinnacle_color;
+ dev->init_data.get_key = get_key_pinnacle_color;
+ dev->init_data.ir_codes = ir_codes_pinnacle_color;
} else {
- init_data.get_key = get_key_pinnacle_grey;
- init_data.ir_codes = ir_codes_pinnacle_grey;
+ dev->init_data.get_key = get_key_pinnacle_grey;
+ dev->init_data.ir_codes = ir_codes_pinnacle_grey;
}
break;
case SAA7134_BOARD_UPMOST_PURPLE_TV:
- init_data.name = "Purple TV";
- init_data.get_key = get_key_purpletv;
- init_data.ir_codes = ir_codes_purpletv;
+ dev->init_data.name = "Purple TV";
+ dev->init_data.get_key = get_key_purpletv;
+ dev->init_data.ir_codes = ir_codes_purpletv;
break;
case SAA7134_BOARD_MSI_TVATANYWHERE_PLUS:
- init_data.name = "MSI t...@nywhere Plus";
- init_data.get_key = get_key_msi_tvanywhere_plus;
- init_data.ir_codes = ir_codes_msi_tvanywhere_plus;
- info.addr = 0x30;
+ dev->init_data.name = "MSI t...@nywhere Plus";
+ dev->init_data.get_key = get_key_msi_tvanywhere_plus;
+ dev->init_data.ir_codes = ir_codes_msi_tvanywhere_plus;
+ dev->info.addr = 0x30;
/* MSI t...@nywhere Plus controller doesn't seem to
respond to probes unless we read something from
an existing device. Weird...
@@ -741,9 +739,9 @@ void saa7134_probe_i2c_ir(struct saa7134
(1 == rc) ? "yes" : "no");
break;
case SAA7134_BOARD_HAUPPAUGE_HVR1110:
- init_data.name = "HVR 1110";
- init_data.get_key = get_key_hvr1110;
- init_data.ir_codes = ir_codes_hauppauge_new;
+ dev->init_data.name = "HVR 1110";
+ dev->init_data.get_key = get_key_hvr1110;
+ dev->init_data.ir_codes = ir_
[125/136] em28xx: ir-kbd-i2c init data needs a persistent object
2.6.31-stable review patch. If anyone has any objections, please let us know.
--
From: Brian Rogers
commit d2ebd0f806fdb6104903365e355675934eec22b2 upstream.
Original commit message:
ir-kbd-i2c's ir_probe() function can be called much later (i.e. at
ir-kbd-i2c module load), than the lifetime of a struct IR_i2c_init_data
allocated off of the stack in cx18_i2c_new_ir() at registration time.
Make sure we pass a pointer to a persistent IR_i2c_init_data object at
i2c registration time.
Thanks to Brian Rogers, Dustin Mitchell, Andy Walls and Jean Delvare to
rise this question.
Before this patch, if ir-kbd-i2c were probed after em28xx, trash data
were used. After the patch, no matter what order, it is properly
reported as tested by me:
input: i2c IR (i2c IR (EM2840 Hauppaug as /class/input/input10
ir-kbd-i2c: i2c IR (i2c IR (EM2840 Hauppaug detected at i2c-4/4-0030/ir0
[em28xx #0]
Original-patch-by: Mauro Carvalho Chehab
Signed-off-by: Mauro Carvalho Chehab
[br...@xyzw.org: backported for 2.6.31]
Signed-off-by: Brian Rogers
Signed-off-by: Greg Kroah-Hartman
---
drivers/media/video/em28xx/em28xx-cards.c | 32 ++
drivers/media/video/em28xx/em28xx.h |4 +++
2 files changed, 19 insertions(+), 17 deletions(-)
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -2170,8 +2170,6 @@ static int em28xx_hint_board(struct em28
/* --- */
void em28xx_register_i2c_ir(struct em28xx *dev)
{
- struct i2c_board_info info;
- struct IR_i2c_init_data init_data;
const unsigned short addr_list[] = {
0x30, 0x47, I2C_CLIENT_END
};
@@ -2179,9 +2177,9 @@ void em28xx_register_i2c_ir(struct em28x
if (disable_ir)
return;
- memset(&info, 0, sizeof(struct i2c_board_info));
- memset(&init_data, 0, sizeof(struct IR_i2c_init_data));
- strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
+ memset(&dev->info, 0, sizeof(&dev->info));
+ memset(&dev->init_data, 0, sizeof(dev->init_data));
+ strlcpy(dev->info.type, "ir_video", I2C_NAME_SIZE);
/* detect & configure */
switch (dev->model) {
@@ -2191,19 +2189,19 @@ void em28xx_register_i2c_ir(struct em28x
break;
case (EM2800_BOARD_TERRATEC_CINERGY_200):
case (EM2820_BOARD_TERRATEC_CINERGY_250):
- init_data.ir_codes = ir_codes_em_terratec;
- init_data.get_key = em28xx_get_key_terratec;
- init_data.name = "i2c IR (EM28XX Terratec)";
+ dev->init_data.ir_codes = ir_codes_em_terratec;
+ dev->init_data.get_key = em28xx_get_key_terratec;
+ dev->init_data.name = "i2c IR (EM28XX Terratec)";
break;
case (EM2820_BOARD_PINNACLE_USB_2):
- init_data.ir_codes = ir_codes_pinnacle_grey;
- init_data.get_key = em28xx_get_key_pinnacle_usb_grey;
- init_data.name = "i2c IR (EM28XX Pinnacle PCTV)";
+ dev->init_data.ir_codes = ir_codes_pinnacle_grey;
+ dev->init_data.get_key = em28xx_get_key_pinnacle_usb_grey;
+ dev->init_data.name = "i2c IR (EM28XX Pinnacle PCTV)";
break;
case (EM2820_BOARD_HAUPPAUGE_WINTV_USB_2):
- init_data.ir_codes = ir_codes_hauppauge_new;
- init_data.get_key = em28xx_get_key_em_haup;
- init_data.name = "i2c IR (EM2840 Hauppauge)";
+ dev->init_data.ir_codes = ir_codes_hauppauge_new;
+ dev->init_data.get_key = em28xx_get_key_em_haup;
+ dev->init_data.name = "i2c IR (EM2840 Hauppauge)";
break;
case (EM2820_BOARD_MSI_VOX_USB_2):
break;
@@ -2215,9 +2213,9 @@ void em28xx_register_i2c_ir(struct em28x
break;
}
- if (init_data.name)
- info.platform_data = &init_data;
- i2c_new_probed_device(&dev->i2c_adap, &info, addr_list);
+ if (dev->init_data.name)
+ dev->info.platform_data = &dev->init_data;
+ i2c_new_probed_device(&dev->i2c_adap, &dev->info, addr_list);
}
void em28xx_card_setup(struct em28xx *dev)
--- a/drivers/media/video/em28xx/em28xx.h
+++ b/drivers/media/video/em28xx/em28xx.h
@@ -595,6 +595,10 @@ struct em28xx {
struct delayed_work sbutton_query_work;
struct em28xx_dvb *dvb;
+
+ /* I2C keyboard data */
+ struct i2c_board_info info;
+ struct IR_i2c_init_data init_data;
};
struct em28xx_ops {
--
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
cx23885 audio
Hi all, It there any cx23885 audio support on current v4l-dvb tree, Or any development tree for cx23885 audio? Thanks David -- 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] firedtv: length field corrupt in ca2host if length>127
Here is a patch that solves a problem in firedtv that has become major for
Swedish DVB-T users the last month or so.
It will most likely solve issues seen by other users as well.
Please review and comment.
---
>From 751c52ea5509b85590cc6eeddb16ecc1eecfcb0c Mon Sep 17 00:00:00 2001
From: Henrik Kurelid
Date: Thu, 1 Oct 2009 07:17:31 +0200
Subject: [PATCH] firedtv: length field corrupt in ca2host if length>127
If the length of an AVC message is greater than 127, the length field should
be encoded in LV mode instead of V mode. V mode can only be used if the
length
is 127 or less. This patch ensures that the CA_PMT message is always encoded
in LV mode so PMT message of greater lengths can be supported.
Signed-off-by: Henrik Kurelid
---
drivers/media/dvb/firewire/firedtv-avc.c | 38
+++--
1 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/media/dvb/firewire/firedtv-avc.c
b/drivers/media/dvb/firewire/firedtv-avc.c
index d056a40..143a322 100644
--- a/drivers/media/dvb/firewire/firedtv-avc.c
+++ b/drivers/media/dvb/firewire/firedtv-avc.c
@@ -1051,28 +1051,28 @@ int avc_ca_pmt(struct firedtv *fdtv, char *msg, int
length)
c->operand[4] = 0; /* slot */
c->operand[5] = SFE_VENDOR_TAG_CA_PMT; /* ca tag */
c->operand[6] = 0; /* more/last */
- /* c->operand[7] = XXXprogram_info_length + 17; */ /* length */
- c->operand[8] = list_management;
- c->operand[9] = 0x01; /* pmt_cmd=OK_descramble */
+ /* Use three bytes for length field in case length > 127 */
+ c->operand[10] = list_management;
+ c->operand[11] = 0x01; /* pmt_cmd=OK_descramble */
/* TS program map table */
- c->operand[10] = 0x02; /* Table id=2 */
- c->operand[11] = 0x80; /* Section syntax + length */
- /* c->operand[12] = XXXprogram_info_length + 12; */
- c->operand[13] = msg[1]; /* Program number */
- c->operand[14] = msg[2];
- c->operand[15] = 0x01; /* Version number=0 + current/next=1 */
- c->operand[16] = 0x00; /* Section number=0 */
- c->operand[17] = 0x00; /* Last section number=0 */
- c->operand[18] = 0x1f; /* PCR_PID=1FFF */
- c->operand[19] = 0xff;
- c->operand[20] = (program_info_length >> 8); /* Program info length
*/
- c->operand[21] = (program_info_length & 0xff);
+ c->operand[12] = 0x02; /* Table id=2 */
+ c->operand[13] = 0x80; /* Section syntax + length */
+ /* c->operand[14] = XXXprogram_info_length + 12; */
+ c->operand[15] = msg[1]; /* Program number */
+ c->operand[16] = msg[2];
+ c->operand[17] = 0x01; /* Version number=0 + current/next=1 */
+ c->operand[18] = 0x00; /* Section number=0 */
+ c->operand[19] = 0x00; /* Last section number=0 */
+ c->operand[20] = 0x1f; /* PCR_PID=1FFF */
+ c->operand[21] = 0xff;
+ c->operand[22] = (program_info_length >> 8); /* Program info length
*/
+ c->operand[23] = (program_info_length & 0xff);
/* CA descriptors at programme level */
read_pos = 6;
- write_pos = 22;
+ write_pos = 24;
if (program_info_length > 0) {
pmt_cmd_id = msg[read_pos++];
if (pmt_cmd_id != 1 && pmt_cmd_id != 4)
@@ -1114,8 +1114,10 @@ int avc_ca_pmt(struct firedtv *fdtv, char *msg, int
length)
c->operand[write_pos++] = 0x00;
c->operand[write_pos++] = 0x00;
- c->operand[7] = write_pos - 8;
- c->operand[12] = write_pos - 13;
+ c->operand[7] = 0x82;
+ c->operand[8] = (write_pos - 10) >> 8;
+ c->operand[9] = (write_pos - 10) & 0xFF;
+ c->operand[14] = write_pos - 15;
crc32_csum = crc32_be(0, &c->operand[10], c->operand[12] - 1);
c->operand[write_pos - 4] = (crc32_csum >> 24) & 0xff;
--
1.6.0.6
--
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
