Hi Mauro,
On 07/14/2011 12:35 AM, Mauro Carvalho Chehab wrote:
Em 28-06-2011 11:23, Michael Jones escreveu:
There is an assumption that the format coming from the device
needs 2 bytes per pixel, which is not the case when the device
delivers e.g. V4L2_PIX_FMT_GREY. This doesn't manifest
Hi,
Does this patch works also for kernel 2.6.38 ?
Kind regards
David
--
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
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
Sent: Thursday, July 14, 2011 3:50 AM
To: Joel A Fernandes
Cc: beaglebo...@googlegroups.com; Kridner, Jason; Javier Martin; linux-
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Joel A Fernandes
Sent: Thursday, July 14, 2011 6:49 AM
To: beaglebo...@googlegroups.com
Cc: Kridner, Jason; Javier Martin; laurent.pinch...@ideasonboard.com;
Hi,
On Wed, Jul 13, 2011 at 11:59 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 13 Jul 2011, Ming Lei wrote:
Almost same.
Come on. Almost same means they are different. That difference is
clearly the important thing you need to track down.
I didn't say entirely same because we
Hi all,
This is the patch against kernel 2.6.32 I used to get to work my TV card Asus
My Cinema PS3-100 (1043:48cd).
More information on this card can be found on this page :
http://techblog.hollants.com/2009/09/asus-mycinema-ps3-100-3-in-1-tv-card/
This card seems to be a clone of the Asus
Hi Vaibhav,
On Thursday 14 July 2011 10:05:41 Hiremath, Vaibhav wrote:
On Thursday, July 14, 2011 3:50 AM Laurent Pinchart wrote:
On Wednesday 13 July 2011 20:22:27 Joel A Fernandes wrote:
* Adds support for mt9v113 sensor by borrowing heavily from PSP 2.6.37
kernel patches * Adapted to
Hi Christian,
On Wednesday 13 July 2011 20:58:12 Christian Gmeiner wrote:
2011/7/11 Christian Gmeiner christian.gmei...@gmail.com:
2011/7/11 Laurent Pinchart laurent.pinch...@ideasonboard.com:
On Sunday 10 July 2011 20:14:21 Christian Gmeiner wrote:
Signed-off-by: Christian Gmeiner
---
Em 14-07-2011 04:03, Michael Jones escreveu:
Hi Mauro,
On 07/14/2011 12:35 AM, Mauro Carvalho Chehab wrote:
Em 28-06-2011 11:23, Michael Jones escreveu:
There is an assumption that the format coming from the device
needs 2 bytes per pixel, which is not the case when the device
delivers
Hi all,
I was thinking about the sensor binning controls.
I have a sensor which can do binning both horizontally and vertically, but
the two are connected. So, the sensor supports e.g. 3x1 and 1x3 binning but
not 3x3.
However, most (I assume) sensors do not have dependencies between the two.
Hello,
I've just found two nasty bugs in this version of CMA. Sadly, both are the
results of posting the patches in a big hurry. I'm really sorry.
Alignment argument was not passed correctly to the
bitmap_find_next_zero_area() function and there was an ugly bug in the
On Thu, Jul 14, 2011 at 05:46:21PM +0530, nitesh moundekar wrote:
Hi all,
This is my first mail in linux mailing list and I hope I contribute
something.
I worked at image sensor company and I had the idea that binning control are
used by these companies to get optimum performance power
Mauro Carvalho Chehab wrote:
Em 13-07-2011 18:26, Jarod Wilson escreveu:
These changes make the redrat3 driver cooperate better with both in-kernel
and lirc userspace decoding of signals, tested with RC5, RC6 and NEC.
There's probably more we can do to make this a bit less hackish, but its
On Thu, 14 Jul 2011, Ming Lei wrote:
Hi,
On Wed, Jul 13, 2011 at 11:59 PM, Alan Stern st...@rowland.harvard.edu
wrote:
On Wed, 13 Jul 2011, Ming Lei wrote:
Almost same.
Come on. �Almost same means they are different. �That difference is
clearly the important thing you need to
Hi Michael,
There's no need to set initial return values to zero if they're assigned to in
all code paths.
[snip]
*client) static int mt9m111_enable(struct i2c_client *client)
{
struct mt9m111 *mt9m111 = to_mt9m111(client);
- int ret;
+ int ret = 0;
ret =
Hi Michael,
On Tuesday 12 July 2011 17:39:04 Michael Grzeschik wrote:
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
drivers/media/video/mt9m111.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/mt9m111.c
Acked-by: Pawel Osciak pa...@osciak.com
Thanks Michael!
Pawel
On Tue, Jul 12, 2011 at 06:46, Michael Olbrich m.olbr...@pengutronix.de wrote:
These are necessary to prevent dead-locks e.g. if one thread waits
in dqbuf at one end and another tries to queue a buffer at the
other end.
Em 29-06-2011 09:51, Tomasz Stanislawski escreveu:
The function fills struct v4l2_dv_enum_preset with appropriate
preset parameters but it forgets to zero field named reserved.
This patch fixes this bug.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
Em 13-07-2011 18:58, Jarod Wilson escreveu:
There are folks with flaky imon hardware out there that doesn't always
respond to requests to write to their displays for some reason, which
can flood logs quickly when something like lcdproc is trying to
constantly update the display, so lets
Mauro Carvalho Chehab wrote:
Em 13-07-2011 18:58, Jarod Wilson escreveu:
There are folks with flaky imon hardware out there that doesn't always
respond to requests to write to their displays for some reason, which
can flood logs quickly when something like lcdproc is trying to
constantly update
Em 08-07-2011 12:25, Sylwester Nawrocki escreveu:
Hi Mauro,
The following changes since commit 6068c012c3741537c9f965be5b4249f989aa5efc:
[media] v4l: Document V4L2 control endianness as machine endianness
(2011-07-07 19:26:11 -0300)
are available in the git repository at:
Em 14-07-2011 06:28, remzouille escreveu:
Hi all,
This is the patch against kernel 2.6.32 I used to get to work my TV card Asus
My Cinema PS3-100 (1043:48cd).
More information on this card can be found on this page :
There are folks with flaky imon hardware out there that doesn't always
respond to requests to write to their displays for some reason, which
can flood logs quickly when something like lcdproc is trying to
constantly update the display, so lets rate-limit all that error spew.
v2: add missing
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:Thu Jul 14 19:00:30 CEST 2011
git hash:bec969c908bb22931fd5ab8ecdf99de8702a6a31
gcc version: i686-linux-gcc (GCC)
On Thu, 14 Jul 2011, Sakari Ailus wrote:
Hi all,
I was thinking about the sensor binning controls.
What wrong with just doing S_FMT on the subdev pad? Binning does in fact
implement scaling.
Thanks
Guennadi
I have a sensor which can do binning both horizontally and vertically, but
the
Hi Mauro,
On Thu, 14 Jul 2011 13:27:17 -0300, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 08-07-2011 12:25, Sylwester Nawrocki escreveu:
Hi Mauro,
The following changes since commit
6068c012c3741537c9f965be5b4249f989aa5efc:
[media] v4l: Document V4L2 control endianness as
On Miércoles, 13 de Julio de 2011 14:41:30 Mauro Carvalho Chehab escribió:
Em 06-07-2011 19:57, Jose Alberto Reguero escreveu:
This patch add suport for the dvb-t part of CT-3650.
Jose Alberto
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
Some of you may have noticed that I've been spending a bit of my time with
my nose in the V4L2 code recently... In this process, I've been chasing a
strange mystery: when the mmp-camera driver is run in contiguous DMA mode,
things in user space (gstreamer or mplayer) slow way down, despite the
This patch adds videobuf2-dma-nc.c and related stuff; it implements a new
contiguous DMA mode which uses non-coherent memory. Going non-coherent can
improve performance greatly (3x frame rate increase over coherent on the
Marvell Armada 610 controller), relieves pressure on coherent memory pools,
Switch to the new non-coherent contiguous DMA option. Non-coherent memory
is far more reliable to allocate and performs vastly better on this
platform.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/marvell-ccic/Kconfig |1 +
When user space stops streaming, there may be buffers which have been given
to buf_prepare() and which may or may not have been passed to buf_queue().
The videobuf2 core simply takes those buffers back; if buf_prepare() does
work that needs cleaning up (like setting up a DMA mapping), that cleanup
The one in-tree videobuf2-dma-sg driver (mmp-camera) has no need for a
kernel-space mapping of the buffers; one suspects that most other drivers
would not either. The videobuf2-dma-sg module does the right thing if
buf-vaddr == NULL - it maps the buffer on demand if somebody needs it. So
let's
Hi Guennadi,
Thanks for the comments.
On Thu, Jul 14, 2011 at 07:56:10PM +0200, Guennadi Liakhovetski wrote:
On Thu, 14 Jul 2011, Sakari Ailus wrote:
Hi all,
I was thinking about the sensor binning controls.
What wrong with just doing S_FMT on the subdev pad? Binning does in fact
On Thu, Jul 14, 2011 at 10:07:03PM +0300, Sylwester Nawrocki wrote:
Hi Mauro,
Hi Sylwester and Mauro,
On Thu, 14 Jul 2011 13:27:17 -0300, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 08-07-2011 12:25, Sylwester Nawrocki escreveu:
...
s5p-fimc: Remove sclk_cam clock handling
On Fri, 15 Jul 2011, Sakari Ailus wrote:
Hi Guennadi,
Thanks for the comments.
On Thu, Jul 14, 2011 at 07:56:10PM +0200, Guennadi Liakhovetski wrote:
On Thu, 14 Jul 2011, Sakari Ailus wrote:
Hi all,
I was thinking about the sensor binning controls.
What wrong with just
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/rc/redrat3.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 5fc2f05..ee1303c 100644
--- a/drivers/media/rc/redrat3.c
+++
Makes it more straight-forward to follow stack traces if the functions
don't have generic names. Using this as a crutch while trying to better
understand the lockdep warnings I get when loading the em28xx driver.
CC: Devin Heitmueller dheitmuel...@kernellabs.com
Signed-off-by: Jarod Wilson
This is a stack of updates made based on the Windows Media Center remote
and receiver/transmitter specification and requirements document that
Rafi Rubin recently pointed me at. Its titled
Windows-Media-Center-RC-IR-Collection-Green-Button-Specification-03-08-2011-V2.pdf
which as of this writing,
Sometimes the init routine is blasting commands out to the hardware
faster than it can reply. Throw a brief delay in there to give the
hardware a chance to reply before we send the next command.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/rc/mceusb.c |2 ++
1 files
Its not uncommon for folks to force these bits enabled, because people
do want to wake their htpc kit via their remote. Lets just set the bits
for 'em.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/rc/mceusb.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff
According to MS docs, the device firmware may halt after receiving an
unknown instruction, but that it should be possible to tell the firmware
to continue running by simply sending a device resume command. So lets
do that.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
Rather than dumping out hex values, lets print the actual calculated
frequency and period the hardware has been configured for. After this
change:
[ 2643.276215] mceusb 3-1:1.0: tx data: 9f 07 (length=2)
[ 2643.276218] mceusb 3-1:1.0: Get carrier mode and freq
[ 2643.277206] mceusb 3-1:1.0: rx
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/rc/mceusb.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index e4171f7..bbd79c0 100644
--- a/drivers/media/rc/mceusb.c
+++
Add note about recent updates coming from Microsoft's publicly available
specs on Windows Media Center remotes and receivers/transmitters.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/rc/mceusb.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git
Supposedly, there are essentially three different classes of devices
that are compatible with Microsoft's specs. First are the legacy
devices, which are built using Microsoft-provided hardware specs and
firmware. Second are emulator devices, which are built using custom
hardware and firmware,
According to the specs, you can read the number of tx ports, number of
rx sensors, which tx ports have cables plugged into them, and which rx
sensors are active. In practice, most of my devices do seem to report
sane values for tx ports and rx sensors (but not all -- one without any
tx ports
I was recently pointed to the document titled
Windows-Media-Center-RC-IR-Collection-Green-Button-Specification-03-08-2011-V2.pdf
which as of this writing, is publicly available from
download.microsoft.com. It covers a LOT of the gaps in the mceusb
driver, which to this point, was written almost
On Fri, Jul 15, 2011 at 12:02:06AM +0200, Guennadi Liakhovetski wrote:
On Fri, 15 Jul 2011, Sakari Ailus wrote:
Hi Guennadi,
Thanks for the comments.
On Thu, Jul 14, 2011 at 07:56:10PM +0200, Guennadi Liakhovetski wrote:
On Thu, 14 Jul 2011, Sakari Ailus wrote:
Hi all,
On Fri, 15 Jul 2011, Sakari Ailus wrote:
On Fri, Jul 15, 2011 at 12:02:06AM +0200, Guennadi Liakhovetski wrote:
On Fri, 15 Jul 2011, Sakari Ailus wrote:
Hi Guennadi,
Thanks for the comments.
On Thu, Jul 14, 2011 at 07:56:10PM +0200, Guennadi Liakhovetski wrote:
On Thu,
Em 14-07-2011 19:09, Jarod Wilson escreveu:
Sometimes the init routine is blasting commands out to the hardware
faster than it can reply. Throw a brief delay in there to give the
hardware a chance to reply before we send the next command.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
On Monday 04 July 2011 02:17:52 Mauro Carvalho Chehab wrote:
Em 03-07-2011 20:24, Oliver Endriss escreveu:
...
Anyway, I spent the whole weekend to re-format the code carefully
and create both patch series, trying not to break anything.
I simply cannot go through the driver code and verify
Em 14-07-2011 20:45, Oliver Endriss escreveu:
On Monday 04 July 2011 02:17:52 Mauro Carvalho Chehab wrote:
Em 03-07-2011 20:24, Oliver Endriss escreveu:
...
Anyway, I spent the whole weekend to re-format the code carefully
and create both patch series, trying not to break anything.
I simply
Em 14-07-2011 02:39, Stas Sergeev escreveu:
14.07.2011 02:00, Mauro Carvalho Chehab wrote:
Now that we don't have the output mute switch, we
allow the alsa driver to unmute not only the recording
that it may need, but also the sound output that goes
to the sound card! IMHO, this is the
Hi,
2 to 7 will be not needed. I screwed up a autoconf.h generation while
refactoring the code. This is being addressed in the kbuild tree by:
https://patchwork.kernel.org/patch/975652/
My bad,
- Arnaud
On Sun, Jul 10, 2011 at 3:53 PM, Randy Dunlap rdun...@xenotime.net wrote:
From: Randy
Hi,
On Thu, Jul 14, 2011 at 11:03 PM, Alan Stern st...@rowland.harvard.edu wrote:
All right; this tends to confirm your guess that the BIOS messes up the
device by resetting it during system resume.
Yes. BIOS messes the device first, then usbcore has to reset the device
at the end of resume,
On Friday 15 July 2011 02:47:27 Mauro Carvalho Chehab wrote:
Em 14-07-2011 20:45, Oliver Endriss escreveu:
On Monday 04 July 2011 02:17:52 Mauro Carvalho Chehab wrote:
Em 03-07-2011 20:24, Oliver Endriss escreveu:
...
Anyway, I spent the whole weekend to re-format the code carefully
and
On 7/8/11, Mauro Carvalho Chehab mche...@redhat.com wrote:
I prefer to not rush merging it, because I don't have the pac207 datasheets,
and it is a good idea to have more tests on it. What webcams had you test
needing such fix?
The camera I have this[1] one. It is identified as ID 093a:2460
Hello,
That's the first time I submit a patch to the Linux kernel. I hope I could do
it right; please forgive me in case of mistakes.
The context: when migrating from Slackware 13.1 to 13.37 (kernel 2.6.33.x to
2.6.37.6), there was some sort of regression with the external webcam installed
at
Em 14-07-2011 21:47, Mauro Carvalho Chehab escreveu:
Em 14-07-2011 20:45, Oliver Endriss escreveu:
- DVB-T tuning does not work anymore.
I think that the better is to revert my patch and apply a solution similar
to cxd2820r_attach. It should work fine if called just once (like
Em 14-07-2011 23:11, Oliver Endriss escreveu:
On Friday 15 July 2011 02:47:27 Mauro Carvalho Chehab wrote:
Em 14-07-2011 20:45, Oliver Endriss escreveu:
On Monday 04 July 2011 02:17:52 Mauro Carvalho Chehab wrote:
Em 03-07-2011 20:24, Oliver Endriss escreveu:
...
Anyway, I spent the whole
Em 14-07-2011 20:45, Oliver Endriss escreveu:
- DVB-T tuning does not work anymore.
The enclosed patch should fix the issue. It were due to a wrong goto error
replacements that happened at the changeset that were fixing the error
propagation logic. Sorry for that.
Please test.
Cheers,
Mauro.
On Friday 15 July 2011 06:18:27 Mauro Carvalho Chehab wrote:
Em 14-07-2011 20:45, Oliver Endriss escreveu:
- DVB-T tuning does not work anymore.
The enclosed patch should fix the issue. It were due to a wrong goto error
replacements that happened at the changeset that were fixing the error
15.07.2011 05:38, Mauro Carvalho Chehab wrote:
Huh? The first time, you said it were due to pulseaudio. Then, you
Yes: pulseaudio does some capturing at startup.
(or, possibly, just opens the capture device). Without
it, nothing bad happens, but I never said the bug is
in pulseaudio.
said it
63 matches
Mail list logo
