resizing xterm larger causes corruption onscreen and in terminal when using compiz

Bug #718339 reported by l8gravely
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mesa (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

I'm running Natty Narwhal on x86_64 but using the gnome-session, not Unity, environment. My home directory is NFS mounted from a Debian x86_64 box. My desktop was running 10.10 with the latest updates before I upgraded this desktop using the non-gui method of 'do release-upgrade'.

If I don't re-size the xterm (version: XTerm(268)) everything is ok. I can shrink the xterm and have the new size work ok, but growing the screen area, shows corruption.

System details:

> lsb_release -rd
Description: Ubuntu natty (development branch)
Release: 11.04

> apt-cache policy xterm
xterm:
  Installed: 268-1ubuntu1
  Candidate: 268-1ubuntu1
  Version table:
 *** 268-1ubuntu1 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/main amd64 Packages
        100 /var/lib/dpkg/status

Tags: natty
affects: ubuntu → xterm (Ubuntu)
tags: added: natty
Revision history for this message
Thomas Dickey (dickey-his) wrote : Re: [Bug 718339] [NEW] resizing xterm larger causes corruption onscreen and in terminal

On Sun, 13 Feb 2011, Launchpad Bug Tracker wrote:

> You have been subscribed to a public bug:
>
> I'm running Natty Narwhal on x86_64 but using the gnome-session, not
> Unity, environment. My home directory is NFS mounted from a Debian
> x86_64 box. My desktop was running 10.10 with the latest updates before
> I upgraded this desktop using the non-gui method of 'do release-
> upgrade'.

I tried to investigate this, using today's build of Natty.
However, its installer had a fatal error.

> If I don't re-size the xterm (version: XTerm(268)) everything is ok. I
> can shrink the xterm and have the new size work ok, but growing the
> screen area, shows corruption.

symptom doesn't sound like other bug reports (unless this is yet another
complaint about compiz - report doesn't specify).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote : Re: resizing xterm larger causes corruption onscreen and in terminal

This seems mostly OK for me on both of my machines (one Intel 945GM, and the other is Radeon HD4350 with open drivers).

On the Intel one, there is a small band of pixel droppings around the left and bottom of the window that is a bit odd; but the contents are fine.
(Radeon setup is Kubuntu, Intel is classic Gnome with compiz).

l8gravely: Can you say what graphics hardware you've got, whether you're using compiz or metacity and anything else about the graphics setup you'd think might be interesting.

Dave

Revision history for this message
l8gravely (john-stoffel) wrote : [Bug 718339] Re: resizing xterm larger causes corruption onscreen and in terminal

>>>>> "Dave" == Dave Gilbert <email address hidden> writes:

Dave> This seems mostly OK for me on both of my machines (one Intel
Dave> 945GM, and the other is Radeon HD4350 with open drivers).

My system is running a Radeon X1650 (RV530) fanless. I'm running
compiz as the window manager, I'll drop that and change back to
metacity as a test.

Dave> On the Intel one, there is a small band of pixel droppings
Dave> around the left and bottom of the window that is a bit odd; but
Dave> the contents are fine. (Radeon setup is Kubuntu, Intel is
Dave> classic Gnome with compiz).

If I resize larger, say both right and down, then there is corruption on
the right and left sides.

Dave> l8gravely: Can you say what graphics hardware you've got,
Dave> whether you're using compiz or metacity and anything else about
Dave> the graphics setup you'd think might be interesting.

I'm running the regular radeon kernel driver, not the AMD/ATI Catalyst
one. It's certainly possible that I've got something messed up in my
setup. I'll double check my setup, since at one time I was playing
with the xorg-edgers stuff, but it was so unstable that I dropped out
of it.

  > dpkg-query -l | grep radeon
  ii libdrm-radeon1 2.4.23-1ubuntu Userspace interface to radeon-specific kerne
  ii radeontool 1.6.1-1 utility to control ATI Radeon backlight func
  ii xserver-xorg-v 1:6.13.2+git20 X.Org X server -- AMD/ATI Radeon display dri

Another thing I notice, is that when I do resize an xterm, the popup
telling you how many columns/rows the terminal has doesn't show up any
more.

Do people want me to send any screen shots?

Thanks,
John

Revision history for this message
l8gravely (john-stoffel) wrote : [Bug 718339] Re: resizing xterm larger causes corruption onscreen and in terminal

>>>>> "l8gravely" == l8gravely <email address hidden> writes:

>>>>> "Dave" == Dave Gilbert <email address hidden> writes:
Dave> This seems mostly OK for me on both of my machines (one Intel
Dave> 945GM, and the other is Radeon HD4350 with open drivers).

l8gravely> My system is running a Radeon X1650 (RV530) fanless. I'm
l8gravely> running compiz as the window manager, I'll drop that and
l8gravely> change back to metacity as a test.

Ok, it looks like the problem is some interaction with compiz. Now
that I've switched back to metacity (did: apt-get purge compiz
compiz-gnome) I don't see the corruption that I did before.

