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): XFree86-4.2.0-8 How reproducible: Always 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 installed. 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.
Rerun Xconfigurator manually, and try again. Does this solve the problem?
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 permanently. 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.
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.
Created attachment 59404 [details] Tarball of configuration files/logs , by step.
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.
This bug has been inappropriately marked MODIFIED. Please review the bug life cycle information at http://bugzilla.redhat.com/bugzilla/bug_status.cgi Changing bug status to ASSIGNED.
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?
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?
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.