Bug 80456 - Using cursor keys in textboxes results in 'pixel smearing' with opensource "nv" driver
Summary: Using cursor keys in textboxes results in 'pixel smearing' with opensource "n...
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: XFree86
Version: phoebe
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
Blocks: 82784
TreeView+ depends on / blocked
Reported: 2002-12-26 19:51 UTC by Peter van Egdom
Modified: 2007-04-18 16:49 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-02-20 05:10:05 UTC

Attachments (Terms of Use)
Screenshot showing the problem (115.22 KB, image/png)
2002-12-26 19:52 UTC, Peter van Egdom
no flags Details
My XFree86 log file (33.95 KB, text/plain)
2003-01-01 10:37 UTC, Peter van Egdom
no flags Details
XFree86 logfile of vesa driver on GeForce 4 card (49.00 KB, text/plain)
2003-01-01 14:12 UTC, Peter van Egdom
no flags Details
XFree86 logfile of nvidia driver on GeForce 4 card (33.95 KB, text/plain)
2003-01-04 10:00 UTC, Peter van Egdom
no flags Details
XFree86 4 configuration file of Nvidia GeForce 4 (3.25 KB, text/plain)
2003-01-04 10:03 UTC, Peter van Egdom
no flags Details
XF86 config file which has no problems with Evolution (4.11 KB, text/plain)
2003-01-10 00:03 UTC, Peter van Egdom
no flags Details
XF86 Config file with the noaccel option (3.28 KB, text/plain)
2003-01-10 00:04 UTC, Peter van Egdom
no flags Details
XF86 config file with problems in Mozilla and Evolution (3.25 KB, text/plain)
2003-01-10 00:05 UTC, Peter van Egdom
no flags Details
XF86 logfile without probs in Evolution (34.03 KB, text/plain)
2003-01-10 00:06 UTC, Peter van Egdom
no flags Details
XF86 log file with noaccel option (33.52 KB, text/plain)
2003-01-10 00:07 UTC, Peter van Egdom
no flags Details
XF86 log file with probs in both Mozilla and Evolution (33.95 KB, text/plain)
2003-01-10 00:08 UTC, Peter van Egdom
no flags Details

Description Peter van Egdom 2002-12-26 19:51:52 UTC
From Bugzilla Helper:

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021218

Description of problem:

When using Mozilla like in this example and using the arrow keys in textboxes 
a lot of 'residu' leaves behind.

This only seems to be the case in Mozilla.

When minimizing / maximizing the window all seems fine again.

See attached screenshot for an example.

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

How reproducible:

Steps to Reproduce:
1. Use the cursor keys in Mozilla when inside a text box.

Actual Results:  screen smearing / residu.

Expected Results:  no pixel mess.

Additional info:

Red Hat Linux release 8.0.92 (Phoebe)

Comment 1 Peter van Egdom 2002-12-26 19:52:45 UTC
Created attachment 88920 [details]
Screenshot showing the problem

Comment 2 Bill Nottingham 2003-01-01 03:48:07 UTC
What X driver are you using? That looks like it could be an X driver or Xft issue...

Comment 3 Peter van Egdom 2003-01-01 10:35:50 UTC
I'm using a GeForce 4 Ti4600 in 1024*768*24 bit color mode.

My setup of Phoebe is still a out-of-the-box one.

I'll attach my "XFree86.0.log" to this Bugzilla.

I'll experiment with using different drivers / screenresolution combinations to
check if this also
occurs in those configurations and report about the results.

I had not this problem with Red Hat 8.0 using the NVidia drivers from the NVidia
site. Maybe if time permits I'll try those NVidia drivers too, but for me that
is tricky because of the installation steps involved (They 'hardcode' their
drivers for a specific version of Red Hat Linux and 8.1 beta 1 is probably not
supported yet).

Comment 4 Peter van Egdom 2003-01-01 10:37:27 UTC
Created attachment 89026 [details]
My XFree86 log file

Comment 5 Peter van Egdom 2003-01-01 14:04:56 UTC
I have tried a couple of things :

First I tried different combinations off resolutions & color depth with the
nvidia driver; that did not help. There was still the 'pixel-smearing' to be
seen inside Mozilla text entry boxes.

I then tried the 'vesa' driver (using redhat-config-xfree86) with 1024*768*24
bit. Boy, what a difference that was!

