Bug 82310 - Screen Flicker on Toshiba 780CDM Laptop
Summary: Screen Flicker on Toshiba 780CDM Laptop
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-21 04:46 UTC by harry paul
Modified: 2007-04-18 16:50 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-24 19:25:00 UTC

Attachments (Terms of Use)
XFree 86 log (26.80 KB, text/plain)
2003-01-21 04:51 UTC, harry paul
no flags Details

Description harry paul 2003-01-21 04:46:57 UTC
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"

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"


Section "Module"
        Load  "dbe"
        Load  "extmod"
	Load  "fbdevhw"
	Load  "dri"
        Load  "glx"
        Load  "record"
        Load  "freetype"
        Load  "type1"

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"	""

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "IMPS/2"
        Option      "Device" "/dev/psaux"
        Option      "ZAxisMapping" "4 5"
        Option      "Emulate3Buttons" "no"

Section "InputDevice"
	Identifier	"Mouse1"
	Driver		"mouse"
	Option		"Device"		"/dev/input/mice"
	Option		"Protocol"		"IMPS/2"
	Option		"Emulate3Buttons"	"no"
	Option		"ZAxisMapping"		"4 5"

Section "Monitor"
        Identifier   "Monitor0"
        VendorName   "Monitor Vendor"
        ModelName    "Monitor Model"
        HorizSync   31.5-48.5
        VertRefresh 40-70
        Option "dpms"


Section "Device"
	# no known options
	Identifier   "S3 ViRGE/MX (generic)"
        Driver       "s3virge"
        VendorName   "S3 ViRGE/MX (generic)"
        BoardName     "S3 ViRGE/MX (generic)"

Section "Screen"
	Identifier   "Screen0"
        Device       "S3 ViRGE/MX (generic)"
        Monitor      "Monitor0"
	DefaultDepth	16

	Subsection "Display"
        	Depth       16
                Modes       "1024x768" "800x600" "640x480" 


Section "DRI"
	Mode 0666


Bugzilla won't let me cut and paste the log file into here for some reason.  



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

How reproducible:

Steps to Reproduce:
1.StartX, see flicker
2.ctl.alt.backspace, see screen flare

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:

Comment 1 harry paul 2003-01-21 04:51:54 UTC
Created attachment 89453 [details]
XFree 86 log

Comment 2 Mike A. Harris 2003-01-21 05:17:25 UTC
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.

Comment 3 Mike A. Harris 2003-01-21 05:25:50 UTC
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"

Please let me know the results of these two tests.

Comment 4 harry paul 2003-01-21 06:35:25 UTC
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,


Comment 5 Mike A. Harris 2003-01-21 09:07:10 UTC
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

Hope this helps.  Take care!

This allows us to give the user a better 

Comment 6 harry paul 2003-01-29 02:34:06 UTC
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??


Harry Paul

Comment 7 Mike A. Harris 2003-01-29 07:51:11 UTC
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.  

Comment 8 Mike A. Harris 2003-02-07 10:25:14 UTC
Does what you see on screen look anything like these pictures:


Comment 9 harry paul 2003-02-10 04:18:09 UTC
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.


Comment 10 harry paul 2003-02-10 04:27:35 UTC
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.  


Comment 11 Mike A. Harris 2004-09-24 19:25:00 UTC
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.

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