https://bugs.kde.org/show_bug.cgi?id=357692
Martin Gräßlin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=357692
--- Comment #14 from Qbert ---
(In reply to Thomas Lübking from comment #13)
> The major problem with Xinput2 is that we don't (perfectly) know whether it
> can cause us deadlocks in Xlib.
> Iff the problem is limited to XIQueryDevice, then it's the by
https://bugs.kde.org/show_bug.cgi?id=357692
--- Comment #13 from Thomas Lübking ---
The major problem with Xinput2 is that we don't (perfectly) know whether it can
cause us deadlocks in Xlib.
Iff the problem is limited to XIQueryDevice, then it's the by far superior
solution (no polling at all) -
https://bugs.kde.org/show_bug.cgi?id=357692
--- Comment #12 from Qbert ---
(In reply to Thomas Lübking from comment #8)
> Try this on top, resp. to lower the "distance" threshold to other values.
Tried lowering the threshold as low as 1 but it still studders on slow
mousemovements. Have not trie
https://bugs.kde.org/show_bug.cgi?id=357692
--- Comment #11 from Martin Gräßlin ---
different approach using XInput: https://git.reviewboard.kde.org/r/126733/
I have not tested with zoom effect, only with track mouse to see whether the
mouse updates correctly.
--
You are receiving this mail be
https://bugs.kde.org/show_bug.cgi?id=357692
--- Comment #10 from Thomas Lübking ---
(In reply to Qbert from comment #9)
> Because the goal is to prevent unnecessary polling when the
> cursor is not moving at all?
Yes. Some dead-zone would be good to protect against judder. One might als want
to
https://bugs.kde.org/show_bug.cgi?id=357692
--- Comment #9 from Qbert ---
Great! I'll have a look at it tonight.
I estimate that it has to be as close to 'no movement at all' in order to
prevent choppy behavior when moving the mouse slightly. But I guess that it's
OK, right? Because the goal is
https://bugs.kde.org/show_bug.cgi?id=357692
--- Comment #8 from Thomas Lübking ---
Try this on top, resp. to lower the "distance" threshold to other values.
diff --git a/cursor.cpp b/cursor.cpp
index 271eec9..e3b3111 100644
--- a/cursor.cpp
+++ b/cursor.cpp
@@ -327,7 +327,7 @@ void X11Cursor::mo
https://bugs.kde.org/show_bug.cgi?id=357692
--- Comment #7 from Qbert ---
(In reply to Thomas Lübking from comment #3)
> Qbert (Hubert? ;-), can you try the patch on your scenario?
Nice! I tried the path and yes it's now very smooth at higher mouse speeds. But
I was perhaps a bit unclear in my d
https://bugs.kde.org/show_bug.cgi?id=357692
--- Comment #6 from Martin Gräßlin ---
> I'll gladly test out patches or contribute in any way I can. Just let me know
> or point me in the right direction.
My suggestion is do what you did here: report good bug reports. As I explained:
we don't know
https://bugs.kde.org/show_bug.cgi?id=357692
--- Comment #5 from Thomas Lübking ---
Apply the patch from https://git.reviewboard.kde.org/r/126716/ to the
Plasma/5.5 branch of https://quickgit.kde.org/?p=kwin.git
Briefly:
--
git clone git://anongit.kde.org/kwin.git
cd kwin
git checkout Plasma/
https://bugs.kde.org/show_bug.cgi?id=357692
--- Comment #4 from Qbert ---
Tank you all for the comments. I've got full respect for the limited resources
available and understand that these niche issues are not top priority.
I'm not a developer but I'm willing to do whatever it takes to help out.
https://bugs.kde.org/show_bug.cgi?id=357692
Thomas Lübking changed:
What|Removed |Added
URL||https://git.reviewboard.kde
https://bugs.kde.org/show_bug.cgi?id=357692
--- Comment #2 from Thomas Lübking ---
More than annoying: see bug #353587 (the issue is there in Qt already, but we'd
add to it)
About polling, present state is somehow suboptimal, we poll too often but it's
insufficient for smooth movements.
=> dynam
https://bugs.kde.org/show_bug.cgi?id=357692
Martin Gräßlin changed:
What|Removed |Added
Severity|grave |normal
--- Comment #1 from Martin Gräßlin ---
15 matches
Mail list logo
