Bug 32549 - Dell Latitude c600 - Cannot test colour depth correctly
Summary: Dell Latitude c600 - Cannot test colour depth correctly
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 7.1
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: Brent Fox
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-03-21 18:04 UTC by David Sainty
Modified: 2007-04-18 16:32 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-09-24 16:11:14 UTC
Embargoed:


Attachments (Terms of Use)

Description David Sainty 2001-03-21 18:04:16 UTC
Whist doing a netboot NFS install of rawhide-20010320 on a new Latitude
c600, when choosing resolution and colour depth, even if you select 8bpp or
24bpp, the test screen still displays in 16bpp depth, and reports that it
is showing 16bpp depth. Observation of the /tmp/XF86Config.test file shows
that all three Display subsections are present for the various colour
depths, and the DefaultDepth is set to 16.

Chipset is an ATI Rage Mobility 128.  lspci can be found in bug #32532.

Comment 1 Michael Fulbright 2001-03-21 18:47:48 UTC
Mike is this a X server issue?

Comment 2 Mike A. Harris 2001-03-22 02:46:29 UTC
I don't think so.  I believe it might be an Xconfigurator issue.
Run it by Preston and Bill first.


Comment 3 Michael Fulbright 2001-03-22 15:50:21 UTC
Bill do you know of any Rage Mobility issues?

Sounds like the X server just does 16 bpp.

Comment 4 Preston Brown 2001-03-22 15:52:51 UTC
No, DefaultDepth is what is causing the problem.  Not sure why a 16bpp section 
is getting written if you didn't pick that at all though.  I'll have to check 
it out.


Comment 5 Michael Fulbright 2001-03-23 16:07:03 UTC
Is this using the GUI installer to setup X, or Xconfigurator via the TUI installer?

Comment 6 David Sainty 2001-03-23 21:00:11 UTC
Using GUI anaconda installer.   the XF86Config.test file just seems to be
written incorrectly for some reason.  I am now grabbing the source to
investigate.  (FYI, as I may have mentioned this was using netboot w/ NFS.)


Comment 7 David Sainty 2001-03-24 00:10:49 UTC
Okay! I understand the issue here, with anaconda.  When you use a "normal" video
card, e.g. GeForce 256, the depth and resolution is specified from
iw/xconfig_gui.py.  These selections "move on" to xf86config.py where they get
written to the test config via %(defaultDepth)s and %(screenModes)s.

In the event of a Rage Mobility 128 card however things are different.  Tracing
through, in def test (self, serverflags=None, spawn=0) we do:

        if laptop:
            self.modes = laptop

quite early, before we call def Version4Config(self, test=0). If laptop has been
set, we do something interesting...    def laptop (self):
        if not self.descr:
            return None
        # PCI descr, (horiz, vert), modes
        laptops = (("ATI|Rage Mobility",
                    ("30-110", "60-110"),
                    { "8" : ["800x600", "1024x768", "1400x1050"],
                      "16" : ["800x600", "1024x768", "1400x1050"],
                      "32" : ["800x600", "1024x768", "1400x1050"]}),
                   )
        for (card, (horiz, vert), modes) in laptops:
            if (len(self.descr) >= len (card)
                and self.descr[:len(card)] == card):
                self.monHoriz = horiz
                self.monVert = vert
                self.monID = "Laptop Screen"
                return modes
        return None 

We change the modes available, and give a number of fixed modes, overwriting any
selection made in the gui....

When we come to set the default depth....

        if maxdepth > 0:
            if maxdepth > 16 and '16' in self.modes.keys() and self.modes['16']:
                data["defaultDepth"] = "\n\tDefaultDepth\t16"
            else:
                data["defaultDepth"] = "\n\tDefaultDepth\t%d" % maxdepth

Depth will always be 16, since maxdepth > 16 and 16 is a valid depth!!

The convenient way of adding all relevant modes for ATI mobility type laptops is
resulting in the current inability to test at a certain colour depth.

We should look and see if there is a better way of doing this I suppose. :-)







Comment 8 Brent Fox 2001-03-27 16:15:46 UTC
This has been a known issue for a while.  I think that some LCD's are made for a
certain color depth and resolution, 1024x768 at 16bpp, for example.  I don't
think that most laptop screens will do 32bpp, but I could be wrong.

Comment 9 Preston Brown 2001-03-27 16:51:22 UTC
I think that the laptop will happily accept 24/32bit color.


Comment 10 Brent Fox 2001-03-28 04:20:44 UTC
Right you are.

Comment 11 Brent Fox 2001-03-28 04:39:51 UTC
Actually, I think the fix may be easier than what dsainty suggested.  In
xf86config.py, we call the laptop() function from inside availableModes() to get
the available modes for ATI cards.  Then, for some reason, we call laptop()
again inside test(), which has the effect of overriding the choices that you
made in the X configuration screen.  

Things work correctly if we remove the call to laptop inside the test() function
like so:


Index: xf86config.py
===================================================================
RCS file: /mnt/devel/CVS/anaconda/xf86config.py,v
retrieving revision 1.149
diff -u -r1.149 xf86config.py
--- xf86config.py       2001/03/07 23:06:49     1.149
+++ xf86config.py       2001/03/28 04:30:39
@@ -993,9 +993,9 @@
 
         files = self.files
         modes = self.modes
-        laptop = self.laptop()
-        if laptop:
-            self.modes = laptop
+#        laptop = self.laptop()
+#        if laptop:
+#            self.modes = laptop
         self.files = """
     RgbPath    "/usr/X11R6/lib/X11/rgb"
     FontPath   "/usr/X11R6/lib/X11/fonts/misc/"


However, since this is a non-critical issue, I'd like some feedback on whether
this patch should be applied at this juncture.

Comment 12 Brent Fox 2001-03-30 21:42:52 UTC
Ok, I've been told that we are only applying patches if they fix tracebacks at
this point, so this will have to wait for a future release.  Thanks for your
report.  Deferring.

Comment 13 Jeremy Katz 2001-09-10 21:46:39 UTC
Does this work better with Fairfax?

Comment 14 Brent Fox 2001-09-24 16:11:09 UTC
Any more info here?

Comment 15 Brent Fox 2001-10-04 14:13:14 UTC
Closing due to inactivity.  Please reopen if you have more information.


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