But I do see annoying flashes when I resize the xterm.

And another note, when running with the compiz window manager, if I
re-sized the xterm, I would lose the ability to grab the lower right
corner of the window, at least until I resize it using the LEFT and
TOP sides of the window back to the original size. This was because I
re-sized down and to the right using the lower right hand corner grab
area to re-size.

Very strange, but obviously something wrong with either compiz, DRM,
Radeon driver(s), X, etc. So it's probably NOT an xterm bug. But
I'll re-install compiz, re-enable it and see if it happens with other
terminals or windows when I re-size them.

Thanks,
John

Revision history for this message
l8gravely (john-stoffel) wrote :

>>>>> "John" == John Stoffel <email address hidden> writes:

>>>>> "l8gravely" == l8gravely <email address hidden> writes:
>>>>> "Dave" == Dave Gilbert <email address hidden> writes:
Dave> This seems mostly OK for me on both of my machines (one Intel
Dave> 945GM, and the other is Radeon HD4350 with open drivers).

l8gravely> My system is running a Radeon X1650 (RV530) fanless. I'm
l8gravely> running compiz as the window manager, I'll drop that and
l8gravely> change back to metacity as a test.

John> Ok, it looks like the problem is some interaction with compiz. Now
John> that I've switched back to metacity (did: apt-get purge compiz
John> compiz-gnome) I don't see the corruption that I did before.

John> But I do see annoying flashes when I resize the xterm.

John> And another note, when running with the compiz window manager, if I
John> re-sized the xterm, I would lose the ability to grab the lower right
John> corner of the window, at least until I resize it using the LEFT and
John> TOP sides of the window back to the original size. This was because I
John> re-sized down and to the right using the lower right hand corner grab
John> area to re-size.

John> Very strange, but obviously something wrong with either compiz, DRM,
John> Radeon driver(s), X, etc. So it's probably NOT an xterm bug. But
John> I'll re-install compiz, re-enable it and see if it happens with other
John> terminals or windows when I re-size them.

More information. The gnome-terminal does NOT exbhibit this bug. But
uxterm, based on XTerm(268) does show the bug. Hmm... I just
installed a whole bunch and did some simple tests.

   Terminal Emulator Status
   ----------------- --------
   eterm ok
   evilvte bad, can't size down, only up.
   gnome-terminal ok
   guake ok
   konsole ok
   kterm bad
   kxterm ok, wierd
   lxterminal ok
   mlterm ok
   mrxvt ok
   mrxvt-full ok
   rxvt bad
   tilda non-resizeable
   uxterm bad
   wterm bad
   xiterm bad

So I'd almost say it's something with the xterm family, maybe Xlib
based?

Let me know if there's more info you need and I'll do my best to get
it to you. I'm happy to apply patches or updates to the system too.
I'll be pulling daily updates and doing full reboots.

THanks,
John

Bryce Harrington (bryce)
summary: - resizing xterm larger causes corruption onscreen and in terminal
+ resizing xterm larger causes corruption onscreen and in terminal when
+ using compiz
Revision history for this message
Bryce Harrington (bryce) wrote :

Thanks for providing a good bug description.

l8gravely, you should also run 'apport-collect 718339' to attach some logs and config files we like to have for troubleshooting X bugs.

The specificity of this to compiz suggests an issue in mesa or kernel drm, rather than xterm. For now let's treat it as a mesa bug. Might be -radeon specific.

On current natty running -radeon with no compiz, I can confirm that the issue does not occur (tested with xterm running top, mutt, etc. and resizing the window). (I'll test with compiz once I've finished building a new mesa to test.)

