On 07/06/2015 11:56 PM, Alex Deucher wrote:
> On Mon, Jul 6, 2015 at 3:19 PM, Dave Jones wrote:
>> I wanted to switch my LCD to a different machine momentarily.
>> When I plugged the cable back in, this was on the screen..
>
> Is this readily reproducible? Did it happen with 4.1? If it also
> ha
On 07/07/2015 01:07 AM, Vadim Girlin wrote:
> On 07/06/2015 11:56 PM, Alex Deucher wrote:
>> On Mon, Jul 6, 2015 at 3:19 PM, Dave Jones
>> wrote:
>>> I wanted to switch my LCD to a different machine momentarily.
>>> When I plugged the cable back in, this was on the screen..
>>
>> Is this readily r
happen with that.
--
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/20150707/6a374e2a/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/61ece162/attachment.html>
On 07.07.2015 07:15, Vadim Girlin wrote:
> On 07/07/2015 01:07 AM, Vadim Girlin wrote:
>> On 07/06/2015 11:56 PM, Alex Deucher wrote:
>>> On Mon, Jul 6, 2015 at 3:19 PM, Dave Jones
>>> wrote:
I wanted to switch my LCD to a different machine momentarily.
When I plugged the cable back in,
export count from si_llvm_export_vs in si_shader_vs
--
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/20150707/1394c
On Mon, 06 Jul 2015 22:50:30 +0100
Steven Newbury wrote:
> Would gles1 be sufficient to run a Wayland compositor, I'm
> guessing probably not..?
If you can find a Wayland compositor that is written to composite with
GLES1, that's all you need from the "Wayland side". (Yeah, this has
nothing to d
On 07.07.2015 01:10, Jerome Glisse wrote:
> On Mon, Jul 06, 2015 at 06:11:29PM +0900, Michel Dänzer wrote:
>>
>> Hi Jérôme,
>>
>> On 13.08.2014 12:52, Jérôme Glisse wrote:
>>> From: Jérôme Glisse
>>>
>>> Current code never allowed the page pool to actualy fill in anyway. This fix
>>> it and
The legacy page_flip driver entry point is the only one left which
requires drivers to update plane->fb themselves. All the other entry
hooks will patch things up for the driver as needed since no one seems
to reliable get this right, see e.g. drm_mode_set_config_internal or
the plane->fb/old_fb ha
On Tue, Jul 07, 2015 at 08:43:03AM +0200, Daniel Vetter wrote:
> The legacy page_flip driver entry point is the only one left which
> requires drivers to update plane->fb themselves. All the other entry
> hooks will patch things up for the driver as needed since no one seems
> to reliable get this
On Wed, Jun 24, 2015 at 08:59:25AM +0200, Maarten Lankhorst wrote:
> It's probably allowed to leave old_fb set to garbage when unlocking,
> but to prevent undefined behavior unset it just in case.
>
> Also crtc_state->event could be NULL on memory allocation failure,
> in which case event_space is
On Sun, Apr 19, 2015 at 12:55 AM, Heiko Stübner wrote:
>
> Am Donnerstag, 16. April 2015, 16:41:51 schrieb Ãrjan Eide:
> > Set vm_pgoff to 0 after using it to look up the GEM node, before passing
> > it on rockchip_gem_mmap_buf() where the offset must be from the start of
> > the buffer.
> >
> >
When inlining the actual hpd output probing in
commit 69787f7da6b2adc4054357a661aaa1701a9ca76f
Author: Daniel Vetter
Date: Tue Oct 23 18:23:34 2012 +
drm: run the hpd irq event code directly
the check for the drm_kms_hlper.poll module option was lost. This
regressed systems where this
This can be a separate case from mode_changed, when connectors stay the
same but only the mode is different. Drivers may choose to implement specific
optimizations to prevent a full modeset for this case.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm
This allows the first atomic call during hw init to be a real modeset,
which is useful for forcing a recalculation.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_fb_helper.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
From: Grigori Goronzy
Everything is evicted from VRAM before suspend, so we need to make
sure all BOs are unpinned and re-pinned after resume. Fixes broken
mouse cursor after resume introduced by commit b9729b17.
[Michel Dänzer: Add pinning BOs on resume]
Bugzilla: https://bugzilla.kernel.org/
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_cursor.c | 49 +-
1 file changed, 19 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c
b/drivers/gpu/drm/radeon/radeon_cursor.c
index fa66174..
From: Michel Dänzer
Take a GEM reference for and pin the new cursor BO, unpin and drop the
GEM reference for the old cursor BO in radeon_crtc_cursor_set2, and use
radeon_crtc->cursor_addr in radeon_set_cursor.
This fixes radeon_cursor_reset accidentally incrementing the cursor BO
pin count, and
A nit only, I'm afraid: a license mismatch.
On ma, 2015-07-06 at 13:40 +0200, Benjamin Gaignard wrote:
> --- /dev/null
> +++ b/drivers/smaf/smaf-core.c
> + * License terms: GNU General Public License (GPL), version 2
> +MODULE_LICENSE("GPL");
The comment at the top of this file states, succinc
> *â *Open source software for ARM SoCs
Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter
<http://twitter.com/#!/linaroorg> | Blog
<http://www.linaro.org/linaro-blog/>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/daaaf5e5/attachment.html>
From: Zhao Junwang
legacy setcrtc ioctl does take a 32 bit value which might indeed
overflow
the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't
needed any more with this
Cc: Daniel Vetter
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/drm_crtc.c |7 +--
1 file chan
https://bugzilla.kernel.org/show_bug.cgi?id=101131
Bug ID: 101131
Summary: Regression: Can't boot on 4.0.5 and later but can boot
on 4.0.4 (on iMac)
Product: Drivers
Version: 2.5
Kernel Version: 4.0.5
Hardware: All
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/f8ea6175/attachment.html>
On Wed, Jul 01, 2015 at 03:23:39PM +0300, Jani Nikula wrote:
>
> +intel-gfx and Matt
>
> On Wed, 01 Jul 2015, Michal Hocko wrote:
> > On Wed 01-07-15 10:26:39, Daniel Vetter wrote:
> >> On Tue, Jun 30, 2015 at 10:13:35PM +0200, Michal Hocko wrote:
> >> > On Tue 30-06-15 18:59:29, Daniel Vetter w
On Tue, Jul 07, 2015 at 04:21:50PM +0800, John Hunter wrote:
> From: Zhao Junwang
>
> legacy setcrtc ioctl does take a 32 bit value which might indeed
> overflow
>
> the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't
> needed any more with this
>
> Cc: Daniel Vetter
> Signed-
On Tue, Jul 07, 2015 at 09:08:12AM +0200, Maarten Lankhorst wrote:
> This can be a separate case from mode_changed, when connectors stay the
> same but only the mode is different. Drivers may choose to implement specific
> optimizations to prevent a full modeset for this case.
>
> Cc: dri-devel at
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/06e16567/attachment.html>
Rather than (incompletely [0]) re-implementing drm_gem_mmap() and
drm_gem_mmap_obj() helpers, call them directly from the rockchip mmap
routines.
Once the core functions return successfully, the rockchip mmap routines
can still use dma_mmap_attrs() to simply mmap the entire buffer.
[0] Previously
From: Zhao Junwang
legacy setcrtc ioctl does take a 32 bit value which might indeed
overflow
the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't
needed any more with this
v2: -polish the annotation according to Daniel's comment
Cc: Daniel Vetter
Signed-off-by: Zhao Junwang
-
On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
> This allows the first atomic call during hw init to be a real modeset,
> which is useful for forcing a recalculation.
fbcon is optional, you can't rely on anything being done in any specific
way. What exactly do you need this for
d...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/a3c9cc0d/attachment.html>
Op 07-07-15 om 10:59 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 09:08:12AM +0200, Maarten Lankhorst wrote:
>> This can be a separate case from mode_changed, when connectors stay the
>> same but only the mode is different. Drivers may choose to implement specific
>> optimizations to prevent a
On 07.07.2015 09:27, Michel Dänzer wrote:
> From: Grigori Goronzy
>
> Everything is evicted from VRAM before suspend, so we need to make
> sure all BOs are unpinned and re-pinned after resume. Fixes broken
> mouse cursor after resume introduced by commit b9729b17.
>
> [Michel Dänzer: Add pinning
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/0f0cfe00/attachment.html>
Op 07-07-15 om 11:18 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
>> This allows the first atomic call during hw init to be a real modeset,
>> which is useful for forcing a recalculation.
> fbcon is optional, you can't rely on anything being done in an
https://bugzilla.kernel.org/show_bug.cgi?id=93701
--- Comment #21 from Frederik vom Hofe ---
Just got a 290 that shows the same phenomena since patch revert.
2d1c18bba15daf89d75ce475ecd2068f483aa12f
Revert "drm/radeon: only mark audio as connected if the monitor supports it
(v3)"
...
Bisected v
https://bugzilla.kernel.org/show_bug.cgi?id=93701
--- Comment #22 from Frederik vom Hofe ---
Created attachment 182061
--> https://bugzilla.kernel.org/attachment.cgi?id=182061&action=edit
dmesg with v4.2-rc1 and 290
--
You are receiving this mail because:
You are watching the assignee of the
https://bugzilla.kernel.org/show_bug.cgi?id=93701
--- Comment #23 from Frederik vom Hofe ---
Created attachment 182071
--> https://bugzilla.kernel.org/attachment.cgi?id=182071&action=edit
Xorg.0.log with v4.2-rc1 and 290
--
You are receiving this mail because:
You are watching the assignee of
On Tue, Jul 07, 2015 at 12:05:40PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 10:59 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:12AM +0200, Maarten Lankhorst wrote:
> >> @@ -373,7 +375,17 @@ drm_atomic_helper_check_modeset(struct drm_device
> >> *dev,
> >>if (crtc->s
On Tue, Jul 07, 2015 at 05:03:36PM +0800, Daniel Kurtz wrote:
> Rather than (incompletely [0]) re-implementing drm_gem_mmap() and
> drm_gem_mmap_obj() helpers, call them directly from the rockchip mmap
> routines.
>
> Once the core functions return successfully, the rockchip mmap routines
> can st
On Tue, Jul 07, 2015 at 05:08:35PM +0800, John Hunter wrote:
> From: Zhao Junwang
>
> legacy setcrtc ioctl does take a 32 bit value which might indeed
> overflow
>
> the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't
> needed any more with this
>
> v2: -polish the annotation a
On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
> >> This allows the first atomic call during hw init to be a real modeset,
> >> which is useful for forcing a reca
On Mon, Jul 6, 2015 at 6:07 PM, Vadim Girlin wrote:
> On 07/06/2015 11:56 PM, Alex Deucher wrote:
>>
>> On Mon, Jul 6, 2015 at 3:19 PM, Dave Jones
>> wrote:
>>>
>>> I wanted to switch my LCD to a different machine momentarily.
>>> When I plugged the cable back in, this was on the screen..
>>
>>
>
On Mon Jul 6 22:26:25 2015 GMT+0100, Daniel Vetter wrote:
> On Mon, Jul 06, 2015 at 09:06:28PM +0100, Steven Newbury wrote:
> > On Mon, 2015-07-06 at 15:42 -0400, Alex Deucher wrote:
> > > On Mon, Jul 6, 2015 at 2:40 PM, Steven Newbury > > > wrote:
> > > > On Mon, 2015-07-06 at 12:25 -0400, Alex
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/dc550132/attachment.html>
k is miscompiled, I tested it pretty
> > > > throughly
> > > > under qemu (with qxl) before deployment, but that of course
> > > > didn't
> > > > exercise the R200 driver. FWIW, other than the failing DRI,
> > > > performance is surprisingly OK, not super fast obviously, but
> > > > a
> > > > *lot*
> > > > better than under Ubuntu! (start-up time is alot quicker, by
> > > > an
> > > > order
> > > > of magnitude!)
> > > >
> > > > I'm attempting to downgrade the xserver and drivers (on the
> > > > live
> > > > system) to see if that works, you can imagine that takes a
> > > > little
> > > > while on a Coppermine-128! I'll find out tomorrow.
> > > > Otherwise, I
> > > > guess I'm recompiling the stack with gcc-4.9 and no-LTO...
>
Sorry about the accidental e-mail.
I've tried an xserver-1.16, and ddx, libdrm without LTO and with
gcc4.9. Exactly the same thing. I wondered whether the unused i810
could be interfering but triggering a device "remove" before starting
X made no difference.
I'm a bit of a loss. I suppose I could try writing a simple test for
drmSetInterfaceVersion(). At least that should determine whether the
xserver/ddx is in the clear.
Any other ideas?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/b2112731/attachment-0001.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=101131
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 f
On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury wrote:
>
> I've tried an xserver-1.16, and ddx, libdrm without LTO and with
> gcc4.9. Exactly the same thing. I wondered whether the unused i810
> could be interfering but triggering a device "remove" before starting
> X made no difference.
>
> I'm
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/693c290d/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=101131
--- Comment #2 from Andreas Tunek ---
I can not bisect upstream Linux, maybe fedora versions...
--
You are receiving this mail because:
You are watching the assignee of the bug.
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/0549325e/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=101131
--- Comment #3 from Andreas Tunek ---
Created attachment 182091
--> https://bugzilla.kernel.org/attachment.cgi?id=182091&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
Op 07-07-15 om 14:10 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 11:18 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
This allows the first atomic call during hw init to be a real m
3.16 and 3.17
--
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/20150707/3a4a19a2/attachment-0001.html>
Op 07-07-15 om 14:10 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 11:18 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
This allows the first atomic call during hw init to be a real m
ri-devel/attachments/20150707/5f92d7f9/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/f2c8f5fa/attachment.html>
On Mon, Jul 6, 2015 at 8:42 PM, Andrew Chew wrote:
> Hello,
>
> I am currently looking into ways to support fixed virtual address allocations
> and sparse mappings in nouveau, as a step towards supporting CUDA.
>
> CUDA requires that the GPU virtual address for a given buffer match the
> CPU virtu
e from radeon_kms.c
I just need to try it on the actual hw now... :-)
-- next part --
A non-text attachment was scrubbed...
Name: test-drm.c
Type: text/x-csrc
Size: 735 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/648
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/5fc64369/attachment-0001.html>
On Tue, Jul 07, 2015 at 04:32:44PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst
On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst
Hello there,
[linux-4.2-rc1/drivers/gpu/drm/radeon/cik.c:1912] ->
[linux-4.2-rc1/drivers/gpu/drm/radeon/cik.c:1913]: (warning) Opposite
conditions in nested 'if' blocks lead to a dead code block.
Source code is
  if (running == 0) {
       if (running) {
           black
On Tue, Jul 7, 2015 at 6:56 AM, David Binderman wrote:
> Hello there,
>
> [linux-4.2-rc1/drivers/gpu/drm/radeon/cik.c:1912] ->
> [linux-4.2-rc1/drivers/gpu/drm/radeon/cik.c:1913]: (warning) Opposite
> conditions in nested 'if' blocks lead to a dead code block.
>
> Source code is
>
>if (runni
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/04c8a94c/attachment-0001.html>
On Tue, Jul 07, 2015 at 11:29:38AM -0400, Ilia Mirkin wrote:
> On Mon, Jul 6, 2015 at 8:42 PM, Andrew Chew wrote:
> > Hello,
> >
> > I am currently looking into ways to support fixed virtual address
> > allocations
> > and sparse mappings in nouveau, as a step towards supporting CUDA.
> >
> > CUD
On Tue, Jul 07, 2015 at 03:39:29PM +0900, Michel Dänzer wrote:
> On 07.07.2015 01:10, Jerome Glisse wrote:
> > On Mon, Jul 06, 2015 at 06:11:29PM +0900, Michel Dänzer wrote:
> >>
> >> Hi Jérôme,
> >>
> >> On 13.08.2014 12:52, Jérôme Glisse wrote:
> >>> From: Jérôme Glisse
> >>>
> >>> Curre
est for few days.
--
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/20150707/a6546393/attachment.html>
Hi Kausal,
On 03/07/15 04:31, Kausal Malladi wrote:
> 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
> S
the second one won't necessarily help the fix the first one.
--
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/20150707/
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/98b2e1dd/attachment-0001.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/20150707/f8fdd51c/attachment.html>
mit. The reset command
resets the HEAD of the current tree to the specified commit.
--
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/20150707/056299b7/attachment.html>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/4a8b23bc/attachment.html>
MDP planes can be implemented using different type of HW pipes,
RGB/VIG/DMA pipes for MDP5 and RGB/VG/DMA pipes for MDP4. Each type
of pipe has different HW capabilities such as scaling, color space
conversion, decimation... Add a variable in plane data structure
to specify the difference of each p
This change is to add planes which use DMA pipes for MDP5.
Signed-off-by: Jilai Wang
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/md
ceiving 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/20150707/02e6be42/attachment.html>
branch name (git branch -b testing2
02376d8282b88f07d0716da6155094c8760b1a13).
--
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/20150707/30fe2281/attachment.html>
On Fri, Jul 03, 2015 at 09:01:37AM +0530, Kausal Malladi wrote:
> 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
On Fri, Jul 03, 2015 at 09:01:38AM +0530, Kausal Malladi wrote:
> 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/
On Fri, Jul 03, 2015 at 09:01:44AM +0530, Kausal Malladi wrote:
> 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
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/8a999887/attachment.html>
vel/attachments/20150707/dc96206f/attachment.html>
org/archives/dri-devel/attachments/20150707/5407351e/attachment.html>
Commit 712a0dd91c4a ("Documentation/drm: Update rotation property")
left an extra 'rowspan' for the row omap, which pushed the following qxl
rows columns out to column 8 and broke the tabulation.
Remove the errant rowspan.
Signed-off-by: Graham Whaley
---
Documentation/DocBook/drm.tmpl | 2 +-
1
On Tue, Jul 07, 2015 at 11:29:38AM -0400, Ilia Mirkin wrote:
> On Mon, Jul 6, 2015 at 8:42 PM, Andrew Chew wrote:
> > These ioctls just call into the allocator to allocate a range of addresses,
> > resulting in a struct nvkm_vma that tracks that allocation (or releases the
> > struct nvkm_vma back
86 matches
Mail list logo
