Garbled chars in xterm

[Loïc Minier]

Binary package hint: xserver-xorg-video-intel

Hi

Since the move from compiz 0.8.4 to 0.8.6, end pf July, I've had corrupted chars in xterm as in the attached picture: some vertical bars clutter the chars.

I checked with the compiz folks who told me this was triggered by a compiz change, but was a xorg bug in my video card's driver (intel).

During Debconf I mentioned the bug to keithp who told me that this was a known issue with a couple of patches in xorg-server 1.9.0 fixing it. We were still in 1.8.x in Ubuntu.

Now we're at 1.9.x+ and I still get the issue; I think it wasn't the one keithp thought of back then.

If I drag the window around, the content gets fixed.

GNOME Terminal doesn't show the issue.

Cheers,

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: xserver-xorg-video-intel 2:2.12.0-1ubuntu3
ProcVersionSignature: Ubuntu 2.6.35-20.29-generic 2.6.35.4
Uname: Linux 2.6.35-20-generic x86_64
Architecture: amd64
DRM.card0.DisplayPort.1:
 status: disconnected
 enabled: disabled
 dpms: On
 modes:
 edid-base64:
DRM.card0.DisplayPort.2:
 status: disconnected
 enabled: disabled
 dpms: On
 modes:
 edid-base64:
DRM.card0.HDMI_Type_A.1:
 status: disconnected
 enabled: disabled
 dpms: On
 modes:
 edid-base64:
DRM.card0.LVDS.1:
 status: connected
 enabled: enabled
 dpms: On
 modes: 1440x900
 edid-base64: AP///////wAwrnRAAAAAAAsTAQOAHRJ46tCjlltXlCYjUlkAAAABAQEBAQEBAQEBAQEBAQEB2CegjFGEGjAwIDYAH7QQAAAYNCGgjFGEGjAwIDYAH7QQAAAYAAAADwCVCjKVCigeAQAwZABVAAAA/gBMVEQxMzNFUTFCCiAgAIc=
DRM.card0.VGA.1:
 status: disconnected
 enabled: disabled
 dpms: On
 modes:
 edid-base64:
