X works somewhat on DFP with latest radeonfb.c

X works somewhat on DFP with latest radeonfb.c

[Kevin B. Hendricks]

Hi Ben,

Thought you might like to know.  I took a look at the XF410
radeon_driver.c and compared it to the latest versions of radeon_driver.c
in XFreee86 CVS HEAD and they are quite different.

CVS HEAD has a *lot* more support for DFP but since I had the radeonfb
working on the DFP I thought what the hell, and started to try to use XF
4.1.0 radeon_driver.c with only a few small tweaks (ignoring all of the
Flat Panel code which is old and not-working in XF410) with the UseFBDev
Option so all the DFP register stuff is handled by the radeonfb.c driver.

X actually starts up with depths of 8 and depths of 24 (32bpp), and works
but the colors are all wrong:  too many pinks in the 8 bit version and
seemingly random colors in the 24 depth.

So I am going to try and play around with the pallette setting.

Anyway, the nice thing is we are getting close!

I hope they release XF 4.X soon with all the DFP fixes so that I can try
driving the board directly and not use the FrameBuffer which will help me
figure out which one is the culprit.

I tried building CVS HEAD but it was clear that a number of files were not
in a buildable state (missing braces, etc).

Do you know of any tree I could grab that is buildable and does have the
most recent DFP support it in?  I chose HEAD.  Should I have chosen a
specific branch (4.1.99?) instead?

Take care.

Kevin

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

Re: X works somewhat on DFP with latest radeonfb.c

[Benjamin Herrenschmidt]

>Hi Ben,
>
>Thought you might like to know.  I took a look at the XF410
>radeon_driver.c and compared it to the latest versions of radeon_driver.c
>in XFreee86 CVS HEAD and they are quite different.
>
>CVS HEAD has a *lot* more support for DFP but since I had the radeonfb
>working on the DFP I thought what the hell, and started to try to use XF
>4.1.0 radeon_driver.c with only a few small tweaks (ignoring all of the
>Flat Panel code which is old and not-working in XF410) with the UseFBDev
>Option so all the DFP register stuff is handled by the radeonfb.c driver.
>
>X actually starts up with depths of 8 and depths of 24 (32bpp), and works
>but the colors are all wrong:  too many pinks in the 8 bit version and
>seemingly random colors in the 24 depth.
>
>So I am going to try and play around with the pallette setting.

Ask Ani for his patches. I think the engine must be properly configured
for big endian.

Ben.


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

Re: X works somewhat on DFP with latest radeonfb.c

[Kevin B. Hendricks]

Hi Ani,

Ben mentioned below that you might have some patches to handle BigEndian
issues for radeon.

Any help would be greatly appreciated.

Thanks,

Kevin


On November 17, 2001 11:07, Benjamin Herrenschmidt wrote:
> >Hi Ben,
> >
> >Thought you might like to know.  I took a look at the XF410
> >radeon_driver.c and compared it to the latest versions of
> > radeon_driver.c in XFreee86 CVS HEAD and they are quite different.
> >
> >CVS HEAD has a *lot* more support for DFP but since I had the radeonfb
> >working on the DFP I thought what the hell, and started to try to use
> > XF 4.1.0 radeon_driver.c with only a few small tweaks (ignoring all of
> > the Flat Panel code which is old and not-working in XF410) with the
> > UseFBDev Option so all the DFP register stuff is handled by the
> > radeonfb.c driver.
> >
> >X actually starts up with depths of 8 and depths of 24 (32bpp), and
> > works but the colors are all wrong:  too many pinks in the 8 bit
> > version and seemingly random colors in the 24 depth.
> >
> >So I am going to try and play around with the pallette setting.
>
> Ask Ani for his patches. I think the engine must be properly configured
> for big endian.
>
> Ben.

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

Re: X works somewhat on DFP with latest radeonfb.c

[Kevin B. Hendricks]

Hi Ani,

I found you XF410 patch at ftp.linuxppc.org/users/ajoshi/radeon/.

Your diff adds the following vga call:

