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: Sat Oct 29 05:00:15 CEST 2016
media-tree git hash:bd676c0c04ec94bd830b9192e2c33f2c4532278d
media_build gi
On Fri, Oct 28, 2016 at 2:53 PM, Hans Verkuil wrote:
> Hi Matt,
>
> On 28/10/16 22:14, Matt Ranostay wrote:
>>
>> So want to toss a few thoughts on adding support for thermopile
>> devices (could be used for FLIR Lepton as well) that output pixel
>> data.
>> These typically aren't DMA'able devices
On Fri, Oct 28, 2016 at 1:30 PM, Devin Heitmueller
wrote:
> Hi Matt,
>
>> Need some input for the video pixel data types, which the device we
>> are using (see datasheet links below) is outputting pixel data in
>> little endian 16-bit of which a 12-bits signed value is used. Does it
>> make sense
On Fri, Oct 28, 2016 at 1:40 PM, Marek Vasut wrote:
> On 10/28/2016 10:30 PM, Devin Heitmueller wrote:
>> Hi Matt,
>>
>>> Need some input for the video pixel data types, which the device we
>>> are using (see datasheet links below) is outputting pixel data in
>>> little endian 16-bit of which a 12
Hi Matt,
On 28/10/16 22:14, Matt Ranostay wrote:
So want to toss a few thoughts on adding support for thermopile
devices (could be used for FLIR Lepton as well) that output pixel
data.
These typically aren't DMA'able devices since they are low speed
(partly to limiting the functionality to be in
On 10/28/2016 10:30 PM, Devin Heitmueller wrote:
> Hi Matt,
>
>> Need some input for the video pixel data types, which the device we
>> are using (see datasheet links below) is outputting pixel data in
>> little endian 16-bit of which a 12-bits signed value is used. Does it
>> make sense to do so
Hi Matt,
> Need some input for the video pixel data types, which the device we
> are using (see datasheet links below) is outputting pixel data in
> little endian 16-bit of which a 12-bits signed value is used. Does it
> make sense to do some basic processing on the data since greyscale is
> goin
So want to toss a few thoughts on adding support for thermopile
devices (could be used for FLIR Lepton as well) that output pixel
data.
These typically aren't DMA'able devices since they are low speed
(partly to limiting the functionality to be in compliance with ITAR)
and data is piped over i2c/sp
Le vendredi 28 octobre 2016 à 14:14 +0200, Michael Haardt a écrit :
> I am currently developing a new image v4l2 sensor driver to acquire
> sequences of still images and wonder how to interface that to the
> v4l2 API.
>
> Currently, cameras are assumed to deliver an endless stream of images
> afte
Kevin Hilman writes:
> This series attempts to add DT support to the davinci VPIF capture
> driver.
>
> I'm not sure I've completely grasped the proper use of the ports and
> endpoints stuff, so this RFC is primarily to get input on whether I'm
> on the right track.
>
> The last patch is the one
Hi Felipe,
On Fri, Oct 28, 2016 at 11:47:02AM -0200, Felipe Sanches wrote:
> but why?
Much of this information is outdated. There's some reasoning behind this in
the patch adding the check in scripts/checkpatch.pl:
commit 4783f894d0f3bfb107cf3b1d9aed1f1a0672ee1d
Author: Josh Triplett
Date: Tu
but why?
2016-10-28 10:43 GMT-02:00 Sakari Ailus :
> Drop the FSF's postal address from the source code files that typically
> contain mostly the license text. The patch has been created with the
> following command without manual edits:
>
> git grep -l "675 Mass Ave\|59 Temple Place\|51 Franklin
Drop the FSF's postal address from the source code files that typically
contain mostly the license text. The patch has been created with the
following command without manual edits:
git grep -l "675 Mass Ave\|59 Temple Place\|51 Franklin St" -- \
drivers/media/ include/media|while read i; d
I am currently developing a new image v4l2 sensor driver to acquire
sequences of still images and wonder how to interface that to the
v4l2 API.
Currently, cameras are assumed to deliver an endless stream of images
after being triggered internally with VIDIOC_STREAMON. If supported by
the driver,
This patch might need some explaining. I actually noticed this problem
early on while trying to fix the sound problem, but it was only this
morning that I realized the (trivial) cause of it.
I first noticed something strange going on when I read the AC97
registers from /proc/asound/cardX/codec97#0
Hi Andi,
On Fri, Oct 28, 2016 at 04:38:39PM +0900, Andi Shyti wrote:
> Hi Sean,
>
> > ret *= sizeof(unsigned int);
> >
> > - /*
> > -* The lircd gap calculation expects the write function to
> > -* wait for the actual IR signal to be transmitted before
> > -* returning.
> > -
The STK1160 needs some time to transfer data from the AC97 registers into its
own. On some
systems reading the chip's own registers to soon will return wrong values. The
"proper" way to
handle this would be to poll STK1160_AC97CTL_0 after every read or write
command until the
command bit has bee
Hi Sean,
> ret *= sizeof(unsigned int);
>
> - /*
> - * The lircd gap calculation expects the write function to
> - * wait for the actual IR signal to be transmitted before
> - * returning.
> - */
> - towait = ktime_us_delta(ktime_add_us(start, duration), ktime_g
On Thu, Oct 27, 2016 at 10:23:24PM +0200, Vincent Stehlé wrote:
> video_device_release() takes a pointer to struct video_device as argument.
> Fix two call sites where the address of the pointer is passed instead.
Sorry, I messed up: please ignore that "fix". The 0day robot made me
realize this is
19 matches
Mail list logo
