Hi,
On 06/17/2014 02:38 AM, Vincent Palatin wrote:
> Map V4L2_CID_TILT_RELATIVE and V4L2_CID_PAN_RELATIVE to the standard UVC
> CT_PANTILT_ABSOLUTE_CONTROL terminal control request.
s/ABSOLUTE/RELATIVE in the commit message here.
Otherwise looks good to me.
Regards,
Hans
>
> Tested by plugg
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Tue Jun 17 04:00:18 CEST 2014
git branch: test
git hash: f7a27ff1fb77e114d1059a5eb2ed1cffdc508ce8
gcc versi
Map V4L2_CID_TILT_RELATIVE and V4L2_CID_PAN_RELATIVE to the standard UVC
CT_PANTILT_ABSOLUTE_CONTROL terminal control request.
Tested by plugging a Logitech ConferenceCam C3000e USB camera
and controlling pan/tilt from the userspace using the VIDIOC_S_CTRL ioctl.
Verified that it can pan and tilt
---
utils/keytable/keytable.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/utils/keytable/keytable.c b/utils/keytable/keytable.c
index 065ac3b..ba98cd3 100644
--- a/utils/keytable/keytable.c
+++ b/utils/keytable/keytable.c
@@ -86,6 +86,7 @@ enum i
On 06/16/2014 05:08 AM, Hans Verkuil wrote:
> Scott,
>
> Here is the correct version :-) Can you verify that it works for you?
>
> Regards,
>
> Hans
>
> When the audio encoding is changed the driver calls hdpvr_set_audio
> with the current opt->audio_input value. However, that should have
> b
Em Mon, 16 Jun 2014 15:04:44 -0400
Devin Heitmueller escreveu:
> >> The official TV playback application, found on the CD with drivers,
> >> captures samples from the card into its buffer, and plays from the other
> >> end of the buffer concurrently. If there are, on average for a few
> >> second
>> The official TV playback application, found on the CD with drivers,
>> captures samples from the card into its buffer, and plays from the other
>> end of the buffer concurrently. If there are, on average for a few
>> seconds, too few samples in the buffer, it means that they are consumed
>> fast
Em Mon, 16 Jun 2014 23:16:02 +0600
"Alexander E. Patrakov" escreveu:
> 16.06.2014 22:24, Mauro Carvalho Chehab wrote:
> > Em Mon, 16 Jun 2014 20:38:52 +0600
> > "Alexander E. Patrakov" escreveu:
> >
> >> 16.06.2014 20:21, Mauro Carvalho Chehab wrote:
> >>> Both xawtv and tvtime use the same code
We offer all purpose loan at 3% interest rate. Contact Us for more details by
Email:santanderfinancegr...@gmail.com
--
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/majordo
on Linux v3.16-rc1, building docbooks to a separate build directory
(mkdir DOC; make O=DOC htmldocs) gives me more than 12,000 lines like this:
grep: ./Documentation/DocBook//vidioc-subdev-g-fmt.xml: No such file or
directory
grep: ./Documentation/DocBook//vidioc-subdev-g-frame-interval.xml: No s
16.06.2014 22:24, Mauro Carvalho Chehab wrote:
Em Mon, 16 Jun 2014 20:38:52 +0600
"Alexander E. Patrakov" escreveu:
16.06.2014 20:21, Mauro Carvalho Chehab wrote:
Both xawtv and tvtime use the same code for audio:
http://git.linuxtv.org/cgit.cgi/xawtv3.git/tree/common/alsa_stream.c
T
Em Mon, 16 Jun 2014 20:38:52 +0600
"Alexander E. Patrakov" escreveu:
> 16.06.2014 20:21, Mauro Carvalho Chehab wrote:
> > Both xawtv and tvtime use the same code for audio:
> > http://git.linuxtv.org/cgit.cgi/xawtv3.git/tree/common/alsa_stream.c
> >
> > There's an algorithm there that gets th
Em Mon, 16 Jun 2014 09:22:08 -0400
Devin Heitmueller escreveu:
> > This looks like a workaround for a userspace bug that would affect all
> > USB audio devices. What period/buffer sizes are xawtv/tvtime trying to
> > use?
>
> I have similar concerns, although I don't know what the right solutio
Fix a regression introduced in commit
efc29f1764a30808ebf7b3e1d9bfa27b909bf641 (libv4lconvert: Reject too
short source buffer before accessing it).
The old code:
case V4L2_PIX_FMT_Y10BPACK:
...
if (result == 0 && src_size < (width * height * 10 / 8)) {
V4LCONVERT_E
16.06.2014 20:21, Mauro Carvalho Chehab wrote:
Both xawtv and tvtime use the same code for audio:
http://git.linuxtv.org/cgit.cgi/xawtv3.git/tree/common/alsa_stream.c
There's an algorithm there that gets the period size form both the
capture and the playback cards, trying to find a minim
Em Mon, 16 Jun 2014 09:39:17 +0200
Clemens Ladisch escreveu:
> (CC stable dropped; this is not how to submit stable patches.)
>
> Mauro Carvalho Chehab wrote:
> > The Auvitek 0828 chip, used on HVR950Q actually need two
> > quirks and not just one.
> >
> > The first one, already implemented, enf
On Mon, Jun 09, 2014 at 12:08:13AM +0600, Alexander Bersenev wrote:
> This patch enables two IR devices in dts:
> - One IR device physically found on Cubieboard 2
> - One IR device physically found on Cubietruck
>
> Signed-off-by: Alexander Bersenev
> Signed-off-by: Alexsey Shestacov
Applied, t
Hi,
On Mon, Jun 09, 2014 at 12:08:11AM +0600, Alexander Bersenev wrote:
> This patch adds pins for two IR controllers on A20
>
> Signed-off-by: Alexander Bersenev
> Signed-off-by: Alexsey Shestacov
Applied, thanks.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android e
Hi,
On Mon, Jun 09, 2014 at 12:08:12AM +0600, Alexander Bersenev wrote:
> This patch adds records for two IR controllers on A20
>
> Signed-off-by: Alexander Bersenev
> Signed-off-by: Alexsey Shestacov
> ---
> arch/arm/boot/dts/sun7i-a20.dtsi | 18 ++
> 1 file changed, 18 insert
> This looks like a workaround for a userspace bug that would affect all
> USB audio devices. What period/buffer sizes are xawtv/tvtime trying to
> use?
I have similar concerns, although I don't know what the right solution
is. For example, the last time Mauro tweaked the latency in tvtime,
it b
y
>
> By the way, I found myself staring at the entries in this file for quite
> some time. Perhaps things would have been easier to understand if
> SMS_USB_DRV and SMS_SDIO_DRV both selected SMS_SIANO_MDTV. But I didn't
> dare to test that idea.
This can still be see
Hello.
On 06/15/2014 11:56 PM, Ben Dooks wrote:
Add pinctrl definitions for i2c1 and i2c2 busses on the Lager board
to ensure these are setup correctly at initialisation time. The i2c0
and i2c3 busses are connected to single function pins.
Signed-off-by: Ben Dooks
Likewise, this as bee
On 06/16/2014 12:11 PM, Denis Carikli wrote:> + reg_lcd_3v3: lcd-en {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_reg_lcd_3v3>;
> + regulator-name = "lcd-3v3";
> + regulator-min-microvolt = <330>
Hello.
On 06/15/2014 11:56 PM, Ben Dooks wrote:
Add i2c0, i2c1, i2c2 and i2c3 nodes to the Lager reference device tree as
these busses all have devices on them that can be probed even if they
are no drivers yet.
Signed-off-by: Ben Dooks
---
arch/arm/boot/dts/r8a7790-lager.dts | 16 +++
Scott,
Here is the correct version :-) Can you verify that it works for you?
Regards,
Hans
When the audio encoding is changed the driver calls hdpvr_set_audio
with the current opt->audio_input value. However, that should have
been opt->audio_input + 1. So changing the audio encoding ina
On 06/16/2014 02:04 PM, Hans Verkuil wrote:
> Scott,
>
> Please verify that this solves your problem. It worked for me.
Never mind, I'll repost the right patch in a minute.
Hans
>
> Hans
>
>
> When the audio encoding is changed the driver calls hdpvr_set_audio
> with the curren
Scott,
Please verify that this solves your problem. It worked for me.
Hans
When the audio encoding is changed the driver calls hdpvr_set_audio
with the current opt->audio_input value. However, that should have
been opt->audio_input + 1. So changing the audio encoding inadvertently
chang
Hi Sakari,
On 06/16/2014 10:53 AM, Sakari Ailus wrote:
Hi Jacek and others,
Comments from the LED API folks would be highly appreciated.
(Cc linux-media as well.)
My comments below.
On Fri, May 09, 2014 at 04:28:44PM +0200, Jacek Anaszewski wrote:
During review of "LED / flash API integrati
Hi Hans,
On Mon, Jun 16, 2014 at 10:48 AM, Hans Verkuil wrote:
> Prabhakar,
>
> Are you going to make a pull request for this, or shall I take it? Should it
> be applied
> to 3.16?
>
As this is not a critical bug, I was planning to wait for v3.17 as
v3.16 is almost closed.
Regards,
--Prabhakar
Two bug fixes that should go to 3.16 (the dv-timings.c fix even for 3.12 and
up).
Regards,
Hans
The following changes since commit f7a27ff1fb77e114d1059a5eb2ed1cffdc508ce8:
[media] xc5000: delay tuner sleep to 5 seconds (2014-05-25 17:50:16 -0300)
are available in the git repository
On Mon, Jun 16, 2014 at 12:11:17PM +0200, Denis Carikli wrote:
> The current BGR666 is not consistent with the other color mapings like BGR24.
> BGR666 should be in the same byte order than BGR24.
>
> Signed-off-by: Denis Carikli
> Acked-by: Philipp Zabel
As I said probably around v10 time, I a
On Mon, Jun 16, 2014 at 12:11:16PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli
> Acked-by: Philipp Zabel
As I said probably around v10 time, I already have this patch queued,
and I was going to send it to Greg before the previous merge window,
but due to the number of patches I wa
On Mon, Jun 16, 2014 at 12:11:15PM +0200, Denis Carikli wrote:
> That new macro is needed by the imx_drm staging driver
> for supporting the QVGA display of the eukrea-cpuimx51 board.
As I said probably around v10 time, I already have this patch queued,
and I was going to send it to Greg before
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- None
ChangeLog v12->v13:
- Added a note explaining why the size is zero in
the eukrea_mbimxsd51_dvi(s)vga structs.
ChangeLog v11->v12:
- Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names
ChangeLog v10->v11:
- New patch.
The CMO-QVGA, DVI-SVGA and DVI-VGA are added.
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- None
ChangeLog v10->v13:
- Rebased
- Removed enable-active-high in reg_lcd_3v3: its GPIO
already has the GPIO_ACTIVE_HIGH flag.
Without this removal, the display was off at boot
and powerin
The imx-drm driver can't use the de-active and
pixelclk-active display-timings properties yet.
Instead the data-enable and the pixel data clock
polarity are hardcoded in the imx-drm driver.
So theses properties are now set to keep
the same behaviour when imx-drm will start
using them.
Signed-off
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- None
ChangeLog v11->v13:
- No changes
ChangeLog v9->v11:
- Now uses the drm-panel instead of the display-timings.
ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- The backlight is now on at boot.
ChangeLog
The previous hardware behaviour was kept if the
flags are not set.
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- Rebased
ChangeLog v12->v13:
- This patch doesn't need the DRM_MODE_FLAG_POL_*_PRESERVE flags anymore.
- code cleanup to improve readability:
- ENABLE_POL_PRESERVE is now go
We need a way to pass signal polarity informations
between DRM panels, and the display drivers.
To do that, a pol_flags field was added to drm_display_mode.
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- Fixed DRM_MODE_FLAG_POL_DE_HIGH's description.
ChangeLog v12->v13:
- Added Docbook
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- Rebased
ChangeLog 12->v13:
- No changes
ChangeLog 11->v12:
- Improved the define names to match the hardware:
ENABLE_POL is not a clock signal but instead an enable signal.
ChangeLog v9->v10:
- New patch which was splitted out from:
"stag
The current BGR666 is not consistent with the other color mapings like BGR24.
BGR666 should be in the same byte order than BGR24.
Signed-off-by: Denis Carikli
Acked-by: Philipp Zabel
---
ChangeLog v13->v14:
- Rebased
ChangeLog v10->v13:
- Rebased
ChangeLog v9->v10:
- Rebased.
- Added Philipp Zab
That new macro is needed by the imx_drm staging driver
for supporting the QVGA display of the eukrea-cpuimx51 board.
Signed-off-by: Denis Carikli
Acked-by: Mauro Carvalho Chehab
Acked-by: Laurent Pinchart
Acked-by: Philipp Zabel
---
ChangeLog v13->v14:
- None
ChangeLog v10->v13:
- No changes
Signed-off-by: Denis Carikli
Acked-by: Philipp Zabel
---
ChangeLog v13->v14:
- Rebased
ChangeLog v9->v13:
- Rebased
ChangeLog v8->v9:
- Rebased.
- Added Philipp Zabel's ack.
- Shortened the patch title.
ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- Rebased.
On 06/12/2014 05:45 PM, Devin Heitmueller wrote:
> Support for Open Firmware was introduced in the V4L2 tree, but
> it depends on features only found in 3.5+. Add a patch to disable
> the support for earlier kernels.
>
> Tested on Ubuntu 10.04 with kernel 3.2.0-030200-generic (which has
> CONFIG_
Prabhakar,
Are you going to make a pull request for this, or shall I take it? Should it be
applied
to 3.16?
Regards,
Hans
On 06/13/2014 08:13 PM, Prabhakar Lad wrote:
> On Thu, Jun 12, 2014 at 8:01 AM, Dan Carpenter
> wrote:
>> We recently changed some locking around so we need some
On 06/09/2014 03:51 PM, Thiago Santos wrote:
> Adds options to allow the buffer dqbuf to happen on one thread while
> the qbuf happens on another. This is useful to test concurrency access to
> the v4l2 features. To enable this, 3 new options were added:
>
> t: enable threaded mode (off by default
Is there any objection if the vbi-test.c and v4lgrab.c utilities are removed
from
the v4l-utils.git? The v4lgrab.c is a v4l1 capture utility that no longer works
since CONFIG_VIDEO_V4L1_COMPAT no longer exists.
vbi-test.c just prints the vbi parameters, which 'v4l2-ctl --get-fmt-vbi' also
does. I
Hi Jacek and others,
Comments from the LED API folks would be highly appreciated.
(Cc linux-media as well.)
My comments below.
On Fri, May 09, 2014 at 04:28:44PM +0200, Jacek Anaszewski wrote:
> During review of "LED / flash API integration" patch sets two issues
> requiring modifications in th
Hello,
No one can give me more information about these registers ?
Thank you.
Bets regards,
Gaëtan Carlier.
On 06/03/2014 10:32 AM, Gaëtan Carlier wrote:
Dear,
I am back to add support of h.264 decoding using Coda DX6 on i.MX27
(after long months of inactivity).
I base my work on driver from lin
Hi Philipp,
I went through this patch series and replied with some comments.
I have two more general questions:
1) can you post the output of 'v4l2-compliance'?
2) what would be needed for 'v4l2-compliance -s' to work?
For the encoder 'v4l2-compliance -s' will probably work OK, but for
the deco
On 06/13/2014 06:08 PM, Philipp Zabel wrote:
> This disables forcing IDR frames at GOP size intervals on CODA7541 and
> CODA960,
> which is only needed to work around a firmware bug on CodaDx6.
> Instead, the V4L2_BUF_FLAG_KEYFRAME v4l2 buffer flag is cleared before marking
> the source buffer don
know -> known
Signed-off-by: Hans Verkuil
---
Documentation/DocBook/media/v4l/io.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/DocBook/media/v4l/io.xml
b/Documentation/DocBook/media/v4l/io.xml
index a086a5d..8c4ee74 100644
--- a/Documentation/DocBook/medi
On 06/13/2014 06:08 PM, Philipp Zabel wrote:
> This patch adds support for the VIDIOC_ENUM_FRAMESIZES ioctl.
> When decoding H.264, the output frame size is rounded up to the
> next multiple of the macroblock size (16 pixels).
Why do you need this? Implementing VIDIOC_ENUM_FRAMESIZES for a m2m dev
On 06/13/2014 06:08 PM, Philipp Zabel wrote:
> The h.264 decoder produces capture frames that are a multiple of the
> macroblock
> size (16 pixels). To inform userspace about invalid pixel data at the edges,
> use the active and padded composing rectangles on the capture queue.
> The cropping info
On 06/13/2014 06:08 PM, Philipp Zabel wrote:
> Currently the rotator unit is used to copy decoded frames out into buffers
> provided by videobuf2. Since the CODA reports the I/P/B frame type of the
> last decoded frame, and this frame will be copied out in a later device_run,
> depending on display
(CC stable dropped; this is not how to submit stable patches.)
Mauro Carvalho Chehab wrote:
> The Auvitek 0828 chip, used on HVR950Q actually need two
> quirks and not just one.
>
> The first one, already implemented, enforces that it won't have
> channel swaps at the transfers.
>
> However, for T
The saa7134 driver uses core-locking, so there is no longer any need
to use the ioctl op instead of the unlocked_ioctl op. This change
was forgotten for the saa7134-empress.c, so fix this.
Signed-off-by: Hans Verkuil
---
drivers/media/pci/saa7134/saa7134-empress.c | 2 +-
1 file changed, 1 inser
57 matches
Mail list logo
