xfree86/fbdevhw not sending right mode to radeonfb.c

Kevin Hendricks khendricks at ivey.uwo.ca
Tue Nov 20 02:28:14 EST 2001


Hi Kostas,

> > I am willing to dig deeper to track this one down if someone can point
> > me to the code that parses the mode info from the XF86Config-4 file
> and
> > loads it into the mode structure.
>
> Hello Kevin,
>
> Take a look at xf86parseModesSection(),xf86parseModeLine() etc
> in xc/programs/Xserver/hw/xfree86/parser/Monitor.c
> and also at configMonitor()
> in xc/programs/Xserver/hw/xfree86/common/xf86Config.c
>
> You might want to take a look at the  *Mode*.c files in ..../common
> as well.
>

Okay, I looked at that code and unless the xf86getSubToken is
broken somehow, then the correct info is being placed in the
linked list of modes.

So something is either stepping on that memory after that point
or  maybe the ValidateMode routine is messing it up somehow.

By the way, this has nothing to do with fbdevHW since I can see the
same missing mode information in RADEONModeInit when I do *NOT*
use useFBDev.  It is just that RADEONModeInit is better at filling in the
blanks properly given its access to the info structure timing info used
for
DFP.

Can anyone else confirm this?

To check, simply turn on DEBUG in xfree86 in the fbdevhw.c file and
include
your own custom modeline or mode and set useFBDev in your XF86Config-4
and
compare what xfree86 hands to fbdevhw.c in the form of the mode to your
original mode line.

I just want to make sure others are seeing the problem too before I jump
in
farther and try to find out why or how the mode info is being stepped on.

Thanks,

Kevin


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/





More information about the Linuxppc-dev mailing list