xfree86/fbdevhw not sending right mode to radeonfb.c

xfree86/fbdevhw not sending right mode to radeonfb.c

[Kevin B. Hendricks]

Hi,

I am still working on the radeon driver for XFree86 and trying to get the
useFBDev options to work properly.

I have a properly constructued mode line in my XF86Config-4 which I
specifiy.

However when the XFree86 radeon_driver passes this initial mode to the
radeonfb.c kernel framebuffer driver, most of the mode information is
missing (no detailed timing info, just xres and yres, etc.

The radeonfb.c messes up when this incomplete mode information is passed
to it (from fbdevHWModeInit ?).

So where should I look to see where this is messing up.  It does not
appear to be an issue with the framebuffer kernel driver since it is the
victim of the receiving end of the bad data.

It is almost like the the xfree86 code that parses the XF86Config-4 config
file is not properly grabbing the specific mode information (or somehow
later it is being mangled).

Any hints or guidance of where to look in xfree86, would be greatly
appreciated.

Thanks,

Kevin

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

Re: xfree86/fbdevhw not sending right mode to radeonfb.c

[Michel Dänzer]

On Sun, 2001-11-18 at 15:12, Kevin B. Hendricks wrote:
>
> I am still working on the radeon driver for XFree86 and trying to get the
> useFBDev options to work properly.
>
> I have a properly constructued mode line in my XF86Config-4 which I
> specifiy.
>
> However when the XFree86 radeon_driver passes this initial mode to the
> radeonfb.c kernel framebuffer driver, most of the mode information is
> missing (no detailed timing info, just xres and yres, etc.
>
> The radeonfb.c messes up when this incomplete mode information is passed
> to it (from fbdevHWModeInit ?).
>
> So where should I look to see where this is messing up.  It does not
> appear to be an issue with the framebuffer kernel driver since it is the
> victim of the receiving end of the bad data.
>
> It is almost like the the xfree86 code that parses the XF86Config-4 config
> file is not properly grabbing the specific mode information (or somehow
> later it is being mangled).
>
> Any hints or guidance of where to look in xfree86, would be greatly
> appreciated.

fbdevHW and fbdevHWModeInit in particular are probably good places to
start. If you enable debugging in fbdevHW, it will print detailed mode
information.


--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

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

Re: xfree86/fbdevhw not sending right mode to radeonfb.c

[Kevin B. Hendricks]

Hi,

fbdevhw.c with DEBUG turned on shows the exact same thing I just reported.
 XFree86 is passing in the wrong mode info (missing detailed timings).

Here is a snippet of the XFree86.log

(--) RADEON(0): Virtual size is 1280x1024 (pitch 1296)
(**) RADEON(0): Mode "1280x1024-FP"
...
fbdevHW: MapMMIO 0
fbdevHW: MapVidmem 0
(**) RADEON(0): RADEONSave
fbdevHW: Save 0
fbdevHW: ModeInit 0
xfree init mode:        108000   1280 0 0 0   1024 0 0 0
fbdev init mode:        9259   1280 -1280 0 0   1024 -1024 0 0   32 8:8:8
fbdevHW: AdjustFrame 0


And here is the 1280x1024-FP mode taken from my XF86Config-4 file:

Mode    "1280x1024-FP"     # vfreq 60.020Hz, hfreq 63.981kHz
    DotClock        108.000000
    HTimings        1280 1408 1520 1688
    VTimings        1024 1028 1031 1066
    Flags   "-HSync" "-VSync"
EndMode

So for some reason xfree is missing all of the detailed timing info when
the fbdevHWModeInit is invoked.

I assume this is why others have reported problems when using different
modes than what the framebuffer devise has set to start up X11 (with
useFBDev) seems to have some problems.

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.

Thanks,

Kevin


On November 18, 2001 12:31, Michel Dänzer wrote:
> On Sun, 2001-11-18 at 15:12, Kevin B. Hendricks wrote:
> > I am still working on the radeon driver for XFree86 and trying to get
> > the useFBDev options to work properly.
> >
> > I have a properly constructued mode line in my XF86Config-4 which I
> > specifiy.
> >
> > However when the XFree86 radeon_driver passes this initial mode to the
> > radeonfb.c kernel framebuffer driver, most of the mode information is
> > missing (no detailed timing info, just xres and yres, etc.
> >
> > The radeonfb.c messes up when this incomplete mode information is
> > passed to it (from fbdevHWModeInit ?).
> >
> > So where should I look to see where this is messing up.  It does not
> > appear to be an issue with the framebuffer kernel driver since it is
> > the victim of the receiving end of the bad data.
> >
> > It is almost like the the xfree86 code that parses the XF86Config-4
> > config file is not properly grabbing the specific mode information (or
> > somehow later it is being mangled).
> >
> > Any hints or guidance of where to look in xfree86, would be greatly
> > appreciated.
>
> fbdevHW and fbdevHWModeInit in particular are probably good places to
> start. If you enable debugging in fbdevHW, it will print detailed mode
> information.

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

Re: xfree86/fbdevhw not sending right mode to radeonfb.c

[Kostas Gewrgiou]

On Sun, 18 Nov 2001, Kevin B. Hendricks wrote:

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

Good luck.

Kostas


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

Re: xfree86/fbdevhw not sending right mode to radeonfb.c

[Kevin B. Hendricks]

Hi Kostas,

FYI: Well I finally figured out what was up.  It seems the first thing the
special code for "DFPValidateModes" in radeon_driver.c does is delete all
modes since the timing info is technically not needed by them for DFP.

That is just a pisser since it removes the completely valid mode I had
placed into the XF86Config-4 for just that reason.

So no great mystery but I just don't think they should do that when using
fbdevhw.

That is only part of the problem, the other is that if you change the
depth from what is used by the frame buffer it does mess up as others have
reported.

Kevin

On November 19, 2001 06:00, Kostas Gewrgiou wrote:
> On Sun, 18 Nov 2001, Kevin B. Hendricks wrote:
> > 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.
>
> Good luck.
>
> Kostas

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

Re: xfree86/fbdevhw not sending right mode to radeonfb.c

[Michel Dänzer]

On Wed, 2001-11-21 at 20:42, Kevin B. Hendricks wrote:

> FYI: Well I finally figured out what was up.  It seems the first thing the
> special code for "DFPValidateModes" in radeon_driver.c does is delete all
> modes since the timing info is technically not needed by them for DFP.
>
> That is just a pisser since it removes the completely valid mode I had
> placed into the XF86Config-4 for just that reason.
>
> So no great mystery but I just don't think they should do that when using
> fbdevhw.

So fix it and submit a patch. ;)


> That is only part of the problem, the other is that if you change the
> depth from what is used by the frame buffer it does mess up as others have
> reported.

I believe Ben's work on radeonfb should fix this.

We were talking about different resolutions, which probably breaks due
to the fbdev driver.


--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

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

Re: xfree86/fbdevhw not sending right mode to radeonfb.c

[Benjamin Herrenschmidt]

>> That is only part of the problem, the other is that if you change the
>> depth from what is used by the frame buffer it does mess up as others have
>> reported.
>
>I believe Ben's work on radeonfb should fix this.
>
>We were talking about different resolutions, which probably breaks due
>to the fbdev driver.

Well, radeonfb has a nasty bug in switch() that could make it lose
track of what console is current if you change only the depth. I
fixed that along with a few other things, it should be in my rsync
tree now (you might need some time for mirrors to be up to date
on rsync.penguinppc.org). It also does 5:5:5 now (for MOL).

Ben.


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

Re: xfree86/fbdevhw not sending right mode to radeonfb.c

[Kevin Hendricks]

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/