Have a tv tuner believe to be sinovideo 1300, and the remote has h-338 in the
back, the tuner is detected as saa7134 proteus 2309, and working fine, the
patch is for the remote.
following buttons supposed to be working: all the number button, channel up and
down, volumn up and down, off, mute,
Op maandag 15-06-2009 om 22:36 uur [tijdzone +0200], schreef sacha:
> Hello
>
> Does anybody know if this devise will ever work with Linux?
> It was promised by one person last year the support will be available
> within months. One year has gone, nothing happens.
> Is there any alternatives to de
Am Mittwoch, den 15.07.2009, 20:35 +0200 schrieb Samuel Rakitnican:
> On Sun, 12 Jul 2009 23:33:06 +0200, hermann pitton
> wrote:
>
> > Hi Samuel,
> >
> > Am Sonntag, den 12.07.2009, 13:30 +0200 schrieb Samuel Rakitnican:
> >> As the card=139 (Compro Videomate T750)
> >>
> >> DVB: Not working,
Mauro,
Please pull from http://linuxtv.org/hg/~ajacquet/v4l-dvb
for the following changeset:
01/01: zr364xx: implement V4L2_CAP_STREAMING
http://linuxtv.org/hg/~ajacquet/v4l-dvb?cmd=changeset;node=3d99e4f816e5
zr364xx.c | 1209
+-
Hi,
Lamarque Vieira Souza wrote:
Em Quinta-feira 16 Julho 2009, Mauro Carvalho Chehab escreveu:
Em Wed, 15 Jul 2009 20:54:55 -0300
[...]
+ if (pipe_info->state != 0) {
+ if (usb_submit_urb(pipe_info->stream_urb, GFP_KERNEL))
+ dev_err(&cam->udev->dev,
Hi,
Am Freitag, den 17.07.2009, 05:19 -0300 schrieb Mauro Carvalho Chehab:
> Em Fri, 17 Jul 2009 10:57:38 +0700
> Pham Thanh Nam escreveu:
>
> > Hi
> > So, should we add an option for this card? For example:
> > modprobe saa7134 card=57 radioontv
>
> IMO, we should just apply a patch doing the
James Guo writes:
> Have a tv tuner believe to be sinovideo 1300, and the remote has h-338 in the
> back, the tuner is detected as saa7134 proteus 2309, and working fine, the
> patch is for the remote.
>
> following buttons supposed to be working: all the number button, channel up
> and
> down,
Hello,
Does anyone know if there is a driver for this cheap USB DVB-S
device? It's only $35 USD on Ebay. I didn't find any info with Google.
Model Name: DM04+ (or sometimes listed as DM04)
Manufacturer: Forwardvideo (HK) Co., Ltd.
Manufacturer Ref.: EQZ2SH5473Y6
Pictures & Specs:
http:
This patch adds support for dbg_g_chip_ident, dbg_g_register,
and dbg_s_register to the gspca core module.
Signed-off-by: Brian Johnson
---
drivers/media/video/gspca/gspca.c | 73 +
drivers/media/video/gspca/gspca.h |7
2 files changed, 80 insertion
Mauro,
Here is the updated version of the gspca sn9c20x subdriver.
I've removed the custom debugging support and replaced it with support
for the v4l2 debugging ioctls. The first patch in this set adds support
to the gspca core for those ioctls. Also included are the fixes Hans
sent in his last em
This patch adds support for Zilog Z8F0811 IR transceiver chips on
CX2341[68] based boards to ir-kbd-i2c for both the old i2c binding model
and the new i2c binding model.
Regards,
Andy
diff -r d754a2d5a376 linux/drivers/media/video/ir-kbd-i2c.c
--- a/linux/drivers/media/video/ir-kbd-i2c.cWed J
This patch add support to the cx18 driver for setting up the
Z8F0811/Hauppauge IR Tx/Rx chip with the i2c binding model in newer
kernels.
My concerns/questions:
1. When using the new i2c binding model, I'm not saving the returned
pointer from i2c_new_probed_device() and am hence taking no action
This patch augments the init data passed by bridge drivers to ir-kbd-i2c
so that the ir_type can be set explicitly and so ir-kbd-i2c internal
get_key functions can be reused without requiring symbols from
ir-kbd-i2c in the bridge driver.
Regards,
Andy
diff -r d754a2d5a376 linux/drivers/media/vid
Jean,
The following patch series is my preliminary cut at getting the cx18
bridge driver supported IR devices set up properly by the cx18 driver to
allow use by ir-kbd-i2c, lirc_i2c, lirc_pvr150, and lirc_zilog for both
old and new (>= 2.6.30) kernels.
They are:
1/3: ir-kbd-i2c: Allow use of ir-
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:Fri Jul 17 19:00:03 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 12270:d754a2d5a376
gcc version: gcc
On 17 Jul, Henrik Kurelid wrote:
[I wrote]
>> Shouldn't the three return statements in debug_fcp_opcode_flag_set be
>> 'return 0' rather than one?
> I gave this some thought when I implemented it. These are "should not
> happend"-situations where the drivers or hardware sends unknown/
> unimplement
On 17 Jul, Henrik Kurelid wrote:
[I wrote]
>> Shouldn't the three return statements in debug_fcp_opcode_flag_set be
>> 'return 0' rather than one?
> I gave this some thought when I implemented it. These are "should not
> happend"-situations where the drivers or hardware sends unknown/
> unimplement
On 17 Jul, Henrik Kurelid wrote:
[I wrote]
>> Shouldn't the three return statements in debug_fcp_opcode_flag_set be
>> 'return 0' rather than one?
> I gave this some thought when I implemented it. These are "should not
> happend"-situations where the drivers or hardware sends unknown/
> unimplement
On 17 Jul, Henrik Kurelid wrote:
[I wrote]
>> Shouldn't the three return statements in debug_fcp_opcode_flag_set be
>> 'return 0' rather than one?
> I gave this some thought when I implemented it. These are "should not
> happend"-situations where the drivers or hardware sends unknown/
> unimplement
Sergio,
Success, I was able to capture data from the OV5620 using the
omap34xxcam and isp. The problem I was was having was due to several
wrong setups (all my fault of course :)
I am using the v4l2 example code. The code wanted YUYV and Interlaced.
I changed it to the SGBRG10 a
strlcpy() will always null terminate the string.
Signed-off-by: Roel Kluin
---
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
index 326f760..cead089 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
Hi,
I gave this some thought when I implemented it. These are "should not
happend"-situations where the drivers or hardware sends unknown/unimplemented
commands. Rather than making sure that they are never seen in the logs I wanted
them to always be logged (as long as some debug logging is turne
Em Fri, 17 Jul 2009 10:57:38 +0700
Pham Thanh Nam escreveu:
> Hi
> So, should we add an option for this card? For example:
> modprobe saa7134 card=57 radioontv
IMO, we should just apply a patch doing the right thing.
I couldn't find any explanation for the change. Let's just fix it with a good
23 matches
Mail list logo
