Created attachment 131562 [details] dmesg Hi there, as discussed with mupuf on #intel-gfx yesterday I am getting an ugly mouse pointer flickering after installing Linux (KDE/Plasma 5.9) on my new ThinkPad T470p (Kaby Lake, HD Graphics 630, Nvidia graphics disabled via ACPI, modesetting). I have three monitors attached (one built-in HiDPI screen, two external ones). I have been able to track down the screen flicker to using --scale 0.75x0.75 on eDP-1 (the internal screen) via xrandr (I need to apply some screen-specific scaling due to the two external screens being normal DPI and the internal one being HiDPI). I am using Arch Linux and hit the issue on both the regular Kernel 4.11.2 and the LTS Kernel 4.9.30. $ uname -a Linux vega 4.11.2-1-ARCH #1 SMP PREEMPT Mon May 22 06:53:49 CEST 2017 x86_64 GNU/Linux Linux distribution: Arch Linux (x86_64) Machine or mother board model: Lenovo ThinkPad T470p (i7-7820HQ) Display connector: 1x eDP (2560x1440 internal 14" screen) 2x DP (2560x1440 external 25" screens connected via Lenovo Ultra Dock) Video recording of flicker: https://goo.gl/photos/E1aspC36Zs967sUV6 dmesg output and Xorg log attached. xrandr command line: -- 8< -- /usr/bin/xrandr -d :0.0 --output DP-3-2 --mode 2560x1440 --pos 0x0 --rotate normal --primary --output DP-3-1 --mode 2560x1440 --pos 2560x0 --rotate normal --output eDP-1 --mode 2560x1440 --pos 5120x774 --rotate normal --scale 0.75x0.75 -- 8< -- Please let me know if you need any further details. Thanks, Thilo
Created attachment 131563 [details] Xorg.log
Created attachment 131564 [details] xrandr --verbose
The flicker from falling back to a swcursor. Two problems here, falling back to a swcursor (transform cursor image instead, only fallback if !affine since you can now malloc from inside the cursor path, just stick the image through pixman and remember to transform the hotpoints; see -intel), and that that path flickers.
(In reply to Chris Wilson from comment #3) > The flicker from falling back to a swcursor. Two problems here, falling back > to a swcursor (transform cursor image instead, only fallback if !affine > since you can now malloc from inside the cursor path, just stick the image > through pixman and remember to transform the hotpoints; see -intel), and > that that path flickers. Why does it fallback to the software cursor?
Is there a way to force using a hw cursor (even if it's not scaled correctly)? The flickering makes precise pointer positioning pretty difficult (and is really annoying as I'm quite sensitive to flickering). I also tried using the intel driver as a workaround, but am regularly getting KDE Plasma freezes.
I am having exactly the same problem. Using Fedora 26, did not have this problem when I was on Fedora 25. Both updated install and fresh install of Fedora 26 has the flickering. It does not matter which display output I use, and switching primary display to secondary display keeps the flickering on the laptop itself. xrandr --output eDP-1 --auto --panning 3840x2160+0+0 --output HDMI-2 --auto --scale 2x2 --right-of eDP-1 $ uname -a Linux localhost.localdomain 4.11.10-300.fc26.x86_64 #1 SMP Wed Jul 12 17:05:39 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
I can confirm this problem, with hd graphics 530 on a i7 6700hq running fedora 26. In the end I just reverted back to the intel driver, the mouse pointer works correctly with it and with zero tearing when using TearFree.
I'm having this problem too except with amdgpu (also happens with the old radeon driver I believe) and it only affects the top 10% of the one screen where I don't scale (which is odd, because I scale a 1440p display to 4k and it doesn't have flickering anywhere). Not a major issue, just a bit annoying.
(In reply to Matthew Scheirer from comment #8) > I'm having this problem too except with amdgpu (also happens with the old > radeon driver I believe) and it only affects the top 10% of the one screen > where I don't scale (which is odd, because I scale a 1440p display to 4k and > it doesn't have flickering anywhere). It doesn't happen on scaled outputs with those drivers because TearFree is enabled by default for scaled outputs.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/70.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.