Hi Guennadi,
Thanks for the response, it's good just to get confirmation that I was
indeed interpreting the code properly.
I guess the main reason this is more significant for me is the
constraints I have on the hardware, i.e. it cannot handle the 640x480 at
any reasonable frame rate so we need t
Hi Adam
On Fri, 29 Oct 2010, Adam Sutton wrote:
> Hi Guennadi,
Please, use the inline reply style.
> Thanks for the response, it's good just to get confirmation that I was
> indeed interpreting the code properly.
>
> I guess the main reason this is more significant for me is the
> constraints
Hi,
Here is updated version of dvb frequencies init file for Poitiers - France.
Damien
### start of contents
Poitiers - Agglomération
#R1
T 50600 8MHz AUTO NONE QAM64 8k AUTO NONE
#R2
T 54600 8MHz AUTO NONE QAM64 8k AUTO NONE
#R3
T 72200 8MHz AUTO NONE QAM64 8k AUTO NONE
#R
Hi Guennadi,
I find that your idea of "provide a generic framebuffer driver
that could sit on top of a v4l output driver", which may be a good
solution of our LCD controller driver, or maybe much more other SOC
LCD drivers. V4L2 interface support many features than framebuffer for
video playbac
Hello Laurant,
> With the media-ctl and yavta test applications, just run
>
> ./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
> CCDC":1->"OMAP3 ISP CCDC output":0[1]'
> ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP
> CCDC":1[SGRBG10 1024x768]'
>
> ./yavt
Hi all, sorry for the noise, but in current mainline (2.6.36-git12)
there are some updates in ov519.c
I'm running this kernel now and my camera is still not working (tested
in windows and it works).
lsusb:
Bus 008 Device 002: ID 05a9:4519 OmniVision Technologies, Inc. Webcam Classic
But on the ca
Hi,
> I did as you said and everything works fine until I use yavta:
>
> Video format set: width: 2952 height: 1944 buffer size: 11508480
> Video format: BA10 (30314142) 2952x1944
ooops, I had a typo... 2952 becomes 2592
> 4 buffers requested.
> length: 11508480 offset: 0
> Buffer 0 mapped at ad
wow, I'm just glad you and other kernel devs take the time to figure
all this out!
-Tim
On Thu, Oct 28, 2010 at 8:51 AM, Devin Heitmueller
wrote:
> On Thu, Oct 28, 2010 at 10:48 AM, Tim Stowell wrote:
>> Ah my bad, I need to read a little deeper it seems :) Thanks for the
>> info, now I'll stop
Hello,
>
> Now it becomes
> Unable to start streaming: 32 : Broken pipe
I saw that my stub mt9p031_get_format gets called. Thanks a lot. So I
reached the point where I can fill my driver with life.
> I will check if the video format of the sensor chip is SGRBG10 in default.
I guess this is GRBG
Em 29-10-2010 01:15, Jarod Wilson escreveu:
> On Thu, Oct 28, 2010 at 11:11:31PM -0400, Jarod Wilson wrote:
>> I've got one of those tiny little 6-button Apple remotes here, now it can
>> be decoded in-kernel (tested w/an mceusb transceiver).
>
> Oh yeah, RFC, because I'm not sure if we should hav
Em 29-10-2010 04:29, Jarkko Nikula escreveu:
> Hi
>
> On Sun, 17 Oct 2010 22:34:32 +0200
> 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]
Hello Laurant,
sorry I am flooding a bit here, but now I reached a point where I am
really stuck.
In the get_fmt_pad I set the following format
*format = mt9p031->format;
that is defined as
mt9p031->format.code = V4L2_MBUS_FMT_SGRBG10_1X10;
mt9p031->format.width = MT9P031_
On Fri, 29 Oct 2010 11:54:34 -0200
Mauro Carvalho Chehab wrote:
> I had to remove it from my queue, as the patch broke compilation:
>
>
> http://git.linuxtv.org/media_tree.git?a=commit;h=350df81ebaccc651fa4dfad27738db958e067ded
>
> What's the sense of adding a patch that breaks a driver?
Convert the driver to use regulator framework instead of set_power callback.
This with gpio_reset platform data provide cleaner way to manage chip VIO,
VDD and reset signal inside the driver.
Signed-off-by: Jarkko Nikula
Cc: Eduardo Valentin
---
v3:
include/media/si4713.h change was accidentally
On Fri, Oct 29, 2010 at 11:46:02AM -0200, Mauro Carvalho Chehab wrote:
> Em 29-10-2010 01:15, Jarod Wilson escreveu:
> > On Thu, Oct 28, 2010 at 11:11:31PM -0400, Jarod Wilson wrote:
> >> I've got one of those tiny little 6-button Apple remotes here, now it can
> >> be decoded in-kernel (tested w/a
On Thursday, October 28, 2010 20:52:44 Mauro Carvalho Chehab wrote:
> Hi Jan,
>
> Em 28-10-2010 16:01, Jan Hoogenraad escreveu:
> > Douglas:
> >
> > First of all thank you for the support you have done so far.
> >
> > Hans:
> >
> > Is it possible to build the tar from
> > http://git.linuxtv.org
The following changes since commit
18cb657ca1bafe635f368346a1676fb04c512edf:
Merge branch 'stable/xen-pcifront-0.8.2' of
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen and branch
'for-linus' of git://xenbits.xen.org/people/sstabellini/linux-pvhvm (2010-10-28
17:11:17 -0700)
are a
On 10/29/2010 7:06 AM, Bastian Hecht wrote:
Hello Laurant,
sorry I am flooding a bit here, but now I reached a point where I am
really stuck.
In the get_fmt_pad I set the following format
*format = mt9p031->format;
that is defined as
mt9p031->format.code = V4L2_MBUS_FMT_SGRBG1
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 Oct 29 19:00:24 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 15167:abd3aac6644e
git master:
This is my current patch queue, the main change is to make struct rc_dev
the primary interface for rc drivers and to abstract away the fact that
there's an input device lurking in there somewhere. The patchset has been
updated to apply on top of the staging/for_v2.6.37-rc1 branch of the
media_tree
This patch adds the changes from Dmitry's large scancode work for the
input subsystem (the patches to the input core and to rc-core which were
accepted upstream). Not to be applied :)
Not-signed-off-by: Anyone
---
drivers/char/keyboard.c| 31 ++-
drivers/input/evdev.c | 100 ++
This patch converts the cx88 driver (for sampling hw) to use the
decoders provided by ir-core instead of the separate ones provided
by ir-functions (and gets rid of those).
The value for MO_DDS_IO had a comment saying it corresponded to
a 4kHz samplerate. That comment was unfortunately misleading.
This patch removes the remaining usages of the ir_input_nokey() and
ir_input_keydown() functions provided by drivers/media/IR/ir-functions.c
by using the corresponding functionality in ir-core instead.
Signed-off-by: David Härdeman
---
drivers/media/IR/imon.c |9 --
drive
cx88 only depends on VIDEO_IR because it needs ir_extract_bits().
Move that function to ir-core.h and make it inline.
Lots of drivers had dependencies on VIDEO_IR when they really
wanted IR_CORE.
The only remaining drivers to depend on VIDEO_IR are bt8xx and
saa7134 (ir_rc5_timer_end is the only
On Fri, Oct 29, 2010 at 11:11:41AM -0400, Jarod Wilson wrote:
> So the Apple remotes do something funky... One of the four bytes is a
> remote identifier byte, which is used for pairing the remote to a specific
> device, and you can change the ID byte by simply holding down buttons on
> the remote.
On Thu, Oct 28, 2010 at 11:08:10PM -0400, Jarod Wilson wrote:
> We were storing a bunch of spaces at the end of each signal, rather than
> a single long space. The in-kernel decoders were actually okay with
> this, but lirc isn't. Both are happy again with this change, which
> starts accumulating d
On Fri, Oct 29, 2010 at 09:17:11PM +0200, David Härdeman wrote:
> On Fri, Oct 29, 2010 at 11:11:41AM -0400, Jarod Wilson wrote:
> > So the Apple remotes do something funky... One of the four bytes is a
> > remote identifier byte, which is used for pairing the remote to a specific
> > device, and yo
On Fri, Oct 29, 2010 at 09:21:21PM +0200, David Härdeman wrote:
> On Thu, Oct 28, 2010 at 11:08:10PM -0400, Jarod Wilson wrote:
> > We were storing a bunch of spaces at the end of each signal, rather than
> > a single long space. The in-kernel decoders were actually okay with
> > this, but lirc isn
On Fri, Oct 29, 2010 at 03:27:33PM -0400, Jarod Wilson wrote:
> On Fri, Oct 29, 2010 at 09:17:11PM +0200, David Härdeman wrote:
> > On Fri, Oct 29, 2010 at 11:11:41AM -0400, Jarod Wilson wrote:
> > > So the Apple remotes do something funky... One of the four bytes is a
> > > remote identifier byte,
Hello,
I've added support of GoTView PCI-E X5 3D Hybrid to cx23885 module (thanks to
help of Gotview support team). Some details:
1. Everything initialize properly except radio.
2. All analog inputs (TV, composite, S-Video) are tested by myself in several
TV norms (SECAM-D, PAL, NTSC), everything
On Fri, Oct 29, 2010 at 09:59:18PM +0200, David Härdeman wrote:
> On Fri, Oct 29, 2010 at 03:27:33PM -0400, Jarod Wilson wrote:
> > On Fri, Oct 29, 2010 at 09:17:11PM +0200, David Härdeman wrote:
> > > On Fri, Oct 29, 2010 at 11:11:41AM -0400, Jarod Wilson wrote:
> > > > So the Apple remotes do som
On Oct 29, 2010, at 3:07 PM, David Härdeman wrote:
> This is my current patch queue, the main change is to make struct rc_dev
> the primary interface for rc drivers and to abstract away the fact that
> there's an input device lurking in there somewhere. The patchset has been
> updated to apply on
> diff --git a/include/linux/input.h b/include/linux/input.h
> index 7892651..0057698 100644
> --- a/include/linux/input.h
> +++ b/include/linux/input.h
> +/**
> + * struct input_keymap_entry - used by EVIOCGKEYCODE/EVIOCSKEYCODE ioctls
> + * @scancode: scancode represented in machine-endian form.
On Thu, 2010-10-28 at 23:13 -0400, Jarod Wilson wrote:
> Apple's remotes use an NEC-like protocol, but without checksumming. See
> http://en.wikipedia.org/wiki/Apple_Remote for details. Since they always
> send a specific vendor code, check for that, and bypass the checksum
> check.
Jarrod,
This
On Friday 29 October 2010 22:36:06 James Hogan wrote:
> I thought I better point out that this breaks make htmldocs (see below)
> because of the '<' characters "in" a kernel doc'd struct. This is with
> 12ba8d1e9262ce81a695795410bd9ee5c9407ba1 from Linus' tree (>2.6.36). Moving
> the #define below
2010/10/23 Mauro Carvalho Chehab :
> This is the list of patches that weren't applied yet. I've made a big effort
> starting
> last weekend to handle everything I could. All pull requests were addressed.
> There are still
> 43 patches on my queue.
>
> Please help me to clean the list.
>
> This is
On 10/30/2010 02:02 AM, Hernán Ordiales wrote:
2010/10/23 Mauro Carvalho Chehab:
This is the list of patches that weren't applied yet. I've made a big effort
starting
last weekend to handle everything I could. All pull requests were addressed.
There are still
43 patches on my queue.
Please he
Em 29-10-2010 21:02, Hernán Ordiales escreveu:
> 2010/10/23 Mauro Carvalho Chehab :
>> This is the list of patches that weren't applied yet. I've made a big effort
>> starting
>> last weekend to handle everything I could. All pull requests were addressed.
>> There are still
>> 43 patches on my qu
On Fri, Oct 29, 2010 at 8:24 PM, Antti Palosaari wrote:
> On 10/30/2010 02:02 AM, Hernán Ordiales wrote:
>>
>> 2010/10/23 Mauro Carvalho Chehab:
>>>
>>> This is the list of patches that weren't applied yet. I've made a big
>>> effort starting
>>> last weekend to handle everything I could. All pull
39 matches
Mail list logo
