Hi
On Wed, May 14, 2014 at 2:03 AM, Dave Airlie airl...@gmail.com wrote:
Since any objects you get with find are only valid under mode_config.mutex,
yes some drivers mess this up, but they should be fixed.
Didn't know that we have such a rule. Then it's fine, of course. The
page-flip code is
On Tue, May 13, 2014 at 03:43:12PM -0700, Jesse Barnes wrote:
On Wed, 14 May 2014 00:30:34 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, May 13, 2014 at 03:05:24PM -0700, Jesse Barnes wrote:
On Tue, 11 Feb 2014 14:19:03 +0530
akash.g...@intel.com wrote:
@@ -810,6 +815,7 @@
On Tue, May 13, 2014 at 03:36:59PM -0700, Jesse Barnes wrote:
On Tue, 25 Mar 2014 12:57:32 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
Make sure that the whole BDB section is within the MMIO region prior to
accessing it contents. That we don't read outside of the secion is left
up
On Wed, May 14, 2014 at 08:05:11AM +0200, David Herrmann wrote:
Hi
On Wed, May 14, 2014 at 2:03 AM, Dave Airlie airl...@gmail.com wrote:
Since any objects you get with find are only valid under mode_config.mutex,
yes some drivers mess this up, but they should be fixed.
Didn't know that
On Tue, 13 May 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
i915.ko has a custom fbdev initialisation routine that aims to preserve
the current mode set by the BIOS, unless overruled by the user. The
user's wishes are determined by what, if any, mode is specified on the
command line (via
On Wed, May 14, 2014 at 11:31:47AM +0300, Jani Nikula wrote:
On Tue, 13 May 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
i915.ko has a custom fbdev initialisation routine that aims to preserve
the current mode set by the BIOS, unless overruled by the user. The
user's wishes are
On Wed, 14 May 2014, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Tue, 13 May 2014 22:22:00 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
coccinelle is seriously a tool I should have played around with much
earlier. Extremely powerful, and extremely dangerous in causing
massive
On Wed, 14 May 2014, Damien Lespiau damien.lesp...@intel.com wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index
Only tricky bit was a bit of debug output sprinkled all over, I've
moved it all to cmp_bo.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
tests/gem_seqno_wrap.c | 62 ++
1 file changed, 22 insertions(+), 40 deletions(-)
diff --git
Step one to untangle the control flow in this test and replace it all
with igt assert magic.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
tests/prime_nv_pcopy.c | 82 ++
1 file changed, 22 insertions(+), 60 deletions(-)
diff --git
Often just folding together of the common if (cond) printf;
abort|igt_skip|igt_fail; pattern. But in a few cases I've ripped out
more since the igt macros will already print the condition and errno.
A few tests where more work (like ripping out return codes en masse)
is needed left as-is.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
tests/prime_nv_api.c | 325 +--
1 file changed, 81 insertions(+), 244 deletions(-)
diff --git a/tests/prime_nv_api.c b/tests/prime_nv_api.c
index 73c0a0d24f5f..99d5cf298537 100644
---
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
tests/kms_flip.c | 56
1 file changed, 24 insertions(+), 32 deletions(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 3032c8d9bcef..d2adc02c8476 100644
---
Now we even have more fine-grained checking and only skip if the
nouveau card isn't supported, but fail properly if something else goes
wrong.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
tests/prime_nv_pcopy.c | 93 ++
1 file changed,
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
tests/prime_nv_pcopy.c | 121 +++--
1 file changed, 36 insertions(+), 85 deletions(-)
diff --git a/tests/prime_nv_pcopy.c b/tests/prime_nv_pcopy.c
index 74388349da3d..6aa48716348e 100644
---
We now know that the hardware can't do this, and it's not designed to.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
tests/prime_nv_pcopy.c | 253 -
1 file changed, 253 deletions(-)
diff --git a/tests/prime_nv_pcopy.c
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
tests/prime_nv_pcopy.c | 172 -
1 file changed, 71 insertions(+), 101 deletions(-)
diff --git a/tests/prime_nv_pcopy.c b/tests/prime_nv_pcopy.c
index d06c1eb205a1..74388349da3d 100644
---
There are certain BDW high res eDP machines that regressed due to
commit 38aecea0ccbb909d635619cba22f1891e589b434
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Mon Mar 3 11:18:10 2014 +0100
drm/i915: reverse dp link param selection, prefer fast over wide again
The commit lead to 2
On Tue, May 13, 2014 at 10:21:59PM +0200, Daniel Vetter wrote:
Noticed while playing with coccinelle.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
1 file changed, 1 insertion(+), 1
On Tue, May 06, 2014 at 04:39:01PM +0300, Mika Kuoppala wrote:
Generate valid (null) render state for each gen. Output
it as a c source file with batch and relocations.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
With the GT3 URB allocation restriction added, this series is
On Tue, May 13, 2014 at 03:11:45PM +0100, Chris Wilson wrote:
On Tue, May 13, 2014 at 04:02:40PM +0200, Daniel Vetter wrote:
On Tue, May 13, 2014 at 02:26:39PM +0100, Chris Wilson wrote:
During initial probing of the modes to assign to the fbdev console, we
use the CRTC and connector ids.
On Tue, May 06, 2014 at 04:26:04PM +0300, Mika Kuoppala wrote:
Hi,
V2 series of the render state initialization patches.
I decided not to pursue the copying of the context object as the ctx
is quite big, atleast on bdw. As discussed in irc, the copying
could be done with blitter, on
Hi Mika,
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Mika Kuoppala
Sent: Tuesday, May 06, 2014 3:30 PM
To: intel-gfx@lists.freedesktop.org
Cc: b...@bwidawsk.net; m...@iki.fi; kris...@linux.intel.com
Subject: [Intel-gfx] [PATCH v3
On Wed, May 14, 2014 at 11:04:03AM +0100, Damien Lespiau wrote:
On Tue, May 13, 2014 at 10:21:59PM +0200, Daniel Vetter wrote:
Noticed while playing with coccinelle.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
Queued for
On Wed, May 14, 2014 at 10:24:53AM +, Mateo Lozano, Oscar wrote:
Hi Mika,
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of
Mika Kuoppala
Sent: Tuesday, May 06, 2014 3:30 PM
To: intel-gfx@lists.freedesktop.org
Cc:
-Original Message-
From: Lespiau, Damien
Sent: Wednesday, May 14, 2014 12:14 PM
To: Mateo Lozano, Oscar
Cc: Mika Kuoppala; intel-gfx@lists.freedesktop.org; b...@bwidawsk.net;
m...@iki.fi; kris...@linux.intel.com
Subject: Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: add render state
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, May 13, 2014 2:36 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 26/50] drm/i915/bdw: Allow non-default, non-
render,
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, May 13, 2014 2:27 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org; Ben Widawsky; Widawsky, Benjamin
Subject: Re: [Intel-gfx] [PATCH 04/50] drm/i915: Extract
If we get the final value of zero as a count of free
entries available, we will underflow our own fifo_count
and then it will take a long time before we check things again.
Admittedly we are in trouble already if we get into this situation,
but prevent the underflow by checking against zero before
On Wed, May 14, 2014 at 11:53:46AM +, Mateo Lozano, Oscar wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Tuesday, May 13, 2014 2:27 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org; Ben Widawsky;
A single object may be referenced by multiple registers fundamentally
breaking the static allotment of ids in the current design. When the
object is used the second time, the physical address of the first
assignment is relinquished and a second one granted. However, the
hardware is still reading
If we get the final value of zero as a count of free
entries available, we will underflow our own fifo_count
and then it will take a long time before we check things again.
Admittedly we are in trouble already if we get into this situation,
but prevent the underflow by returning early.
v2: Less
On Tue, May 13, 2014 at 03:28:27PM +0200, Daniel Vetter wrote:
On Fri, May 09, 2014 at 01:08:36PM +0100, oscar.ma...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
In the upcoming patches, we plan to break the correlation between
engines (a.k.a. rings) and ringbuffers, so it
On Wed, May 14, 2014 at 04:18:02PM +0300, Mika Kuoppala wrote:
If we get the final value of zero as a count of free
entries available, we will underflow our own fifo_count
and then it will take a long time before we check things again.
Admittedly we are in trouble already if we get into this
On Wed, May 14, 2014 at 04:35:42PM +0300, Ville Syrjälä wrote:
On Wed, May 14, 2014 at 04:18:02PM +0300, Mika Kuoppala wrote:
If we get the final value of zero as a count of free
entries available, we will underflow our own fifo_count
and then it will take a long time before we check things
HW guys say that it is not a cool idea to let device
go into rc6 without proper 3d pipeline state.
For each new uninitialized context, generate a
valid null render state to be run on context
creation.
This patch introduces a skeleton with empty states.
v2: - No need to vmap (Chris Wilson)
-
These are generated with intel-gpu-tools/tools/null_state_gen
v2: Don't use header file for states (Daniel Vetter)
v3: Proper URB state size for gen8/GT3 (Damien Lespiau)
Tested-by: Kristen Carlson Accardi kris...@linux.intel.com (v1)
Tested-by: Oscar Mateo oscar.ma...@intel.com (v2)
Acked-by:
If we get the final value of zero as a count of free
entries available, we will underflow our own fifo_count
and then it will take a long time before we check things again.
Admittedly we are in trouble already if we get into this situation,
but prevent the underflow by returning early.
v2: Less
Conflict between me and Thomas pushing patches in parallel.
Cc: Thomas Wood thomas.w...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
lib/igt_core.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index
From: Deepak S deepa...@linux.intel.com
In BDW, Apart from unmasking up/down threshold interrupts. we need
to umask bit 32 of PM_INTRMASK to route interrupts to target via Display
Interface.
v2: Add (131) mask (Ville)
v3: Add Gen check for the mask (ville)
Signed-off-by: Deepak S
On Friday 09 May 2014 06:49 PM, Mika Kuoppala wrote:
Hi Deepak,
deepa...@linux.intel.com writes:
From: Deepak S deepa...@linux.intel.com
v2: Configure PCBR if BIOS fails allocate pcbr (deepak)
v3: Fix PCBR condition check during CHV RC6 Enable flag set
v4: Fixup PCBR comment msg. (Chris)
On Wed, May 14, 2014 at 09:07:53PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
In BDW, Apart from unmasking up/down threshold interrupts. we need
to umask bit 32 of PM_INTRMASK to route interrupts to target via Display
Interface.
v2: Add (131) mask
On Tue, May 13, 2014 at 09:18:45AM +0530, Sharma, Shashank wrote:
Daniel,
Please find my comments inline.
Regards
Shashank
On 5/12/2014 8:58 PM, Daniel Vetter wrote:
On Mon, May 12, 2014 at 05:35:13PM +0530, Sharma, Shashank wrote:
Thanks for your time and the comments David.
please find
On Fri, Feb 14, 2014 at 02:06:07PM +0100, Daniel Vetter wrote:
Otherwise we end up tearing down fences when e.g. the client quits
way too early. Might or might not fix a fence pin_count BUG Ville has
reported.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter
On Wed, May 14, 2014 at 05:02:16PM +0300, Mika Kuoppala wrote:
HW guys say that it is not a cool idea to let device
go into rc6 without proper 3d pipeline state.
For each new uninitialized context, generate a
valid null render state to be run on context
creation.
This patch introduces a
On Wed, May 14, 2014 at 07:14:13PM +0300, Ville Syrjälä wrote:
On Fri, Feb 14, 2014 at 02:06:07PM +0100, Daniel Vetter wrote:
Otherwise we end up tearing down fences when e.g. the client quits
way too early. Might or might not fix a fence pin_count BUG Ville has
reported.
Cc: Ville
On Wed, May 14, 2014 at 05:37:39PM +0100, Damien Lespiau wrote:
On Wed, May 14, 2014 at 05:02:16PM +0300, Mika Kuoppala wrote:
HW guys say that it is not a cool idea to let device
go into rc6 without proper 3d pipeline state.
For each new uninitialized context, generate a
valid null
I want to use them elsewhere ...
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
lib/igt_aux.c | 114 +
lib/igt_aux.h | 11 ++
tests/pm_pc8.c | 96 ++--
3 files changed, 128
These check whether everything is still ok wrt vblank handling after
runtime pm and system suspend-resume.
In addition to the usual checks they also ensure that the vblank frame
counter isn't totally ridiculous, something Keith complained about
aeons ago. With Ville's drm_vblank_on/off rework
We do have to continue the investigation on the link training side, but
since 76711 is a critical I'm completely in favor of this workaround for
now.
I just tested and it worked very well here, so:
Tested-by: Rodrigo Vivi rodrigo.v...@gmail.com
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, May 14, 2014 at 06:00:46PM +0200, Daniel Vetter wrote:
I want to use them elsewhere ...
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
lib/igt_aux.c | 114
+
lib/igt_aux.h | 11 ++
tests/pm_pc8.c | 96
On Mon, May 5, 2014 at 11:19 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Hi Dave,
Update pull request with drm core patches. Mostly some polish for the
primary plane stuff and a pile of patches all over from Thierry. Has
survived a few days in drm-intel-nightly without causing ill.
I've
On Wed, May 14, 2014 at 06:50:27PM +0100, Damien Lespiau wrote:
On Wed, May 14, 2014 at 06:00:46PM +0200, Daniel Vetter wrote:
I want to use them elsewhere ...
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
lib/igt_aux.c | 114
On Wed, May 14, 2014 at 08:34:03PM +0200, Daniel Vetter wrote:
On Wed, May 14, 2014 at 06:50:27PM +0100, Damien Lespiau wrote:
On Wed, May 14, 2014 at 06:00:46PM +0200, Daniel Vetter wrote:
I want to use them elsewhere ...
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
If we want to use this functionality in generic helpers to make
sure that all drivers have somewhat sane vblank handling across
modesets/dpms, we need to make it work for all drivers. But some
don't support interrupts and hence also not vblank waits.
Just return early on such drivers.
Note that
- Integrate into the drm DocBook
- Disable kerneldoc for functions not exported to drivers.
- Properly document the new drm_vblank_on|off and add cautious
comments explaining when drm_vblank_pre|post_modesets shouldn't be
used.
- General polish and OCD.
Signed-off-by: Daniel Vetter
Leftover from the old days of ums and should be used any longer. Since
commit 29935554b384b1b3a7377d6f0b03b21d18a61683
Author: Laurent Pinchart laurent.pinch...@ideasonboard.com
Date: Wed May 30 00:58:09 2012 +0200
drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers
it is a complete no-Op
Hi all,
This is Ville's vblank rework series, slightly pimped. I've added kerneldoc,
some polish and also some additional nasty igt testcases for these crtc on/off
vs vblank issues. Seems all to hold together nicely.
Now one thing I wanted to do is roll this out across all drm drivers, but that
We don't have hardware based disable bits on gmch platforms, so need
to block spurious underrun reports in software. Which means that we
_must_ start out with fifo underrun reporting disabled everywhere.
This is in big contrast to ilk/hsw/cpt where there's only _one_
disable bit for all platforms
From: Peter Hurley pe...@hurleysoftware.com
The irq flags state is already established by the outer
spin_lock_irqsave(); re-disabling irqs is redundant.
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_irq.c | 6
We need to start somewhere ... With this the only places left in i915
where we use pipe integers is in the interrupt handling code. And
there it actually makes some amount of sense.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_irq.c| 81
It literally took us years in i915 to track down all the vblank
bogosity, which means that userspace has now code to deal with random
crap like stuck vblank waits, needless counter wraps and other
hilarity.
To make sure that all drivers are at least somewhat sane enforce
minimal standards in the
Originally these functions have been for user modesetting drivers to
ensure vblank processing doesn't fall over completely around modeset
changes. This has been carried over ever since then.
Now that Ville cleaned our vblank handling with an explicit
drm_vblank_off/on braket when
We don't have hardware based disable bits on gmch platforms, so need
to block spurious underrun reports in software. Which means that we
_must_ start out with fifo underrun reporting disabled everywhere.
This is in big contrast to ilk/hsw/cpt where there's only _one_
disable bit for all platforms
From: Ville Syrjälä ville.syrj...@linux.intel.com
If there's a blocking vblank wait in progress while the vblank interrupt
gets disabled, the current code will just let the vblank wait time out.
Instead make it return immediately when vblank interrupts get disabled.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä ville.syrj...@linux.intel.com
Currently there's one per-device vblank disable timer, and it gets
reset wheneven the vblank refcount for any crtc drops to zero. That
means that one crtc could accidentally be keeping the vblank interrupts
for other crtcs enabled even if there
Now that we unconditionally dtrt when disabling/enabling crtcs we
don't need any hacks any longer to keep the vblank logic sane when
all the registers go poof. So let's rip it all out.
This essentially undoes
commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6
Author: Paulo Zanoni
On Wed, May 14, 2014 at 08:51:06PM +0200, Daniel Vetter wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
drm_vblank_off() will turn off vblank interrupts, but as long as the
refcount is elevated drm_vblank_get() will not re-enable them. This
is a problem is someone is holding a
From: Ville Syrjälä ville.syrj...@linux.intel.com
drm_vblank_off() will turn off vblank interrupts, but as long as the
refcount is elevated drm_vblank_get() will not re-enable them. This
is a problem is someone is holding a vblank reference while a modeset is
happening, and the driver requires
Now that we unconditionally dtrt when disabling/enabling crtcs we
don't need any hacks any longer to keep the vblank logic sane when
all the registers go poof. So let's rip it all out.
This essentially undoes
commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6
Author: Paulo Zanoni
If we want to use this functionality in generic helpers to make
sure that all drivers have somewhat sane vblank handling across
modesets/dpms, we need to make it work for all drivers. But some
don't support interrupts and hence also not vblank waits.
Just return early on such drivers.
Note that
On Wed, May 14, 2014 at 08:47:38PM +0200, Bruno Prémont wrote:
CCing intel-gfx as otherwise it will probably not get seen by developers.
On Sun, 11 May 2014 Carbonated Beverage ram...@psychosnugglebunnies.net
wrote:
Bisecting from 3.13.6 (good) to 3.14.3 (bad) ended up with...
commit
On Wed, May 14, 2014 at 09:19:32PM +0200, Daniel Vetter wrote:
On Wed, May 14, 2014 at 08:47:38PM +0200, Bruno Prémont wrote:
CCing intel-gfx as otherwise it will probably not get seen by developers.
On Sun, 11 May 2014 Carbonated Beverage ram...@psychosnugglebunnies.net
wrote:
On Wed, 2014-05-14 at 20:51 +0200, Daniel Vetter wrote:
We don't have hardware based disable bits on gmch platforms, so need
to block spurious underrun reports in software. Which means that we
_must_ start out with fifo underrun reporting disabled everywhere.
This is in big contrast to
On Wed, May 14, 2014 at 3:33 PM, Greg KH gre...@linuxfoundation.org wrote:
On Wed, May 14, 2014 at 09:19:32PM +0200, Daniel Vetter wrote:
On Wed, May 14, 2014 at 08:47:38PM +0200, Bruno Prémont wrote:
CCing intel-gfx as otherwise it will probably not get seen by developers.
On Sun, 11 May
On Wed, May 14, 2014 at 03:43:53PM -0400, Josh Boyer wrote:
On Wed, May 14, 2014 at 3:33 PM, Greg KH gre...@linuxfoundation.org wrote:
On Wed, May 14, 2014 at 09:19:32PM +0200, Daniel Vetter wrote:
On Wed, May 14, 2014 at 08:47:38PM +0200, Bruno Prémont wrote:
CCing intel-gfx as otherwise
On Wed, May 14, 2014 at 03:43:53PM -0400, Josh Boyer wrote:
On Wed, May 14, 2014 at 3:33 PM, Greg KH gre...@linuxfoundation.org wrote:
On Wed, May 14, 2014 at 09:19:32PM +0200, Daniel Vetter wrote:
On Wed, May 14, 2014 at 08:47:38PM +0200, Bruno Prémont wrote:
CCing intel-gfx as otherwise
Do you know if the DSI patch set is being maintained? I noticed it is
not integrated into drm-intel-next, the patches don't apply cleanly to
anything, and there has been no activity in about a month on them.
-Jon
On Sun, May 11, 2014 at 1:45 PM, Daniel Vetter dan...@ffwll.ch wrote:
Asus T100
On 2014-04-19 22:19 (GMT-0400) Felix Miata composed:
Has no one opened a freedesktop.org bug for this? I couldn't find one for
i810 changed more recently than 18 months ago.
I have an openSUSE i810E rev03 test system with 1.16.0 RC 2. Newest changelog
entry 08 April. Last intel driver
On 15.05.2014 03:51, Daniel Vetter wrote:
Leftover from the old days of ums and should be used any longer. Since
commit 29935554b384b1b3a7377d6f0b03b21d18a61683
Author: Laurent Pinchart laurent.pinch...@ideasonboard.com
Date: Wed May 30 00:58:09 2012 +0200
drm: Disallow
On 5/15/2014 6:05 AM, Jon Pry wrote:
Do you know if the DSI patch set is being maintained? I noticed it is
not integrated into drm-intel-next, the patches don't apply cleanly to
anything, and there has been no activity in about a month on them.
The basic DSI sequence is merged already and the
What I understood from the reviews comments from the experts, is having
a central color management at DRM kernel layer is not a good idea, and
we should create individual DRM properties for the color correction
methods, and let the control be there in the user space level, where an
atomic
82 matches
Mail list logo
