Created attachment 135142 [details] dmesg since boot with drm.debug=0x06 Hi, I noticed that the touchpad coasting has been acting really strange at random with the current release candidates of 4.14, with rc6 being the last I tested. Everything is fine with 4.13 or older releases. After a bit of experimenting it seems that whenever my desktop environment shows an on screen display, touchpad coasting happens in the wrong direction: if I'm scrolling up, the window scrolls down. I can upload a video showing the problem if needed. I think the problem is caused by some desktop effect that is used for OSDs since I think I've observed the same behavior even when no OSD was displayed. In addition to that, disabling desktop effects gets rid of the problem. Interestingly I observed this behavior only with QT applications. This has never happened with 4.13, so I did a bisection and found the change that's causing this behavior: commit dc911f5bd8aacfcf8aabd5c26c88e04c837a938e Author: Jim Bride <jim.bride@linux.intel.com> Date: Wed Aug 9 12:48:53 2017 -0700 drm/i915/edp: Allow alternate fixed mode for eDP if available. I confirm that reverting this change fixes the problem on v4.14-rc6. This could really be a bug in some userspace component that it's being triggered by that change, but it has never happened until now, so I'm reporting this here. I built xf86-video-intel from master (4798e18b2b2c8b0a05dc967e6140fd9962bc1a73), but the problem persists. I'm using Debian sid and xserver 1.19.5 on a Dell XPS 13 9333 (i7-4500U with HD Graphics 4400). Gabriele
Hello, could you please share a dmesg with drm.debug=0xe instead. Thank you.
Created attachment 135190 [details] dmesg with drm.debug=0xe
Created attachment 135277 [details] [review] Fix alternate mode comparison I find it odd that something to do with the display mode would impact the touchpad, but there may be an interaction that I'm not aware of. The patch wasn't behaving as intended, though, so I uploaded a patch that appears to fix dc911f5bd8aa based on my testing. Can you try the attached patch without the revert on 4.14.rc6 or rc8 (I tested on rc8) and see if it addresses your problem?
Yes, the patch fixes my problem, thanks.
(In reply to Jim Bride from comment #3) > Created attachment 135277 [details] [review] [review] > Fix alternate mode comparison > > I find it odd that something to do with the display mode would impact the > touchpad, > but there may be an interaction that I'm not aware of. The patch wasn't > behaving as intended, though, so I uploaded a patch that appears to fix > dc911f5bd8aa based on my > testing. Can you try the attached patch without the revert on 4.14.rc6 or > rc8 (I > tested on rc8) and see if it addresses your problem? Huh, isn't the typical alt mode basically the same mode with different vrefresh? Like in this case. Aren't we now throwing away the alt mode altogether with this patch? Gabriele, *without* any patches applied, can you see a difference between using the 60 vs. 48 Hz refresh rate modes?
(In reply to Jani Nikula from comment #5) > Huh, isn't the typical alt mode basically the same mode with different > vrefresh? Like in this case. Aren't we now throwing away the alt mode > altogether with this patch? > > Gabriele, *without* any patches applied, can you see a difference between > using the 60 vs. 48 Hz refresh rate modes? I can't notice any difference when I change the refresh rate. Using some tools that measure the refresh rate of the screen I found that 4.14-rc6 is stuck at 48Hz, no matter what value I set for the refresh rate, while 4.13 and 4.14-rc8+path are stuck at 60Hz.
It seems that being stuck at alternative low fps issue caused by commit dc911f5bd8aacfcf8aabd5c26c88e04c837a938e affects many people https://bugzilla.kernel.org/show_bug.cgi?id=198241 https://github.com/NixOS/nixpkgs/issues/31999#issuecomment-354617884 https://forum.manjaro.org/t/poor-opengl-performance-on-linux-4-14/35453 https://bbs.archlinux.org/viewtopic.php?id=232354 https://bugs.archlinux.org/task/56711
More users reporting that Jim's patch https://bugs.freedesktop.org/attachment.cgi?id=135277 fixes issues, see https://forum.manjaro.org/t/poor-opengl-performance-on-linux-4-14/35453/156 It would be nice if it can land on drm-tip and then be backported to 4.15 and 4.14 kernels. There are also two potential duplicates: https://bugs.freedesktop.org/show_bug.cgi?id=104414 https://bugs.freedesktop.org/show_bug.cgi?id=104357
*** Bug 104414 has been marked as a duplicate of this bug. ***
Any status update of this? We have regression, bisected, patch available, affected dozens of people and it doesn't even make it to drm-tip, not saying about linux-mainline or linux-stable. Are there any issues discussed internally? Arch based distros are already including Jim's patch downstream.
Citing dc911f5bd8aa ("drm/i915/edp: Allow alternate fixed mode for eDP if available."), "Some fixed resolution panels actually support more than one mode, with the only thing different being the refresh rate." Now, the patch proposed in comment #3 (and never submitted to the intel-gfx mailing list, btw) requires the same refresh rate in the alt mode. This seems like defeating the whole purpose of the original commit. What's the point? Without an explanation, I'd rather merge a revert of the original commit.
@Jani Nikula Thx for the answer. IMO revert would be ok but I don't know what Jim Bride (original submitter) thinks of this. Anyway don't forget backporting it to 4.14/4.15
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Closing, please re-open if still occurs.
I've just tried 4.17-rc3 and this is still a problem. I didn't try drm-tip, but I don't see neither the revert nor the patch here attached. I'll try to get drm-tip tested and reopen this if the problem still occurs, unless someone does it before me.
Jani, any help here?
This is related to https://bugs.freedesktop.org/show_bug.cgi?id=105469 and fix is being worked on https://patchwork.freedesktop.org/patch/216619/
Please try this revert patch on top of drm-tip, and report back: http://patchwork.freedesktop.org/patch/msgid/20180516080110.22770-1-jani.nikula@intel.com
I tested the revert on top of drm-tip and I confirm that it fixes the problem.
Fixed in drm-tip: https://cgit.freedesktop.org/drm-tip/commit/?id=d93fa1b47b8fcd149b5091f18385304f402a8e15
Thanks for the bug report, testing, and patience everyone. Please reopen if the problem persists with that commit, or reappears.
Canlı TV, internet üzerinden kesintisiz TV izleme noktasıdır. Kısacası, uydu çanağını bir cep telefonu, tablet veya bilgisayar üzerinden kullanabilirsiniz. televizyon izlemeye gerek kalmadan. Internet TV izlemenin dezavantajları gibi birçok olumlu yönü vardır. İnternet bağlantınız iyi kalitede Kesintisiz ücretsiz TV şovları izleyebildiğiniz sürece, sınırsız sayıda kanalı takip edebilirsiniz. https://canlitv.center/
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.