Screen graininess/distortion in some applications, Xorg 1.20.11, i3 4.17.1, gfx intel i915
Linux - DesktopThis forum is for the discussion of all Linux Software used in a desktop context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Screen graininess/distortion in some applications, Xorg 1.20.11, i3 4.17.1, gfx intel i915
Hi,
I'm getting a problem with some applications I'm running on this laptop, where things like menus, tooltips and graphic buttons glitch as they first display.
The glitches update and correct within a couple of seconds, but also pause display of other things while they happen, so if I'm running my cursor over a menu bar or graphical option, the glitch on the first hover stops the next pop-up/hover rendering. Sometimes, the glitching is repeatable, sometimes it only happens on the first display (like there's a cache of the image and the cache holds the right one).
The glitch looks like a short line of pixels have been displaced in the image, usually staggered through the whole lot. It is very much like the sort of left/right glitching TV and film often use to indicate a disturbed display of something.
Example applications are the Mu editor (big icons at the top glitch), the tooltips for the extension icons in Chrome and Vivaldi, and the icons on screenrec. But applications like Franz, Netbeans and Steam do not do it at all.
One thing I suspect may be quite telling is that if I start the glitching applications as root from the command line, they do not glitch.
I've tried making my root environment the same as my plain user one (setting all the XDG environment variables root doesn't usually have for example), but root still has no problem running them.
I'm stuck on what to look at next, any pointers would be very welcome!
Xorg 1.20.11,
Window manager is i3 4.17.1,
Graphics card (sorry, not actually sure, hwinfo chucks out a lot of numbers, but includes intel i915)
Does it happen if you open an alternate X session type, such as IceWM, instead of i3?
It sounds like what you're describing is what driver developers call "tearing", a driver issue, not an application, WM or DE issue per se. i915 doesn't actually tell us anything, as virtually all Intel IGPs depend on that kernel device driver to support an optimal display driver. Depending on the actual IGP (aka CPU) model that you have, there may be a kernel command line option or Xorg configuration option that can mitigate the tearing. I'm running an Intel IGP here:
Providing same info here might help someone here help you find an option, or might tell you there's nothing that can be done about it, or not until you upgrade to a more recent kernel and/or Xorg and/or DE. I've had tearing in the past, but not for a while.
I'm currently seeing something that I think is very close to what OP describes; it happens with UI elements, also text entries, but not actual images afaics.
It happens with certain applications (kepassxc, tor-browser, virtualbox - also inside VMs) but not others (firefox, alacritty, xterm, pcmanfm, openbox).
I made a screencast but the phenomenon doesn't show up there.
I tried taking some screenshots but could not catch it there either.
I would describe it as mostly horizontal displacement of pixels in certain UI elements. I would not describe it as tearing, although there's a time element: the displacement fixes itself after a second or so.
I do not use any of the application OP cites, but I'm pretty sure we are talking about the same problem here.
Grobbendonk, please show us
Code:
grep -iEA5 'uxa|sna|tearfree|accel' ~/.local/share/xorg/Xorg.0.log
ls /etc/X11/xorg.conf.d/*ntel*conf
cat /etc/X11/xorg.conf.d/*ntel*conf
______________________
I played with my /etc/X11/xorg.conf.d/20-intel.conf file and fiddled around with the 2 drivers & the Options TearFree and AccelMethod.
The "modesetting" driver is built into the kernel, the "intel" driver requires installation of xf86-video-intel (or xserver-xorg-video-intel on Debian).
This is what I figured out about my situation (had to log out of and into Xorg many times):
modesetting driver:
do not specify anything: can play STK, but artefacts on screen. tearing in non-fullscreen video.
specify TearFree true: can play STK, but artefacts on screen. tearing in non-fullscreen video.
specify TearFree false: can play STK, but artefacts on screen. tearing in non-fullscreen video.
specify AccelMethod uxa: video playback broken, STK too slow, no artefacts
specify AccelMethod sna: video playback broken, STK too slow, no artefacts
specify Accel off/false, and make sure AccelMethod is commented out: tearing with non-fullscreen video, STK OK, artefacts
intel driver:
do not specify anything: can play STK, no artefacts, no tearing
specify TearFree true: as above
specify TearFree false: can play STK, no artefacts, tearing in non-fullscreen video.
specify AccelMethod uxa: tearing in non-fullscreen video, STK OK, no artefacts
specify AccelMethod sna: no tearing, STK OK, no artefacts
specify AccelMethod off: no tearing, STK OK, no artefacts
specify Accel off, and make sure AccelMethod is commented out: STK unplayably slow, no artefacts, video playback broken, even alacritty broken
Take it with a grain of salt; I only quickly tested with 1 x264 video with mpv and only one game (Supertuxkart), and I suspect this is device-specific (see lspci output from previous post).
Ideally one should also run the above mentioned 'grep' command after every change.
Also note that the default values if unspecified (commented) seem to differ a little from this man page.
Great, thank you both for looking at it for me. I think ondoho's description of the problem is much better than mine - "... mostly horizontal displacement of pixels in certain UI elements ... the displacement fixes itself after a second or so."
Only returned hits on "accel" and those were all about the touchpad on the machine, not the graphics. There's no xorg.conf.d directory, nor any "intel.conf" type config files anywhere I've looked.
And I tried Tor browser - confirm it's happening there - the page loading bar, and the icons to the right of the address bar all glitch.
Am I right in thinking that's normal for an off-the-shelf Xorg install? And that if I want to start playing with settings, I can create /etc/X11/xorg.conf.d/20-intel.conf and start setting overriding parameters in there? I don't need to do anything else?
Last edited by Grobbendonk; 10-15-2021 at 05:11 PM.
OP has Intel Comet Lake GT2, quite a bit newer than ondoho's 530/Sky Lake(?), and likely not yet entirely debugged as of the X version shown by inxi, which by the way is a buggy antique. To use inxi with considerably fewer bugs, and improved output options, you may try upgrading it via the -U switch. Pop!_OS may have disabled -U, in which case, best to follow the upstream instructions here before using it again. And, any time you're pasting command output here, please enclose it in code tags (#), as you see ondoho and I have done, to preserve readability.
Quote:
Am I right in thinking that's normal for an off-the-shelf Xorg install? And that if I want to start playing with settings, I can create /etc/X11/xorg.conf.d/20-intel.conf and start setting overriding parameters in there? I don't need to do anything else?
It's either there, or possibly various kernel command line parameters. Or, ask of the Intel driver writers on their mailing list. Someone there may suggest your best option and/or whether it's a known and/or correctable problem.
Sorry, I'm used to forums that do formatting a lot better, it's been a while since I was here.
I know inxi is old, but as it was suggested, I thought it might be of use to the person who mentioned it.
I am not sure what you mean by "It's either there, or possibly various kernel command line parameters". I already said the file is not there, and that the install is off-the-shelf, so unless you know what those kernel command line parameters are for an off-the-shelf install and have forgotten to explain what that means, I'm stuck on what you're getting at.
To me, the important part of my follow-up question was "can I just create the config file and start putting settings in it?". I can't find any coherent explanation of if I can do that. There's lots of stuff on what I might put in it, which I will work through, but I can't see if it really is just "create the file". I've been burned before by "create an override file, but you will need to also set a flag to tell the software to actually read the overrides" and by "if you create this file and get it wrong, everything stops working".
I know inxi is old, but as it was suggested, I thought it might be of use to the person who mentioned it.
It's useful regardless, just much better with current version than from the antique shipped by the OS, which omits useful options later added, besides including copious bugs.
Quote:
I am not sure what you mean by "It's either there,
I meant create it, use it modify it. You can't do any permanent damage with it.
Quote:
or possibly various kernel command line parameters".
Kernel driver options generally get added to grub stanza's kernel command lines, while display driver options go in config files. The general purpose of /etc/ is for global/administrator options.
Quote:
To me, the important part of my follow-up question was "can I just create the config file and start putting settings in it?".
Am I right in thinking that's normal for an off-the-shelf Xorg install? And that if I want to start playing with settings, I can create /etc/X11/xorg.conf.d/20-intel.conf and start setting overriding parameters in there?
Yes.
I am aware that our hardware differs and possibly also many software versions (for example, I do not use a compositor), but the error description is similar enough to encourage you to try these things.
For my specific situation there was no setting that would allow me to play games and watch video (with GPU accelaration), and have no artefacts on the screen - with the modesetting driver.
With the intel driver, it's almost the other way round: almost all settings "Just Work".
I think it's no coincidence that the archwiki still recommends it.
Which reminds me, please make sure to check out both links in my last post, they help significantly in understanding what I'm rambling about here.
FWIW, I have settled on the following now: /etc/X11/xorg.conf.d/20-intel.conf:
Code:
# see wiki.archlinux.org/title/Intel_graphics#Xorg_configuration
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
#Driver "modesetting"
Option "TearFree" "false"
# AccelMethod: one of sna (default), uxa, or blt (case INsensitivie?)
#Option "AccelMethod" "sna"
Option "RelaxedFencing" "true"
# man.archlinux.org/man/intel.4#CONFIGURATION_DETAILS says "Default: Enabled for G33 and later"
EndSection
Quote:
I don't need to do anything else?
As I wrote in post #4:
Quote:
The "modesetting" driver is (already) built into the kernel, the "intel" driver requires installation of xf86-video-intel (or xserver-xorg-video-intel on Debian).
I'm guessing it's the latter for Ubuntu-based Pop_OS.
Please go back to my post #3 and check at least /proc/cmdline for the unlikely case that you have something in there that has a bearing on this situation (look for the keyword "intel" or "i915").
The grep command will help you understand what's going on - if you want, execute it any time you make a change to /etc/X11/xorg.conf.d/somethingsomethingintel.conf, that is after you logged out/in.
If you want to do some testing, keep in mind that you only need to restart the Xorg server (i.e. log out of the graphical session and back in) after every change, not the whole machine.
The "modesetting" driver is (already) built into the kernel, the "intel" driver requires installation of xf86-video-intel (or xserver-xorg-video-intel on Debian).
I'm guessing it's the latter for Ubuntu-based Pop_OS.
The mode setting services, aka KMS, kernel device driver (module) for our Intel IGPs is named i915. We have no other option.
The "modesetting" is the DIX (Device Independent X) display driver provided by the Xorg server package, a newer technology that supports GPUs for which a kernel module providing KMS exists, which includes AMD/ATI, Intel and NVidia. It's the technical default, but because most distros ship a meta-package that installs xf86-video-*, it may or may not be the selected driver in any given distro.
The old technology, Intel-specific, DDX (Device Dependent X) display driver upstream, and in some distros, is provided by the xf86-video-intel package, and renamed xserver-xorg-video-intel by Debian and its derivatives (e.g. Pop!_OS), and other names by some other distros. The xf86-video-intel driver has had no official release in over 7 years, in part due to who pays for it - Intel - and what else they are paid to do, which is (in part) maintaining the (newer technology; default) "modesetting" DIX.
For more info on graphics drivers I wrote a primer here.
99% of the fix was reading and understanding what you've both been talking about, and the last 1% was trial-and-error on me trying out some xorg/driver settings that looked related to things you've told me to look at. I went in hard by creating a new xorg config file (after you told me it was safe to do so, and what parameters to look at), and dropping every suggestion into it, but then trimming it down until I was left with this:
We have talked about this before - while it hasn't had a release for 7 years, it is still being maintained & worked on. The latest commit to master was 9 months ago, and Archlinux uses that for its repo package. Ubuntu focal and later use commits from 2020.
I appreciate that DDX might run out evtl. but as of now, and for my specific setup, it's the only one that satisfies 100%.
@Grobbendonk: My box sucks too - it has nearly identical specs to yours.
IMO the intel driver does fractionally better 2D (I know that's heresy) but they're just handling too much stuff with the modesetting driver now, and the Ivy Bridge cards lost out a bit in the updates. The intel driver does NO 3D, and you'll end up very sad if you open google earth and try to get clever.
My laptop was made in 2012. There is a hardware upgrade due, and I intend to get a box, with no APU and individually replaceable component parts. That's the real solution.
for my specific setup, it's the only one that satisfies 100%.
Some people do, some people don't. I have hundreds of installations of various distros. The only ones I run on the Intel DDX are the antiques that the Modesetting DIX doesn't support. That from which I type this:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