The first thing I noticed was the mouse cursor. 

With the 'nvidia' driver the color of the mouse cursor was transparant and
somewhere between light grey and dark grey.

With the 'vesa' driver the color of the mouse cursor was white (as it should be
- I guess) and the 'pixel-smearing' inside Mozilla text entry boxes completely

This is obviously a nvidia driver issue.

I'll attach my XFree86 log file of the nvidia driver to this Bugzilla.

Comment 6 Peter van Egdom 2003-01-01 14:10:59 UTC
Source RPM: XFree86-

Comment 7 Peter van Egdom 2003-01-01 14:12:29 UTC
Created attachment 89027 [details]
XFree86 logfile of vesa driver on GeForce 4 card

Comment 8 Mike A. Harris 2003-01-02 15:55:23 UTC
You mention above that the "vesa" driver works ok, and have attached the
log file from the working vesa driver.  Could you attach the log file
and config file from the non-working driver instead?

Also please read bug #73733 concerning the Nvidia proprietary driver.

If you're using the "nv" driver, perhaps it is a 2D acceleration issue,
or it could even just be a mozilla bug.

Comment 9 Mike A. Harris 2003-01-02 16:03:56 UTC
Adding Chris Blizzard to CC

Comment 10 Peter van Egdom 2003-01-04 10:01:00 UTC
Created attachment 89123 [details]
XFree86 logfile of nvidia driver on GeForce 4 card

Comment 11 Peter van Egdom 2003-01-04 10:03:50 UTC
Created attachment 89124 [details]
XFree86 4 configuration file of Nvidia GeForce 4

Comment 13 Mike A. Harris 2003-01-07 13:14:31 UTC
Oops, I closed instead of duped.

Comment 14 Mike A. Harris 2003-01-07 13:15:16 UTC

*** This bug has been marked as a duplicate of 73733 ***

Comment 15 Owen Taylor 2003-01-07 16:17:57 UTC
The comments and log files above clearly indicate that the misbehavior
is with the open source 'nv' driver, not the proprietary nvivdia driver.

Comment 16 Peter van Egdom 2003-01-07 18:49:44 UTC
Sorry for the confusion. The last comment by Owen Taylor is correct. I have not
tried the Nvidia closed source driver yet (on Phoebe 8.0.92). The described
problem occurs with the open source Nvidia (nv) driver and not with the open
source vesa driver.

Package : XFree86-

Comment 17 Peter van Egdom 2003-01-07 21:37:41 UTC
I just discovered that Ximian Evolution also has this same problem. It has this
same problem in the 'compose new message' entry screen. So it's not a Mozilla

"kedit" (qt3?) and "gedit" (gtk2?) don't have this problem. The problem might be
caused by some shared library being used by both Mozilla and Ximian Evolution in
combination with the open source 'nv' driver / module.

Package : evolution-1.2.1-2

Comment 19 Peter van Egdom 2003-01-09 19:33:08 UTC
Again, sorry for the confusion. I should have said "nv" where I said 'nvidia'.
I'll play with the options in the "nv" configuration file to see if described
problem goes away; if I find anything interesting to report, I'll attach my
logfiles to this bugzilla. Thanks!

Comment 20 Peter van Egdom 2003-01-09 23:46:44 UTC
Some interesting news.

First of all, I'll change the subject from this Bugzilla:

from : "Using cursor keys in Mozilla textboxes leaves 'smearing' with nvidia
to : "Using cursor keys in textboxes results in 'pixel smearing' with opensource
"nv" driver.

