From: Akash Goel
The frequency values(Rp0, Rp1, Rpn) reported by RP_STATE_CAP register
are stored, initially by the Driver, inside the dev_priv->rps structure.
Since these values are expected to remain same throughout, there is no real
need to read this register, on dynamic basis, from debugfs/sy
The code in function intel_crtc_compute_config() that evens pipe_src_w
if necessary would look at the current config instead of the staged one
when deciding if there is an LVDS encoder in use. This could potentially
lead to the value not being updated, if during the modeset a crtc wasn't
driving an
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5819
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 281/281
Yes, it has the updated values squashed in.
Thanks,
Sonika
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, February 25, 2015 8:37 PM
To: Jindal, Sonika
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 0/
On Wed, Feb 25, 2015 at 11:17:00PM +0100, Daniel Vetter wrote:
> On Fri, Feb 13, 2015 at 11:48:14AM +, john.c.harri...@intel.com wrote:
> > From: John Harrison
> >
> > For some reason, the i915_add_request() call in
> > i915_gem_execbuffer_retire_commands() was explicitly having its return co
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 62e537f8d568
("drm/i915: Fix frontbuffer false positve") from the drm-intel-fixes
tree and commit 6a418fcd84d6 ("drm/i915: Use fb modifiers in
intel_check_cursor_plane") fro
On Mon, Feb 23, 2015 at 05:41:51PM +0100, Daniel Vetter wrote:
> On Fri, Feb 13, 2015 at 10:34:51AM +, Chris Wilson wrote:
> > On Fri, Feb 13, 2015 at 10:55:46AM +0100, Daniel Vetter wrote:
> > > On Thu, Feb 12, 2015 at 09:03:06PM +, Chris Wilson wrote:
> > > > On Thu, Feb 12, 2015 at 08:05
On Wed, Feb 25, 2015 at 01:12:16PM -0800, Matt Roper wrote:
> As vendors transition their drivers from legacy to atomic there's some
> duplication of data between drm_crtc and drm_crtc_state (since
> unconverted drivers likely won't have a state structure).
>
> i915 is partially converted and does
Hi Dave,
A few random things and a few small patches for atomic. Pull request for
4.1 so that Laurent can rebase his rcar atomic conversion, which needs a
few things from here. Also better to get the renames in before there's
conflicts.
Cheers, Daniel
The following changes since commit 96abd10e
On Fri, Feb 13, 2015 at 11:48:23AM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Added explicit creation creation and submission of the request structure to
> the
> display object pinning code. This removes any reliance on the OLR keeping
> track
> of the request and the unk
On Fri, Feb 13, 2015 at 11:48:16AM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Start of explicit request management in the execbuffer code path. This patch
> adds a call to allocate a request structure before all the actual hardware
> work
> is done. Thus guaranteeing that
On Fri, Feb 13, 2015 at 11:48:14AM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> For some reason, the i915_add_request() call in
> i915_gem_execbuffer_retire_commands() was explicitly having its return code
> ignored. The _retire_commands() function itself was 'void'. Given th
On Fri, Feb 13, 2015 at 11:48:13AM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The do_execbuf() function takes quite a few parameters. The actual set of
> parameters is going to change with the conversion to passing requests around.
> Further, it is due to grow massively wit
On Fri, Feb 13, 2015 at 11:48:12AM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> In execlist mode, the ringbuf is a function of the ring and context whereas in
> legacy mode, it is derived from the ring alone. Thus the calculation required
> to
> determine the ringbuf pointer
On Fri, Feb 13, 2015 at 11:48:10AM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> There is a flags word that is passed through the execbuffer code path all the
> way from initial decoding of the user parameters down to the very final
> dispatch
> buffer call. It is simply call
On Wed, Feb 18, 2015 at 02:28:16PM +, John Harrison wrote:
> On 13/02/2015 17:03, Chris Wilson wrote:
> >On Fri, Feb 13, 2015 at 04:58:24PM +, John Harrison wrote:
> >>On 13/02/2015 12:19, Chris Wilson wrote:
> >>>On Fri, Feb 13, 2015 at 11:48:56AM +, john.c.harri...@intel.com wrote:
>
On Wed, Feb 25, 2015 at 05:08:37PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Just a few basic tests to make sure fb modifiers can be used and
> behave sanely when mixed with the old set_tiling API.
>
> v2:
>* Review feedback from Daniel Vetter:
> 1. Move cap detection int
On Wed, Feb 18, 2015 at 03:27:38PM +, John Harrison wrote:
> On 13/02/2015 12:15, Chris Wilson wrote:
> >On Fri, Feb 13, 2015 at 11:48:33AM +, john.c.harri...@intel.com wrote:
> >>From: John Harrison
> >>
> >>In execlist mode, context initialisation is deferred until first use of the
> >>g
As vendors transition their drivers from legacy to atomic there's some
duplication of data between drm_crtc and drm_crtc_state (since
unconverted drivers likely won't have a state structure).
i915 is partially converted and does have a crtc->state structure, but
still uses direct crtc fields inter
On Fri, Feb 13, 2015 at 12:21:29PM +, Chris Wilson wrote:
> On Fri, Feb 13, 2015 at 11:48:17AM +, john.c.harri...@intel.com wrote:
> > From: John Harrison
> >
> > The alloc_request() function does not actually return the newly allocated
> > request. Instead, it must be pulled from ring->o
On 01/28/2015 02:07 AM, Chris Wilson wrote:
> On Wed, Jan 28, 2015 at 10:50:18AM +0100, Daniel Vetter wrote:
>> On Wed, Jan 28, 2015 at 09:23:46AM +, Chris Wilson wrote:
>>> On Wed, Jan 28, 2015 at 10:22:15AM +0100, Daniel Vetter wrote:
On Mon, Jan 26, 2015 at 09:08:03AM +, Chris Wilso
On Wed, Feb 25, 2015 at 11:43:25AM -0800, Matt Roper wrote:
> As vendors transition their drivers from legacy to atomic there's some
> duplication of data between drm_crtc and drm_crtc_state (since
> unconverted drivers likely won't have a state structure).
>
> i915 is partially converted and does
As we transition to full atomic modesetting, we want to be able to pass
intel_crtc_state around in various places that we pass intel_crtc
directly today. Ensure that the ->crtc backpointer is properly
initialized in case we need to get back to the associated CRTC.
Signed-off-by: Matt Roper
---
T
As vendors transition their drivers from legacy to atomic there's some
duplication of data between drm_crtc and drm_crtc_state (since
unconverted drivers likely won't have a state structure).
i915 is partially converted and does have have a crtc->state structure,
but still uses direct crtc fields
On ti, 2015-02-24 at 20:00 +0100, Bjørn Mork wrote:
> Imre Deak writes:
>
> > The poweroff handlers undo the actions of the thaw handlers. As the
> > original commit stated saving the registers is not needed there, but
> > it's also not a big overhead and there should be no problem doing it. We
>
Some of the workarounds are to be applied during context save but before
restore and some at the end of context save/restore but before executing
the instructions in the ring. Workaround batch buffers are created for
this purpose as they cannot be applied using normal means. HW executes
them at spe
Starting from Gen8 we have some workarounds that are applied Per context and
they are applied using special batch buffers called as WA batch buffers.
HW executes them at specific stages during context save/restore.
First patch adds a function to create a ringbuffer in which instructions for
WA bat
From: Namrta
This can be used to enable WA BB infrastructure for features like
RC6, SSEU and in between context save/restore etc.
The patch which would need WA BB will have to declare the wa_bb obj
utilizing the function here. Update the WA BB with required commands
and update the address of the
From: Damien Lespiau
Now that the Android build has cairo, we can put cairo-dependant code
back into lib/
v2: Document image format. (Daniel Vetter)
Signed-off-by: Damien Lespiau
---
lib/intel_batchbuffer.c | 26 ++
lib/intel_batchbuffer.h | 2 ++
tests/gem_render_cop
From: Tvrtko Ursulin
Just a few basic tests to make sure fb modifiers can be used and
behave sanely when mixed with the old set_tiling API.
v2:
* Review feedback from Daniel Vetter:
1. Move cap detection into the subtest so skipping works.
2. Added some gtkdoc comments.
3. T
When enabling atomic state object for this ioctl in
commit abd69c55dd8f1f71b33b8c6165217f4329db8f25
Author: Daniel Vetter
Date: Tue Nov 25 23:50:05 2014 +0100
drm: Handle atomic state properly in kms getfoo ioctl
I've forgotten to remove this hunk in one of the later revisions.
drm_encode
From: Tvrtko Ursulin
Recent BSpect updates have changed the watermark calculation to avoid
display flickering in some cases.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_pm.c | 52 +
1 file changed, 32 insertions(+), 20 deletions(-)
diff
From: Tvrtko Ursulin
Starting with SKL display engine can scan out Y, and newly introduced Yf
tiling formats so add the latter to the frame buffer modifier space.
v2: Definitions moved to drm_fourcc.h.
v3: Try to document the format better.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Damien Les
From: Tvrtko Ursulin
Display watermarks need different programming for different tiling
modes.
Set the relevant flag so this happens during the plane commit and
add relevant data into a structure made available to the watermark
computation code.
v2: Pass in tiling info to sprite plane updates a
From: Damien Lespiau
1Mb!
v2: Rebased for addfb2 interface. (Tvrtko Ursulin)
v3: Rebased for fb modifier changes. (Tvrtko Ursulin)
Signed-off-by: Damien Lespiau
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c | 8 ++--
1 file changed, 6
From: Damien Lespiau
v2: Rebased for addfb2 interface and consolidated a bit. (Tvrtko Ursulin)
v3: Rebased for fb modifier changes. (Tvrtko Ursulin)
v4: Use intel_fb_stride_alignment instead of open coding. (Damien Lespiau)
Signed-off-by: Damien Lespiau
Signed-off-by: Tvrtko Ursulin
Reviewed-b
From: Damien Lespiau
Skylake is able to scannout those tiling formats. We need to allow them
in the ADDFB ioctl and tell the harware about it.
v2: Rebased for addfb2 interface. (Tvrtko Ursulin)
v3: Rebased for fb modifier changes. (Tvrtko Ursulin)
v4: Don't allow Y tiled fbs just yet. (Tvrtko Ur
From: Tvrtko Ursulin
Starting with Skylake the display engine can scan out Y tiled objects. (Both
legacy Y tiled, and the new Yf format.)
This series takes the original work by Damien Lespiau and converts it to use the
new frame buffer modifiers instead of object set/get tiling. Some patches nee
From: Tvrtko Ursulin
By this patch all underlying bits have been implemented and this
patch actually enables the feature.
v2: Validate passed in fb modifiers to reject garbage. (Daniel Vetter)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Damien Lespiau (v1)
---
drivers/gpu/drm/i915/intel_displ
From: Damien Lespiau
We now need the bpp of the fb as Yf tiling has different tile widths
depending on it.
v2: Rebased for the new addfb2 interface. (Tvrtko Ursulin)
v3: Rebased for fb modifier changes. (Tvrtko Ursulin)
v4: Added missing case and 128-bit pixel warning. (Damien Lespiau)
Signed-o
On Wed, Feb 25, 2015 at 04:11:18PM +, tim.g...@intel.com wrote:
> From: Tim Gore
>
> The gem_render_linear_blits test tends to get oom killed
> on low memory (< 4GB) Android systems. This is because the
> test tries to allocate (sysinfo.totalram * 9 / 10) in
> buffer objects and the remaining
From: Tim Gore
The gem_render_linear_blits test tends to get oom killed
on low memory (< 4GB) Android systems. This is because the
test tries to allocate (sysinfo.totalram * 9 / 10) in
buffer objects and the remaining 10% of memory is not
always enough for the Android system.
After a discussion w
On Wed, Feb 25, 2015 at 04:52:39PM +0200, Mika Kuoppala wrote:
> Michel Thierry writes:
>
> > The next patch in the series will require it for alloc_pt_single.
> >
> > v2: Rebased after s/page_tables/page_table/.
> >
> > Signed-off-by: Michel Thierry
>
> Reviewed-by: Mika Kuoppala
Merged up t
On Wed, Feb 25, 2015 at 02:00:18PM +, Damien Lespiau wrote:
> > It's either square or 2:1 rectangular. I'll try to double check the numbers
> > for 64bpp then.
>
> Thanks. Thinking about it a bit more, it could just be that the display
> engine has a slightly stricter constraint than the 3D pi
On Wed, Feb 25, 2015 at 02:26:21PM +0530, Praveen Paneri wrote:
> Gen8 Onwards use 48 bit addressing for src and dst base
> addresses. This patch fixes this for destination base address.
>
> Signed-off-by: Praveen Paneri
Merged, thanks.
-Daniel
> ---
> tests/gem_bad_blit.c | 2 ++
> 1 file chan
On Wed, Feb 25, 2015 at 10:29:10AM +0530, Sonika Jindal wrote:
> Skylake supports low voltage swing in edp 1.4. The translation table is
> selected
> based upon the vbt entry for selecting low vswing
> These patches are being pulled from -internal to -nightly.
I presume the 2nd patch has the fixu
On Wed, Feb 25, 2015 at 10:55:48AM +, Tvrtko Ursulin wrote:
>
> On 02/24/2015 09:51 PM, Daniel Vetter wrote:
> >On Mon, Feb 23, 2015 at 03:57:55PM +, Tvrtko Ursulin wrote:
> >>From: Damien Lespiau
> >>
> >>Signed-off-by: Damien Lespiau
> >
> >testdisplay is a bit an awkward test, mostly
On Wed, Feb 25, 2015 at 10:50:04AM +, Tvrtko Ursulin wrote:
> On 02/24/2015 09:42 PM, Daniel Vetter wrote:
> >On Mon, Feb 23, 2015 at 03:56:00PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Display watermarks need different programming for different tiling
> >>modes.
> >>
> >
Michel Thierry writes:
> The next patch in the series will require it for alloc_pt_single.
>
> v2: Rebased after s/page_tables/page_table/.
>
> Signed-off-by: Michel Thierry
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 29 -
> 1 file ch
On Wed, Feb 25, 2015 at 10:50:04AM +, Tvrtko Ursulin wrote:
> Not sure if FIXME is warranted here - to say what? That it will be
> refactored with the two-stage wm rewrite?
Something like that. How about?
"FIXME: The plan for WM updates is to be always computed at check time
to make sure we c
On Wed, Feb 25, 2015 at 12:29:50PM +, Michel Thierry wrote:
> On 2/25/2015 10:55 AM, Mika Kuoppala wrote:
> >Daniel Vetter writes:
> >
> >>On Tue, Feb 24, 2015 at 04:22:33PM +, Michel Thierry wrote:
> >>>This patchset addresses comments from v5 by Mika, specially some rename
> >>>changes
On Wed, Feb 25, 2015 at 10:34:19AM +, Tvrtko Ursulin wrote:
> >While this was what was documented at some point, it's not anymore.
> >Would need an extra patch before this one to introduce
> >plane_blocks_per_line and then this one on top.
>
> Don't follow - what is plane_blocks_per_line and w
On Wed, Feb 25, 2015 at 10:54:31AM +, Tvrtko Ursulin wrote:
>
> On 02/24/2015 04:54 PM, Damien Lespiau wrote:
> >On Mon, Feb 23, 2015 at 03:55:57PM +, Tvrtko Ursulin wrote:
> >>From: Damien Lespiau
> >>
> >>We now need the bpp of the fb as Yf tiling has different tile widths
> >>depending
On Wed, Feb 25, 2015 at 03:29:05PM +0200, Jani Nikula wrote:
> On Wed, 25 Feb 2015, Dan Carpenter wrote:
> > Static checkers complain that we should probably add curly braces
> > because, from the indenting, it looks like seq_printf() should be inside
> > the list_for_each_entry() loop. But the c
Michel Thierry writes:
> From: Ben Widawsky
>
> As we move toward dynamic page table allocation, it becomes much easier
> to manage our data structures if break do things less coarsely by
> breaking up all of our actions into individual tasks. This makes the
> code easier to write, read, and ve
On Wed, 25 Feb 2015, Dan Carpenter wrote:
> Static checkers complain that we should probably add curly braces
> because, from the indenting, it looks like seq_printf() should be inside
> the list_for_each_entry() loop. But the code is actually correct, it's
> just the indenting which is off.
>
>
Static checkers complain that we should probably add curly braces
because, from the indenting, it looks like seq_printf() should be inside
the list_for_each_entry() loop. But the code is actually correct, it's
just the indenting which is off.
Besides fixing the indenting on seq_printf(), I did ad
Conform to same style as the rest of the driver.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_opregion.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 10c60199029d..
Make it easier to handle the extended didl. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_opregion.c | 50 +++
1 file changed, 39 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/d
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_opregion.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index d8de1d5140a7..bce9bbe05549 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/dr
This has fallen between the cracks. No changes since [1]. The cover letter
copy-pasted from there:
Hi all, here's a few updates to opregion. Patches 1-4 should be pretty
trivial and not do anything drastic. Patch 5 starts using the extended
DIDL, but I doubt it will make a huge difference anyway.
Adding support for did2, or the extended support display devices ID
list, increases the total to 15.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_opregion.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_o
Inluding extended didl and cpdl fields
Present since opregion version 3.0.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_opregion.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/inte
Signed-off-by: Jani Nikula
---
include/drm/drm_dp_helper.h | 37 +
1 file changed, 37 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index cc96024e8776..07d94faa9255 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/d
Keep the DPCD macros ordered by address, and make indentation conform to
the rest of the file.
commit e045d20bef41707dbba676e58624b54f9f39e172
Author: Sonika Jindal
Date: Thu Feb 19 13:16:44 2015 +0530
drm: Adding edp1.4 specific dpcd macros
Signed-off-by: Jani Nikula
---
Daniel, this
Mostly display control related DPCD addresses.
Signed-off-by: Jani Nikula
---
include/drm/drm_dp_helper.h | 32
1 file changed, 32 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 209c5b91b0e8..cc96024e8776 100644
--- a/
Signed-off-by: Jani Nikula
---
include/drm/drm_dp_helper.h | 95 ++---
1 file changed, 90 insertions(+), 5 deletions(-)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 98fefe45d158..209c5b91b0e8 100644
--- a/include/drm/drm_dp_
On Mon, 23 Feb 2015, Michael Leuchtenburg wrote:
> I'm certain that it has dynamic backlight control of some sort, as the
> brightness varies based on content. I'm also sure it has an eDP panel, and
> an Intel graphics adapter. I'm not certain that DPCD will let me adjust it,
> or how to check, th
Occasionally it would be interesting to read some of the DPCD registers
for debug purposes, without having to resort to logging. Add an i915
specific i915_dpcd debugfs file for DP and eDP connectors to dump parts
of the DPCD. Currently the DPCD addresses to be dumped are statically
configured, and
On 2/25/2015 10:55 AM, Mika Kuoppala wrote:
Daniel Vetter writes:
On Tue, Feb 24, 2015 at 04:22:33PM +, Michel Thierry wrote:
This patchset addresses comments from v5 by Mika, specially some rename changes
touched several patches.
For GEN8, it has also been extended to work in logical ri
On Wed, Feb 25, 2015 at 10:36:38AM +, Tvrtko Ursulin wrote:
>
> On 02/24/2015 05:36 PM, Ville Syrjälä wrote:
> > On Mon, Feb 23, 2015 at 03:55:56PM +, Tvrtko Ursulin wrote:
> >> From: Damien Lespiau
> >>
> >> Skylake is able to scannout those tiling formats. We need to allow them
> >> in
On 02/24/2015 09:51 PM, Daniel Vetter wrote:
On Mon, Feb 23, 2015 at 03:57:55PM +, Tvrtko Ursulin wrote:
From: Damien Lespiau
Signed-off-by: Damien Lespiau
testdisplay is a bit an awkward test, mostly used by QA for manual
testing. I think we also need some basic kms_setmode subtest to
Daniel Vetter writes:
> On Tue, Feb 24, 2015 at 04:22:33PM +, Michel Thierry wrote:
>> This patchset addresses comments from v5 by Mika, specially some rename
>> changes
>> touched several patches.
>>
>> For GEN8, it has also been extended to work in logical ring submission (lrc)
>> mode, a
On 02/24/2015 04:54 PM, Damien Lespiau wrote:
On Mon, Feb 23, 2015 at 03:55:57PM +, Tvrtko Ursulin wrote:
From: Damien Lespiau
We now need the bpp of the fb as Yf tiling has different tile widths
depending on it.
v2: Rebased for the new addfb2 interface. (Tvrtko Ursulin)
v3: Rebased for
On 02/24/2015 09:46 PM, Daniel Vetter wrote:
On Mon, Feb 23, 2015 at 03:56:01PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
By this patch all underlying bits have been implemented and this
patch actually enables the feature.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/int
On 02/24/2015 05:36 PM, Ville Syrjälä wrote:
On Mon, Feb 23, 2015 at 03:55:56PM +, Tvrtko Ursulin wrote:
From: Damien Lespiau
Skylake is able to scannout those tiling formats. We need to allow them
in the ADDFB ioctl and tell the harware about it.
v2: Rebased for addfb2 interface. (Tvrtk
On Wed, 25 Feb 2015, Daniel Vetter wrote:
> On Tue, Feb 24, 2015 at 01:42:39PM -0800, Matt Roper wrote:
>> On Tue, Feb 24, 2015 at 01:37:54PM -0800, Rodrigo Vivi wrote:
>> > This return 0 without setting atomic bits on fb == crtc->cursor->fb
>> > where causing frontbuffer false positives.
>> >
>>
77 matches
Mail list logo