Meanwhile, please do attach screenshots (or digital photos if the corruption doesn't show up with a simple screenshot). With corruption bugs we ALWAYS like to have images since often what looks like noise can reveal details to a knowledgeable expert about what the video memory is up to.

Also, there have been several other xterm/corruption bug reports lately (see also bug #713440 and bug #717114). A photo would help prove whether this is a dupe of one of those or not.

Again, please provide a photo and run apport-collect 718339. Thanks!

affects: xterm (Ubuntu) → mesa (Ubuntu)
Changed in mesa (Ubuntu):
status: New → Incomplete
Revision history for this message
l8gravely (john-stoffel) wrote : [Bug 718339] Re: resizing xterm larger causes corruption onscreen and in terminal when using compiz

Bryce> Thanks for providing a good bug description.

You're welcome. I'm try to stay upto date with all the latest Natty
packages and doing full reboots on this desktop to test out any
changes.

Bryce> l8gravely, you should also run 'apport-collect 718339' to attach some
Bryce> logs and config files we like to have for troubleshooting X bugs.

I'll do this when I get home tonight, can't seem to make it or
'apport-cli -u 718339' work from the CLI properly.

Bryce> The specificity of this to compiz suggests an issue in mesa or
Bryce> kernel drm, rather than xterm. For now let's treat it as a
Bryce> mesa bug. Might be -radeon specific.

I suspect so too, esp once I saw it repeating in other terminals.

Bryce> On current natty running -radeon with no compiz, I can confirm
Bryce> that the issue does not occur (tested with xterm running top,
Bryce> mutt, etc. and resizing the window). (I'll test with compiz
Bryce> once I've finished building a new mesa to test.)

Do you find that screen refreshes or window moves are *slower* when
you do this? I was seeing a flash of the entire screen which was
quite annoying. It might be releated to the vsync blanking issues
Dave Airle was chasing down in DRM/MESA/Radeon drivers.

Bryce> Meanwhile, please do attach screenshots (or digital photos if
Bryce> the corruption doesn't show up with a simple screenshot). With
Bryce> corruption bugs we ALWAYS like to have images since often what
Bryce> looks like noise can reveal details to a knowledgeable expert
Bryce> about what the video memory is up to.

Will do, but with the latest updates, the screen isn't getting
corrupted anymore on re-size, but it *is* getting corrupted when I use
an xterm to ssh into another server and run emacs inside a 'screen'
session. The screen fails to update, or blanks lines or characters
randomly. Doing a Ctrl-L to force a refresh fixes it for a second,
but the problem comes back.

I'll send more details tonight when I get a chance.

Bryce> Also, there have been several other xterm/corruption bug
Bryce> reports lately (see also bug #713440 and bug #717114). A photo
Bryce> would help prove whether this is a dupe of one of those or not.

I've gone and looked at these bugs and while they sound similiar, they
don't quite have the same issues that I'm seeing. But I suspect that
since I'm on older Radeon hardware, that it's the same root cause, but
just manifests itself differently.

Bryce> Again, please provide a photo and run apport-collect 718339. Thanks!

Will do tonight! Thanks.

John

Revision history for this message
Bryce Harrington (bryce) wrote :

Hi l8gravely, just checking in, do you still have this corruption with xterm issue?

Changed in mesa (Ubuntu):
status: Incomplete → New
status: New → Incomplete
Revision history for this message
l8gravely (john-stoffel) wrote :

Bryce> Hi l8gravely, just checking in, do you still have this
Bryce> corruption with xterm issue?

Yes, I still have this corruption, along with corruption inside the
Xterm if I don't resize it. I'm generally ssh'ing to another system
and opening up emacs and editing files and reading email using 'vm'.
I see lots of lines not getting re-painted properly when the screen is
re-drawn.

I'll apply the latest updates and try to confirm this issue again.

Thanks,
John

Bryce Harrington (bryce)
Changed in mesa (Ubuntu):
importance: Undecided → Medium
status: Incomplete → Confirmed
Revision history for this message
Bryce Harrington (bryce) wrote :

Fwiw, the lines not re-painting properly might be the same as a recently fixed kernel bug, so that aspect may have gone away now. But that bug didn't display corruption when resizing xterms, and wasn't particular to mesa, so guessing you still have this issue.

Revision history for this message
Bryce Harrington (bryce) wrote :

Alright, when you've gotten the chance to test the latest updates please report back here and we can send it upstream or diagnose further.

Changed in mesa (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
l8gravely (john-stoffel) wrote :

Bryce,

Sorry for the delay in following up on this, but I think you can now
close this bug. With the latest updates as of 3/31/2011, all my
corruption issues with the Xterm seem to be gone now. I can resize it
properly, and I don't see any problems.

Thanks,
John

Changed in mesa (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.