Hi,
I just discovered almost 100 of the following entries in my log:
[drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed register before
interrupt
Those were accumulated in about 12 hours of operation. I also have one that says
i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog
On Sat, Jan 17, 2015 at 1:49 AM, Chris Wilson wrote:
> On Sat, Jan 17, 2015 at 05:23:59AM +0100, Daniel Vetter wrote:
>> On Fri, Jan 16, 2015 at 05:46:00PM -0800, Kristian Høgsberg wrote:
>> > The I915_EXEC_NO_RELOC flag lets us tell the kernel that the offset we
>> > provide in the validate list
On Mon, Jan 19, 2015 at 08:40:24AM -0800, Matt Roper wrote:
> On Mon, Jan 19, 2015 at 11:04:04AM +, Chris Wilson wrote:
> > On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> > > There's also an issue in (most) X drivers which exaberates this
> > > issues: When changing the cursor
On Fri, Jan 16, 2015 at 8:23 PM, Daniel Vetter wrote:
> On Fri, Jan 16, 2015 at 05:46:00PM -0800, Kristian Høgsberg wrote:
>> The I915_EXEC_NO_RELOC flag lets us tell the kernel that the offset we
>> provide in the validate list entry is what we've used in all relocations
>> to the bo in question.
A very simple testcase to exercise nuclear pageflip. We'll definitely
want to expand upon this in the future, but this is a good starting
point to sanity check nuclear pageflip support.
Signed-off-by: Matt Roper
---
tests/Makefile.sources | 1 +
tests/kms_nuclear.c| 318 ++
Add a call to igt_debug_wait_for_keypress() immediately before we commit
new hardware state to help simplify display debugging.
To use this, just set the environment variable:
IGT_DEBUG_INTERACTIVE=commit
Signed-off-by: Matt Roper
---
lib/igt_kms.c | 1 +
1 file changed, 1 insertion(+)
This commit style only covers the "nuclear pageflip" subset of the
atomic API (i.e., single CRTC, plane updates only). In the future when
our kernel driver has full atomic modeset support, we'll add another
commit style 'atomic' which will re-use the same plane commit calls
added here, but will ge
These patches add support for nuclear pageflip to the IGT testsuite to help
exercise the kernel patches just posted.
Note that nuclear pageflip (and eventually full atomic modeset) support
requires a very new libdrm that hasn't yet gone upstream; you can find a copy
in Rob Clark's repo here:
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5606
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 353/353
We don't have full atomic modeset support yet, but the "nuclear
pageflip" subset of functionality (i.e., plane operations only) should
be ready. Allow the user to force atomic on for debug purposes, or for
fixed-purpose embedded devices that will only use atomic for plane
updates.
The term 'nucle
Cc: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d8b58d6..c5cbcd7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/
drm_plane_helper_{update,disable} are not specific to primary planes;
fix some copy/paste summaries to avoid confusion.
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_plane_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dri
We want to enable/test plane updates via the atomic interface, but as
soon as we flip DRIVER_ATOMIC on, the DRM core will take some atomic
codepaths to lookup properties during drmModeGetConnector() and some of
those codepaths unconditionally dereference connector->state
(specifically when looking
Once we start creating connector states, the DRM core will want to be
able to clean them up for us. Hook up the destruction entrypoint to the
core's helper.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_crt.c| 2 ++
drivers/gpu/drm/i915/intel_dp.c | 2 ++
drivers/gpu/drm/i915
The atomic helpers need these to prepare a new state object when
starting a new atomic operation.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_atomic.c | 35 +++
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 3 +
All of the previous refactoring/consolidation of plane code has resulted
in intel_primary_plane_funcs, intel_cursor_plane_funcs, and
intel_sprite_plane_funcs being identical. Replace all of these with a
single 'intel_plane_funcs' vtable for simplicity.
Signed-off-by: Matt Roper
---
drivers/gpu/
Even though we only support atomic plane updates at the moment, we still
need to add an .atomic_get_property() entrypoint for connectors before
we allow the driver to flip on the DRIVER_ATOMIC bit. As soon as that
bit gets set, the DRM core will start adding atomic connector properties
(in additio
Runtime state that can be manipulated via properties should now go in
intel_plane_state instead so that it can be tracked as part of an atomic
transaction.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 36
drivers/gpu/drm/i915/intel_drv
This patchset adds experimental "nuclear pageflip" support to the i915 driver.
Nuclear pageflip is the subset of atomic modeset functionality that is most
important to display compositors --- i.e., plane updates for a single CRTC.
Nuclear pageflip allows a compositor to ensure that the frame-specif
Add the top-level atomic entrypoints for check/commit. These won't get
called yet; we still need to either enable the atomic ioctl or switch to
using the non-transitional atomic helpers for legacy operations.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gp
This switch allows us to exercise the .atomic_set_property() that will
be used by atomic. The only real changes we need to make here are:
* extract the property validation from our old set_property handler and
stick it in intel_plane_atomic_check().
* make intel_check_*_plane() functions capa
When we flip on the DRIVER_ATOMIC bit, the DRM core will start calling
this entrypoint to set and lookup driver-specific plane property values,
rather than maintaining a shadow copy in object->properties.
Note that although we add these functions to the plane vtable, they will
not yet be called.
Add a transitional helper for planes' .set_property() entrypoint,
similar to what we already have for .update_plane() and
.disable_plane(). This allows drivers that are still in the process of
transitioning to implement and exercise the .atomic_set_property()
driver entrypoint that will eventually
On Monday 19 January 2015 05:20 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
On VLV/CHV the media well rc6 residency gets reported separately
from the render well, so add another file to sysfs so that we can
report the residency to the user.
Signed-off-by: Ville Syrjälä
Loo
On Monday 19 January 2015 05:20 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
On VLV/CHV the rc6 residency calculations read a second register to
determine the actual units used for the residency value. The variable
name 'reg' where that register value is stored shadows the func
On Monday 19 January 2015 05:20 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
We don't register the rc6p and rc6pp sysfs files on VLV, so there's no
point in having any VLV checks in them. Drop the checks.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_sysfs.c |
On Monday 19 January 2015 05:20 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
The performance regression from the CHV RC6 EI->TO change is now fixed
so re-enable TO mode for better RC6 resicency.
This reverts commit e85a5c7989c5be8fe30acc35eba9fb54b3450f36.
Signed-off-by: Vill
On Monday 19 January 2015 05:20 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
We use decimal for all the other RP magic values, so change
GEN6_RP_DOWN_TIMEOUT to decimal as well. Also change the order
of the register writes to match the BIOS spec for easier verification.
Signed
On Monday 19 January 2015 05:20 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Follow the sequence in the BIOS spec and clear the RC_CONTROL register
before changing any of the other RC6/RP registers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 6 ++
On Monday 19 January 2015 05:20 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
CherryViewA0_iGfx_BIOS_DRIVER_PUNIT_spec_y14w28d5 tells us not to enable
the RP down timeout interrupt, and says that the timeout value is hence
not used. We do enable that interrupt currently though,
On Monday 19 January 2015 03:14 PM, Daniel Vetter wrote:
On Fri, Jan 16, 2015 at 08:42:16PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S
Starting with Cherryview, devices may have a varying number of EU for
a given ID due to creative fusing. Punit support different frequency for
diff
BDW with PCI-IDs ended in "2" aren't ULT, but HALO.
Let's fix it and at least allow VGA to work on this units.
v2: forgot ammend and v1 doesn't compile
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87220
Cc: Xion Zhang
Cc: Guo Jinxian
Cc: Jani Nikula
Cc: Stable
Signed-off-by: Rodrigo
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5604
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 353/353
BDW with PCI-IDs ended in "2" aren't ULT, but HALO.
Let's fix it and at least allow VGA to work on this units.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87220
Cc: Xion Zhang
Cc: Guo Jinxian
Cc: Jani Nikula
Cc: Stable
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.
On Mon, Jan 19, 2015 at 08:40:24AM -0800, Matt Roper wrote:
> On Mon, Jan 19, 2015 at 11:04:04AM +, Chris Wilson wrote:
> > On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> > > There's also an issue in (most) X drivers which exaberates this
> > > issues: When changing the cursor
We have BDW that PCH might not be propperly identified and we force it to be
LPT.
However when we correctly identify it is LPT we incorrectly WARN that this isn't
a Haswell. For now we have many platforms out there we still need to force
LPT so let's keep the force below, but let's remove the WARN
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5603
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 353/353
If we need to change the fb height constraints, it sounds like a good
idea to have to do it in one place only.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 19 +++
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_fbdev.c | 3
This vfunc and related structure are only used for fast boot, so let's
rename them to not take them as general purpose ones.
Suggested-by: Daniel Vetter
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++---
drivers/gpu/drm/i915/intel_display.c | 44 +
We may as well try to be consistent everywhere and know the pipes by
their name.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/
crtc->plane can only be different from crtc->pipe pre-Gen4. Don't use it
in new-ish code.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gp
crtc->base.primary->fb was used everywhere. Use fb to temporarily point
there and don't forget to assign fb to its final destination at the end.
v2: Rebase on top of misc changes (mask of DSPSURF, PAGE_ALIGN)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 61 ++
Universal planes have changed a bit the register organization.
v2: Rebase on top of the latest drm-intel-nightly
v3: Use PLANE_SIZE to retrieve the fb size (Tvrtko)
Don't use BUG() (Tvrtko)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 113 +++
We will have a skl_ version shortly!
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1678dd3..08a7130 100644
--- a/d
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index eed2050..1678dd3 100644
--- a
Rather than having "tiled" meaning "is it X-tiled?" convert the field to
explicitely store the tiling mode. The code doesn't have to change much
as 1 is conveniently I915_TILING_X.
This is to accommodate future changes around tiling modes and scannout
buffers.
Signed-off-by: Damien Lespiau
---
Follow up of
http://lists.freedesktop.org/archives/intel-gfx/2014-October/054391.html
with:
- Remarks from Tvrtko on patch 8 addressed.
- Suggestion from Daniel implemented (patch 9)
--
Damien
Damien Lespiau (9):
drm/i915: Change plane_config to store a tiling_mode
drm/i915: Use a comm
On Fri, Oct 31, 2014 at 11:38:34AM +, Tvrtko Ursulin wrote:
>
> On 10/29/2014 05:22 PM, Damien Lespiau wrote:
> >Universal planes have changed a bit the register organization.
> >
> >Signed-off-by: Damien Lespiau
> >---
> > drivers/gpu/drm/i915/intel_display.c | 108
> >
On Mon, Jan 19, 2015 at 11:04:04AM +, Chris Wilson wrote:
> On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> > There's also an issue in (most) X drivers which exaberates this
> > issues: When changing the cursor buffer the X cursor code does a a)
> > disable cursor b) update cur
A previous commit:
commit 2f2c491cf3167befe7c79e4b17afb4f6284dfc84
Author: Mika Kuoppala
Date: Fri Mar 28 10:52:46 2014 +0200
lib/drmtest: don't dup quiescent fd
introduced a regression for drm object leak checking. A following commit:
commit 8741c2289f17e9bcb740a01cad4764a71c918eea
Aut
On Fri, Jan 16, 2015 at 06:07:28PM +, Damien Lespiau wrote:
> From: Akash Goel
>
> Updated the i915_drpc_info & i915_gen6_forcewake_count debugfs interface
>
> v2: Change all IS_GEN9() by gen >= 9 (Damien)
>
> Change-Id: Ibed2fb71b233a369e69278bc96298df82d032a47
> Signed-off-by: Akash Goel
On Fri, Jan 16, 2015 at 06:07:27PM +, Damien Lespiau wrote:
> From: Zhe Wang
>
> Enable coarse power gating for Gen9. This feature allows render and
> media engine to enter RC6 independently. Policies are configured
> together with RC6. This feature will only be enabled when RC6 is
> enabled.
From: Mika Kuoppala
As we now have forcewake domains, take advantage of it
by putting the differences in gen fw handling in data rather
than in code.
In past we have opencoded this quite extensively as the fw handling
is in the fast path. There has also been a lot of cargo-culted
copy'n'pasting
Otherwise setting the rotation property will cause the primary plane to
be disabled, caused by having a 0x0 initial value.
v2: Rebase on top of the move to plane helpers.
Cc: sta...@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87662
Signed-off-by: Ander Conselvan de Oliv
This adds a test that does a suspend/resume cycle between configuring
a plane and getting the crc value for the pipe. The intention is to
test if the user requested stated is restored properly, instead of
being clobbered by the state read out from the hardware.
Signed-off-by: Ander Conselvan de Ol
On 15/01/15 07:38, Jaeyong Yoo wrote:
> Hello Daniel and other maintainers,
>
> While I'm working on drm memory allocator with myself, I've encountered
> render ring hang.
> And I am noticed that I can diagnose the command streamer's status with the
> following registers:
>
> INSTPS: 0x2070
> C
On 15/01/15 07:38, Jaeyong Yoo wrote:
> Hello Daniel and other maintainers,
>
> While I'm working on drm memory allocator with myself, I've encountered
> render ring hang.
> And I am noticed that I can diagnose the command streamer's status with the
> following registers:
>
> INSTPS: 0x2070
> C
On Mon, Jan 19, 2015 at 01:50:53PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On VLV/CHV the media well rc6 residency gets reported separately
> from the render well, so add another file to sysfs so that we can
> report the residency to the user.
>
> Signed-off-by: Vil
On Mon, Jan 19, 2015 at 01:50:52PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On VLV/CHV the rc6 residency calculations read a second register to
> determine the actual units used for the residency value. The variable
> name 'reg' where that register value is stored sha
On Mon, Jan 19, 2015 at 01:50:48PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We use decimal for all the other RP magic values, so change
> GEN6_RP_DOWN_TIMEOUT to decimal as well. Also change the order
> of the register writes to match the BIOS spec for easier verifica
On Mon, Jan 19, 2015 at 01:50:47PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Follow the sequence in the BIOS spec and clear the RC_CONTROL register
> before changing any of the other RC6/RP registers.
Hmm, we do disable RC_CONTROL except for a very notable absence of
On Mon, Jan 19, 2015 at 01:50:52PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On VLV/CHV the rc6 residency calculations read a second register to
> determine the actual units used for the residency value. The variable
> name 'reg' where that register value is stored sha
On Mon, Jan 19, 2015 at 01:50:51PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We don't register the rc6p and rc6pp sysfs files on VLV, so there's no
> point in having any VLV checks in them. Drop the checks.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
From: Ville Syrjälä
On VLV/CHV the rc6 residency calculations read a second register to
determine the actual units used for the residency value. The variable
name 'reg' where that register value is stored shadows the function
argument 'reg'. That can easily leave the readed utterly confused, so
r
From: Ville Syrjälä
CherryViewA0_iGfx_BIOS_DRIVER_PUNIT_spec_y14w28d5 tells us not to enable
the RP down timeout interrupt, and says that the timeout value is hence
not used. We do enable that interrupt currently though, so leaving the
timeout as 0 results in very poor performance as the GPU freq
From: Ville Syrjälä
The performance regression from the CHV RC6 EI->TO change is now fixed
so re-enable TO mode for better RC6 resicency.
This reverts commit e85a5c7989c5be8fe30acc35eba9fb54b3450f36.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 5 +++--
1 file changed, 3
From: Ville Syrjälä
We use decimal for all the other RP magic values, so change
GEN6_RP_DOWN_TIMEOUT to decimal as well. Also change the order
of the register writes to match the BIOS spec for easier verification.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file
From: Ville Syrjälä
Follow the sequence in the BIOS spec and clear the RC_CONTROL register
before changing any of the other RC6/RP registers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm
From: Ville Syrjälä
We don't register the rc6p and rc6pp sysfs files on VLV, so there's no
point in having any VLV checks in them. Drop the checks.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_sysfs.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i91
From: Ville Syrjälä
On VLV/CHV the media well rc6 residency gets reported separately
from the render well, so add another file to sysfs so that we can
report the residency to the user.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_sysfs.c | 25 +
1 file cha
From: Ville Syrjälä
This series fixes the performance regression caused by the CHV RC6
EI->TO mode change. I also slapped on some other cleanups, and I
added a new media_rc6 residency file to sysfs so that we can observe
the RC6 residency of the media well and not just the render well.
Ville Syr
On Saturday 17 January 2015 09:54 AM, Daniel Vetter wrote:
On Fri, Jan 16, 2015 at 02:07:26PM +0530, Sonika Jindal wrote:
Mainly taking care of some register offsets, otherwise things are similar to
hsw. Also, programming ddi aux to use hardcoded values for psr data select.
v2: introduce EDP_
On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> On 19/01/2015 10:08, Ville Syrjälä wrote:
> > On Sat, Jan 17, 2015 at 02:06:35AM -0800, Jeremiah Mahler wrote:
> >> Matt, all,
> >>
> >> Commit ea2c67bb4aff introduces a bug which causes the mouse to move in a
> >> very unusual way, a
On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> There's also an issue in (most) X drivers which exaberates this
> issues: When changing the cursor buffer the X cursor code does a a)
> disable cursor b) update cursor image c) enable cursor cycle.
Notably not -intel on which the bug
On 19/01/2015 10:08, Ville Syrjälä wrote:
On Sat, Jan 17, 2015 at 02:06:35AM -0800, Jeremiah Mahler wrote:
Matt, all,
Commit ea2c67bb4aff introduces a bug which causes the mouse to move in a
very unusual way, as if it has a lot of inertia. It will lag behind and
then overshoot the expected pos
Damien Lespiau writes:
> From: Jesse Barnes
>
> Per latest PM programming guide.
>
> v2: the wrong flavour of the function updating the ring frequency was
> called, leading to dead locks (Tvrtko)
>
> v3: Add GEN6_RP_MEDIA_IS_GFX to RP_CONTROL (Imre, done by Damien)
>
> Signed-off-by: Jesse B
On Sat, Jan 17, 2015 at 11:05:59AM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> Use new Sideband offset to read max/min/gaur freq based on the SKU it
> is running on. Based on the Number of EU, we read different bits to
> identify the max frequencies at which system can run.
>
> v
On Fri, Jan 16, 2015 at 08:42:16PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> Starting with Cherryview, devices may have a varying number of EU for
> a given ID due to creative fusing. Punit support different frequency for
> different fuse data. We use this patch to help get tota
On Sat, Jan 17, 2015 at 02:06:35AM -0800, Jeremiah Mahler wrote:
> Matt, all,
>
> Commit ea2c67bb4aff introduces a bug which causes the mouse to move in a
> very unusual way, as if it has a lot of inertia. It will lag behind and
> then overshoot the expected position.
>
> I reproduced this bug o
On Fri, Jan 16, 2015 at 06:16:50PM +0200, Jani Nikula wrote:
> On Fri, 16 Jan 2015, Matt Roper wrote:
> > When we transitioned to the atomic plane helpers in commit:
> >
> > commit ea2c67bb4affa84080c616920f3899f123786e56
> > Author: Matt Roper
> > Date: Tue Dec 23 10:41
80 matches
Mail list logo
