Added following property to pipeline, now it is better,
v4l2src always-copy=0 queue-size=4
regards
Purush
- Original Message
From: Michael Trimarchi
To: Purushottam R S
Cc: linux-media@vger.kernel.org
Sent: Mon, 23 November, 2009 9:01:16 PM
Subject: Re: flicker/jumpy at the bottom of
Hi
Working tm6000 driver is my next task. I'll start with tm6000 around New Year.
With my best regards, Dmitry.
> On Mon, Nov 23, 2009 at 4:28 PM, Mauro Carvalho Chehab
> wrote:
> > Hi Dmitri,
> >
> > I added this patch, but the driver is essentially broken. It would
> > be wonderful if you hav
On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:
On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
Mauro Carvalho Chehab writes:
Event input has the advantage that the keystrokes will provide an unique
representation that is independent of the device.
This can hardly work as t
On 11/23/2009 07:58 AM, Mauro Carvalho Chehab wrote:
Jarod Wilson wrote:
lirc driver for SoundGraph iMON IR receivers and displays
Successfully tested with multiple devices with and without displays.
+static struct usb_device_id imon_usb_id_table[] = {
+ /* TriGem iMON (IR only) -- T
On 11/23/2009 04:10 PM, Christoph Bartelmus wrote:
Hi Jarod,
on 23 Nov 09 at 14:17, Jarod Wilson wrote:
Krzysztof Halasa wrote:
[...]
If you see patch 3/3, of the lirc submission series, you'll notice a driver
that has hardware decoding, but, due to lirc interface, the driver
generates pseudo
On Mon, 2009-11-23 at 12:09 -0500, Devin Heitmueller wrote:
> On Mon, Nov 23, 2009 at 7:12 AM, Andy Walls wrote:
> > 5. If you don't give an MDL back to the firmware, it never uses it
> > again. That's why you see the sweep-up log messages. As soon as an MDL
> > is skipped *on the order of the d
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the
remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer
field on the subsequent MPEG2-TS frame.
This patch was generated and tested against v2.6.32-rc8
Signed-off-by: Kuninori Morimoto
---
v1 -> v2
o remove noisy macro
o add explain for polarity inverte
drivers/media/video/tw9910.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index a4ba720..f
Signed-off-by: Kuninori Morimoto
---
v1 -> v2
o remove pclock field
o rename macro
drivers/media/video/sh_mobile_ceu_camera.c | 17 +
include/media/sh_mobile_ceu.h |2 ++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/sh_mo
On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote:
> l...@bartelmus.de (Christoph Bartelmus) writes:
>
> >> I think we shouldn't at this time worry about IR transmitters.
> >
> > Sorry, but I have to disagree strongly.
> > Any interface without transmitter support would be absolutely unacc
Hi Dominic,
Am Montag, den 23.11.2009, 10:01 -0800 schrieb Dominic Fernandes:
> Hi,
>
> I need help to compile v4l-dvb drivers for saa7134 modules.
> I'm new to v4l-dvb not sure how to get past the errors concerning
> undefined declarations found in saa7134-inputs.c file for the videomate
> S350
Hi Mauro,
Am Montag, den 23.11.2009, 14:04 -0200 schrieb Mauro Carvalho Chehab:
> Hi Lukáš/Hermann,
>
> Any news about this patch? I'll mark it as RFC at the patchwork, since it
> seems that this is not finished yet. Please let me know if you make some
> progress.
>
> > @@ -1352,6 +1353,7 @@ s
Hello everyone,
here is a little update to my question and to the source code.
After i implemented an function with the VIDIOC_ENUM_FMT ioctl i
recognized, that only two formats are support by the driver by now.
(Thanks to Mr. Liakhovetski by the way ;) )
The output.txt shows the output of thi
On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
> Czesc Krzysztof,
>
> on 23 Nov 09 at 15:14, Krzysztof Halasa wrote:
> [...]
> > I think we shouldn't at this time worry about IR transmitters.
>
> Sorry, but I have to disagree strongly.
> Any interface without transmitter support wo
Dear Guennadi
> > -#define HSP_LOW 0x00 /* 0 : HS pin output polarity is active low */
> > +#define HSP_LO 0x00 /* 0 : HS pin output polarity is active low */
>
> I would remove field names with "0" values completely. Also see below
(snip)
> > +#define VSP_V_LOVSP_HI /* xSSL_xVALID
Dear Guennadi
Thank you checking
> In any case, this confirms, how important good name choice is:-) Now, HSP,
> etc. have nothing to do with SH, on CEU these fields are called HDPOL and
> VDPOL. But I would suggest some descriptive names, like
> SH_CEU_FLAG_HSYNC_HIGH or similar.
OK. I under
> Fix geometry parameter calculations for the pass-through mode, using the
> imagebus API, Also fix try-fmt result reporting for natively supported by
> the driver pixel formats.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> Marked as RFC because this is based on my imagebus tree. Otherw
Dear Guennadi
> Hm, strange... This doesn't work at all for me. Getting only timeouts.
> Have you tested this on Migo-R?
Hmm.. strange...
It works well on my environment.
Of course Migo-R too.
my environment is based on your 20091105 patches
and my patches
Kuninori Morimoto (13):
soc-c
Devin Heitmueller writes:
> For example, you might want the IR receiver to be listening for codes
> using the "Universal Remote Control XYZ" profile and the IR
> transmitter pretending to be "Cable Company Remote Control ABC" when
> blasting IR codes to the cable box. Ideally, there would be a s
That is the weak point of linux in general, in my case I can't
capture, edit and process DV video using linux, TS I doesn't even
count. In windows I have virtualdub and avisynth (with plugins) to do
whatever I need to process any capture type.
Since I got to know Linux OS (your linux OS brand here
On Mon, Nov 23, 2009 at 5:31 PM, Krzysztof Halasa wrote:
> Devin Heitmueller writes:
>
>> There is an argument to be made that since it may be desirable for
>> both IR receivers and transmitters to share the same table of remote
>> control definitions, it might make sense to at least *consider* h
Devin Heitmueller writes:
> There is an argument to be made that since it may be desirable for
> both IR receivers and transmitters to share the same table of remote
> control definitions, it might make sense to at least *consider* how
> the IR transmitter interface is going to work, even if it i
I though about it a bit - my idea:
1. Receivers that can only decode their own remote controllers.
The present code (saa713x etc) can stay mostly unchanged. I'd only
verify that 7 bits (or whatever the number is) is enough for all
cases. The ioctl() should stay unchanged. That means keybo
On Mon, Nov 23, 2009 at 4:46 PM, Krzysztof Halasa wrote:
> l...@bartelmus.de (Christoph Bartelmus) writes:
>
>>> I think we shouldn't at this time worry about IR transmitters.
>>
>> Sorry, but I have to disagree strongly.
>> Any interface without transmitter support would be absolutely unacceptabl
l...@bartelmus.de (Christoph Bartelmus) writes:
>> I think we shouldn't at this time worry about IR transmitters.
>
> Sorry, but I have to disagree strongly.
> Any interface without transmitter support would be absolutely unacceptable
> for many LIRC users, including myself.
I don't say don't use
On Mon, Nov 23, 2009 at 4:28 PM, Mauro Carvalho Chehab
wrote:
> Hi Dmitri,
>
> I added this patch, but the driver is essentially broken. It would
> be wonderful if you have some time to fix it.
>
> Cheers,
> Mauro.
Yeah, I saw his patch and was wondering why on Earth he submitted a
patch adding c
Hi Dmitri,
I added this patch, but the driver is essentially broken. It would
be wonderful if you have some time to fix it.
Cheers,
Mauro.
Dmitri Belimov wrote:
> Hi All
>
> Add new TV cards of Beholder for autodetect.
>
> diff -r 3919b17dc88e linux/drivers/staging/tm6000/tm6000-cards.c
> ---
Hi Jarod,
on 23 Nov 09 at 14:17, Jarod Wilson wrote:
>> Krzysztof Halasa wrote:
[...]
>> If you see patch 3/3, of the lirc submission series, you'll notice a driver
>> that has hardware decoding, but, due to lirc interface, the driver
>> generates pseudo pulse/space code for it to work via lirc in
Czesc Krzysztof,
on 23 Nov 09 at 15:14, Krzysztof Halasa wrote:
[...]
> I think we shouldn't at this time worry about IR transmitters.
Sorry, but I have to disagree strongly.
Any interface without transmitter support would be absolutely unacceptable
for many LIRC users, including myself.
Chris
Hans Verkuil wrote:
> On Monday 23 November 2009 18:14:26 Mauro Carvalho Chehab wrote:
>> Mauro Carvalho Chehab wrote:
>>> Hans Verkuil wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
following:
- v4l2-spec: add missing V4L2-PIX-FM
Dmitry Torokhov writes:
> Curreently the "scan" codes in the input layer serve just to help users
> to map whatever the device emits into a proper input event code so that
> the rest of userspace would not have to care and would work with all
> types of devices (USB, PS/2, etc).
>
> I would not w
Jarod Wilson writes:
> There are quite a few available IR options that are NOT tied to a
> video capture device at all -- the mceusb and imon drivers submitted
> in my patch series are actually two such beasts.
Precisely. This also includes the parallel and serial port receivers,
I'm under impre
On Monday 23 November 2009 18:14:26 Mauro Carvalho Chehab wrote:
> Mauro Carvalho Chehab wrote:
> > Hans Verkuil wrote:
> >> Hi Mauro,
> >>
> >> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
> >> following:
> >>
> >> - v4l2-spec: add missing V4L2-PIX-FMT-STV0680 description.
Mauro Carvalho Chehab writes:
> If you see patch 3/3, of the lirc submission series, you'll notice a driver
> that has hardware decoding, but, due to lirc interface, the driver generates
> pseudo pulse/space code for it to work via lirc interface.
IOW the driver generates artificial pulse code f
Hi Kai
On Mon, 23 Nov 2009, Kai Tiwisina wrote:
> Hello,
>
> my name is Kai Tiwisina and i'm a student in germany and i'm trying to
> communicate with a Omnivision ov9655 camera which is atteched with my
> embedded linux system via the v4l commands.
>
> I've written a small testprogram which
Mauro Carvalho Chehab writes:
>> (This is no recommendation for lirc. I have no idea whether a
>> pulse/space -> scancode -> keycode translation would be practical
>> there.)
It would, but not exactly in the present shape.
> For example, there are several bttv and saa7134 devices that polls (o
Mauro Carvalho Chehab writes:
> True, but this means that everyone with an IR will need to use lirc.
I think that if the input layer (instead of raw code) is used, a utility
which only sets the mapping(s) would suffice. I.e. no daemon.
> /me thinks that, whatever decided with those lirc drivers
James Mastros writes:
> (This is the
> difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned
> to it at boottime, so it works out-of-box. This isn't really possible
> with an IR remote -- though perhaps rc5 is standarized enough, I don't
> think other protocols neccessarly are.)
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:Mon Nov 23 19:00:05 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 13381:2f87f537fb2b
gcc version: gcc (
e9hack wrote:
> e9hack schrieb:
>> can you please commit this patch? It's perfect just I wrote here
>> (http://news.gmane.org/gmane.linux.drivers.video-input-infrastructure).
>
> Ooops, the link wasn't correct.
> http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/11846
>
> Re
I'm a bit short on time to write up a more complete reply to anything in this
thread at the moment, but a few quick notes interspersed below.
On Nov 23, 2009, at 12:29 PM, Mauro Carvalho Chehab wrote:
> Krzysztof Halasa wrote:
>> Mauro Carvalho Chehab writes:
...
>>> Considering the common cas
El Mon, 23 Nov 2009 19:27:04 +0100
Németh Márton escribió:
> Hi,
> Gustavo Chaín Dumit wrote:
> > Hi
> >
> > I'm testing a Pixart Imaging device (0x93a:0x2622)
> > Everything works fine, but vertical orientation. Image looks
> > rotated. So I wrote a little hack to prevent it.
> > [...]
> > Any o
Hello,
my name is Kai Tiwisina and i'm a student in germany and i'm trying to
communicate with a Omnivision ov9655 camera which is atteched with my
embedded linux system via the v4l commands.
I've written a small testprogram which should grow step by step while i'm
trying one ioctl after anoth
On Sat, Nov 21, 2009 at 1:30 PM, Jarod Wilson wrote:
> On Nov 21, 2009, at 12:18 PM, Alex Deucher wrote:
>
>> Does anyone know if there is a driver or documentation available for
>> the ENE CIR controller that's incorporated into many of their keyboard
>> controllers? If there is no driver but do
Hi,
Gustavo Chaín Dumit wrote:
> Hi
>
> I'm testing a Pixart Imaging device (0x93a:0x2622)
> Everything works fine, but vertical orientation. Image looks rotated.
> So I wrote a little hack to prevent it.
> [...]
> Any one has the same problem ?
You might want to have a look to libv4l ( http://fr
Hi,
I need help to compile v4l-dvb drivers for saa7134 modules.
I'm new to v4l-dvb not sure how to get past the errors concerning
undefined declarations found in saa7134-inputs.c file for the videomate
S350 board, saying ir_codes, mask_keycodes, mask_keydown as undeclared:
snip:-
make[2]: Enter
James Mastros wrote:
> 2009/11/23 Devin Heitmueller :
>> Just bear in mind that with the current in-kernel code, users do *not
>> * have to manually select the RC code to use if they are using the
>> default remote that shipped with the product.
> This could still happen, if LIRC checks the identif
Stefan Richter wrote:
> Krzysztof Halasa wrote:
>> Mauro Carvalho Chehab writes:
>>
>>> Event input has the advantage that the keystrokes will provide an unique
>>> representation that is independent of the device.
>> This can hardly work as the only means, the remotes have different keys,
>> the
On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
> > Event input has the advantage that the keystrokes will provide an unique
> > representation that is independent of the device.
>
> This can hardly work as the only means, the remotes have diff
For whatever reason, the device structure pointer to
videobuf_queue_vmalloc_init is typed "void *", even though it's passed
right through to videobuf_queue_core_init(), which expects a struct
device pointer. The other videobuf implementations use struct device *;
I think vmalloc should too.
Signe
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> Event input has the advantage that the keystrokes will provide an unique
>> representation that is independent of the device.
>
> This can hardly work as the only means, the remotes have different keys,
> the user almost always has to
Is there a video editor which can be used to extract pieces
of video to file? Two of the editors in Ubuntu failed to load
the DVB TS streamfile, Kino converted it to DV format, and slowly.
That is bad. And I don't know what DV format is, and how to convert
it losslessly back to DVB TS format.
Sim
Mauro Carvalho Chehab wrote:
> Hans Verkuil wrote:
>> Hi Mauro,
>>
>> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
>> following:
>>
>> - v4l2-spec: add missing V4L2-PIX-FMT-STV0680 description.
>
> Something went wrong here:
>
> $ less /tmp/newpatches/hg_v4l-dvb_01.patch|
On Mon, Nov 23, 2009 at 12:05 PM, James Mastros wrote:
> 2009/11/23 Devin Heitmueller :
>> Just bear in mind that with the current in-kernel code, users do *not
>> * have to manually select the RC code to use if they are using the
>> default remote that shipped with the product.
> This could still
Hans Verkuil wrote:
> Hi Mauro,
>
> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
> following:
>
> - v4l2-spec: add missing V4L2-PIX-FMT-STV0680 description.
Something went wrong here:
$ less /tmp/newpatches/hg_v4l-dvb_01.patch|diffstat -p1
linux/Documentation/DocBook/v
On Mon, Nov 23, 2009 at 7:12 AM, Andy Walls wrote:
> 5. If you don't give an MDL back to the firmware, it never uses it
> again. That's why you see the sweep-up log messages. As soon as an MDL
> is skipped *on the order of the depth* of q_busy times, when looking for
> the currently DMA_DONE'd M
2009/11/23 Devin Heitmueller :
> Just bear in mind that with the current in-kernel code, users do *not
> * have to manually select the RC code to use if they are using the
> default remote that shipped with the product.
This could still happen, if LIRC checks the identifiers of the
reciving device,
2009/11/23 Devin Heitmueller :
> Just bear in mind that with the current in-kernel code, users do *not
> * have to manually select the RC code to use if they are using the
> default remote that shipped with the product.
This could still happen, if LIRC checks the identifiers of the
reciving device,
Hans Verkuil wrote:
>> Hans Verkuil wrote:
>>> On Friday 20 November 2009 22:06:02 Devin Heitmueller wrote:
On Fri, Nov 20, 2009 at 3:38 PM, Hans Verkuil
wrote:
> Hi Mauro,
>
> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging
> for the following:
>
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> Event input has the advantage that the keystrokes will provide an unique
>> representation that is independent of the device.
>
> This can hardly work as the only means, the remotes have different keys,
> the user almost always has to
Ben Hutchings wrote:
> The recently added support for lgs8g75 included some 8051 machine code
> without accompanying source code. Replace this with use of the
> firmware loader.
>
> Compile-tested only.
>
> Signed-off-by: Ben Hutchings
> ---
> This firmware can be added to linux-firmware.git in
Hi Lukáš/Hermann,
Any news about this patch? I'll mark it as RFC at the patchwork, since it seems
that this is not finished yet. Please let me know if you make some progress.
> @@ -1352,6 +1353,7 @@ struct saa7134_board saa7134_boards[] =
> .tuner_addr = ADDR_UNSET,
>
It is perhaps time to resurrect Jon Smirl's work about In-kernel IR remote
control support ?
See http://marc.info/?l=linux-kernel&m=122591465821297&w=2 and all discussions
around it.
Regards,
Emmanuel.
---
Laposte
David T. L. Wong wrote:
> Hi,
>
> This patch adds support for Maxim MAX2165 silicon tuner.
>
> It is tested on Mygica X8558Pro, which has MAX2165, ATBM8830 and CX23885
Applied, thanks.
Please submit a patch to fix this warning:
/home/v4l/master/v4l/atbm8830.c:166: warning: 'set_agc_config'
Purushottam R S wrote:
Hi ,
I am using latest gspca driver from dvb for camera driver. But I see bottom of
the video has flickering/jumping effect.
I have "Zippys" web camera, which is from Z-Star. I have loaded the following
drivers.
1. gspca_zc3xx 44832 0 - Live 0xbf01f000
2. gspca_main 23
> Hans Verkuil wrote:
>> On Friday 20 November 2009 22:06:02 Devin Heitmueller wrote:
>>> On Fri, Nov 20, 2009 at 3:38 PM, Hans Verkuil
>>> wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging
for the following:
- Enable staging drive
On Mon, Nov 23, 2009 at 9:14 AM, Krzysztof Halasa wrote:
> I think this makes a lot of sense.
> But: we don't need a database of RC codes in the kernel (that's a lot of
> data, the user has to select the RC in use anyway so he/she can simply
> provide mapping e.g. RC5<>keycode).
Just bear in mind
Mauro Carvalho Chehab writes:
> Event input has the advantage that the keystrokes will provide an unique
> representation that is independent of the device.
This can hardly work as the only means, the remotes have different keys,
the user almost always has to provide customized key<>function map
Hans Verkuil wrote:
> On Friday 20 November 2009 22:06:02 Devin Heitmueller wrote:
>> On Fri, Nov 20, 2009 at 3:38 PM, Hans Verkuil wrote:
>>> Hi Mauro,
>>>
>>> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging
>>> for the following:
>>>
>>> - Enable staging drivers by default w
Am Mon, 23 Nov 2009 14:19:10 +0100 (CET)
schrieb Patrick Boettcher :
> On Mon, 23 Nov 2009, Patrick Boettcher wrote:
>
> > On Mon, 23 Nov 2009, grafgrim...@gmx.de wrote:
> >> [..]
> >> - hello stupid I2C access
> >> Pid: 255, comm: khubd Tainted: P A 2.6.31.6 #1
> >> Call Trace:
On Mon, 23 Nov 2009, Patrick Boettcher wrote:
On Mon, 23 Nov 2009, grafgrim...@gmx.de wrote:
[..]
- hello stupid I2C access
Pid: 255, comm: khubd Tainted: P A 2.6.31.6 #1
Call Trace:
[] ? dibusb_i2c_xfer+0xe2/0x130 [dvb_usb_dibusb_common]
[] ? i2c_transfer+0x91/0xe0
[] ? dib300
Jarod Wilson wrote:
> lirc driver for SoundGraph iMON IR receivers and displays
>
> Successfully tested with multiple devices with and without displays.
>
> +static struct usb_device_id imon_usb_id_table[] = {
> + /* TriGem iMON (IR only) -- TG_iMON.inf */
> + { USB_DEVICE(0x0aa8, 0x800
Jarod Wilson wrote:
> lirc driver for Windows Media Center Ed. IR transceivers
>
> Successfully tested with the mce v2 transceiver and remote that shipped with a
> Hauppauge HVR-1500 expresscard tuner and an mce v1 transceiver from an old HP
> Media Center system.
>
> Changes from prior submissio
Mauro Carvalho Chehab wrote:
> Jarod Wilson wrote:
> 1) As I said before, this code adds a new input API. So, you should
> get input people's ack about it. It seems fine for me;
>> Index: b/drivers/input/lirc/lirc.h
>> ===
>> --- /de
Hi Mauro,
Maybe my previous mail was lost..
Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb
for the following 8 changesets:
01/08: gspca - pac7302: Remove redundant stream off command.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=1551c621e75f
02/08: gspca - pac7311/pac
On Mon, 2009-11-23 at 07:12 -0500, Andy Walls wrote:
> On Sun, 2009-11-22 at 22:04 -0500, Devin Heitmueller wrote:
> > On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls wrote:
> > > OK, here's my second attempt at getting rid of cx18 YUV frame alignment
> > > and tearing issues.
> > >
> > >http
On Mon, 23 Nov 2009, grafgrim...@gmx.de wrote:
[..]
- hello stupid I2C access
Pid: 255, comm: khubd Tainted: P A 2.6.31.6 #1
Call Trace:
[] ? dibusb_i2c_xfer+0xe2/0x130 [dvb_usb_dibusb_common]
[] ? i2c_transfer+0x91/0xe0
[] ? dib3000_write_reg+0x51/0x70 [dib3000mb]
[] ? dvb_pll_a
On Sun, 2009-11-22 at 22:04 -0500, Devin Heitmueller wrote:
> On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls wrote:
> > OK, here's my second attempt at getting rid of cx18 YUV frame alignment
> > and tearing issues.
> >
> >http://linuxtv.org/hg/~awalls/cx18-yuv2
>
> Hi Andy,
>
> I did some
Hi Jarod,
Jarod Wilson wrote:
> Core Linux Infrared Remote Control driver and infrastructure
>
> -Add Kconfig and Makefile bits
> -Add device driver interface and headers
>
> The initial Kconfig and Makefile bits were done by Mario Limonciello for
> the Ubuntu kernel, but have been tweaked a bit
Stacey wrote:
I've built the module okay. It installed correctly and copied the files
into /lib/modules/2.6.31-14-generic/kernel/drivers/media/dvb/dvb-usb.
After that I rebooted (since it was easier for me). Then I got to the
"If the Modules load correctly" section to find that nothing has worked
Am Mon, 23 Nov 2009 12:11:40 +0100 (CET)
schrieb Patrick Boettcher :
> On Mon, 23 Nov 2009, Mario Bachmann wrote:
> >> sequence in dibusb_i2c_xfer
> >>
> >> instead of break, please add something like
> >>
> >> printk(KERN_ERR "- hello stupid I2C access \n");
> >>
> >> recompile and load t
On Mon, 23 Nov 2009, Mario Bachmann wrote:
sequence in dibusb_i2c_xfer
instead of break, please add something like
printk(KERN_ERR "- hello stupid I2C access \n");
recompile and load the new module, then check whether the line is
appearing in /var/log/messages or /var/log/syslog when y
Am Mon, 23 Nov 2009 10:01:36 +0100 (CET)
schrieb Patrick Boettcher :
> Hi Mario,
>
> On Sat, 21 Nov 2009, grafgrim...@gmx.de wrote:
>
> > Am Thu, 19 Nov 2009 16:37:18 +0100 (CET)
> > schrieb Patrick Boettcher :
> >
> >> On Sat, 7 Nov 2009, Mario Bachmann wrote:
> >>
> >>> Hi there,
> >>>
> >>> I
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the
remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer
field on the subsequent MPEG2-TS frame.
This patch was generated and tested against v2.6.32-rc8
Hi ,
I am using latest gspca driver from dvb for camera driver. But I see bottom of
the video has flickering/jumping effect.
I have "Zippys" web camera, which is from Z-Star. I have loaded the following
drivers.
1. gspca_zc3xx 44832 0 - Live 0xbf01f000
2. gspca_main 23840 1 gspca_zc3xx, Live 0
Hi Mario,
On Sat, 21 Nov 2009, grafgrim...@gmx.de wrote:
Am Thu, 19 Nov 2009 16:37:18 +0100 (CET)
schrieb Patrick Boettcher :
On Sat, 7 Nov 2009, Mario Bachmann wrote:
Hi there,
I tried linux-2.6.31.5 and tuning still does not work:
tuning to 73800 Hz
video pid 0x0131, audio pid 0x0132
On Sun, 22 Nov 2009 19:17:59 -0500, Andy Walls wrote:
> On Sun, 2009-11-22 at 21:32 +0100, Jean Delvare wrote:
> > The fact that 0x30-0x37 and 0x50-0x5f all reply suggest that the bus
> > driver erroneously returns success to "SMBus receive byte" transactions
> > even when no device acks. This is a
87 matches
Mail list logo