Okay, I've followed Mike's advice (in comment # 18) and did the following :

I inserted the line :

    Option      "noaccel" "on"

in the file "/etc/X11/XF86Config". I did this in the section called "Device".
This action solved all reported problems (the pixel mess in textboxes of both
Mozilla and Evolution), but introduced much slowness with full-window dragging.

I then followed his advice with the XaaNo* options, which I retrieved from the
manpage with the following command :

     "man XF86Config |col -b |grep -i XaaNo"

I copy & pasted the result of this command in the "/etc/X11/XF86Config" file,
under the "Device" section and deleted the line with the option "Noaccel". I
also commented every 'XaaNo' option generated by the above command. I then
deleted the commented character of the option :
         Option      "XaaNoSolidTwoPointLine" "on" 

and did a restart of the X server.

By starting Evolution and bringing up the 'compose new message' option I did try
using the cursor keys in the text entry of Evolution's compose window. The
reported problem did not occur. To be sure that the option
"XaaNoSolidTwoPointLine" was the cause of this, I commented it again and
restarted the X server. The reported problem returned again. I then deleted the
comment char of "XaaNoSolidTwoPointLine" and tried, after restarting X, the
cursor key test in Evolution again. And ..... the reported problem did not occur.

So, I then tried Mozilla's text entry box on RH Bugzilla. Strangely Mozilla
still had this problem. So with the option "XaaNoSolidTwoPointLine" the problem
disappeared with Evolution but still occurred with Mozilla textboxes.

I'll attach the config & log files of the 3 times in a row reproduced situation
with Evolution to this Bugzilla. Due to lack of time at the moment for me, I
cannot try all options to check out Mozilla's problem.

I'll attach the config & logfiles with the open source "nv" driver with the
"noaccel" option on and off.

I'll also attach the config & logfiles with the open source "nv" driver with the
"XaaNoSolidTwoPointLine" option on and off.

Comment 21 Peter van Egdom 2003-01-10 00:03:22 UTC
Created attachment 89268 [details]
XF86 config file which has no problems with Evolution

Comment 22 Peter van Egdom 2003-01-10 00:04:16 UTC
Created attachment 89269 [details]
XF86 Config file with the noaccel option

Comment 23 Peter van Egdom 2003-01-10 00:05:16 UTC
Created attachment 89270 [details]
XF86 config file with problems in Mozilla and Evolution

Comment 24 Peter van Egdom 2003-01-10 00:06:34 UTC
Created attachment 89271 [details]
XF86 logfile without probs in Evolution

Comment 25 Peter van Egdom 2003-01-10 00:07:34 UTC
Created attachment 89272 [details]
XF86 log file with noaccel option

Comment 26 Peter van Egdom 2003-01-10 00:08:28 UTC
Created attachment 89273 [details]
XF86 log file with probs in both Mozilla and Evolution

Comment 27 Dave Habben 2003-02-01 21:31:18 UTC
The correct option to fix Mozilla when using the open source "nv" driver is:
        Option "XaaNoSolidFillRect"

When using just this option Evolution still has the pixel corruption issue. So I
added the entry above of:
	Option "XaaNoSolidTwoPointLine"

These two options combined fix both Mozilla and Evolution.

Comment 28 Peter van Egdom 2003-02-01 23:25:47 UTC
On my system both these options fix the pixel corruption problem in Evolution
and Mozilla also.

Comment 29 Mike A. Harris 2003-02-02 01:24:58 UTC
Ok thanks.  I'll set the config file defaults to use the following options
for now, and I'll inform the upstream "nv" driver maintainer as well.

    Option "XaaNoSolidFillRect"
    Option "XaaNoSolidTwoPointLine"

Comment 30 Mike A. Harris 2003-02-02 22:59:38 UTC
I've reported this to the upstream driver maintainer, and here is
his suggestion:

>I've got well over a dozen cards and haven't seen any problems
>with those two primitives.  Who made that card and what's its
>BIOS version?  Could be a broken card, but it's more like that
>it just POSTs with the clocks too low.

Could you please provide the card manufacturer's name, BIOS version,
and also check and see if they've got a newer BIOS as well.

Comment 31 Dave Habben 2003-02-03 15:06:29 UTC
Leadtek Research Inc.
GeForce3 Ti 500
Product: NV20 Board
Version Chip Rev A3

I'll test out the new refrence BIOS and see if that fixes the issue.

Comment 32 Dave Habben 2003-02-03 19:19:32 UTC
Micro-Star International
GeForce3 Ti 200
Product: NV20 Board
Version Chip Rev A3

This GF3 also has the pixel corruption issue, I tried the latest reference BIOS
for this model and it still had the issue after the update.

I've also tested on a:
Dell Inspiron 8000 Laptop

This system appears to work perfectly without any Xaa options needing to be set,
is this bug perhaps limited to GeForce3 models?

Comment 33 Dave Habben 2003-02-04 05:02:10 UTC
>Leadtek Research Inc.
>GeForce3 Ti 500

The pixel corruption still occurs with the latest BIOS

Comment 34 Tommy McNeely 2003-02-04 17:14:00 UTC
I have the same problem... using the opensource "nv" driver..

G-Force 4 - Ti4600

I am not sure where to find the BIOS version (and since I am in initdefault 3, I
can't find the log file (isn't that somewhere in /tmp?) ... The only place I
remember seeing the Bios version is during a reboot (which I wont be able to see
from here)

01:05.0 VGA compatible controller: nVidia Corporation NV25 [GeForce4 Ti4600]
(rev a3)01:05.0 VGA 

(lspci -v)
compatible controller: nVidia Corporation NV25 [GeForce4 Ti4600] (rev a3)
(prog-if 00 [VGA])
	Subsystem: VISIONTEK: Unknown device 0037
	Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 17
	Memory at 52000000 (32-bit, non-prefetchable) [size=16M]
	Memory at c0000000 (32-bit, prefetchable) [size=128M]
	Memory at c8000000 (32-bit, prefetchable) [size=512K]
	Expansion ROM at <unassigned> [disabled] [size=128K]
	Capabilities: [60] Power Management version 2
	Capabilities: [44] AGP version 2.0

If I can provide any more information, please let me know.


Comment 35 Peter van Egdom 2003-02-04 23:20:22 UTC
Okay, here's my card :

Manufacturer : MSI
Card : NVidia GeForce 4 Ti4600
Model name : MS-8872
BIOS version :

"lspci -v -v" gives :

01:00.0 VGA compatible controller: nVidia Corporation NV25 [GeForce4 Ti4600]
(rev a2) (prog-if 00 [VGA])
        Subsystem: nVidia Corporation: Unknown device 0130
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (1250ns min, 250ns max)
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at de000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M]
        Region 2: Memory at ddc80000 (32-bit, prefetchable) [size=512K]
        Expansion ROM at dfee0000 [disabled] [size=128K]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [44] AGP version 2.0
                Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2,x4
                Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>

