Bug 65791 - Mouse pointer garbage in X using SiS 620 card
Mouse pointer garbage in X using SiS 620 card
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-05-31 14:23 EDT by Darren Gamble
Modified: 2007-04-18 12:42 EDT (History)
0 users

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

Attachments (Terms of Use)
Tarball of configuration files/logs , by step. (8.44 KB, application/octet-stream)
2002-06-03 13:35 EDT, Darren Gamble
no flags Details

  None (edit)
Description Darren Gamble 2002-05-31 14:23:43 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; H010818)

Description of problem:
Under Redhat 7.3, using a SiS 620 video card, the mouse pointer has horizontal 
lines of garbage in it.

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

How reproducible:

Steps to Reproduce:
1. Start X with a SiS620 card

Actual Results:  The mouse pointer has garbage.

Expected Results:  The mouse pointer should not have garbage.

Additional info:

Probably a driver problem.  Before 7.3, it was was running Redhat 7.2 (which 
was kept up2date'd) which did not have this problem.  XFree86-4.2.0-8 is 

I noted someone else had something kind of similar (bug #32401) which 
apparently was fixed via a "revert" to an older X server version.  It may be 
that the problem was not properly addressed.
Comment 1 Mike A. Harris 2002-06-01 03:46:09 EDT
Rerun Xconfigurator manually, and try again.  Does this solve the problem?

Comment 2 Mike A. Harris 2002-06-01 04:03:43 EDT
Actually, I get a lot of bug reports on this hardware, however there is a big
problem with actually fixing/resolving the issue properly.  The problem is
I don't have any SiS hardware or specs, and the people reporting the bugs
are generally more concerned about just getting it working at all, even if
they have to use an old driver or something, and once they've got it working
even with a hack, they are no longer interested in testing new things or
helping troubleshoot anymore.  As such - SiS support stays broken pretty much

Want to be the one to change all of that?  ;o)

If so, it could go a LONG way to helping get the driver in a working state
by default, and keep it there, as well as providing useful debug information
back to the driver maintainer.  The whole process will take no longer than
20 minutes to an hour or so.

If you're interested in the above, do the following:

1) Run Xconfigurator --preferxf4 to reconfigure the card, and test it.
   Does that work [YES/NO] - please attach XFree86 log and config file
   (XF86Config-4) from this test to the bug report before proceeding.

2) Edit the config file by hand, and in the "Device" section, add in the
   line:  Option "swcursor"   then save and exit, and restart X.
   Does that work [YES/NO] - please attach XFree86 log and config file
   (XF86Config-4) from this test to the bug report before proceeding.

3) Even if #2 succeeded, please continue.  Edit the config file again,
   now this time comment out the swcursor line above by placing a "#"
   at the beginning of the line.  Now add the following to the Device
   section:  Option "noaccel"  - this will slow things down a lot, but
   we're troubleshooting.  Now test it out.
   Does that work [YES/NO] - please attach XFree86 log and config file
   (XF86Config-4) from this test to the bug report before proceeding.

4) If both #2 and #3 failed, try doing both this time - enable both
   swcursor and noaccel.
   Does that work [YES/NO] - please attach XFree86 log and config file
   (XF86Config-4) from this test to the bug report before proceeding.

And finally, if you determine that option "noaccel" is required in order
to make this problem really go away, then we can work on determining
what specific part of accleration is broken.  That is a fairly simple
process as well.

Simply edit the config file again, comment out the noaccel option, read
the XF86Config manpage, and near the middle you'll find a list of options
beginning with XaaNoxxxxxxxx.  Try the top option and see if it fixes
things too.  If not, comment it out, and try the second XaaNo option.
Go through the whole list one at a time even if you find one that
makes the problem go away.  Please report back which of the XaaNo options
fix the problem.  If more than one must be supplied, please indicate that.

With this information gathered, I can do two things for this driver that
will make it better in the future.

1) I can make the default configuration work out of the box, even if the
   driver has bugs.
2) With the XaaNo test results, I can report to the driver author the
   problem, and what portion of code is causing it.  He can then reproduce
   it hopefully and try to fix the driver.

Hopefully we can get this fixed.
Comment 3 Darren Gamble 2002-06-03 13:20:30 EDT
Hey, I'd be happy to do anything in my power to help out Linux. =)

Part 1: Ran Xconfigurator; reconfigured X, restarted X.  Problem persisted.  
The configuration file made by Xconfigurator was significanly different than 
the one made by the installer, so I've attached both copies for reference.

Part 2: Edited config, added Option "swcursor" to Device section, restarted X.  
Problem no longer present.  Huzzah!

Part 3: Edited config, commented out Option "swcursor", added 
Option "noaccel" , restarted X.  Problem STILL not present.  Hrm.

So, it appears that adding either line fixes my problem.

I'll attach the config/log files, and then I'll go though each of the 
acceleration options a bit later today.

Comment 4 Darren Gamble 2002-06-03 13:35:39 EDT
Created attachment 59404 [details]
Tarball of configuration files/logs , by step.
Comment 5 Darren Gamble 2002-06-03 14:25:37 EDT
And the winner is:

Option "XaaNoScanlineCPUToScreenColorExpandFill"

Out of the 19 acceleration-disabling options listed on the man page, this is 
the only one which fixes the problem.

Anything else that I can do?  I'll happily test Rawhide RPMS too.

Comment 6 Mike McLean 2003-01-02 14:57:05 EST
This bug has been inappropriately marked MODIFIED. Please review the bug life
cycle information at 

Changing bug status to ASSIGNED.
Comment 7 Mike A. Harris 2003-01-15 17:02:11 EST
The SiS driver has been dramatically improved in the current
rawhide XFree86 packages.

What version of Red Hat Linux and XFree86 are you using currently?
Comment 8 Darren Gamble 2003-01-15 17:29:47 EST
I am still using XFree86-4.2.0-8 on 7.3 on that machine.

If the packages can be installed without too many dependancy problems, sure,
I'll try them out.  Do you want me to try this?
Comment 9 Mike A. Harris 2003-01-24 04:02:30 EST
No, the packages won't install in RHL 7.x at all.  They require an installation
of our latest beta release in order to work.  They are rebuildable in RHL 8.0
as well.

I've gotten feedback from another user via email that this problem is fixed
for him, so I'm closing this as fixed in RAWHIDE.

Please reopen the report if you have problems with the rawhide X release SiS
driver, or the final release of our next product.

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