o sit there not
starting the vid.
Without valgrind both will just play the vid without issue until I quit.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/arc
On (07/15/15 11:51), Michel Dänzer wrote:
> On 14.07.2015 22:41, Sergey Senozhatsky wrote:
> >
> > sometimes `xset dpms force off' just turns off the panel for a second,
> > sometimes -- until I generate a `wakeup' event (key press, etc.)
>
> FWIW, the former case is because releasing the enter
On (07/14/15 17:11), Daniel Vetter wrote:
> Have you forwarded to a more recent -nightly? I just merged a patch which
> might have fixed this ...
>
Hello,
yep, I use the most recent -next usually (update it everyday),
when it boots. I can't reproduce the problem so far, hopefully
the commit you m
David,
Please incorporate the latest Synopsis DesignWare HDMI driver development
updates, which can be found at:
git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-dwhdmi-devel
with SHA1 b2779af1fd087320ebde01614f770b12e2dc3e5c.
Here are some development updates for the Synopsis Designware HDM
This patch fix following warnings.
Warning(.//drivers/gpu/drm/drm_irq.c:1279): No description
found for parameter drm_crtc'
Warning(.//drivers/gpu/drm/drm_irq.c:1279): Excess function
parameter 'crtc' description in 'drm_crtc_vblank_reset'
Signed-off-by: Masanari Iida
---
drivers/gpu/drm/drm_ir
CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into CGM (Color Gamut Mapping) registers.
This patch does the following:
1. Adds the core function to program CSC correction values for
CHV/BSW platform
2. Adds CSC correction macros/defines
Signed-off
This patch adds set_property handler for CSC color correction
and enhancement capability at Pipe level on CHV/BSW platform. The set
function just attaches the CSC blob to CRTC state, that later
gets committed using atomic path.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
dr
Color Manager framework defines a color correction property for color
space transformation and Gamut mapping. This property is called CTM (Color
Transformation Matrix).
This patch adds a new structure in DRM layer for CTM color correction.
This structure will be used by all user space agents to co
CHV/BSW supports DeGamma color correction feature, which linearizes all
the non-linear color values. This will be applied before Color
Transformation.
This patch does the following:
1. Adds the core function to program DeGamma correction values for
CHV/BSW platform
2. Adds DeGamma correction ma
This patch adds set_property handler for deGamma color correction and
enhancement capability at Pipe level on CHV/BSW platform. The set
function just attaches the deGamma blob to CRTC state, that later gets
committed using atomic path.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
CHV/BSW platform supports various Gamma correction modes, which are:
1. Legacy 8-bit mode
2. 10-bit CGM (Color Gamut Mapping) mode
This patch does the following:
1. Adds the core function to program Gamma correction values for CHV/BSW
platform
2. Adds Gamma correction macros/defines
Signed-off
This patch adds set_property handler for Gamma color correction and
enhancement capability at Pipe level on CHV/BSW platform. The set
function just attaches the Gamma blob to CRTC state, that later gets
committed using atomic path.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
This patch adds new structures in DRM layer for Palette color
correction.
These structures will be used by user space agents to configure
appropriate number of samples and Palette LUT for a platform.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/uapi/drm/drm.h | 27 +
This patch adds blob properties to CRTC state to hold the respective
blobs for color properties. These will be required by set_property calls
to attach blobs for atomic commit later.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/drm/drm_crtc.h | 5 +
1 file change
This patch adds atomic set property interface for Intel CRTC. This
interface will be used to set color correction DRM properties.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_atomic.c | 11 +++
drivers/gpu/drm/i915/intel_display.c | 2 ++
As per Color Manager design, each driver is responsible to load its
palette color correction and enhancement capabilities in the form of
a DRM blob property, so that user space can query and read.
This patch loads all CHV platform specific gamma color capabilities
for CRTC into a blob that can be
drm_property_replace_global_blob() is getting used by many wrapper
functions to replace an existing blob with new values. Because this
function was static, modules are forced to create wrapper functions in
same file. Exporting this function will remove need for such wrapper
functions.
This patch m
The DRM color management framework is targeting various hardware
platforms and drivers. Different platforms can have different color
correction and enhancement capabilities.
A commom user space application can query these capabilities using the
DRM property interface. Each driver can fill this pro
This patch does the following:
1. Adds new files intel_color_manager(.c/.h)
2. Attaches color properties to CRTC while initialization
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/intel_color_manager.c |
Color Management is an extension to Kernel display framework. It allows
abstraction of hardware color correction and enhancement capabilities by
virtue of DRM properties.
This patch initializes color management framework by :
1. Introducing new pointers in DRM mode_config structure to
carry CTM
From: Matt Roper
The intel_atomic_check() function had some simple testing to make
sure that an atomic update isn't updating more than one CRTC at a time.
The logic assumed that a plane was always being updated, so it figured
out the "nuclear pipe" from the first plane it encountered and just mad
This patch set adds Color Manager implementation in DRM layer. Color Manager is
an extension in DRM framework to support color correction/enhancement. Various
Hardware platforms can support several color correction capabilities.
Color Manager provides abstraction of these capabilities and allows a
David,
Please incorporate the latest Armada DRM fixes fixes, which can be
found at:
git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-armada-fixes
with SHA1 c62ff6b3c7325c34d649a5fc3253445af1fd3ba8.
A range of fixes for the Armada DRM driver:
- A missing wakeup could result in overlay frames
This patch depends on "drm: add support for for clk and de polarity".
Since "drm: add support for for clk and de polarity", clock and data
polarity set in devicetree are passed correctly through drm_display_mode
to videomode flags used by ipuv3.
Removes custom configuration flags for clock and de p
To get full support for parallel and LVDS displays with drm:
Add representation for clock and data enable polarity in drm_display_mode
flags (similar to HSYNC/VSYNC polarity) and update conversion functions
from/to videomode accordingly.
This is especially important for embedded devices where para
Avoids legacy userspace/code getting confused when dpms doesn't
reflect reality of what's going on.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_help
Hello!
These patches address a problem we ran into using parallel displays
with Freescale i.MX53 and i.MX6 SoC's.
In short: We wanted to change the clock signal polarity by using
display-timing in the devicetree description, but the output signal stayed
unchanged.
Parallel displays may have diffe
On 15 July 2015 at 16:44, Daniel Vetter wrote:
> Avoids legacy userspace/code getting confused when dpms doesn't
> reflect reality of what's going on.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Daniel Stone
It doesn't change any bindings fields, only remove one level of childs on DT.
Old DTBs may not work but it will impact only very few peoples and no
products so it isn't a problem.
The patch fix driver and DT files so I don't think it could create issues.
2015-07-15 15:34 GMT+02:00 Thierry Reding
This only grabs the mutex when really needed, but still has a
might-acquire lockdep check to make sure that's always possible.
With this patch tegra is officially struct_mutex free, yay!
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/tegra/drm.c | 4 +---
drivers/gpu/drm/te
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
While at it also fix a leak when this ioctl is call
/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/3d432157/attachment.sig>
On 07/15/15 14:35, Hans Verkuil wrote:
> On 07/14/15 12:16, Daniel Vetter wrote:
>
>
>
> I would guess that a LUT supporting 16 bit color components would need a
> precision
> of 0.20 or so (assuming the resulting values are used in further
> calculations).
>
> High dyn
-
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/2c1e41a6/attachment.sig>
Fix misunderstanding in how use component framework.
drm_platform_init() is now call only when all the
sub-components are register themselves instead of the
previous two stages mechanism.
Update devicetree and bindings documentation according
to this new behavior.
Signed-off-by: Benjamin Gaignard
Thanks a lot Russell, I have now understand where was my mistake.
2015-07-15 12:42 GMT+02:00 Russell King - ARM Linux :
> On Wed, Jul 15, 2015 at 12:19:01PM +0200, Benjamin Gaignard wrote:
>> The build order in Makefile hasn't been change so the bug doesn't occur...
>>
>> In addition of taking ca
Thanks for the comments, Thierry.
We can surely do this.
Regards
Shashank
-Original Message-
From: Thierry Reding [mailto:thierry.red...@gmail.com]
Sent: Wednesday, July 15, 2015 6:55 PM
To: Malladi, Kausal
Cc: Roper, Matthew D; Barnes, Jesse; Lespiau, Damien; Jindal, Sonika; R,
Durgad
freedesktop.org/archives/dri-devel/attachments/20150715/3e7e031b/attachment.sig>
me that
it wasn't well documented and the behaviour seemed at odds with what
documentation there is (i.e. the function name).
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/39b41ca6/attachment.sig>
On 07/14/15 12:16, Daniel Vetter wrote:
I would guess that a LUT supporting 16 bit color components would need a
precision
of 0.20 or so (assuming the resulting values are used in further
calculations).
High dynamic range video will be an important driving force t
On Wed, Jul 15, 2015 at 07:25:42PM +0900, Masanari Iida wrote:
> This patch fix following warnings.
>
> Warning(.//drivers/gpu/drm/drm_irq.c:1279): No description
> found for parameter drm_crtc'
> Warning(.//drivers/gpu/drm/drm_irq.c:1279): Excess function
> parameter 'crtc' description in 'drm_cr
Hey there,
I've been discussing with Daniel Vetter about adding Markdown support to
kernel-doc.
There were some discussions about improving documentation flexibility and
although there were no
consensus at the time I believe (and I think others might agree) that Markdown
is best suit for this j
;
> - if (fd == -1)
> + if (fd < 0)
> return 0;
>
> v = drmGetDeviceNameFromFd(fd);
> --
> 2.4.5
>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/a12e00a5/attachment.sig>
rt --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/eb2817be/attachment.sig>
On 15 July 2015 at 12:47, Thierry Reding wrote:
> On Tue, Jul 14, 2015 at 03:10:04PM +0100, Emil Velikov wrote:
>> Spotted by looking for similar "let's assume fd == 0 is invalid" bugs.
>>
>> Cc: Thierry Reding
>> Signed-off-by: Emil Velikov
>> ---
>> xf86drm.c | 2 +-
>> 1 file changed, 1 inse
-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/1aee025d/attachment.sig>
one with no hangs :
https://bugs.freedesktop.org/attachment.cgi?id=117136
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/d18bf325/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/ded0f130/attachment.html>
The build order in Makefile hasn't been change so the bug doesn't occur...
In addition of taking care of not changing build order in Makefile,
I would like to understand what is the expected behavior of component
framework when
master call component_bind_all() before any component_add() calls.
Sh
The vidi is virtual kms driver and now it is registered earlier than
actual hw kms drivers, so it will occupy crtc index 0. Some users
assume the condition yet that actual hw kms driver has crtc index 0.
It may or may not be matter but let's arrange register order.
Signed-off-by: Joonyoung Shim
-
On 14.07.2015 22:41, Sergey Senozhatsky wrote:
>
> sometimes `xset dpms force off' just turns off the panel for a second,
> sometimes -- until I generate a `wakeup' event (key press, etc.)
FWIW, the former case is because releasing the enter key generates an
input event, which changes the DPMS st
On Wed, Jul 15, 2015 at 12:19:01PM +0200, Benjamin Gaignard wrote:
> The build order in Makefile hasn't been change so the bug doesn't occur...
>
> In addition of taking care of not changing build order in Makefile,
> I would like to understand what is the expected behavior of component
> framewor
Argh, I screwed up this doesn't even compile ...
-Daniel
On Wed, Jul 15, 2015 at 10:52 AM, Daniel Vetter
wrote:
> Hi Dave,
>
> Compared to the old drm-fixes pull request just added the compat32 patch
> from Tvrtko.
>
> Cheers, Daniel
>
>
> The following changes since commit e24ff467e12e1560de753
From: Dave Airlie
It appears some MST docks are worse than other, but the only
way to know is to see the sw revisions in here, so dump
the branch OUI so we can look at the sw revision.
v2: Theirry made me feel guilty, so I parsed the branch
OUI.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/
Hi Dave,
Compared to the old drm-fixes pull request just added the compat32 patch
from Tvrtko.
Cheers, Daniel
The following changes since commit e24ff467e12e1560de753313976c46e84fa6306a:
drm/crtc: Fix edid length computation (2015-07-04 00:52:34 +0200)
are available in the git repository at
Hi Dave,
Next batch of i915 fixes. Note that the compat32 patch here needs the drm
core one to be actually useful, I'll send you that one with a separate
drm-fixes pull request. One revert because a fix in -rc2 did break
existing userspace.
Cheers, Daniel
The following changes since commit bc01
From: Tvrtko Ursulin
Frame buffer modifiers extensions provided in;
commit e3eb3250d84ef97b766312345774367b6a310db8
Author: Rob Clark
Date: Thu Feb 5 14:41:52 2015 +
drm: add support for tiled/compressed/etc modifier in addfb2
Missed the structure packing/alignment problem w
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_display.c
between commit:
ccfb8b2ed4d4 ("rm/i915: Do not call intel_crtc_disable if the crtc is already
disabled.")
from the drm-intel-fixes tree and commit:
69024de8ba9e ("drm/i915: ge
On 14 July 2015 at 18:28, Thierry Reding wrote:
> On Tue, Jul 14, 2015 at 11:34:39AM +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> It appears some MST docks are worse than other, but the only
>> way to know is to see the sw revisions in here, so dump
>> the branch OUI so we can look at the
On Mon, Jun 22, 2015 at 12:54 PM, Shobhit Kumar
wrote:
> In case we unload and load a driver module again that is registering a
> lookup table, without this it will result in multiple entries. Provide
> an option to remove the lookup table on driver unload
>
> v2: Ccing maintainers
> v3: Correct
from Max Qia ---
How would you revert a commit then bisect?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/1e060
/dri-devel/attachments/20150715/2e6d26f4/attachment.html>
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/cacf48b2/attachment.html>
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/1e7b69f5/attachment.html>
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/96d07a0d/attachment-0001.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/a0dd8903/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/d82c53c1/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/5e6f3019/attachment.html>
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/546a1601/attachment.html>
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/82e8b217/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/9fff3e3e/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/b9b707c9/attachment.html>
glxinfo.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/c714009f/attachment-0001.html>
-children=yes to valgrind?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150715/2b155d36/attachment.html>
74 matches
Mail list logo