Bug 49786 - In xterm, some rectangles are not redrawn when the window is partly covered
Summary: In xterm, some rectangles are not redrawn when the window is partly covered
Status: NEEDINFO
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: 7.6 (2010.12)
Hardware: Other All
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-11 03:25 UTC by Vincent Lefevre
Modified: 2016-01-12 15:23 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
file "text" used in the command to reproduce the bug (9.31 KB, application/octet-stream)
2012-05-11 03:25 UTC, Vincent Lefevre
no flags Details
snapshot showing the corrupt display (see the top part of the window) (13.74 KB, image/png)
2012-05-11 03:27 UTC, Vincent Lefevre
no flags Details
snapshot showing the correct contents after a full redraw (14.71 KB, image/png)
2012-05-11 03:28 UTC, Vincent Lefevre
no flags Details
dmesg output - DELL Latitude E6400 (2013-08-21) (67.40 KB, text/plain)
2013-08-21 09:59 UTC, Vincent Lefevre
no flags Details
Xorg.0.log - DELL Latitude E6400 (2013-08-21) (51.01 KB, text/plain)
2013-08-21 10:00 UTC, Vincent Lefevre
no flags Details
Shell script to reproduce the bug (needs xterm and base64) (12.78 KB, text/plain)
2013-08-21 10:01 UTC, Vincent Lefevre
no flags Details
Shell script to reproduce the bug (needs xterm and base64) (12.83 KB, text/plain)
2013-08-21 10:23 UTC, Vincent Lefevre
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Lefevre 2012-05-11 03:25:56 UTC
Created attachment 61438 [details]
file "text" used in the command to reproduce the bug

When an xterm window is partly covered by another window, not everything is redrawn. The problem can be reproduced in the following way (this is tested on a Debian/unstable machine). Run the following command:

$ xterm -geometry 80x60 -e 'sleep 10; cat text; sleep 999'

(with the file "text" that will be attached), then put a smaller window covering the middle of the right part, and wait for the text (after "sleep 10" terminates).

I'll also attach 2 snapshots showing the problem: the first one being what I obtain after the above steps (corrupt output), the second one being what I obtain after a full redraw (the correct output), e.g. when switching the desktop and going back (one can also move a window over the xterm window).

The corresponding Debian bug report:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640464
Comment 1 Vincent Lefevre 2012-05-11 03:27:17 UTC
Created attachment 61439 [details]
snapshot showing the corrupt display (see the top part of the window)
Comment 2 Vincent Lefevre 2012-05-11 03:28:10 UTC
Created attachment 61440 [details]
snapshot showing the correct contents after a full redraw
Comment 3 Vincent Lefevre 2012-05-11 03:34:16 UTC
If I disable acceleration with an xorg.conf file containing

Section "Device"
        Identifier      "Device0"
        Driver          "nouveau"
        Option          "NoAccel" "true"
EndSection

this display problem doesn't occur.
Comment 4 Ilia Mirkin 2013-08-21 06:29:57 UTC
Can you confirm that this happens with the latest DDX (1.0.9)? If so, we'll need a bit more information -- please attach both a dmesg + Xorg.0.log for your system. (Even if there are no errors, they contain information that describes your system.)
Comment 5 Vincent Lefevre 2013-08-21 09:59:24 UTC
Created attachment 84379 [details]
dmesg output - DELL Latitude E6400 (2013-08-21)
Comment 6 Vincent Lefevre 2013-08-21 10:00:06 UTC
Created attachment 84380 [details]
Xorg.0.log - DELL Latitude E6400 (2013-08-21)
Comment 7 Vincent Lefevre 2013-08-21 10:01:46 UTC
Created attachment 84381 [details]
Shell script to reproduce the bug (needs xterm and base64)
Comment 8 Vincent Lefevre 2013-08-21 10:23:03 UTC
Created attachment 84383 [details]
Shell script to reproduce the bug (needs xterm and base64)
Comment 9 Vincent Lefevre 2013-08-21 10:27:54 UTC
(In reply to comment #4)
> Can you confirm that this happens with the latest DDX (1.0.9)? If so, we'll
> need a bit more information -- please attach both a dmesg + Xorg.0.log for
> your system. (Even if there are no errors, they contain information that
> describes your system.)

The problem still occurs. I don't know what is the DDX, but Xorg.0.log says:

[    47.996] (II) Module nouveau: vendor="X.Org Foundation"
[    47.996]    compiled for 1.12.4, module version = 1.0.9
[    47.996]    Module class: X.Org Video Driver
[    47.996]    ABI class: X.Org Video Driver, version 12.1

I've attached both dmesg output and the Xorg.0.log file after rebooting the machine and testing.

I've also attached a new shell script to test: it automatically opens the xterm windows at the right place (bitmap fonts may need to be enabled, otherwise I don't know if the bug still occurs). It needs the base64 utility (from the coreutils) to output the data to the first xterm window. Just wait for a few seconds for the second xterm then the text to appear.
Comment 10 Vincent Lefevre 2013-08-21 10:59:49 UTC
Some other thing: the dmesg and Xorg.0.log I've attached correspond to the DELL Latitude E6400. The bug also occurs on a different machine (not with me here); I'll try to attach information in the next few days.
Comment 11 Ilia Mirkin 2013-08-21 14:25:22 UTC
Great repro script! Bug confirmed on my NV96, and disconfirmed on NV18. I see that your card is a NV98, so this is probably a bug in the nv50 exa logic.
Comment 12 Vincent Lefevre 2013-08-21 15:05:41 UTC
FYI, the other machine where the bug occurs also has a NV98 chipset. The exact card is the following:

  NVIDIA Corporation G98 [Quadro NVS 295] (rev a1)

according to lspci. The one on the DELL Latitude is:

  NVIDIA Corporation G98M [Quadro NVS 160M] (rev a1)
Comment 13 Ilia Mirkin 2013-08-21 15:36:11 UTC
And as I suspected, if you run a compositor, the issue goes away (e.g. with xcompmgr).
Comment 14 Ilia Mirkin 2013-08-31 17:43:29 UTC
Also tested on NV42, doesn't happen there either. Further points to something in the nv50 exa rather than something generic...
Comment 15 Tobias Klausmann 2015-01-17 00:58:14 UTC
still a problem with recent xf86-video-nouveau? Imirkin, maybe you could test this and just provide a status update
Comment 16 Ilia Mirkin 2015-01-17 01:04:27 UTC
(In reply to Tobias Klausmann from comment #15)
> still a problem with recent xf86-video-nouveau? Imirkin, maybe you could
> test this and just provide a status update

Nothing has been changed relevant to this, so I don't see why it wouldn't be.
Comment 17 Vincent Lefevre 2015-01-18 00:24:57 UTC
(In reply to Tobias Klausmann from comment #15)
> still a problem with recent xf86-video-nouveau?

This still occurs in Debian/unstable (xserver-xorg-video-nouveau 1:1.0.11-1).
Comment 18 Vincent Lefevre 2015-01-18 00:37:11 UTC
(In reply to Vincent Lefevre from comment #17)
> This still occurs in Debian/unstable (xserver-xorg-video-nouveau 1:1.0.11-1).

But in November 2013, I noticed that this bug did not occur every time (after killing the compositor):

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640464#150
Comment 19 Vincent Lefevre 2016-01-12 15:23:25 UTC
The bug still occurs with the xserver-xorg-video-nouveau 1:1.0.12-1 Debian package and the NVD9 chipset. The video card is:

NVIDIA Corporation GF119 [NVS 315] (rev a1)


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.