Currently the colors for the Y16 and Y16_BE pixelformats are in the range
0x-0xff00. So pure white (0x) is never created.
Improve this by making white really white. For other colors the lsb remains 0
so vivid can be used to detect endian problems.
Signed-off-by: Hans Verkuil
diff --git
Hi Kyle,
Great to hear you haven't had any problems since applying this patch!
I'm looking forward to seeing it in the Linux master branch too.
Version 5 of the patch has been accepted and committed to the media tree
by Mauro:
http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?id=7797808
This has been plaguing users for years (there's a number of threads on
the Ubuntu board). I've been using revision 1 of the patch without
issue since early February. This is from having to constantly reboot
the system to flawless recording. If something has been outstanding
from Brendan, please let
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: Fri Jun 5 04:02:25 CEST 2015
git branch: test
git hash: c1c3c85ddf60a6d97c122d57d385b4929fcec4b3
gcc versi
Hi folks
just a brief comment on this one:
On Thu, 30 Apr 2015, Boris Brezillon wrote:
> Clock rates are stored in an unsigned long field, but ->round_rate()
> (which returns a rounded rate from a requested one) returns a long
> value (errors are reported using negative error codes), which can l
On 06/04/2015 08:36 PM, Hurda wrote:
How can I enable debug-output to get the log-messages like
http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/dvb-frontends/si2168.c#n164
?
Compile kernel with dynamic debugs. After that you could enable debugs:
modprobe si2168; echo -n 'mod
How can I enable debug-output to get the log-messages like
http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/dvb-frontends/si2168.c#n164
?
Am 28.05.2015 07:26, schrieb Antti Palosaari:
On 05/28/2015 01:27 AM, Hurda wrote:
Hello.
I think I came across a bug in either of the dr
Vinod,
On 06/02/2015 03:55 PM, Vinod Koul wrote:
> On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote:
>> On 05/29/2015 01:18 PM, Vinod Koul wrote:
>>> On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote:
On Fri, May 29, 2015 at 11:33 AM, Vinod Koul wrote:
> On
Thank you for the replies. Laurent I have started using the platform
data to see if I can determine whether I have a software problem or a
hardware problem. One thing that is confusing me, is how are memory
resources are supposed to be properly mapped to a kernel module in a
DT enabled kernel using
On Thu, Jun 4, 2015 at 9:22 AM, Olli Salonen wrote:
> I compiled an old HVR-2205 driver from my git tree:
> https://github.com/trsqr/media_tree/tree/hvr2205
https://github.com/trsqr/media_tree/commit/61c2ef874b8a9620f498c9a4ab4138e97119462b
That's the difference perhaps.
--
Steven Toth - Kerne
I suspect saa7164 driver. It has some strange looking I2C hacks. It has
even some logic to split register and data - which I2C adapter should
not be aware at all - it just should transfer bulk bytes.
regards
Antti
On 06/04/2015 04:22 PM, Olli Salonen wrote:
I compiled an old HVR-2205 driver f
I compiled an old HVR-2205 driver from my git tree:
https://github.com/trsqr/media_tree/tree/hvr2205
And kaboom, the device is identified correctly and correct firmware is loaded:
[ 882.227379] si2168 1-0064: found a 'Silicon Labs Si2168-B40'
[ 882.227763] si2168 1-0064: downloading firmware fr
>> This fix works well for me and properly enables DVB-T tuning behavior
>> using tzap.
>>
>> Thanks to Peter Faulkner-Ball for describing his workaround.
>
>
> hymm, I am not sure that patch at all. It is Olli who has been responsible
> adding support for multiple chip revisions, so I will leave t
I'll test it with my old code I should have hanging around still
somewhere. I'm sure the chip on my card has been previously been
identified as Si2168-B40 by the code (I posted the logs already
earlier) and it definitely has not turned into a Si2168-D40 chip
somehow.
I don't think there's version
On 06/04/2015 03:38 PM, Steven Toth wrote:
We're seeing a mix of SI2168 demodulators appearing on HVR2205 and
HVR2215 cards, the chips are stamped with different build dates,
verified on my cards.
The si2168 driver detects some cards fine, others not at all. I can
reproduce the working and non-w
> If the GPIOs aren't truly resetting the SI2168 and thus a warm boot
> didn't flush the firmware, I suspect dropping the patches would have
> no immediate effect until a full power-down took place. I'm wondering
> whether the testing was invalid and indeed we have a problem in the
> field, as well
Antti, for your records here's the I2C reply when the si2168 asks for
the chip id from one of these newer D40 chips:
80 00 44 34 30 02 00 00 00 00 00 00 00 00
It might make sense to change the "unknown chip version Si21%d-%c%c%c"
default message to include a hex dump of the first 5 bytes, to
acce
We're seeing a mix of SI2168 demodulators appearing on HVR2205 and
HVR2215 cards, the chips are stamped with different build dates,
verified on my cards.
The si2168 driver detects some cards fine, others not at all. I can
reproduce the working and non-working case. The fix, if we detect a
newer ca
On 27 May 2015 at 16:05, Laurent Pinchart
wrote:
> Even though 'compatability' has a dedicated entry in the Wiktionary,
> it's listed as 'Mispelling of compatibility'. Fix it.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/net/wireless/ipw2x00/ipw2100.h | 2 +-
>
Acked-by: Stanislav Yakov
Hi,
On 04-06-15 10:52, Dan Carpenter wrote:
We already know status is negative because of the earlier check so there
is no need to check again.
Signed-off-by: Dan Carpenter
Makes sense:
Acked-by: Hans de Goede
Mauro, can you pick this one up directly please?
Regards,
Hans
diff --git
We already know status is negative because of the earlier check so there
is no need to check again.
Signed-off-by: Dan Carpenter
diff --git a/drivers/media/usb/gspca/sn9c2028.c
b/drivers/media/usb/gspca/sn9c2028.c
index c75b738..4f2050a 100644
--- a/drivers/media/usb/gspca/sn9c2028.c
+++ b/driv
My card has been always installed in a machine that does not have
Windows, so any interference with the Windows driver should not be an
issue. I found some old console logs from February 21 when I was
trying to put together a driver for the board. It shows that the
Si2168 chip on my board was at th
22 matches
Mail list logo