I was asked to report this here after I inserted comment number 27 in
The problem concerns corruption of text displayed on gnome utilities on my Dell Latitude E6410 using intel graphics, running Fedora 22 and and Fedora 24 with ctwm window manager.
I seem to have fixed the problem on that machine (using f24) by inserting Option "AccelMethod" "uxa" in /etc/X11/xorg.conf.d/20-intel.conf, i.e. I created a file /etc/X11/xorg.conf.d/20-intel.conf
Identifier "Intel Graphics"
Option "AccelMethod" "uxa"
based on instructions found here:
Scanning bug reports I find different sorts of font/text corruption problems reported. E.g. a different problem is reported on this site in
So similar wording in the bug reports may be misleading.
The problem I reported did not affect the vast majority of text displays, including use of xterm, firefox and other browsers, liberoffice, other editors. It affects *only* gnome related text corruption, e.g. in gnome-control-center and other displays concerned with sound/volume control, sound recorder, and networking. It also affected xclock.
I don't have any screenshots, and I have now fixed the problem on my laptop by using the "uxa" option. However examples partly similar to the ones I experenced are shown in attachments in various bug reports. The symptoms include mainly missing characters, but in some cases characters are displayed in a corrupted form, e.g. with black blotches.
Using google, I found similar bug reports, with similar sample images, on several different web sites not part of the fedora or redhat bug reporting mechanism, so it is not a problem specific to fedora. A few users reported successful use of "uxa" instead of "sna" but in most cases users and their advisors seem to be completely in the dark. So it looks as if a fix is needed across distributions, without users having to edit configuration files, though that has worked for me.
Please attach your Xorg.log (both working and broken would be useful). Are you are able to build from https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/ ?
Created attachment 127070 [details]
Xorg Log Sept 26
First of two log files requested -- this show use of SNA
Created attachment 127071 [details]
Xorg Log Oct 6
Second of two log files requested. This shows use of uxa (also using a newer kernel) If requested I can rever to sna with this kernel, when I get time.
(In reply to Chris Wilson from comment #1)
> Please attach your Xorg.log (both working and broken would be useful).
I have now attached two Xorg.log files, though using different kernels as well as different settings. (I was advised to use the 'upstream' kernel to avoid another problem with i915 driver.)
I hope that provides the requested information. If necessary I can replace uxa with sna (or blank) using my current kernel 4.8.0-0.rc8.git2.2.fc26.x86_64
> you are able to build from
> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/ ?
I have never done anything like that. I would need detailed instructions, or a pointer to a suitable rpm that I could download and install.
All this is on Dell Latitude E6410 (vintage 2010).
Created attachment 127165 [details]
Composite image with examples of text corrupted
I tried removing
"Option "AccelMethod" "uxa"
and restarting X. I very soon had examples of corrupt text on xclock and gnome
panels. So I created a composite image showing the evidence.
After the "uxa" option had been restored I restarted X, and there has been no
text corruption since then.
(Dell Latitude E6410)
New information: "blt" works even better than "uxa"
As reported in comment 34 in Bug #88584 I had seen a recommendation to use "blt" instead of "sna" or "uxa", so I changed
Identifier "Intel Graphics"
Option "AccelMethod" "blt"
And ran before and after tests using gtkperf. The results showed very significant improvements, as did ordinary use tests (video in firefox, dvb, etc.).
There does not seem to be much online information about the "blt" option even in web pages that explicitly compare "uxa" and "sna" options.
This solves my problem, but the bug that led to the solution remains.
*** This bug has been marked as a duplicate of bug 96970 ***