Dear Maintainer,

For quite some time (and therefore a lot of different versions of xorg, kernel,
gnome, iceweasel, etc.) now, when resuming from Suspend, I get some slight
corruption of some characters: some characters of some fonts at some given font
sizes get a horizontal line left transparent (see the small example
screenshot).

When the corruption appear in the fonts of a web page, zooming in and then out
shows that the corrupted characters depend not only on the font but also on the
precise size, and that this is deterministic: reverting to the initial
rendering size yields the same corruption.

I have no real idea who might be the culprit, neither how to track it down.

Best regards
Sam

found 675734 2:2.13.0-2
kthxbye

Hi,

Samuel Hym wrote:

I suffer from this issue, too, on my EeePC 4G 701 for approximately
1.5 to 2 years now. Some suspect it's related to font caching. Others
suspected HW issues (which is why I was reluctant reporting it). You
bug-report shows me that it's likely rather a software than a hardware
issue. Thanks. :-)

I though never noticed that it is related to suspending the laptop as
I do that very often, but reboot only seldom, i.e. I had the issue
nearly always, mostly in the web browsers, but sometimes also in other
applications.

KiBi: This is what I showed you / talked with you about at the BSP in
Paris in 2010.

		Regards, Axel

Hello,

Nice to see that my report is useful ;-)

A small addition / modification of my bug description: after a long series
of zooming in and out randomly, I saw that the corruption is not that
deterministic as I tought. Some characters that were not “initially”
corrupted at some given font size appeared to become corrupted after some
time. And conversely, some previously corrupted might end up being rendered
as hoped.
I thought it might have been that the font cache might be corrupted by the
waking up, but this suggests some corruptions might be produced after
waking up. I don't know how the cache is handled but it seems even trickier
that I thought it would.

Cheers,
Sam

tags 614296 - fixed-upstream
forcemerge 614296 675734
forwarded 614296 https://bugs.freedesktop.org/show_bug.cgi?id=36326
quit


Dear Debian folks,


Am Dienstag, den 24.07.2012, 13:24 +0200 schrieb Paul Menzel:

[…]

[…]

reading up on all the links regarding this report, this is what I found.

First the work around. Using the SNA backend(?) of the Intel DDX
(`xserver-xorg-video-intel`) as suggested by Chris Wilson on #intel-gfx
by creating `/etc/X11/xorg.conf.d/99-local.conf` with the following
content

    Section "Device"
        Identifier "Device0"
        Driver "intel"
        Option "AccelMethod" "sna"
    EndSection

the rendering corruptions do not occur anymore on my Eee PC 701 4G. Only
once I saw some kind of smearing(?) – letters not rendered sharply but
blurry –

Chris Wilson also suggested to try the options

    Option "DebugFlushBatches" "1"

and

    Option "DebugFlushWait" "1"

together and separately with the default backend (non SNA). But I did
not try those. Maybe someone else has some time to do so and capture all
relevant log files as by turning on log level debug logged to
`/var/log/Xorg.0.log` and to provide all information listed at their Web
page »How to file a good bug report« [2].

This would be especially desirable to fix the issue with the old backend
because SNA will not be enabled by default I guess and the current way
is difficult to do for normal users.

Also we need to consider that upstream does not maintain older versions
and the one in Debian Wheezy/testing is already superseded by version
2.20.1 [3] which will not be packaged for Debian Sid/unstable until
after the release and will not be allowed for Debian Wheezy due to the
freeze (I think). Therefore testing newer versions is also difficult.

Now some information regarding other resources concerning this issue.
After reproducing this issue with Fedora I created ticket #704959 at the
Red Hat Bugzilla [5] and Sitsofe Wheeler informed me about the reports
at the freedesktop.org Bugzilla #36326 [4] and at Launchpad #745608 [6].

Although the freedesktop.org Bugzilla ticket #36326 is named

    [915GM] Characters sometimes have horizontal lines through them (glyph font corruption)

some people also report the same problem with 945GM/GMS (and others do
not :/).

Samual and Axel, maybe you can subscribe to the freedesktop.org Bugzilla
ticket #36326. I believe the upstream developers will be the only ones
being able to fix this issue properly.

But first I hope the SNA fix will work for you too and I did not mess
anything up with this merge.


Thanks,

Paul
[2] http://intellinuxgraphics.org/how_to_report_bug.html
[3] http://lists.freedesktop.org/archives/xorg/2012-July/054916.html
[4] https://bugs.freedesktop.org/show_bug.cgi?id=36326
[5] https://bugzilla.redhat.com/show_bug.cgi?id=704959
[6] https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745608

Dear Debian folks,


Am Dienstag, den 24.07.2012, 14:31 +0200 schrieb Paul Menzel:

