Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 Description of problem: screen has serious flicker on Toshiba laptop. It appears flicker cannot be seen when viewing a black on white or white on black screen. When colors are introduced (i.e. the default blue desktop screen under GNOME), the flicker is really bad. Also, the screen flares really bright, changes colors, splits and rolls when X is shut down or an init 3, init 6 or logout is done. For instance, when an init 6 is entered, the screen will flare and roll and nothing is visible on the screen until the machine is completely shut down and is doing a reset. It is impossible to run under X and then do an init 3 to go back to the console as the screen will just flare, roll, and split with lines through it until the system is manually reset. This laptop worked correctly under RH7.0 And while not relevant, it also worked under Mandrake 9.0 but only when installed using the X servers 3.3.6 option offered by Mandrake. It would not work when installed with the 4.2.0 X servers. XF86Config file # File generated by anaconda. Section "ServerLayout" Identifier "Anaconda Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Mouse1" "SendCoreEvents" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "Files" # The location of the RGB database. Note, this is the name of the # file minus the extension (like ".txt" or ".db"). There is normally # no need to change the default. RgbPath "/usr/X11R6/lib/X11/rgb" # Multiple FontPath entries are allowed (they are concatenated together) # By default, Red Hat 6.0 and later now use a font server independent of # the X server to render fonts. FontPath "unix/:7100" EndSection Section "Module" Load "dbe" Load "extmod" Load "fbdevhw" Load "dri" Load "glx" Load "record" Load "freetype" Load "type1" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "keyboard" # Option "AutoRepeat" "500 5" # when using XQUEUE, comment out the above line, and uncomment the # following line # Option "Protocol" "Xqueue" # Specify which keyboard LEDs can be user-controlled (eg, with xset(1)) # Option "Xleds" "1 2 3" # To disable the XKEYBOARD extension, uncomment XkbDisable. # Option "XkbDisable" # To customise the XKB settings to suit your keyboard, modify the # lines below (which are the defaults). For example, for a non-U.S. # keyboard, you will probably want to use: # Option "XkbModel" "pc102" # If you have a US Microsoft Natural keyboard, you can use: # Option "XkbModel" "microsoft" # # Then to change the language, change the Layout setting. # For example, a german layout can be obtained with: # Option "XkbLayout" "de" # or: # Option "XkbLayout" "de" # Option "XkbVariant" "nodeadkeys" # # If you'd like to switch the positions of your capslock and # control keys, use: # Option "XkbOptions" "ctrl:swapcaps" Option "XkbRules" "xfree86" Option "XkbModel" "pc105" Option "XkbLayout" "us" #Option "XkbVariant" "" #Option "XkbOptions" "" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/psaux" Option "ZAxisMapping" "4 5" Option "Emulate3Buttons" "no" EndSection Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Device" "/dev/input/mice" Option "Protocol" "IMPS/2" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" HorizSync 31.5-48.5 VertRefresh 40-70 Option "dpms" EndSection Section "Device" # no known options Identifier "S3 ViRGE/MX (generic)" Driver "s3virge" VendorName "S3 ViRGE/MX (generic)" BoardName "S3 ViRGE/MX (generic)" #BusID EndSection Section "Screen" Identifier "Screen0" Device "S3 ViRGE/MX (generic)" Monitor "Monitor0" DefaultDepth 16 Subsection "Display" Depth 16 Modes "1024x768" "800x600" "640x480" EndSubsection EndSection Section "DRI" Mode 0666 EndSection /var/log/XFree86.0.log Bugzilla won't let me cut and paste the log file into here for some reason. Thanks, Harry Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.StartX, see flicker 2.ctl.alt.backspace, see screen flare 3. Actual Results: screen flares really bright, changes colors, splits with lines through it. Expected Results: there should be no screen flicker and a person should be able to go to X and back to console without screen flare. Additional info:
Created attachment 89453 [details] XFree 86 log
Bugzilla wont let you cut and paste it because you're not supposed to cust and paste large files into the bug report text. It makes them very huge and unreadable after several comments. Always use file attachments.
Please test the following things in order, and let me know which one works better (if any): Put the following line in the Device section of your config: Option "noaccel" Restart X, and see if it makes any improvement at all. If it does not, try running "redhat-config-xfree86" and changing the driver to the "vesa" driver. Please let me know the results of these two tests.
Wow,you're good! noaccel had no effect but using the vesa driver seems to have cured the problems. Since it worked in RH7.0, I guess that means there is a problem with the latest version of the s3virge driver from XFree86???? Is there any disadvantage to using the vesa driver permanently?? Like maybe performance, functionality, etc.??? Should I put a bug report into XFree86.org??? thanks for the help, Harry
The "s3virge" driver was never used by default for this card in the past releases. Instead, the XFree86 3.3.6 X server was used by default. As such, the s3virge driver was never widely tested, and bugs tended to not get reported, so they never got fixed by XFree86.org either unfortunately. Now that we no longer ship XFree86 3.3.6, all hardware which used to default to it, has been changed to default to the native 4.x driver instead during our beta testing. Cards that are unsupported by the 4.x native drivers default to the "vesa" driver now. Cards that are reported to us to not work, which things like "noaccel" do not resolve, and to which we are unable to fix ourselves due to lack of hardware, docs, prioritization of issues, and other reasons, we default to the "vesa" driver if it turns out to work. Using "vesa" for cards that we can't fix, or don't have the resources to do so, and which XFree86.org doesn't fix or wont fix, allows us to give a user working video out of the box by default rather than nonworking video. Unfortunately, we don't have all of the various video cards out there, in particular a lot of older ones, so for older hardware, we rely on our beta testers, users, and customers to run our beta test releases during development, and report bugs to us, and problems such as the above. When someone reports an issue during beta testing, we often can fix things or workaround problems on a given video card before the OS goes gold. However, if a particular video board doesn't work, and nobody reports it to us in time, then the OS might end up shipping with broken video on the lesser used chips and legacy video. This has shown to be the case with a fair amount of S3 hardware unfortunately. ;o/ >Is there any disadvantage to using the vesa driver permanently?? Like maybe >performance, functionality, etc.??? Yes, the "vesa" driver uses the video card's BIOS to set up video modes, etc. and as such is not accelerated. Video is noticeably slower when using vesa. Also, some features of a video card may be unavailable, such as 3D acceleration, Xvideo support, and other features. >Should I put a bug report into XFree86.org??? Sure, never hurts. You can report it to xfree86@xfree86.org if you like. You might not get a response, but it lets them know the card isn't working still. Hope this helps. Take care! This allows us to give the user a better
I tried to view bug# 82783 and Bugzilla says I'm not authorized to view that bug. What's up with this?? I'd like to be able to view "any" bug in the system. Are there "secret" bugs that can't be viewed?? thanks, Harry Paul
Bugzilla is a Red Hat internal development tool. Red Hat has decided a long time ago to allow the general public to also have access to reporting bugs and querying the parts of the database that are public. Bugzilla does not contain just publically reported bugs, it also contains private bug reports filed by Red Hat partner companies and hardware vendors which contain private information under non-disclosure agreements. Bugzilla also contains developer's personal private todo list items, tracking bugs and other private information. A lot of these private bugs are either uninteresting to the public, or are not intended for the public at all due to containing private information or personal information, security related issues that are not public, or other items. Keeping track of this information in 8 separate databases is not beneficial for the purposes of data separation, so it is kept in one database, and private information is flagged as private to a certain group or groups of bugzilla users. In general, any bug that does not contain private information is marked public. Also, bugs that private information is no longer needed to be private, get changed to be public over time. I hope this helps to clarify why some bugs are publically viewable, and other bugs are marked private.
Does what you see on screen look anything like these pictures: ftp://people.redhat.com/mharris/pictures/RageIIC
No. In those pictures you are able to see what "type" of information is actually on the screen. With my problem, the screen flares really bright and you cannot see any form of data on the screen. Just a really bright screen with what looks a bad tv screen that needs demagnetizing (if you've ever seen one of those). And even when you do a ctl+(=)equal to shut down X, you still can't see anything on the screen. My screen will be a really bright white with blues fringes around the edges but it also will roll and split. You can't see any data at all, even though it probably is still there. Harry
If you were referring to the screen "flicker problem" I have, it is not like the pictures either. My screen data is very clear but the screen (when it isn't black on white, or white on black, has what looks like a 30-50hz flicker throughout the color part of the screen. Then when you shut down X to go back to terminal window, the screen begins the flaring and the screen won't be normal again until you shut down the system and reboot. Harry
Please upgrade to Fedora Core 2 or later, and if this issue turns out to still be reproduceable, please file a bug report in the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg" component. Once you've filed your bug report to X.Org, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized X.Org bug tracker, and will review any bug fixes that become available for consideration in future updates.