Comment 36 Mike A. Harris 2003-02-05 09:41:47 UTC
The driver maintainer says he can't reproduce this, however I've sent
him the information you've provided above in hopes he might have some
idea after seeing your updates.

If he's still unable to reproduce this after that however, I would be
inclined to believe that this is either a Mozilla bug, or an Xft bug.

It's rather hard to say.  It doesn't reproduce on any ATI or Matrox
hardware that I have here.  I've got a Quadro 2 and a Quadro 4 here
that I can test as well though.

Please also make absolutely sure that you are all running the absolute
latest beta (phoebe second release) and the latest Mozilla, evolution,
XFree86, freetype, fontconfig, and other software updates.

Please continue to provide more information and testing results as well.

Could each of you provide the Mozilla version that you're using here too?

Comment 37 Mike A. Harris 2003-02-05 18:32:36 UTC
I have great difficulty believing that this isn't either:

1) A driver bug


2) A hardware bug or hardware not properly producing lines that match
   what fb draws.

Since the problem goes away with disabling acceleration, I can't think
of anything that could cause this to _not_ be driver related.

Comment 38 Mike A. Harris 2003-02-13 01:10:44 UTC
And.....  <drumroll>

I was right.  The 'nv' driver maintainer received more bug reports from
other people, and looked into it deeper, and determined that the problem
did occur on some hardware and was due to the BIOS posting with clocks
low on some hardware.  He has committed a change to CVS to try to address

Date: Wed, 12 Feb 2003 13:26:28 -0800 (PST)
From: Mark Vojkovich <mvojkovi@XFree86.Org>
To: cvs-commit@XFree86.Org
List-Id: CVS commit messages from the XFree86 repository <cvs-commit.XFree86.Org>
Subject: CVS Update: xc (branch: trunk)
CVSROOT:        /home/x-cvs
Module name:    xc
Changes by:     mvojkovi@public.xfree86.org.    03/02/12 13:26:28
Log message:
     Use GXCOPY_ONLY for solid fills on newer NVIDIA cards.  The bios
  posts with the clocks too low to accelerate this without corruption.
Modified files:
  Revision      Changes    Path
  1.29          +13 -103   xc/programs/Xserver/hw/xfree86/drivers/nv/nv_xaa.c

Comment 39 Dave Habben 2003-02-20 04:36:34 UTC
This issue is fixed in the latest Phoebe beta3 (8.0.94)

The work-around is no longer necessary for Mozilla, or Evolution

Comment 40 Mike A. Harris 2003-02-20 05:10:05 UTC

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