[i855] Strange rendering of some letters with driver version >2.4.x

Hi glasen,

Thanks for including an image to demonstrate the issue. Could you also please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

Please attach the output of `lspci -vvnn` too.

[This is an automated message. If this script has reached you erroneously, please accept our apologies; any reply to this message will be sufficient to prevent it from doing further automated processing.]

The bug is very easy for me to reproduce :

I've to install a driver version above 2.3.x (e.g. 2.5.1 from the intel-gfx-testing PPA or self compiled vanilla version from freedesktop.org). I don't have an "xorg.conf"-file under "/etc/X11". Everything is activated automatically (EXA, DRI, etc.). The bug only occurs when i'm using "EXA" as render method. With "XAA" activated everything is okay.

The bug is not Ubuntu-specific. I've tested Fedora 10 (also driver version 2.5.1) and it has the same problem.

I can confirm this also for me; it's more than a month I'm affected by this and it's very annoying.
Also, some other widgets are anti-aliased in a strange way; for example some web pages are rendered badly, or some widget borders flicker.

More irritatingly, these artifacts change when you type, so your attention gets easily carried away. It does stress your sight.

00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 01)
 Subsystem: IBM Device [1014:0543]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
 Latency: 0
 Interrupt: pin A routed to IRQ 11
 Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M]
 Region 1: Memory at d0000000 (32-bit, non-prefetchable) [size=512K]
 Region 2: I/O ports at 1800 [size=8]
 Capabilities: <access denied>
 Kernel modules: intelfb

00:02.1 Display controller [0380]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 01)
 Subsystem: IBM Device [1014:0543]
 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Region 0: Memory at e8000000 (32-bit, prefetchable) [size=128M]
 Region 1: Memory at d0080000 (32-bit, non-prefetchable) [size=512K]
 Capabilities: <access denied>

Sorry,

I've made a mistake. Only driver versions 2.5.x and higher are affected from this bug. Version 2.4.x works fine. Can someone please change the title of this bug from "driver version >2.3.x" to "driver version >2.4.x".

glasen

Hi,

A week ago i have upgraded my ubuntu-installation to Jaunty. After the upgrade I've made two interesting discoveries :

The new Xserver only works if i disable DRI or switch to UXA (Bug #304871).

Now, when i'm disabling DRI, the bug does not occur again (EXA is used). When i'm activating UXA, the bug reoccurs.

Two days ago i compiled libdrm 2.4.5 and intel-driver 2.6.2 under Jaunty and this bug is now gone. The font rendering is normal with EXA and UXA.

I confirm that libdrm 2.4.5 and intel-drive 2.6.2 fixed the problem for me. It sounds like these packages should be upgraded.

Setting status to fix committed. It's fixed upstream based on last comments.

I hope that 2.6.2 driver (or 2.6.3 already released) could fix also my bug #330416 that looks similar to this one.

Hi,

I played i a little with the source of version 2.6.1 and some of the patches in the git-tree of the driver. When i apply the following git-commits, the strange rendering vanishes :

704177b5dd0ab7a5f5bef937eac53d725bc509b5 -> Remove logical context setup

and

12b581bb9e6dd77092cd7561b595fe37c948d894 -> Fix compile failure after 45f45c73469f1bd46a1b6fb206f2e9e5e4fd66b3

The first commit seems to correct the problem, the second commit is needed that the source-code compiles cleanly.

I've confirmed the 2.6.3 driver has this patch included, so the problem should no longer exist. Reopen with further details if that is incorrect.