On Sat, May 21, 2011 at 11:22 PM, Roman Gaufman wrote:
>> 1. Find some developer who cares enough to take a free board just for
>> the fun of making it work.
>
> Any suggestions where?
You're already in the right place. Unfortunately, finding a developer
willing to spend ten or twenty hours whe
On 22 May 2011 04:11, Devin Heitmueller wrote:
> On Sat, May 21, 2011 at 10:25 PM, Roman Gaufman wrote:
>> I figured as much, but what can I do now?
>
> Your options at this point are:
>
> 1. Find some developer who cares enough to take a free board just for
> the fun of making it work.
Any sug
>I think you're using a borken version. Are you using this one with all the
>ref counting fixes?
>http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/staging/lirc/lirc_zilog.c;h=dd6a57c3c3a3149bac53eb36fd4ddeabed804050;hb=HEAD
Well, you were right. I was using the one right out of 2.6.38. T
On Sat, May 21, 2011 at 10:25 PM, Roman Gaufman wrote:
> I figured as much, but what can I do now?
Your options at this point are:
1. Find some developer who cares enough to take a free board just for
the fun of making it work.
2. If you're a commercial entity, hire somebody to do the work
(Ke
Jason Gauthier wrote:
>All,
>
>
>>Okay, so I emailed a little too quickly. The messages above got me
>thinking. One of them is successful the other is not.
>>I verified with irsend. So, this may be an issue with multiple
>hdpvrs.
>
>I believe I've tracked this down.
>
>In lirc_zilog.c:
>
> A
On Sat, 2011-05-21 at 10:14 -0300, Mauro Carvalho Chehab wrote:
> Em 16-05-2011 19:07, Malcolm Priestley escreveu:
> > Currently priv is freed from memory by dvb-usb on any error or exit.
> > If any buffer has been allocated in the priv structure,
> > freeing it is tricky. While freeing it on d
I figured as much, but what can I do now?
Should I take some high resolution pictures of the board?
Any other details I can provide to help developers add support for this board?
Is there anyone in particularly I should contact?
Anywhere I can post any information I collect on this board?
I'm hap
Just revisiting this again after close to 2 years - still experiencing
the same. Loud static like sound. Tried a few CX23881 cards and it
seems the same :(
I'm doing: arecord -D hw:1,0 -f dat test.wav
I tried it for all the CX8801 audio sources (8 chip DVR card), here
are the output wav files and
>So, simply changing the check to if (ret<0) seems to resolve this. Then if
>-ENOMEM is returned it will fail, and otherwise succeed.
>Sorry, this is not an official patch. The maintainer (Jarod?) should be able
>to see what I am talking about and correct this.
>Thanks!
Last email on this to
All,
>Okay, so I emailed a little too quickly. The messages above got me thinking.
>One of them is successful the other is not.
>I verified with irsend. So, this may be an issue with multiple hdpvrs.
I believe I've tracked this down.
In lirc_zilog.c:
At 1307:
ret = add_i
On Sat, May 21, 2011 at 3:34 PM, Roman Gaufman wrote:
> I have a PCI-E capture card with two connexant cx25821 chips.
> 04:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210
> 05:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210
>
>
> There is a staging driver
Hi,
One of the remotes has a picture available at:
http://lirc.sourceforge.net/remotes/leadtek/Y04G0004.jpg
As there's one variant with a set direction keys plus vol/chann
keys, and the same table is used for both models, change it to
represent all keys, avoiding the usage of weird func
Hi,
One of the remotes has a picture available at:
http://lirc.sourceforge.net/remotes/leadtek/Y04G0004.jpg
As there's one variant with a set direction keys plus vol/chann
keys, and the same table is used for both models, change it to
represent all keys, avoiding the usage of weird func
I have a PCI-E capture card with two connexant cx25821 chips.
04:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210
05:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210
There is a staging driver in latest linux kernels. Looks like it uses v4l2
api.
I tried to
>Admittedly, I do not understand exactly what I am reading. It seems to probe
>the IR Tx (i2c-1) successfully:
>May 21 12:51:06 jgauthier-mythtv kernel: [ 43.088265] lirc_zilog: probe of
>IR Tx on Hauppage HD PVR I2C (i2c-1) done. IR unit ready.
>But, then below on (i2c-2) is failed:
>May 21
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:Sat May 21 19:00:50 CEST 2011
git hash:f9b51477fe540fb4c65a05027fdd6f2ecce4db3b
gcc version: i686-linux-gcc (GCC) 4.5
All,
>>If all goes well, with Jarrod's change, you should be able to test the
>>hdpvr module with the ir-kbd-i2c module and test IR Rx.
>>Strictly speaking, lirc_zilog needs some rework to use the kernel
>>internal interfaces properly. It might still work, but don't be
>>surprised if it doesn't.
On Sat, 21 May 2011, Mauro Carvalho Chehab wrote:
> This is an automatic generated email to let you know that the following patch
> were queued at the
> http://git.linuxtv.org/media_tree.git tree:
>
> Subject: [media] ov9740: Cleanup, and more resolutions
> Author: Andrew Chew
> Date:Mon
I noticed that too on the C code:
If keypress comes from the remote control,
driver does both "push down" and "release" immediately.
Some years ago I made a version that did something like this:
I measured that a remote control sends "key pressed" in about 20ms cycles.
Thus I decided that the
On Fri, 20 May 2011, Javier Martin wrote:
> This driver adds basic support for Aptina mt9p031 sensor.
>
> Signed-off-by: Javier Martin
> ---
> drivers/media/video/Kconfig |8 +
> drivers/media/video/Makefile |1 +
> drivers/media/video/mt9p031.c | 751
>
Disable dynamic current limit for ttpci budget cards.
According to the ISL6423 datasheet, if dynamic current limiting is turned on,
the static limit is ignored and the current drawn can be as high as 990mW.
This is not what we want as it might overload the PCI bus. Disabling
dynamic limit also avo
Em 16-05-2011 19:07, Malcolm Priestley escreveu:
> Currently priv is freed from memory by dvb-usb on any error or exit.
> If any buffer has been allocated in the priv structure,
> freeing it is tricky. While freeing it on device disconnect
> is fairly easy, on error it is almost impossible beca
Hi Laurent,
Despite all those changes at Nokia side, I'm still assuming that you're
handling the
omap3 patches. So, I'm just marking those two patches as RFC until I receive a
pull
request from you.
Anyway, in this specific case, Koen made some comments, so we should wait for
Javier
answer bef
Em 19-05-2011 18:33, Jim Cromie escreveu:
> Since new api passes dev_t*, hoist inline MKDEV out to local var
> assignment, and replace other inline MKDEVs with new var.
While I don't see the need for this change, I'm ok with that.
Please notice that it is not clear if you expect me to apply the p
Em 21-05-2011 03:59, Jean-Francois Moine escreveu:
> The following changes since commit
> f9b51477fe540fb4c65a05027fdd6f2ecce4db3b:
>
> [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09
> 05:47:20 +0200)
>
> are available in the git repository at:
> git://linuxtv.org/jfr
The helper chips are classified by their function. Unfortunaltely,
with time, developers added their stuff into the wrong places.
Fix it by moving itens to be at the right place. Also add a new
category for sensors and for misc devices that are found only on
a certain specific board.
While here,
Em 19-05-2011 07:41, Sakari Ailus escreveu:
> This patch adds the driver for the adp1653 LED flash controller. This
> controller supports a high power led in flash and torch modes and an
> indicator light, sometimes also called privacy light.
>
> The adp1653 is used on the Nokia N900.
>
> Signed-
Em 19-05-2011 05:38, Hans Petter Selasky escreveu:
> --HPS
The patches look sane, but, please send one patch per email. Otherwise,
only the first patch will be caught by patchwork:
https://patchwork.kernel.org/patch/796522/
Also, please sign your patches (with Signed-off-by:) and send the
Em 19-05-2011 05:35, Hans Petter Selasky escreveu:
> Hi,
>
> In my setup I am building the DVB code without dvb_net.c, because there is no
> IP-stack currently in my "Linux kernel". Is this worth a separate
> configuration entry?
I have no problems with that, but your patch is wrong ;) It is no
Em 18-05-2011 13:06, Sanjeev Premi escreveu:
> This patch fixes this compiler warning:
> drivers/media/video/omap3isp/isp.c: In function 'isp_isr_dbg':
> drivers/media/video/omap3isp/isp.c:392:2: warning: zero-length
>gnu_printf format string
>
> Since printk() is used in next few statemen
Em 21-05-2011 03:05, stefan.rin...@arcor.de escreveu:
> From: Stefan Ringel
>
> fix uninitialized field, change prink to dprintk
Applied, thanks.
A quick note: please don't repeat the patch subject at the
first line of the body. It requires me to manually drop it
when importing the patch. Inste
Em 20-05-2011 19:15, James Huk escreveu:
> Hello everybody.
>
> First of all - this post is not meant as the flame starter, nor is it
> "I DEMAND" kind of post - I just would like to know what is the policy
> with driver patches.
>
> I bought Medion CTX1921 USB DVB-T stick, since I saw patches fo
On Sat, 21 May 2011 08:59:33 +0200
Jean-Francois Moine wrote:
> The following changes since commit
> f9b51477fe540fb4c65a05027fdd6f2ecce4db3b:
>
> [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09
> 05:47:20 +0200)
>
> are available in the git repository at:
> git://li
Haven't noticed earlier that every button press is executed twice, until
I did some testing with Oxine. Not sure how much Lirc is to blame for
this, and for button 0 not working. I will move to the Lirc list.
Thanks again for the patch.
--
Adrian C. (anrxc) | anrxc..sysphere.org | PGP ID: D20A
Hello, I got 2.6.39 so I tried this, on Technisat SkyStar2 HD2.
Device showed up as /dev/input/event3. ir-keytable does not show any
protocols for it:
Found /sys/class/rc/rc0/ (/dev/input/event3) with:
Driver mantis_core, table rc-terratec-cinergy-s2-hd
Supported protocols:
35 matches
Mail list logo