vgaHWGetIOBase

which casues an immediate SEGFAULT of the Xserver.

Does this call need any special attention under ppc linux?  Do we even
need to make this call at all is we have the useFBDev option set?

Also, your diff does not add the "fbPictureInit" symbol to the list of
symbols which need to be loaded from the fb code (fbSymbols[]).

I had to add that symbol to get XF 410 with your patch to start up at all.

Any ideas here?  That patch is old (from June or July?).  Did I grab the
wrong patch?

Thanks,

Kevin

On November 17, 2001 11:23, Kevin B. Hendricks wrote:
> Hi Ani,
>
> Ben mentioned below that you might have some patches to handle BigEndian
> issues for radeon.
>
> Any help would be greatly appreciated.
>
> Thanks,
>
> Kevin
>
> On November 17, 2001 11:07, Benjamin Herrenschmidt wrote:
> > >Hi Ben,
> > >
> > >Thought you might like to know.  I took a look at the XF410
> > >radeon_driver.c and compared it to the latest versions of
> > > radeon_driver.c in XFreee86 CVS HEAD and they are quite different.
> > >
> > >CVS HEAD has a *lot* more support for DFP but since I had the
> > > radeonfb working on the DFP I thought what the hell, and started to
> > > try to use XF 4.1.0 radeon_driver.c with only a few small tweaks
> > > (ignoring all of the Flat Panel code which is old and not-working in
> > > XF410) with the UseFBDev Option so all the DFP register stuff is
> > > handled by the radeonfb.c driver.
> > >
> > >X actually starts up with depths of 8 and depths of 24 (32bpp), and
> > > works but the colors are all wrong:  too many pinks in the 8 bit
> > > version and seemingly random colors in the 24 depth.
> > >
> > >So I am going to try and play around with the pallette setting.
> >
> > Ask Ani for his patches. I think the engine must be properly
> > configured for big endian.
> >
> > Ben.
>

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

Re: X works somewhat on DFP with latest radeonfb.c

[Ani Joshi]

Hi Kevin,

Yes, this is a problem with the latest macs and their 3 pci busses,
anyhow, you shouldn't have any problems with current CVS since I've merged
most all of the PPC/BE radeon bits into CVS a while ago.  I will try a
build and see if anything fails today.


ani

On Sat, 17 Nov 2001, Kevin B. Hendricks wrote:

> Hi Ani,
>
> I found you XF410 patch at ftp.linuxppc.org/users/ajoshi/radeon/.
>
> Your diff adds the following vga call:
>
> vgaHWGetIOBase
>
> which casues an immediate SEGFAULT of the Xserver.
>
> Does this call need any special attention under ppc linux?  Do we even
> need to make this call at all is we have the useFBDev option set?
>
> Also, your diff does not add the "fbPictureInit" symbol to the list of
> symbols which need to be loaded from the fb code (fbSymbols[]).
>
> I had to add that symbol to get XF 410 with your patch to start up at all.
>
> Any ideas here?  That patch is old (from June or July?).  Did I grab the
> wrong patch?
>
> Thanks,
>
> Kevin
>
> On November 17, 2001 11:23, Kevin B. Hendricks wrote:
> > Hi Ani,
> >
> > Ben mentioned below that you might have some patches to handle BigEndian
> > issues for radeon.
> >
> > Any help would be greatly appreciated.
> >
> > Thanks,
> >
> > Kevin
> >
> > On November 17, 2001 11:07, Benjamin Herrenschmidt wrote:
> > > >Hi Ben,
> > > >
> > > >Thought you might like to know.  I took a look at the XF410
> > > >radeon_driver.c and compared it to the latest versions of
> > > > radeon_driver.c in XFreee86 CVS HEAD and they are quite different.
> > > >
> > > >CVS HEAD has a *lot* more support for DFP but since I had the
> > > > radeonfb working on the DFP I thought what the hell, and started to
> > > > try to use XF 4.1.0 radeon_driver.c with only a few small tweaks
> > > > (ignoring all of the Flat Panel code which is old and not-working in
> > > > XF410) with the UseFBDev Option so all the DFP register stuff is
> > > > handled by the radeonfb.c driver.
> > > >
> > > >X actually starts up with depths of 8 and depths of 24 (32bpp), and
> > > > works but the colors are all wrong:  too many pinks in the 8 bit
> > > > version and seemingly random colors in the 24 depth.
> > > >
> > > >So I am going to try and play around with the pallette setting.
> > >
> > > Ask Ani for his patches. I think the engine must be properly
> > > configured for big endian.
> > >
> > > Ben.
> >
>


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

