You are a recipient to Mrs Julie Leach Donation of $3 million USD. Contact (
julieleac...@gmail.com ) for claims.
--
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
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: Sun Nov 27 05:00:18 CET 2016
media-tree git hash:d3d83ee20afda16ad0133ba00f63c11a8d842a35
media_build git
>>
>> However when you try to use the new mapping in some application then
>> it does not work?
>
> That's correct. ir-keytable seems to be doing the right thing, mapping
> the scancode to the input-event-codes.h key code I asked it to.
>
> The application I am trying to use it with is the mythtv f
On Fri, 25 Nov 2016, Laurent Pinchart wrote:
> Hi Alan,
Hello.
> On Friday 25 Nov 2016 10:21:21 Alan Stern wrote:
> > On Fri, 25 Nov 2016, Sakari Ailus wrote:
> > > On Thu, Nov 24, 2016 at 09:15:39PM -0500, Alan Stern wrote:
> > >> On Fri, 25 Nov 2016, Laurent Pinchart wrote:
> > >>> Dear linux-
On Sun, Nov 13, 2016 at 10:29 AM, Antti Palosaari wrote:
> Remove DVB-T2 BER as it does not work at all and I didn't find
> how to fix.
>
> Fix DVB-T and DVB-C BER. It seems to return new some realistic
> looking values.
>
> Use (1 << 64) base for CNR calculations to keep it in line with
> dvb log
Using sprintf() with a non-literal string makes some compiler complain
when building with -Wformat-security (eg. clang reports "format string
is not a string literal (potentially insecure)").
Here sprintf() format parameter is indirectly a literal string so there
is no security issue. Nevertheles
-i2c-driver/20161126-144805
base: git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-x015-201648 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings
On 26 November 2016 at 10:52, Marcel Hasler wrote:
> 2016-11-20 18:36 GMT+01:00 Ezequiel Garcia :
>> On 27 October 2016 at 17:35, Marcel Hasler wrote:
>>> Allow setting a custom record gain for the internal AC97 codec (if
>>> available). This can be
>>> a value between 0 and 15, 8 is the default
On 26 November 2016 at 10:38, Marcel Hasler wrote:
> Hello, and thanks for your feedback.
>
> 2016-11-20 18:36 GMT+01:00 Ezequiel Garcia :
>> Marcel,
>>
>> On 27 October 2016 at 17:34, Marcel Hasler wrote:
>>> Exposing all the channels of the device's internal AC97 codec to userspace
>>> is unne
2016-11-20 18:37 GMT+01:00 Ezequiel Garcia :
> On 28 October 2016 at 05:52, Marcel Hasler wrote:
>> 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
>
2016-11-20 18:37 GMT+01:00 Ezequiel Garcia :
> On 28 October 2016 at 05:52, Marcel Hasler wrote:
>> 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
>
2016-11-20 18:36 GMT+01:00 Ezequiel Garcia :
> On 27 October 2016 at 17:35, Marcel Hasler wrote:
>> Allow setting a custom record gain for the internal AC97 codec (if
>> available). This can be
>> a value between 0 and 15, 8 is the default and should be suitable for most
>> users. The Windows
>>
2016-11-20 18:36 GMT+01:00 Ezequiel Garcia :
> On 27 October 2016 at 17:34, Marcel Hasler wrote:
>> Some STK1160-based devices use the chip's internal 8-bit ADC. This is
>> configured through a strap
>> pin. The value of this and other pins can be read through the POSVA
>> register. If the inter
Hello, and thanks for your feedback.
2016-11-20 18:36 GMT+01:00 Ezequiel Garcia :
> Marcel,
>
> On 27 October 2016 at 17:34, Marcel Hasler wrote:
>> Exposing all the channels of the device's internal AC97 codec to userspace
>> is unnecessary and
>> confusing. Instead the driver should setup the
Hi!
> 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
Hi Dan,
On Sat, Nov 26, 2016 at 12:57:17PM +0300, Dan Carpenter wrote:
> Hello Sean Young,
>
> The patch afbb110172b9: "[media] lirc: prevent use-after free" from
> Oct 31, 2016, leads to the following static checker warning:
>
> drivers/media/rc/lirc_dev.c:190 lirc_cdev_add()
> erro
Hello Sean Young,
The patch afbb110172b9: "[media] lirc: prevent use-after free" from
Oct 31, 2016, leads to the following static checker warning:
drivers/media/rc/lirc_dev.c:190 lirc_cdev_add()
error: potential null dereference 'cdev'. (cdev_alloc returns null)
drivers/media/rc
17 matches
Mail list logo