Bug 82310 - Screen Flicker on Toshiba 780CDM Laptop
Screen Flicker on Toshiba 780CDM Laptop
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
8.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-20 23:46 EST by harry paul
Modified: 2007-04-18 12:50 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-24 15:25:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description harry paul 2003-01-20 23:46:57 EST
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:
Comment 1 harry paul 2003-01-20 23:51:54 EST
Created attachment 89453 [details]
XFree 86 log
Comment 2 Mike A. Harris 2003-01-21 00:17:25 EST
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 00:25:50 EST
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.
Comment 4 harry paul 2003-01-21 01:35:25 EST
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
Comment 5 Mike A. Harris 2003-01-21 04:07:10 EST
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 

Comment 6 harry paul 2003-01-28 21:34:06 EST
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
Comment 7 Mike A. Harris 2003-01-29 02:51:11 EST
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 05:25:14 EST
Does what you see on screen look anything like these pictures:

ftp://people.redhat.com/mharris/pictures/RageIIC
Comment 9 harry paul 2003-02-09 23:18:09 EST
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
Comment 10 harry paul 2003-02-09 23:27:35 EST
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
 
Comment 11 Mike A. Harris 2004-09-24 15:25:00 EDT
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.