Re: Adding support for Benq DC E300 camera
On Sat, 12 Dec 2009 20:41:24 +0100
Francesco Lavra francescola...@interfree.it 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\] usbsnoop file
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 isoc \[%d\] l:%d 0x$n 0x$l]
return $line
}
proc vendor {fd} {
# outgoing message
global deltatime
set out 0
set b {}
while {[gets $fd line] = 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 GET $r $v $i $b
}
return $line
}
proc interf {fd} {
# select interface
global deltatime
set i {??}
set a {??}
while {[gets $fd line] = 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 Bulk/Int IN $b
} else {
puts Bulk/Int OUT $b
}
return $line
}
proc main {argv} {
global nowtime prevtime withtime deltatime nobulk noisoc
set withtime 0
set nobulk 0
set noisoc 0
set deltatime {}
set fn {}
foreach a $argv {
switch -- $a {
-t {
set withtime 1
}
-nb {
set nobulk 1
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 francescola...@interfree.it 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 GET 06 0100 12 01 10 01 00 00 00 08 a5 04 35 30 00 00 00 00 00 01 GET 06 0200 09 02 ef 00 01 01 00 c0 32 09 04 00 00 02 0a ff 00 00 07 05 83 01 40 00 01 07 05 82 01 40 00 01 09 04 00 01 02 0a ff 00 00 07 05 83 01 40 00 01 07 05 82 01 40 00 01 09 04 00 02 02 0a ff 00 00 GET 06 0200 09 02 ef 00 01 01 00 c0 32 09 04 00 00 02 0a ff 00 00 07 05 83 01 40 00 01 07 05 82 01 40 00 01 09 04 00 01 02 0a ff 00 00 07 05 83 01 40 00 01 07 05 82 01 40 00 01 09 04 00 02 02 0a ff 00 00 07 05 83 01 40 00 01 07 05 82 01 40 00 01 09 04 00 03 02 0a ff 00 00 07 05 83 01 40 00 01 07 05 82 01 40 00 01 09 04 00 04 02 0a ff 00 00 07 05 83 01 40 00 01 07 05 82 01 40 00 01 09 04 00 05 02 0a ff 00 00 07 05 83 01 40 00 01 07 05 82 01 40 00 01 09 04 00 06 02 0a ff 00 00 07 05 83 01 40 00 01 07 05 82 01 40 00 01 09 04 00 07 02 0a ff 00 00 07 05 83 01 40 00 01 07 05 82 01 40 00 01 09 04 00 08 02 0a ff 00 00 07 05 83 01 40 00 01 07 05 82 01 40 00 01 09 04 00 09 02 0a ff 00 00 07 05 83 01 40 00 01 07 05 82 01 00 00 01 GET 03 0001 0c 00 GET 03 0003 3c 00 GET 03 0004 3c 00 GET 03 0005 3c 00 GET 03 0006 3c 00 GET 03 0007 3c 00 == +14112 ms == [14200 ms] SET 02 0003 0002 intf 00 alt 05 == +45 ms isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048 isoc [32] l:2048 == +3 ms isoc [32] l:2048
[PATCH 3/9] drivers/media: Correct code taking the size of a pointer
From: Julia Lawall ju...@diku.dk
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/)
// smpl
@@
expression *x;
expression f;
type T;
@@
*f(...,(T)x,...)
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
---
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 jonsm...@gmail.com 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 mche...@redhat.com
+ *
+ * This program is free software; you can redistribute it and/or modify
[PATCH 2/6] V4L/DVB: Davinci VPFE Capture: remove unused #include linux/version.h
Remove unused #include linux/version.h('s) in
drivers/media/video/davinci/vpfe_capture.c
Signed-off-by: Huang Weiyi weiyi.hu...@gmail.com
---
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 linux/init.h
#include linux/platform_device.h
#include linux/interrupt.h
-#include linux/version.h
#include media/v4l2-common.h
#include linux/io.h
#include media/davinci/vpfe_capture.h
--
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 aos...@netup.ru 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 mche...@infradead.org 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 lcostant...@gmail.com
---
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-state = (UVC_BUF_STATE_DONE | UVC_BUF_STATE_UNQUEUED);
+ if (!list_empty(queue-irqqueue))
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 spiel...@ewetel.net: 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 olori...@gmail.com Signed-off-by: Jean-Francois Moine moin...@free.fr --- 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 olori...@gmail.com +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 erik.and...@gmail.com 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 dvbli...@free.fr 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 dvbli...@free.fr 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 dvbli...@free.fr: 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 dvbli...@free.fr 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 nm...@freemail.hu
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 nm...@freemail.hu
---
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 nm...@freemail.hu
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 nm...@freemail.hu
---
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 nm...@freemail.hu The conex and etoms drivers only build with kernel version 2.6.25 and later. Signed-off-by: Márton Németh nm...@freemail.hu --- 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 nm...@freemail.hu:
From: Márton Németh nm...@freemail.hu
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 nm...@freemail.hu
---
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 dheitmuel...@kernellabs.com
--
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
