Bugzilla has been recently updated. As such, some functions and behaviors may have changed. Please review the Release Notes for more information.
Bug 681359 - xterm: no data shown under the screen program
xterm: no data shown under the screen program
Status: RESOLVED INVALID
Classification: openSUSE
Product: openSUSE 11.4
Classification: openSUSE
Component: KDE4 Workspace
Final
x86-64 Other
: P5 - None : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
https://bugs.kde.org/show_bug.cgi?id=...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-21 17:56 UTC by Rich Coe
Modified: 2011-08-15 20:41 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Coe 2011-03-21 17:56:56 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12) Gecko/20110222 Firefox/4.0b12

opensuse 11.4
I'm running screen under an xterm.  When I'm scrolling through a file with
less or vi, sometimes many lines don't paint.  At first I thought this may
be a problem with screen, but when I moved the mouse out of the window and the 
window lost focus, the window repainted with the correct data.  I have 'focus
follows under mouse' configured.

I've also gotten it happen by running a command on the command line,
rpm -q --info screen, several times in a row.

I just upgraded opensuse from 11.3 to 11.4.
I'm using kde-4.6.0.
Xserver is xorg-x11-server-7.6_1.9.3-15.18.4.x86_64
My display card is 'Broadway XT [Mobility Radeon HD 5800 Series]'.

It also happened in this details text window while scrolling with the mouse.

Reproducible: Always

Steps to Reproduce:
scroll text with less or vi in a xterm running screen
Actual Results:  
Some lines of text are missing

Expected Results:  
All lines of text shall be displayed
Comment 1 Rich Coe 2011-03-22 02:43:06 UTC
I can make this happen in xterm without screen running with
vi and long lines.
Comment 2 Thomas Dickey 2011-04-20 08:20:50 UTC
Is that "xterm", or some other terminal?
If xterm, what does "xterm -v" say?
Comment 3 Rich Coe 2011-04-21 22:59:21 UTC
Xorg 5.8.99.903 268

Xterm-268-1.2.1
Comment 4 Thomas Dickey 2011-04-21 23:39:11 UTC
So xterm is not getting the exposure events.

I've seen several reports describing problems due to compiz
over the past year.  Are you using compiz?

Other than that, I've not seen any recent reports dealing
with painting/repainting.  Which window-manager (or desktop)
are you using?  (I have a VM with OpenSUSE 11.3 which I might
use to see if I can reproduce this).
Comment 5 Rich Coe 2011-04-22 01:53:41 UTC
I did not install or configure compiz, so I shouldn't be running it.
I first saw this after installing 11.4. I did not have this issue on 11.3.
I use kde desktop.
Comment 6 Marcus Meissner 2011-05-27 09:29:13 UTC
do you have KDE desktop effects enabled?

can yozu try disabling them and to reproduce?
Comment 7 Rich Coe 2011-05-27 13:00:57 UTC
I found that cntrl-f8 shows the desktop when desktop effects are enabled.
I also found that alt-shift-f12 will toggle desktop effects on/off.

Yes, desktop effects are enabled.
After disabling desktop effects, the problem with xterm updating went away!

Unfortunately, re-enabling desktop effects did not make the problem return,
at least in my limited testing.
Comment 8 Rich Coe 2011-07-14 15:58:24 UTC
I've been very happy running with KDE desktop effect disabled.
Comment 9 Marcus Meissner 2011-07-18 12:03:15 UTC
so its not really a xterm problem, but a kde desktop effects issue.

can you report it upstream with them perhaps?
Comment 10 Rich Coe 2011-07-22 19:41:48 UTC
KDE just released kde-4.6.5
I'm going to install it from 
http://download.opensuse.org/repositories/KDE:/Release:/46/openSUSE_11.4 
and verify it still happens.
Comment 11 Rich Coe 2011-08-15 20:41:35 UTC
I can still recreate this after installing
http://download.opensuse.org/repositories/KDE:/Release:/47/openSUSE_11.4

I created https://bugs.kde.org/show_bug.cgi?id=280156
to track this issue.