Date: Fri Sep 10 21:28:28 2010
MachineType: LENOVO 2777CTO
ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.35-20-generic root=/dev/mapper/hostname--vg0-ubuntu--root ro quiet splash
ProcEnviron:
 LANGUAGE=fr_FR:fr:en_GB:en
 PATH=(custom, user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/zsh
SourcePackage: xserver-xorg-video-intel
dmi.bios.date: 03/12/2009
dmi.bios.vendor: LENOVO
dmi.bios.version: 6EET27WW (1.08 )
dmi.board.name: 2777CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6EET27WW(1.08):bd03/12/2009:svnLENOVO:pn2777CTO:pvrThinkPadX301:rvnLENOVO:rn2777CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 2777CTO
dmi.product.version: ThinkPad X301
dmi.sys.vendor: LENOVO
system:
 distro: Ubuntu
 codename: maverick
 architecture: x86_64
 kernel: 2.6.35-20-generic

[Loïc Minier (lool)]

Note that the number of bars increases as I type chars towards the right. This seems relative to the window position, wherever it is on the screen.

[Stephane Epardaud (stef-inforealm)]

The same bug is filed against xterm: https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/644943. Note that I have the same issue with nvidia, so this either isn't an intel driver bug, or it exists in both drivers…

[Didier Roche (didrocks)]

from the other bug report:
- it seems to happen only with compiz (just to confirm, despite Loic talked to compiz upstream)
- it seems however to appears on both nvidia and intel. So not related to intel only

[Didier Roche (didrocks)]

redirecting to xserver-xorg right now, as it's not related to intel or nvidia hardware (can reliably reproduce it there). Will try to ping compiz guy again.

[Charles Cox (chuck-chezcox)]

I'm getting the same behavior since upgrading from 10.04 to 10.10. This is on an HP laptop with Intel graphics.

[robertjlee (ubuntubrainstorm)]

I get the same problem with emacs, so it looks like this affects any application using bitmap fonts.
From the look of it, single characters are more affected than large areas (even on normal repaints where nothing has changed, eg switching desktops), so my guess would be that something isn't properly clearing bitmaps at their edges before copying them.
Using Maverick + compiz + gnome. Worked fine in 10.04

[Paul Donohue (s-launchpad-paulsd-com)]

I've got the same problem since upgrading to Maverick. wmbattery also has similar corruption. Happens for me using intel, radeon, or fglrx drivers with compiz/emerald. Does not happen if I switch to enlightenment. I've only tried 64-bit Ubuntu, so it may be a 64-bit issue.

I believe this is the same problem as well:
https://bugzilla.redhat.com/show_bug.cgi?id=614542

[Paul Donohue (s-launchpad-paulsd-com)]

The bug appears to have been introduced by:
http://git.compiz.org/compiz/core/commit/?h=compiz-0.8&id=6d4833f0e3217c63f516acbdc90796b4d78eecfb

The bug is fixed either by reverting that commit or changing the added lines to:
w->width = attr.width + (attr.border_width * 2);
w->height = attr.height + (attr.border_width * 2);

I'm currently unable to get to http://bugs.opencompositing.org/ so I have not filed an upstream bug report.

[Paul Donohue (s-launchpad-paulsd-com)]

Patch has been committed upstream:
http://git.compiz.org/compiz/core/commit/?h=compiz-0.8&id=0f95c41a0aa175ddf7947ba18b01f746c95594a9

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz - 1:0.8.6-0ubuntu10

---------------
compiz (1:0.8.6-0ubuntu10) natty; urgency=low

  * New patch, 635258-fix-pixmap-size-calculations, from commit
    0f95c41a0aa175ddf7947ba18b01f746c95594a9 in the 0.8 branch; thanks
    Paul Donohue; LP: #635258.
 -- Loic Minier <email address hidden> Sun, 17 Oct 2010 22:02:58 +0200

[Paul Smith (psmith-gnu)]

I'm not sure what it means that this bug is marked "fixed released"... it seems to have been fixed on Oct 17 but it's not Oct 21 and there's still no package available (for Maverick) containing this fix. I do have all my Ubuntu repos enabled including proposed.

What's the relationship between a bug being marked as "fixed released" and a package showing up available for download? Is there some kind of extra state that is set or comment added to launchpad when the package is available?

This bug is just killing me; the borderWidth change discussed in the Red Hat bug doesn't work reliably, and having to resize each of my windows when I create them (esp. given the other long-standing Ubuntu bug about resize handles being impossibly thin) is very frustrating; I use xterm exactly because my workflow tends to create/destroy a LOT of terminal windows, all the time.

Thanks for the quick work on this and I can't wait to get access to the fix!

[Steve Newcomb (srn-coolheads)]

Curiously, I have the "cursor droppings" on xterm screens -- the little vertical bars before each typed character -- but this NEVER happens in emacs 22 or emacs 23.

FYI, I launch xterm with a red blinking cursor as follows; the little vertical lines are red, so it's obvious that it has to do with the cursor.

xterm -cr red -ah -bc -si -sl 10000 -sb -l -fn 7x13

A pretty good display of the problem can be seen at:

http://ubuntuforums.org/showthread.php?t=1597277

[Loïc Minier (lool)]

It's Fix Released because it was fixed in the development version of Ubuntu (natty, which you may now recognize in the changelog message copied to this bug).

I've just approved the bug for a maverick update now, and also pushed an upload to maverick; would you test it when it's published in -proposed? This bug will receive a notification when that happens

[Kalle Valo (kvalo)]

I just installed compiz 1:0.8.6-0ubuntu12 from natty to my maverick laptop and I can confirm that the problem in xterm is now fixed.

Thank you for fixing this.

[Martin Pitt (pitti)]

Accepted compiz into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Marc Gariépy (mgariepy)]

I just tested by updating compiz package from maverick-proposed and it work.

Thanks for fixing this :)

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz - 1:0.8.6-0ubuntu9.1

---------------
compiz (1:0.8.6-0ubuntu9.1) maverick-proposed; urgency=low

  * New patch, 635258-fix-pixmap-size-calculations, from commit
    0f95c41a0aa175ddf7947ba18b01f746c95594a9 in the 0.8 branch; thanks
    Paul Donohue; LP: #635258.
 -- Loic Minier <email address hidden> Sun, 17 Oct 2010 22:02:58 +0200

[Albert Chin (bugs-ubuntu-vendor)]

Any plans to backport 0.8.6-0ubuntu9.1 to Lucid?

[Gennady N. Uraltsev (gennady-uraltsev)]

This patch does not fix the emacs problem! Emacs (emacs23-snapshot and emacs23) still has a garbled screen. I am on an Intel Corporation Mobile 945GM video card.

[John Clemens (clemej)]

Its baaack in Onieric Beta 1, intel 4500, unity 3d. To reproduce, just open xterm and start typing.... what you type will be garbles, but the output will be fine. Similar corruption to before, with a white box covering the first part of any letter typed, and scrolling leaving a few pixels of the fonts on the left side of the terminal window. Now to figure out how to re-open this bug against Onieric...

Also, since this has now come back at least twice, and xterm has uncovered other previously unknown bugs (like nouveau w/ 3d support crashing Xorg with fixed width fonts) can we get the ubuntu QA team to add 'xterm' to a test case somewhere? xterm is a basic application, and problems like this with it often indicate real issues that other applications will eventually hit. Just run it, make sure you can type into the window, and that all the fonts look right on both the input and output text, and that it's white text on a black background. Its a simple 30 second test, and will catch issues like this.

[Loïc Minier (lool)]

See bug #841103 for the re-occurrence.