Bug 82430 - Unusable mode created for R128
Summary: Unusable mode created for R128
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
Depends On:
Blocks: 82779
TreeView+ depends on / blocked
Reported: 2003-01-22 01:34 UTC by adam.huffman
Modified: 2007-04-18 16:50 UTC (History)
2 users (show)

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

Attachments (Terms of Use)
X config after colour mode altered (3.09 KB, text/plain)
2003-01-22 01:36 UTC, adam.huffman
no flags Details
X log (34.85 KB, text/plain)
2003-01-22 01:37 UTC, adam.huffman
no flags Details

Description adam.huffman 2003-01-22 01:34:50 UTC
Description of problem:
The mode created by the installer for X on a Dell Latitude C800 with the ATI
Rage Mobility M4 chipset does not work properly - half the screen is obscured,
with the effect that firstboot is unusable.

The problem seems to lie with using 24-bit colour.  When I booted the phoebe2
system and manually changed XF86Config to 16-bit colour, the screen problems
were fixed (though it would be better if 24-bit colour worked).

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

How reproducible:
Every time

Steps to Reproduce:
1. Install from CD
2. boot in runlevel 5
Actual results:
Screen is unusable

Expected results:
Screen should be usable

Additional info:

Comment 1 adam.huffman 2003-01-22 01:36:24 UTC
Created attachment 89499 [details]
X config after colour mode altered

Comment 2 adam.huffman 2003-01-22 01:37:10 UTC
Created attachment 89500 [details]
X log

Comment 3 Don Hardaway 2003-01-23 16:25:45 UTC
I am having the same problem on my dell c800 laptop and have reported it in
another bug report.

Comment 4 Don Hardaway 2003-01-25 17:17:15 UTC
Just upgraded XFree86 to the latest in rawhide dated 1/22/2003.  Still get white
screens of death.  This must be an extemely difficult problem--it has continued

Comment 5 Mike A. Harris 2003-01-25 18:46:23 UTC
To be quite honest, I haven't looked at this problem at all whatsoever on
the debugging level, and that is why it hasn't changed.  With 200+ bugs
on XFree86, I regretably am unable to drop what I am doing, and work 18
hours per day in parallel on all 200 bugs simultaneously.

This bug report will be updated with a note to the effect "I am working
on this right now" when that time comes.  Lack of such a message indicating
that, can be taken as a sign that one or more of the other 200+ bugs
that are reported in bugzilla against XFree86 currently have higher
priority over this one.

Apologies for any inconveniences.

Comment 6 Mike A. Harris 2003-01-25 18:50:09 UTC
As an added note - problems like this tend to require *physical* possession
or direct physical access to the problematic hardware.  I have _zero_
laptop hardware.  As such, this problem most likely will be resolved when
XFree86.org or someone else in the community who has access to the hardware
fixes it and contributes the fix to XFree86.org.

Comment 7 Don Hardaway 2003-01-25 21:20:51 UTC
Thanks for the communication.  I have offered to somehow try to help since I
have the hardware but need your guidance and skills.  Another idea might be for
you to network into my laptop over the internet and look at what you need to
just as I do with my servers from remote. Let me know if any of these options
look workable.

Comment 8 Mike A. Harris 2003-01-26 01:07:36 UTC
These types of problems really do require physical access, and anywhere from
a day to a week of nonstop debugging and troubleshooting, requiring nonstop
reboots, etc.

Remote access is not really useful, as it requires a physical person on
the other end, whom is available 24/7 to reboot the machine, and whom
is also available instantly.  It also does not permit the person working
on it to see the screen.

Also, for security reasons and liability, I do not accept offers from people
to have remote access to their machines.

All I can suggest, is that you experiment on your own to try to find a
workaround in the mean time, or request help on XFree86 mailing lists, as
I am unable to provide technical support in bugzilla.  Bugzilla is strictly
a bug tracker, and not a tech support forum.  The bug has been reported,
and is being tracked now.  When the time comes that I can allot time
resources into investigating this issue, I will do so, and will update
the bug report to request more information if needed.

I simply can not however provide tech support in bugzilla.  Sorry.

Comment 9 Mike Chambers 2003-02-11 03:43:56 UTC
Maybe for now, that this bug should be filed against anaconda and also setup to 
default to 16-bit to at least get a working system?

Comment 10 Don Hardaway 2003-02-26 14:32:49 UTC
Below is a copy of a reply from Dell that i received the other day when I
inquired about the status of Dell supporting Linux for my laptop C800.  Does
this mean that you will soon have access to the laptop engineers at Dell and
have hardware in your lab to use to debug this X problem that so many of us with
Dell laptops are having?

"Hi Don, I found out that we are not currently supporting Linux on any laptops
or on our mobile Precision M50.  However, we will be releasing a new laptop line
at the end of next month (the D-series) that should have Linux support."

Comment 11 Mike A. Harris 2004-09-24 19:23:39 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.