Re: X works somewhat on DFP with latest radeonfb.c

[Daniel Berlin]

At least for poweroboks, the problem is that they rely on the bios being
there to detect the DFP/LCD.
Thus, it detects a size of 65535x65535, and things get screwy.
Also, DDC is disabled for PPC, because some can't handle int10 properly.
However, my powerbook seems to deal with it fine.
Comment out the part disabling int10 on powerpc, and see if ddc detects
your DFP properly.

Forcing the Panel size to the right size, I can use the CVS XFree86 on
my tibook2, without the UseFBDev option.

In fact, I almost have DRI working, too.
We just get the wrong address for the location of agp on the uninorth
(It says 16 meg @ 0x0), and thus, screw up.  But it inits the engine
okay, etc.

--Dan
On Saturday, November 17, 2001, at 11:23  AM, Kevin B. Hendricks wrote:

>
> Hi Ani,
>
> Ben mentioned below that you might have some patches to handle BigEndian
> issues for radeon.
>
> Any help would be greatly appreciated.
>
> Thanks,
>
> Kevin
>
>
> On November 17, 2001 11:07, Benjamin Herrenschmidt wrote:
>>> Hi Ben,
>>>
>>> Thought you might like to know.  I took a look at the XF410
>>> radeon_driver.c and compared it to the latest versions of
>>> radeon_driver.c in XFreee86 CVS HEAD and they are quite different.
>>>
>>> CVS HEAD has a *lot* more support for DFP but since I had the radeonfb
>>> working on the DFP I thought what the hell, and started to try to use
>>> XF 4.1.0 radeon_driver.c with only a few small tweaks (ignoring all of
>>> the Flat Panel code which is old and not-working in XF410) with the
>>> UseFBDev Option so all the DFP register stuff is handled by the
>>> radeonfb.c driver.
>>>
>>> X actually starts up with depths of 8 and depths of 24 (32bpp), and
>>> works but the colors are all wrong:  too many pinks in the 8 bit
>>> version and seemingly random colors in the 24 depth.
>>>
>>> So I am going to try and play around with the pallette setting.
>>
>> Ask Ani for his patches. I think the engine must be properly configured
>> for big endian.
>>
>> Ben.
>


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

Re: X works somewhat on DFP with latest radeonfb.c

[Michel Dänzer]

On Sat, 2001-11-17 at 17:07, Benjamin Herrenschmidt wrote:
>
> >Thought you might like to know.  I took a look at the XF410
> >radeon_driver.c and compared it to the latest versions of radeon_driver.c
> >in XFreee86 CVS HEAD and they are quite different.
> >
> >CVS HEAD has a *lot* more support for DFP but since I had the radeonfb
> >working on the DFP I thought what the hell, and started to try to use XF
> >4.1.0 radeon_driver.c with only a few small tweaks (ignoring all of the
> >Flat Panel code which is old and not-working in XF410) with the UseFBDev
> >Option so all the DFP register stuff is handled by the radeonfb.c driver.
> >
> >X actually starts up with depths of 8 and depths of 24 (32bpp), and works
> >but the colors are all wrong:  too many pinks in the 8 bit version and
> >seemingly random colors in the 24 depth.
> >
> >So I am going to try and play around with the pallette setting.
>
> Ask Ani for his patches. I think the engine must be properly configured
> for big endian.

With Option "UseFBDev", the framebuffer device is used for setting the
palette.


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