[…]

Sitsofe pointed out the name of this option is `DebugWait` [7].

    Option "DebugWait" "1"

Encouraged by Sitsofe’s comment [7] I tried just

    Option "DebugWait" "1"

and at least in this session I did not see any corruptions. Could you
please confirm this on your systems too?


Thanks,

Paul
[7] https://bugs.freedesktop.org/show_bug.cgi?id=36326#c50

Hi,

Paul Menzel wrote:
until then black tinted urxvt suddenly was tinted blue. No idea why.

My *rxvt X resource settings:

Rxvt*tintColor:     black
Rxvt*shading:       50
Rxvt*reverseVideo:  True
Rxvt*inheritPixmap: True
Rxvt*fading:        0

No font corruption so far yet, but I wouldn't bet on it yet. Will give
feedback after having it used a few days.

*sigh* I hate Bugzilla.

I subscribed to the Launchpad bug report. That one seems to copy all
messages from the Bugzilla bug report.

		Regards, Axel

Dear Axel,


thank you for your reply. I am putting Samuel back to CC and hope that
it is fine with him to updated about our findings.


Am Mittwoch, den 25.07.2012, 15:12 +0200 schrieb Axel Beckert:

On #intel-gfx Chris Wilson told me that this has been fixed already and
should work in 2.20.1. Although he did not tell me what commit since
there have been more than hundreds of them in between.

Maybe also try enabling the `DebugWait` option. This worked for me so
far and is using the „old“ UXA backend. Although Chris Wilson noted that
x11perf might suffer when using this option.

Talking to Julian Cristau, one of the release managers, he told me that
he does not consider this bug release critical and that if no fix is
found Debian Wheezy will be released with this bug.

Chris Wilson also noted that he tried to figure out the cause of this
error for quite some time and did not find the reason for it.

But let us hope for the best and be optimistic.

Me too. I am still wondering if everyone uses the Web interface or if
there are also some command line tools making it more bearable.


Thanks,

Paul


PS: Axel, one unrelated question, what way did you use to reply to
Samuel’s original report. `bts show --mbox 675734`, using the provided
links to the mbox file on the bug report Web page with your browser or
some other magic I do not know about?

Hi,

Paul Menzel wrote:

JFTR: I experienced this bug definitely on my EeePC 701 4G with kernel
3.4 (currently 3.4.4-1~experimental.1) from the moment it hit Debian
Experimental until I switched to sna, i.e. for months.

Using sna had strange side-effects like wrong tint colors in urxvt:
blue, cyan and 100% transparency instead of 50%, i.e. clear instead of
shaded. After X start I always had blue, after adding another screen
via xrandr, I got 100% transparency, after removing that screen again,
I had cyan.

So far I haven't noticed any font corruption since the switch to sna,
also not after suspend to RAM (which was suspected somewhere else to
trigger the corruption).

		Regards, Axel

Hi,

JFTR, as Sitsofe Wheeler writes on the Freedesktop Bugzilla[1], this
issue is still present when running under the 3.5 kernel from Debian
Experimental (without having SNA enabled). It though seems to happen
more seldom than with earlier kernels.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=36326#c54

		Regards, Axel

Hi,

I ran into this bug on a fresh install of Debian 8 (Jessie) RC2 on an
EeePC 701 4G with Intel i915GM graphics. Linux kernel 3.16, X.Org
1.16.4, X.Org intel module 2.21.15.

Using acceleration method SNA instead of UXA, as suggested before,
seems to still solve it:

# cat /etc/X11/xorg.conf
Section "Device"
        Identifier "Intel Graphics"
        Driver "intel"
        Option "AccelMethod" "sna"
EndSection

(Said to also give better performance. [1] [2])

Upstream seems to have marked this bug as fixed, not because it was
fixed in UXA, but because they changed the default acceleration method
from UXA to SNA since 2.99.901 [3], and the bug does not show up under
SNA [4]. However, for Debian that change is still in experimental [5]:

It seems Jessie will ship with version 2.21.15, using UXA as default.

Considering that this issue was never really fixed in UXA in the four
years that it was open upstream, and that a change to SNA is unlikely
to be allowed into an (upcoming) stable release, I guess this bug will
probably remain unresolved for Jessie... Right?

Regards,
Peter

[1] http://cynic.cc/blog/posts/sna_acceleration_vs_uxa/
[2] https://wiki.debian.org/DebianEeePC/HowTo/Configure
[3] http://www.phoronix.com/scan.php?page=news_item&px=MTQ1MzU
[4] https://bugs.freedesktop.org/show_bug.cgi?id=36326#c98
[5] http://metadata.ftp-master.debian.org/changelogs//main/x/xserver-xorg-video-intel/experimental_changelog