Garbled chars in xterm

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.

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…

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

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.

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

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

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

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.

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

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

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!

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

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

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.

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!

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

Thanks for fixing this :)

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

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

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.

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.

See bug #841103 for the re-occurrence.