Bug 495151 - xterm scrolling is broken
xterm scrolling is broken
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-04-09 18:31 EDT by David Howells
Modified: 2009-04-17 02:01 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-17 02:01:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
X server log (33.82 KB, text/plain)
2009-04-09 18:31 EDT, David Howells
no flags Details
Kernel log (36.43 KB, text/plain)
2009-04-09 18:32 EDT, David Howells
no flags Details
Picture of broken xterm (8.36 KB, image/png)
2009-04-09 18:39 EDT, David Howells
no flags Details
X server log (nomodeset) (44.04 KB, text/plain)
2009-04-10 08:58 EDT, David Howells
no flags Details

  None (edit)
Description David Howells 2009-04-09 18:31:20 EDT
Created attachment 339011 [details]
X server log

Description of problem:

Scrolling in xterms under the rawhide X server using kernel mode setting is broken.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Start xterm.
2. Run "ls /usr/bin" in it.  Note the position of the new command prompt in the window.
3. Scroll the window using S-PgUp and S-PgDown.
Actual results:

In 2, I see the ls generate more lines than the xterm can hold, but the prompt the shell generates after the ls doesn't wind up on the last line of the window, but rather several lines up.  Several blank lines follow it.

In 3, scrolling about causes the chunks of data in the scroll buffer to go missing and be represented on the screen by blank space.  Sometimes individual characters of text will be partially obscured.

Expected results:

In 2, the bash prompt after the ls should be on the bottom line of the window.

In 3, the data in the scroll buffer should be displayed correctly, no matter how much scrolling is done.

Additional info:

This does not happen if nomodeset is provided to the kernel.

I have a Radeon X300 based chipset in my laptop, and I currently have no Xorg.conf file.  I'm attaching the X server log and the dmesg log.
Comment 1 David Howells 2009-04-09 18:32:13 EDT
Created attachment 339013 [details]
Kernel log
Comment 2 David Howells 2009-04-09 18:39:14 EDT
Created attachment 339017 [details]
Picture of broken xterm
Comment 3 Miroslav Lichvar 2009-04-10 04:16:26 EDT
This is most likely a video driver problem.
Comment 4 François Cami 2009-04-10 05:42:52 EDT

Could you also add Xorg.0.log from the nomodeset attempt ?

Thanks in advance

Fedora Bugzappers volunteer triage team
Comment 5 David Howells 2009-04-10 08:58:58 EDT
Created attachment 339088 [details]
X server log (nomodeset)
Comment 6 Bruno Wolff III 2009-04-10 11:38:49 EDT
I don't know if this is the same issue or not, but with xorg-x11-drv-ati-6.12.1-9.fc11.x86_64 I am seeing improper scrolling in xterm as well. This is with the fvwm desktop, modesetting and an rv530. (I don't see this on another machine which is not using modesetting, is using gnome for a desktop and is an rv280.)
When text scolls part of lines are not redrawn, so that only partial lines are visible. Switching to another desktop space and back results in the text being correctly redrawn.
The behavior started recently, but because there were 2 or 3 releases in short succession, I didn't notice the issue until I was on -9. If you need to know which version it originated in I can do some further testing.
Comment 7 Bruno Wolff III 2009-04-10 13:35:49 EDT
xorg-x11-drv-ati-6.12.1-10.fc11.x86_64 still shows the problem with the xterm used in fvwm. It seems with today's updates I can use gnome again and I am not seeing the problem in the terminal program I run there.
Comment 8 Bruno Wolff III 2009-04-16 16:25:40 EDT
I tried this again with today's rawhide plus the following from koji:
mesa-7.5-0.11.fc11.x86_64 (and i586)
and am not seeing the behavior any more.
Comment 9 David Howells 2009-04-16 18:27:29 EDT
That works for me, thanks!

Note You need to log in before you can comment on or make changes to this bug.