Re: Adding support for Benq DC E300 camera
On Sat, 12 Dec 2009 20:41:24 +0100 Francesco Lavra wrote: > I'm trying to get my Benq DC E300 camera to work under Linux. > It has an Atmel AT76C113 chip. I don't know how many Linux users would > benefit from a driver supporting this camera (and possibly other > models, too), so my question is: if/when such a driver will be > written, is there someone willing to review it and finally get it > merged? If the answer is yes, I will try to write something working. > > This camera USB interface has 10 alternate settings, and altsetting 5 > is used to stream data; it uses two isochronous endpoints to transfer > an AVI-formatted video stream (320x240) to the USB host. > It would be great if someone could give me some information to make > writing the driver easier: so far, I have only USB sniffer capture > logs from the Windows driver. Hi Francesco, gspca already handles some cameras and some Benq webcams. From a USB snoop, it may be easy to write a new gspca subdriver. I join the tcl script I use to extract the important information from raw snoop traces. May you send me the result with your logs? Then, I could see if an existing subdriver could be used or if a new one has to be created. Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ #!/bin/sh # -*- tcl -*- \ exec tclsh "$0" ${1+"$@"} proc usage {} { puts "Parse a ms-win USB snoop Usage: parsnoop \[options\] Options: -nb Don't display the Bulk/Interrupt messages -ni Don't display the Isochronous messages -t Display the delta time between exchanges" exit } proc isoc {fd} { global deltatime noisoc set in 0 while {[gets $fd line] >= 0} { switch -regexp -- $line { " URB " break StartFrame { if {[string compare [lindex $line 2] ] != 0} { set in 1 } } TransferBufferLength { set l [lindex $line 2] } NumberOfPackets { set n [lindex $line 2] } } } if {!$in || $noisoc} { return $line } puts -nonewline $deltatime puts [format "= 0} { switch -regexp -- $line { " URB " break DIRECTION_OUT { set out 1 } TransferBufferLength { # set l 0x[lindex $line 3] } 0..0: { if {$out} { if {[string length $b] != 0} { append b "\n\t\t " } append b [lrange $line 1 end] } } "Request" { set r [format %02x 0x[lindex $line 2]] } "Value" { set v [format %04x 0x[lindex $line 2]] } "Index" { set i [format %04x 0x[lindex $line 2]] } } } if {$out} { puts -nonewline $deltatime puts " SET $r $v $i $b" } return $line } proc ctrl {fd} { # incoming message global deltatime set in 0 set b {} set setup 0 while {[gets $fd line] >= 0} { switch -regexp -- $line { " URB " break DIRECTION_IN { set in 1 } SetupPacket { set setup 1 } " 0" { if {!$in} continue if {!$setup} { if {[string length $b] == 0} { set b [lrange $line 1 end] } else { append b "\n<\t\t " append b [lrange $line 1 end] } } else { set r [lindex $line 2] set v [lindex $line 4][lindex $line 3] set i [lindex $line 6][lindex $line 5] } } } } if {$in} { puts -nonewline $deltatime puts "= 0} { switch -regexp -- $line { " URB " break InterfaceNumber { set i [format %02x 0x[lindex $line 3]] } AlternateSetting { set a [format %02x 0x[lindex $line 3]] } } } puts -nonewline $deltatime puts " intf $i alt $a" return $line } proc feature {fd} { global deltatime while {[gets $fd line] >= 0} { switch -regexp -- $line { " URB " break } } puts -nonewline $deltatime puts "feature" return $line } proc transf {fd} { # bulk or interrupt transfer global deltatime nobulk set in 0 set b {} while {[gets $fd line] >= 0} { switch -regexp -- $line { DIRECTION_IN { set in 1 } " 00" { if {!$nobulk} { if {[string length $b] == 0} { set b [lrange $line 1 end] } else { append b "\n\t " append b [lrange $line 1 end] } } } " 0100" { if {!$nobulk} { append b "\n\t ..." } } " URB " break } } if {$nobulk || [string length $b] == 0} { return $line } puts -nonewline $deltatime if {$in} { puts "= 0} { set isoc 0 switch -regexp -- $line { URB_FUNCTION_ISOCH_TRANSFER { set line [isoc $fd] set isoc 1 incr nisoc } URB_FUNCTION_VENDOR { set line [vendor $fd] } URB_FUNCTION_CONTROL_TRANSFER { set line [ctrl $fd] } URB_FUNCTION_SELECT_INTERFACE { set line [interf $fd] } URB_FUNCTION_SET_FEATURE_TO_DEVICE { set line [feature $fd] } URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER { set line [transf $fd] } } if {!$noisoc && !$isoc && $nisoc != 0} { puts -nonewline $deltatime puts
Re: Adding support for Benq DC E300 camera
On Sun, 2009-12-13 at 09:48 +0100, Jean-Francois Moine wrote: > On Sat, 12 Dec 2009 20:41:24 +0100 > Francesco Lavra wrote: > > I'm trying to get my Benq DC E300 camera to work under Linux. > > It has an Atmel AT76C113 chip. I don't know how many Linux users would > > benefit from a driver supporting this camera (and possibly other > > models, too), so my question is: if/when such a driver will be > > written, is there someone willing to review it and finally get it > > merged? If the answer is yes, I will try to write something working. > > > > This camera USB interface has 10 alternate settings, and altsetting 5 > > is used to stream data; it uses two isochronous endpoints to transfer > > an AVI-formatted video stream (320x240) to the USB host. > > It would be great if someone could give me some information to make > > writing the driver easier: so far, I have only USB sniffer capture > > logs from the Windows driver. > > Hi Francesco, > > gspca already handles some cameras and some Benq webcams. From a USB > snoop, it may be easy to write a new gspca subdriver. > > I join the tcl script I use to extract the important information from > raw snoop traces. May you send me the result with your logs? Then, I > could see if an existing subdriver could be used or if a new one has to > be created. Hi Jean-Francois, thanks for your interest. In attachment my log from a video streaming session. As you can see, it uses altsetting 5 for streaming, while all altsettings from 0 to 9 have the same isoc endpoints. I have already tried to write a gspca subdriver for it, but the main gspca driver sets altsetting to 9 for streaming, which is not appropriate for this device. But of course I may be missing something, so your help would be very much appreciated. Francesco
[PATCH 3/9] drivers/media: Correct code taking the size of a pointer
From: Julia Lawall sizeof(print_buf) is just the size of the pointer. Change it to the size used in the allocation of print_buf earlier in the same function. A simplified version of the semantic patch that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression *x; expression f; type T; @@ *f(...,(T)x,...) // Signed-off-by: Julia Lawall --- drivers/media/video/hdpvr/hdpvr-core.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/hdpvr/hdpvr-core.c b/drivers/media/video/hdpvr/hdpvr-core.c index e280eb1..51f393d 100644 --- a/drivers/media/video/hdpvr/hdpvr-core.c +++ b/drivers/media/video/hdpvr/hdpvr-core.c @@ -145,7 +145,7 @@ static int device_authorization(struct hdpvr_device *dev) #ifdef HDPVR_DEBUG else { hex_dump_to_buffer(dev->usbc_buf, 46, 16, 1, print_buf, - sizeof(print_buf), 0); + 5*buf_size+1, 0); v4l2_dbg(MSG_INFO, hdpvr_debug, &dev->v4l2_dev, "Status request returned, len %d: %s\n", ret, print_buf); @@ -168,13 +168,13 @@ static int device_authorization(struct hdpvr_device *dev) response = dev->usbc_buf+38; #ifdef HDPVR_DEBUG - hex_dump_to_buffer(response, 8, 16, 1, print_buf, sizeof(print_buf), 0); + hex_dump_to_buffer(response, 8, 16, 1, print_buf, 5*buf_size+1, 0); v4l2_dbg(MSG_INFO, hdpvr_debug, &dev->v4l2_dev, "challenge: %s\n", print_buf); #endif challenge(response); #ifdef HDPVR_DEBUG - hex_dump_to_buffer(response, 8, 16, 1, print_buf, sizeof(print_buf), 0); + hex_dump_to_buffer(response, 8, 16, 1, print_buf, 5*buf_size+1, 0); v4l2_dbg(MSG_INFO, hdpvr_debug, &dev->v4l2_dev, " response: %s\n", print_buf); #endif -- 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] What are the goals for the architecture of an in-kernel IR system?
Dmitry Torokhov wrote: > On Sun, Dec 06, 2009 at 09:34:26PM +0100, Krzysztof Halasa wrote: >> Jon Smirl writes: >> Once again: how about agreement about the LIRC interface (kernel-userspace) and merging the actual LIRC code first? In-kernel decoding can wait a bit, it doesn't change any kernel-user interface. >>> I'd like to see a semi-complete design for an in-kernel IR system >>> before anything is merged from any source. >> This is a way to nowhere, there is no logical dependency between LIRC >> and input layer IR. >> >> There is only one thing which needs attention before/when merging LIRC: >> the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and, >> actually, making a correct IR core design without the LIRC merged can be >> only harder. > > This sounds like "merge first, think later"... > > The question is why we need to merge lirc interface right now, before we > agreed on the sybsystem architecture? Noone _in kernel_ user lirc-dev > yet and, looking at the way things are shaping, no drivers will be > _directly_ using it after it is complete. So, even if we merge it right > away, the code will have to be restructured and reworked. Unfortunately, > just merging what Jarod posted, will introduce sysfs hierarchy which > is userspace interface as well (although we not as good maintaining it > at times) and will add more constraints on us. > > That is why I think we should go the other way around - introduce the > core which receivers could plug into and decoder framework and once it > is ready register lirc-dev as one of the available decoders. > I've committed already some IR restruct code on my linux-next -git tree: http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git The code there basically moves the input/evdev registering code and scancode/keycode management code into a separate ir-core module. To make my life easy, I've moved the code temporarily into drivers/media/IR. This way, it helps me to move V4L specific code outside ir-core and to later use it for DVB. After having it done, probably the better is to move it to be under /drivers or /drivers/input. The enclosed patch just adds a skeleton for the new sysfs class for remote controllers and registers an yet unused ir_protocol attribute, creating this tree: /sys/class/irrcv/ |-- irrcv0 | |-- ir_protocol | |-- power | | `-- wakeup | |-- subsystem -> ../../irrcv | `-- uevent `-- irrcv1 |-- ir_protocol |-- power | `-- wakeup |-- subsystem -> ../../irrcv `-- uevent While writing the code, it occurred to me that calling it as "IR" is not the better way, since there's nothing on the code that is related to infra-red, but, instead, is is related to remote controller. So, if it is ok for everybudy, IMO, we should use, instead "rc" meaning remote controller, naming the core module as "rc-core", putting it into drivers/rc. Also, since the same rc chip can have a receiver and a transmitter, maybe we can create the class as: /sys/class/rc rcrcv0/ rcrcv1/ ... rctx0/ rctx1/ ... Comments? --- linux/drivers/media/IR/Makefile |2 linux/drivers/media/IR/ir-keytable.c | 17 +- linux/drivers/media/IR/ir-sysfs.c| 94 +++ linux/include/media/ir-core.h| 12 +++- 4 files changed, 119 insertions(+), 6 deletions(-) --- master.orig/linux/drivers/media/IR/Makefile +++ master/linux/drivers/media/IR/Makefile @@ -1,5 +1,5 @@ ir-common-objs := ir-functions.o ir-keymaps.o -ir-core-objs := ir-keytable.o +ir-core-objs := ir-keytable.o ir-sysfs.o obj-$(CONFIG_IR_CORE) += ir-core.o obj-$(CONFIG_VIDEO_IR) += ir-common.o --- master.orig/linux/drivers/media/IR/ir-keytable.c +++ master/linux/drivers/media/IR/ir-keytable.c @@ -448,12 +448,21 @@ int ir_input_register(struct input_dev * input_set_drvdata(input_dev, ir_dev); rc = input_register_device(input_dev); + if (rc < 0) + goto err; + + rc = ir_register_class(input_dev); if (rc < 0) { - kfree(rc_tab->scan); - kfree(ir_dev); - input_set_drvdata(input_dev, NULL); + input_unregister_device(input_dev); + goto err; } + return 0; + +err: + kfree(rc_tab->scan); + kfree(ir_dev); + input_set_drvdata(input_dev, NULL); return rc; } EXPORT_SYMBOL_GPL(ir_input_register); @@ -473,6 +482,8 @@ void ir_input_unregister(struct input_de kfree(rc_tab->scan); rc_tab->scan = NULL; + ir_unregister_class(dev); + kfree(ir_dev); input_unregister_device(dev); } --- /dev/null +++ master/linux/drivers/media/IR/ir-sysfs.c @@ -0,0 +1,94 @@ +/* ir-register.c - handle IR scancode->keycode tables + * + * Copyright (C) 2009 by Mauro Carvalho Chehab + * + * This program is free software; yo
[PATCH 2/6] V4L/DVB: Davinci VPFE Capture: remove unused #include
Remove unused #include ('s) in drivers/media/video/davinci/vpfe_capture.c Signed-off-by: Huang Weiyi --- drivers/media/video/davinci/vpfe_capture.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/davinci/vpfe_capture.c b/drivers/media/video/davinci/vpfe_capture.c index 12a1b3d..08e51d7 100644 --- a/drivers/media/video/davinci/vpfe_capture.c +++ b/drivers/media/video/davinci/vpfe_capture.c @@ -70,7 +70,6 @@ #include #include #include -#include #include #include #include -- 1.6.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-ci-irq/
Mauro, Please pull change: http://udev.netup.ru/hg/v4l-dvb-aospan-ci-irq/ "configurable IRQ mode on NetUP Dual DVB-S2 CI; IRQ from CAM processing (CI interface works faster)". with this patch CI works 7x times faster in our benchmarks. Thanks. -- Abylai Ospan NetUP Inc. signature.asc Description: This is a digitally signed message part
[PULL] http://linuxtv.org/hg/~endriss/v4l-dvb
Hi Mauro, Please pull from http://linuxtv.org/hg/~endriss/v4l-dvb for the following 2 changesets: 01/02: lnbp21: Implement 22 kHz tone control http://linuxtv.org/hg/~endriss/v4l-dvb?cmd=changeset;node=75331e740f61 02/02: stv090x: Add DiSEqC envelope mode http://linuxtv.org/hg/~endriss/v4l-dvb?cmd=changeset;node=a2b4d12e74f2 lnbp21.c | 28 +++- stv090x.c |7 --- stv090x.h |2 ++ 3 files changed, 33 insertions(+), 4 deletions(-) Thanks, 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://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Sat, Dec 12, 2009 at 5:34 PM, Mauro Carvalho Chehab wrote: > Hi Devin, > > It is better to submit the RFC patches to alsa ML for they to take a look. > > Cheers, > Mauro Is there something specific you want the ALSA people to review? There are no changes to the ALSA core and this is a pretty simple/straightforward PCM capture device modelled after the existing cx88/saa7134/em28xx-alsa drivers. The driver is complete, tested by both KernelLabs and the customer. As far as I know, we generally haven't bothered the ALSA people with devices in the /media tree in the past unless there was some specific issue. If there is something here "out of the ordinary" here that you felt the ALSA people would be able to offer some insight on, I would be more than happy to send it to them. 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: uvcvideo kernel panic when using libv4l
Hi Costantino, thanks for investigating the problem. On Sunday 13 December 2009 08:48:24 lcostant...@gmail.com wrote: > There seems to be a 'kind of race', when queue and dequeue buffer as in > capture.c (attached on the first mail) it's used. > > This could be easily detected on a kernel with DEBUG_LIST enabled. The > poison values will be shown on the oops. Indeed, your analysis seems correct. > This is a test patch only.. > > The oops its triggered when something like this happens: > >suppose X=1 (v4l2_buf->index) >uvc_queue_next_buffer-> > buf = [buf_index_X] >* in the middle, the same buffer is attached to the list... How would that happen ? I can see a tiny race condition in the code, but I'm not sure it could get triggered in practice. When the interrupt handler marks the buffer as done, a userspace application could then dequeue and requeue the buffer before the interrupt handler calls uvc_queue_next_buffer() to remove from the irqqueue list. That would require an SMP system, and a userspace application running fast enough to call both DQBUF and QBUF between the time the buffer is marked as done and the time the buffer is removed from the list. Theoretically possible, but highly improbable. >* uvc_queue_next_buffer calls list_del(&buf->queue) >* Now prev and next from buf->queue are "poisoned" >* next uvc_queue_next_buffer will fetch the same buffer index, and > call list_del again, triggering the oops. If the buffer can indeed end up back in the list before being dequeued, I agree with your analysis. > I can only reproduce this using the capture.c attached, that should > return 0 after an -EAGAIN and not 'continue the loop'. In fact, after > this little thest patch , the capture.c shouldn't work anymore, but > svv.c (from jmoinef) , will work as expected using the read method. I can't reproduce the problem here so I can't investigate. Could you find out how the race condition is triggered ? > I really, didn't have time to like if this can be fixed getting some > of the lokcs earlier, so , this patch it just for testing if the oops > still happens with you. It just added a new 'state' , if a buffer is > marked as done but , ihave not been "dequeued", in the sense of > list_del have been called, then -EINVAL will be returned. This should > the the common behavior, but for those reasons, it's not ben returned. > > Also, trace shouldn't be used to trigger the buf, since it's during > interrupt context, the delays added by the printk, make it more > difficult to trigger. > > Laurent, could you check if something of this make sense, or i am just > talking bs? States are not bit flags, so UVC_BUF_STATE_DONE|UVC_BUF_STATE_UNQUEUED will actually be equal to UVC_BUF_STATE_UNQUEUED. No sure if that's what you wanted. > I tested it on ID 064e:a101 Suyin Corp. Laptop integrated WebCam (acer 5420) > > PD: Note that this patch apply only to isoc decode. In case of a > proposed apply, decode_bulk, and isight should be taken in account too > when checking the buf->state. > > Signed-off-by: Costantino Leandro > --- > > diff -Nru gspca-e16961fe157d/linux/drivers/media/video/uvc/uvc_queue.c > gspca-dev//linux/drivers/media/video/uvc/uvc_queue.c --- > gspca-e16961fe157d/linux/drivers/media/video/uvc/uvc_queue.c 2009-12-02 > 12:39:53.0 -0500 +++ > gspca-dev//linux/drivers/media/video/uvc/uvc_queue.c 2009-12-13 > 04:06:44.0 -0500 @@ -197,6 +197,7 @@ > switch (buf->state) { > case UVC_BUF_STATE_ERROR: > case UVC_BUF_STATE_DONE: > + case (UVC_BUF_STATE_DONE | UVC_BUF_STATE_UNQUEUED): > v4l2_buf->flags |= V4L2_BUF_FLAG_DONE; > break; > case UVC_BUF_STATE_QUEUED: > @@ -341,10 +342,13 @@ > uvc_trace(UVC_TRACE_CAPTURE, "[W] Corrupted data " > "(transmission error).\n"); > ret = -EIO; > - case UVC_BUF_STATE_DONE: > + case (UVC_BUF_STATE_DONE|UVC_BUF_STATE_UNQUEUED): > + uvc_trace(UVC_TRACE_CAPTURE, "[I] Buffer %u completed." > + " Ready for 'reuse'.\n", v4l2_buf->index); > buf->state = UVC_BUF_STATE_IDLE; > break; > - > + case UVC_BUF_STATE_DONE: > + break;; > case UVC_BUF_STATE_IDLE: > case UVC_BUF_STATE_QUEUED: > case UVC_BUF_STATE_ACTIVE: > @@ -383,8 +387,8 @@ > buf = list_first_entry(&queue->mainqueue, struct uvc_buffer, stream); > > poll_wait(file, &buf->wait, wait); > - if (buf->state == UVC_BUF_STATE_DONE || > - buf->state == UVC_BUF_STATE_ERROR) > + if (buf->state == (UVC_BUF_STATE_DONE | UVC_BUF_STATE_UNQUEUED) > + || buf->state == UVC_BUF_STATE_ERROR) > mask |= POLLIN | POLLRDNORM; > > done: > @@ -489,7 +493,9 @@ > > spin_lock_irqsave(&queue->irqlock, flags); > list_del(&buf->queue); > - if (!list_empty(&queue->irqqueue)) > + > + buf->
Re: [linux-dvb] Is there somobody dealing with DVB cards here ?!?
My question was specific: Support for device ASUS (1043:48cd) lacks in current saa driver; I managed to make it work by modifying current version, since it's a clone of ASUS (1043:4876) device; How could I share this, if this list is the relevant audience of linux-dvb stuff. Perhaps this list is NOT the right place to deal with dvb driver development, I don't know. Regards. Le samedi 12 décembre 2009 à 20:43 -0800, VDR User a écrit : > On Sat, Dec 12, 2009 at 8:04 AM, dvblinux wrote: > > Hi all. > > > > I kindly asked a question yesterday, no answer at all, of any kind... > > > > Is there somebody dealing with DVB-T/DVB-S cards here ?!? > > > > Regards. > > It's probably safe to assume yes but nonetheless you might get a > better response if your question was a little more specific. > -- > 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: [linux-dvb] Rotor not working Skystar hd2(VP1041/STB0899) S2API MYTHTV
Hi Hartmut, sorry, I'm at the begining. I didn't try to receive HDTV yet. Tonda 2009/11/27 Hartmut : > Hi Tonda, > > I can not help you with this topic, but you can tell me (us) wether you > are able to receive HDTV with this card? I'm not ... > > Hartmut > > > kutil2010 schrieb: >> I have the same problem. Skystar HD2, a new S2-liplianin driver and >> motor Optikum DM3800 don't spin. Of course extra power cord connected. >> Logs without mistake. Is somebody, who knows the solution? >> >> Tonda >> >> ___ >> linux-dvb users mailing list >> For V4L/DVB development, please use instead linux-media@vger.kernel.org >> linux-...@linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb >> >> >> > > > ___ > linux-dvb users mailing list > For V4L/DVB development, please use instead linux-media@vger.kernel.org > linux-...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > -- 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] MAINTAINERS file
Patch of the MAINTAINERS file to include the gspca_gl860 driver Signed-off-by: Olivier Lorin Signed-off-by: Jean-Francois Moine --- diff ../orgn/MAINTAINERS MAINTAINERS -rupN --- ../orgn/MAINTAINERS 2009-12-05 22:21:59.0 +0100 +++ MAINTAINERS 2009-09-20 03:35:18.0 +0200 @@ -2224,6 +2224,13 @@ T: git git://git.kernel.org/pub/scm/linu S: Maintained F: drivers/media/video/gspca/finepix.c +GSPCA GL860 SUBDRIVER +M: Olivier Lorin +L: linux-media@vger.kernel.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git +S: Maintained +F: drivers/media/video/gspca/gl860/ + GSPCA M5602 SUBDRIVER M: Erik Andren L: linux-media@vger.kernel.org -- 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: [linux-dvb] Is there somobody dealing with DVB cards here ?!?
On Sun, Dec 13, 2009 at 10:39 AM, dvblinux wrote: > My question was specific: Asking if people deal with DVB-T/DVB-S is really generic. There's nothing specific about it. See below. > Support for device ASUS (1043:48cd) lacks in current saa driver; > > I managed to make it work by modifying current version, since it's a > clone of ASUS (1043:4876) device; > > How could I share this, if this list is the relevant audience of > linux-dvb stuff. > > Perhaps this list is NOT the right place to deal with dvb driver > development, I don't know. You should have posted all this the first time but to answer your questions.. Create a patch and post it with an explanation of what it does. Someone will likely sign-off on it as long as there's no problems. Yes, this is the right list for media-related things. 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: [linux-dvb] Is there somobody dealing with DVB cards here ?!?
I first have to learn what is and how to "create a patch" since I only used my vi to modify the source of the driver and then recompiled it... Thanks for the answers. Regards. Le dimanche 13 décembre 2009 à 10:59 -0800, VDR User a écrit : > On Sun, Dec 13, 2009 at 10:39 AM, dvblinux wrote: > > My question was specific: > > Asking if people deal with DVB-T/DVB-S is really generic. There's > nothing specific about it. See below. > > > Support for device ASUS (1043:48cd) lacks in current saa driver; > > > > I managed to make it work by modifying current version, since it's a > > clone of ASUS (1043:4876) device; > > > > How could I share this, if this list is the relevant audience of > > linux-dvb stuff. > > > > Perhaps this list is NOT the right place to deal with dvb driver > > development, I don't know. > > You should have posted all this the first time but to answer your > questions.. Create a patch and post it with an explanation of what it > does. Someone will likely sign-off on it as long as there's no > problems. Yes, this is the right list for media-related things. > > 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 > -- 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: [linux-dvb] Is there somobody dealing with DVB cards here ?!?
Hi, 2009/12/13 dvblinux : > I first have to learn what is and how to "create a patch" since I only > used my vi to modify the source of the driver and then recompiled it... > Start from here: http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches /Honza -- 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: [linux-dvb] Is there somobody dealing with DVB cards here ?!?
On Sun, Dec 13, 2009 at 11:03 AM, dvblinux wrote: > I first have to learn what is and how to "create a patch" since I only > used my vi to modify the source of the driver and then recompiled it... You can use the "diff" command to do it and also see the link the other guy posted. It's pretty simple actually. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Dec 13 19:00:05 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13631:05d734027b4a 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.32-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: ERRORS linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK 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: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: OK linux-2.6.32-i686: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.30-mips: OK linux-2.6.31-mips: OK linux-2.6.32-mips: ERRORS linux-2.6.30-powerpc64: OK linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: OK 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: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: OK linux-2.6.32-x86_64: OK spec: OK sparse (linux-2.6.32): ERRORS linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The 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
[PATCH] cx231xx: use NULL when pointer is needed
From: Márton Németh The gpio field in the cx231xx_board.input structure is a pointer. Eliminate the following sparse warnings (see "make C=1"): * cx231xx-cards.c:72:13: warning: Using plain integer as NULL pointer * cx231xx-cards.c:77:13: warning: Using plain integer as NULL pointer * cx231xx-cards.c:84:13: warning: Using plain integer as NULL pointer * cx231xx-cards.c:111:13: warning: Using plain integer as NULL pointer * cx231xx-cards.c:116:13: warning: Using plain integer as NULL pointer * cx231xx-cards.c:123:13: warning: Using plain integer as NULL pointer * cx231xx-cards.c:151:13: warning: Using plain integer as NULL pointer * cx231xx-cards.c:156:13: warning: Using plain integer as NULL pointer * cx231xx-cards.c:163:13: warning: Using plain integer as NULL pointer Signed-off-by: Márton Németh --- diff -r e2f13778b5dc linux/drivers/media/video/cx231xx/cx231xx-cards.c --- a/linux/drivers/media/video/cx231xx/cx231xx-cards.c Sat Dec 12 17:25:43 2009 +0100 +++ b/linux/drivers/media/video/cx231xx/cx231xx-cards.c Sun Dec 13 18:33:37 2009 +0100 @@ -69,19 +69,19 @@ .type = CX231XX_VMUX_TELEVISION, .vmux = CX231XX_VIN_3_1, .amux = CX231XX_AMUX_VIDEO, - .gpio = 0, + .gpio = NULL, }, { .type = CX231XX_VMUX_COMPOSITE1, .vmux = CX231XX_VIN_2_1, .amux = CX231XX_AMUX_LINE_IN, - .gpio = 0, + .gpio = NULL, }, { .type = CX231XX_VMUX_SVIDEO, .vmux = CX231XX_VIN_1_1 | (CX231XX_VIN_1_2 << 8) | CX25840_SVIDEO_ON, .amux = CX231XX_AMUX_LINE_IN, - .gpio = 0, + .gpio = NULL, } }, }, @@ -108,19 +108,19 @@ .type = CX231XX_VMUX_TELEVISION, .vmux = CX231XX_VIN_3_1, .amux = CX231XX_AMUX_VIDEO, - .gpio = 0, + .gpio = NULL, }, { .type = CX231XX_VMUX_COMPOSITE1, .vmux = CX231XX_VIN_2_1, .amux = CX231XX_AMUX_LINE_IN, - .gpio = 0, + .gpio = NULL, }, { .type = CX231XX_VMUX_SVIDEO, .vmux = CX231XX_VIN_1_1 | (CX231XX_VIN_1_2 << 8) | CX25840_SVIDEO_ON, .amux = CX231XX_AMUX_LINE_IN, - .gpio = 0, + .gpio = NULL, } }, }, @@ -148,19 +148,19 @@ .type = CX231XX_VMUX_TELEVISION, .vmux = CX231XX_VIN_3_1, .amux = CX231XX_AMUX_VIDEO, - .gpio = 0, + .gpio = NULL, }, { .type = CX231XX_VMUX_COMPOSITE1, .vmux = CX231XX_VIN_2_1, .amux = CX231XX_AMUX_LINE_IN, - .gpio = 0, + .gpio = NULL, }, { .type = CX231XX_VMUX_SVIDEO, .vmux = CX231XX_VIN_1_1 | (CX231XX_VIN_1_2 << 8) | CX25840_SVIDEO_ON, .amux = CX231XX_AMUX_LINE_IN, - .gpio = 0, + .gpio = NULL, } }, }, -- 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] au8522: modify the attributes of local filter coefficients
From: Márton Németh Make the local filter coefficients static and const. This will eliminate the following sparse warnings (see "make C=1"): * au8522_decoder.c:71:31: warning: symbol 'filter_coef' was not declared. Should it be static? * au8522_decoder.c:113:31: warning: symbol 'lpfilter_coef' was not declared. Should it be static? Signed-off-by: Márton Németh --- diff -r e2f13778b5dc linux/drivers/media/dvb/frontends/au8522_decoder.c --- a/linux/drivers/media/dvb/frontends/au8522_decoder.cSat Dec 12 17:25:43 2009 +0100 +++ b/linux/drivers/media/dvb/frontends/au8522_decoder.cSun Dec 13 21:16:25 2009 +0100 @@ -68,7 +68,7 @@ The values are as follows from left to right 0="ATV RF" 1="ATV RF13" 2="CVBS" 3="S-Video" 4="PAL" 5=CVBS13" 6="SVideo13" */ -struct au8522_register_config filter_coef[] = { +static const struct au8522_register_config filter_coef[] = { {AU8522_FILTER_COEF_R410, {0x25, 0x00, 0x25, 0x25, 0x00, 0x00, 0x00} }, {AU8522_FILTER_COEF_R411, {0x20, 0x00, 0x20, 0x20, 0x00, 0x00, 0x00} }, {AU8522_FILTER_COEF_R412, {0x03, 0x00, 0x03, 0x03, 0x00, 0x00, 0x00} }, @@ -110,7 +110,7 @@ 0="SIF" 1="ATVRF/ATVRF13" Note: the "ATVRF/ATVRF13" mode has never been tested */ -struct au8522_register_config lpfilter_coef[] = { +static const struct au8522_register_config lpfilter_coef[] = { {0x060b, {0x21, 0x0b} }, {0x060c, {0xad, 0xad} }, {0x060d, {0x70, 0xf0} }, -- 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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
Hans Verkuil wrote: > Detailed results are available here: > > http://www.xs4all.nl/~hverkuil/logs/Sunday.log >> linux-2.6.24.7-i686: ERRORS >> >> /marune/build/v4l-dvb-master/v4l/conex.c:1049: error: expected '=', ',', >> ';', 'asm' or '__attribute__' before '__devinitconst' >> /marune/build/v4l-dvb-master/v4l/conex.c:1065: error: 'device_table' >> undeclared here (not in a function) >> make[3]: *** [/marune/build/v4l-dvb-master/v4l/conex.o] Error 1 >> make[3]: *** Waiting for unfinished jobs >> /marune/build/v4l-dvb-master/v4l/etoms.c:873: error: expected '=', ',', ';', >> 'asm' or '__attribute__' before '__devinitconst' >> /marune/build/v4l-dvb-master/v4l/etoms.c:893: error: 'device_table' >> undeclared here (not in a function) >> make[3]: *** [/marune/build/v4l-dvb-master/v4l/etoms.o] Error 1 >> make[2]: *** [_module_/marune/build/v4l-dvb-master/v4l] Error 2 >> make[2]: Leaving directory `/marune/build/trees/i686/linux-2.6.24.7' >> make[1]: *** [default] Error 2 >> make[1]: Leaving directory `/marune/build/v4l-dvb-master/v4l' >> make: *** [all] Error 2 >> Sun Dec 13 19:13:59 CET 2009 It seems that kernels before 2.6.24 (inclusively) do not have "__devinitconst", so conex.c and etoms.c can only build with 2.6.25 and later. Should USB_GSPCA_CONEX and USB_GSPCA_ETOMS be added to v4l/versions.txt? --- From: Márton Németh The conex and etoms drivers only build with kernel version 2.6.25 and later. Signed-off-by: Márton Németh --- diff -r e2f13778b5dc v4l/versions.txt --- a/v4l/versions.txt Sat Dec 12 17:25:43 2009 +0100 +++ b/v4l/versions.txt Sun Dec 13 21:40:58 2009 +0100 @@ -54,6 +54,11 @@ RADIO_SI4713 I2C_SI4713 +[2.6.25] +# The drivers uses "__devinitconst" +USB_GSPCA_CONEX +USB_GSPCA_ETOMS + [2.6.24] # Some freezer routines USB_GSPCA_SN9C20X_EVDEV -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://mercurial.intuxication.org/hg/v4l-dvb-commits
Mauro, Please pull from http://mercurial.intuxication.org/hg/v4l-dvb-commits for the following changeset: 01/01: Add support for yet another DvbWorld, TeVii and Prof USB devices http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=ab7f084779b0 Kconfig |8 - dw2102.c | 456 ++- 2 files changed, 315 insertions(+), 149 deletions(-) Thanks, Igor -- 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] au8522: modify the attributes of local filter coefficients
2009/12/13 Németh Márton : > From: Márton Németh > > Make the local filter coefficients static and const. This will eliminate the > following sparse warnings (see "make C=1"): > * au8522_decoder.c:71:31: warning: symbol 'filter_coef' was not declared. > Should it be static? > * au8522_decoder.c:113:31: warning: symbol 'lpfilter_coef' was not declared. > Should it be static? > > Signed-off-by: Márton Németh > --- > diff -r e2f13778b5dc linux/drivers/media/dvb/frontends/au8522_decoder.c > --- a/linux/drivers/media/dvb/frontends/au8522_decoder.c Sat Dec 12 > 17:25:43 2009 +0100 > +++ b/linux/drivers/media/dvb/frontends/au8522_decoder.c Sun Dec 13 > 21:16:25 2009 +0100 > @@ -68,7 +68,7 @@ > The values are as follows from left to right > 0="ATV RF" 1="ATV RF13" 2="CVBS" 3="S-Video" 4="PAL" 5=CVBS13" 6="SVideo13" > */ > -struct au8522_register_config filter_coef[] = { > +static const struct au8522_register_config filter_coef[] = { > {AU8522_FILTER_COEF_R410, {0x25, 0x00, 0x25, 0x25, 0x00, 0x00, 0x00} }, > {AU8522_FILTER_COEF_R411, {0x20, 0x00, 0x20, 0x20, 0x00, 0x00, 0x00} }, > {AU8522_FILTER_COEF_R412, {0x03, 0x00, 0x03, 0x03, 0x00, 0x00, 0x00} }, > @@ -110,7 +110,7 @@ > 0="SIF" 1="ATVRF/ATVRF13" > Note: the "ATVRF/ATVRF13" mode has never been tested > */ > -struct au8522_register_config lpfilter_coef[] = { > +static const struct au8522_register_config lpfilter_coef[] = { > {0x060b, {0x21, 0x0b} }, > {0x060c, {0xad, 0xad} }, > {0x060d, {0x70, 0xf0} }, > -- > 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 > Acked-by: Devin Heitmueller -- 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: New ASUS P3-100 DVB-T/DVB-S device (1043:48cd)
Hi, sorry for delay, no time for the list during the last days. Am Freitag, den 11.12.2009, 16:02 +0100 schrieb dvbli...@free.fr: > Hi all, I'm new on this list. > > I modified on my own the SAA driver to manage an ASUS PS3-100 combo card not > supported yet in current version. > > It features two DVB-S and DVB-T receivers packed on the same PCI card. I'm not aware of such an Asus PCI card with two DVB-S and DVB-T receivers. We might hang in wording ... Maybe one DVB-S, one DVB-T/analog hybrid tuner/demod and also support for analog radio and external S-Video/Composite and analog audio in? > The DVB-T part is identical to ASUS P7131 Hybrid and therefore is managed thru > the existing driver after a light patch in the driver source (and card.c): > copying relevant stuff from (1043:4876) to (1043:48cd). > > I'm not a developper, how to share my successfull experiments ? We have support for the Asus Tiger 3in1 since last summer. This board was OEM only and also does not come with a remote, but your stuff is very likely based on that one. Please try all functions and inputs and post related "dmesg" output loading the saa7134 driver with "card=147 i2c_scan=1". It has the same LNA config like the ASUS P7131 Hybrid LNA too. I can't tell anything about a possible remote, but last on Asus was a transmitter labeled PC-39 that far and that one we do support. 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: New ASUS P3-100 DVB-T/DVB-S device (1043:48cd)
The complete name of the board is: "ASUS My Cinema PS3-100/PTS/FM/AV/RC" ouch :-) You're right: It features the same features than the "ASUS My Cinema P7131 Hybrid" that is: S-Video in, Composite and audio in with a special splitter cord, an FM tuner and IR remote control. All connectors are the same for both cards, but the additionnal DVB-S. The remote control seems to behave exactely the same as P7131, i.e new entries in /dev/input/ as a regular keyboard. I'll post additionnal stuff later, thanks for your answer. Regards. Le lundi 14 décembre 2009 à 02:36 +0100, hermann pitton a écrit : > Hi, > > sorry for delay, no time for the list during the last days. > > Am Freitag, den 11.12.2009, 16:02 +0100 schrieb dvbli...@free.fr: > > Hi all, I'm new on this list. > > > > I modified on my own the SAA driver to manage an ASUS PS3-100 combo card not > > supported yet in current version. > > > > It features two DVB-S and DVB-T receivers packed on the same PCI card. > > I'm not aware of such an Asus PCI card with two DVB-S and DVB-T > receivers. We might hang in wording ... > > Maybe one DVB-S, one DVB-T/analog hybrid tuner/demod and also support > for analog radio and external S-Video/Composite and analog audio in? > > > The DVB-T part is identical to ASUS P7131 Hybrid and therefore is managed > > thru > > the existing driver after a light patch in the driver source (and card.c): > > copying relevant stuff from (1043:4876) to (1043:48cd). > > > > I'm not a developper, how to share my successfull experiments ? > > We have support for the Asus Tiger 3in1 since last summer. > This board was OEM only and also does not come with a remote, but your > stuff is very likely based on that one. > > Please try all functions and inputs and post related "dmesg" output > loading the saa7134 driver with "card=147 i2c_scan=1". > > It has the same LNA config like the ASUS P7131 Hybrid LNA too. > > I can't tell anything about a possible remote, but last on Asus was a > transmitter labeled PC-39 that far and that one we do support. > > 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 > -- 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