radeonfb on pegasos powerpc motherboard and X endianess problem

radeonfb on pegasos powerpc motherboard and X endianess problem

[Sven Luther]

Hello,

I finally have a working pegasos motherboard as well as a working kernel
with a 1.6 radeonfb. I have also installed Daniel Stone's X 4.3.0
debian/sid packages, and notice the following :

  1) radeonfb works fine in 8bpp and 32bpp but depth 15 and 16 only give
  me some very dark grey.

  2) when running X with the UseFBDev option the colors are bad, i guess
  it is an endianess problem. (with and without accel)

  3) When running X without the UseFBDev option, the colors are good,
  but i get garbage when i return to the console. Not exactly garbage,
  at first it is ok, but when i enter a line or somehow pan the screen,
  the corruption start. Doing a vt switch and back redraws a clean
  screen.

So, i think something is wrong. The kernel was forked around the
2.4.18-rc4 time in a messy way, i am actually working on bringing the
patch in sync with the newer ppc trees. Matroxfb also had problems and
Petr told me that it probably was an endianess issue back then. I am
using a Radeon 9000 board.

So, since this is a pegasos, based on the pop specification, which in
turn are related to the chrp ones, and i was told that most chrp
motherboard did endianess inversion in the northbridge or something
such, and i believe that the pegasos doesn't do so, is it possible that
this is the cause, and that XFree86 know how to program the graphic card
to do endianess conversion, and fbdev knows not, or maybe that the
XFree86 radeon driver doesn't know how to act exactly and accidentally
reverts the endianess conversion or something such.

Using the fbdev driver in xfree86, i get a seemingly working X, but the
background X image is yellowish and the mode is not set correctly it is
correct, but the image is a bit smaller than the screen, and centered or
moved to the right.

Does someone know with more exactitude what the situation is exactly
with regard the kernel and endianess conversion with the different
powerpc subarches.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Michel Dänzer]

On Wed, 2003-06-04 at 16:54, Sven Luther wrote:
> 
> I finally have a working pegasos motherboard as well as a working kernel
> with a 1.6 radeonfb. I have also installed Daniel Stone's X 4.3.0
> debian/sid packages, and notice the following :
> 
>   1) radeonfb works fine in 8bpp and 32bpp but depth 15 and 16 only give
>   me some very dark grey.
> 
>   2) when running X with the UseFBDev option the colors are bad, i guess
>   it is an endianess problem. (with and without accel)

You want radeonfb from a recent benh kernel, anything else is more or
less broken.

>   3) When running X without the UseFBDev option, the colors are good,
>   but i get garbage when i return to the console. Not exactly garbage,
>   at first it is ok, but when i enter a line or somehow pan the screen,
>   the corruption start. Doing a vt switch and back redraws a clean
>   screen.

Sounds like the radeon driver doesn't restore the framebuffer aperture
byte swapping correctly.


-- 
Earthling Michel Dänzer   \  Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast  \     http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Sven Luther]

On Wed, Jun 04, 2003 at 05:27:00PM +0200, Michel Dänzer wrote:
> On Wed, 2003-06-04 at 16:54, Sven Luther wrote:
> > 
> > I finally have a working pegasos motherboard as well as a working kernel
> > with a 1.6 radeonfb. I have also installed Daniel Stone's X 4.3.0
> > debian/sid packages, and notice the following :
> > 
> >   1) radeonfb works fine in 8bpp and 32bpp but depth 15 and 16 only give
> >   me some very dark grey.
> > 
> >   2) when running X with the UseFBDev option the colors are bad, i guess
> >   it is an endianess problem. (with and without accel)
> 
> You want radeonfb from a recent benh kernel, anything else is more or
> less broken.

A, ok, but then, i think i will not worry about this, and simply port
the pegasos changes to the latest benh kernel (or maybe i can simply
replace the radeonfb.c file ? Mmm, i will try it). By recent benh
kernel, you mean the one from the linuxppc_2_4_devel tree or the one from the
linuxppc_2_4 tree ? Or maybe both are the same.

> >   3) When running X without the UseFBDev option, the colors are good,
> >   but i get garbage when i return to the console. Not exactly garbage,
> >   at first it is ok, but when i enter a line or somehow pan the screen,
> >   the corruption start. Doing a vt switch and back redraws a clean
> >   screen.
> 
> Sounds like the radeon driver doesn't restore the framebuffer aperture
> byte swapping correctly.

Yep. same solution as above i guess.

Sound is also messed up, i guess it is also an endianess issue, but most
probably due to endianess issue in the VT82Cxx driver, and no other
powerpc box should use this, i think.

Thanks.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Benjamin Herrenschmidt]

On Wed, 2003-06-04 at 16:54, Sven Luther wrote:
> Hello,
> 
> I finally have a working pegasos motherboard as well as a working kernel
> with a 1.6 radeonfb. I have also installed Daniel Stone's X 4.3.0
> debian/sid packages, and notice the following :
> 
>   1) radeonfb works fine in 8bpp and 32bpp but depth 15 and 16 only give
>   me some very dark grey.

Can you try my devel tree version ?

(rsync.penguinppc.org::benh-devel)

>   2) when running X with the UseFBDev option the colors are bad, i guess
>   it is an endianess problem. (with and without accel)

What radeon card is this ?

>   3) When running X without the UseFBDev option, the colors are good,
>   but i get garbage when i return to the console. Not exactly garbage,
>   at first it is ok, but when i enter a line or somehow pan the screen,
>   the corruption start. Doing a vt switch and back redraws a clean
>   screen.

Known problem. This is actually a bit nasty. X doesn't fully restore the
engine state (and it's in fact quite difficult to know in which state
it should restore it) and there's no hook in the fbdev layer for
restoring things like that when switching from KD_GRAPHICS back to
KD_TEXT. I'm thinking about adding such a hook in 2.5. Usually, a VT
switch will trigger a restore of the engine state, at least it will
with my version of the driver.

> So, i think something is wrong. The kernel was forked around the
> 2.4.18-rc4 time in a messy way, i am actually working on bringing the
> patch in sync with the newer ppc trees. Matroxfb also had problems and
> Petr told me that it probably was an endianess issue back then. I am
> using a Radeon 9000 board.

Ok, there is a problem with older radeonfb's on these regarding
endianness, newer driver should work.

> So, since this is a pegasos, based on the pop specification, which in
> turn are related to the chrp ones, and i was told that most chrp
> motherboard did endianess inversion in the northbridge or something
> such, and i believe that the pegasos doesn't do so, is it possible that
> this is the cause, and that XFree86 know how to program the graphic card
> to do endianess conversion, and fbdev knows not, or maybe that the
> XFree86 radeon driver doesn't know how to act exactly and accidentally
> reverts the endianess conversion or something such.
> 
> Using the fbdev driver in xfree86, i get a seemingly working X, but the
> background X image is yellowish and the mode is not set correctly it is
> correct, but the image is a bit smaller than the screen, and centered or
> moved to the right.
> 
> Does someone know with more exactitude what the situation is exactly
> with regard the kernel and endianess conversion with the different
> powerpc subarches.

Endianness shouldn't be related to the subarch at all


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Benjamin Herrenschmidt]

> A, ok, but then, i think i will not worry about this, and simply port
> the pegasos changes to the latest benh kernel (or maybe i can simply
> replace the radeonfb.c file ? Mmm, i will try it). By recent benh
> kernel, you mean the one from the linuxppc_2_4_devel tree or the one from the
> linuxppc_2_4 tree ? Or maybe both are the same.

From the linuxppc_2_4_benh tree :)

> > >   3) When running X without the UseFBDev option, the colors are good,
> > >   but i get garbage when i return to the console. Not exactly garbage,
> > >   at first it is ok, but when i enter a line or somehow pan the screen,
> > >   the corruption start. Doing a vt switch and back redraws a clean
> > >   screen.
> > 
> > Sounds like the radeon driver doesn't restore the framebuffer aperture
> > byte swapping correctly.
> 
> Yep. same solution as above i guess.

The "fuzzyness" on scroll (basically clear operation not behaving
correctly) is an engine setup problem, not an endian problem.

> Sound is also messed up, i guess it is also an endianess issue, but most
> probably due to endianess issue in the VT82Cxx driver, and no other
> powerpc box should use this, i think.

Probably ;)



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Sven Luther]

On Thu, Jun 05, 2003 at 09:59:47AM +0200, Benjamin Herrenschmidt wrote:
> On Wed, 2003-06-04 at 16:54, Sven Luther wrote:
> > Hello,
> > 
> > I finally have a working pegasos motherboard as well as a working kernel
> > with a 1.6 radeonfb. I have also installed Daniel Stone's X 4.3.0
> > debian/sid packages, and notice the following :
> > 
> >   1) radeonfb works fine in 8bpp and 32bpp but depth 15 and 16 only give
> >   me some very dark grey.
> 
> Can you try my devel tree version ?
> 
> (rsync.penguinppc.org::benh-devel)

Err, is that the same devel tree as the one in linuxppc_2_4_devel ?

And no, i cannot really try it out, i need to port the pop+pegasos
patches first.

BTW, i have some questions about this :

  1) i think the hackyiness nature of it was because they simply #if 0
  ed out code that didn't fit them, so doing proper #if CONFIG_PEGASOS
  should clean this out, or was there also other kind of hackiness.

  2) head.S has some code which i guess is for early serial logging or
  something such. I guess such a thing can never be part of the official
  tree, right ?

  3) arch/ppc/platforms/chrp_setup.c got patched about io_block_mapping,
  but this doesn't seem to exist anymore in the current
  linuxppc_2_4_devel tree. Whatever happened to it, and what replaces it ?

  4) drivers/ide/ide-pci.c also is no more to be found in the current
  tree.

> >   2) when running X with the UseFBDev option the colors are bad, i guess
> >   it is an endianess problem. (with and without accel)
> 
> What radeon card is this ?

Radeon 9000 non-pro (and thus fanless).

> >   3) When running X without the UseFBDev option, the colors are good,
> >   but i get garbage when i return to the console. Not exactly garbage,
> >   at first it is ok, but when i enter a line or somehow pan the screen,
> >   the corruption start. Doing a vt switch and back redraws a clean
> >   screen.
> 
> Known problem. This is actually a bit nasty. X doesn't fully restore the
> engine state (and it's in fact quite difficult to know in which state
> it should restore it) and there's no hook in the fbdev layer for
> restoring things like that when switching from KD_GRAPHICS back to
> KD_TEXT. I'm thinking about adding such a hook in 2.5. Usually, a VT
> switch will trigger a restore of the engine state, at least it will
> with my version of the driver.

Mmm, so is this a problem in the X server or in the fbdev driver ? I
understand that you will fix this in the fbdev since you have a more
difficult time doing it in the X driver, but this does mean that the X
driver will do a partial save/restore, and that fbdev will then do a
full save/restore ? Seems overkill to me. We can either fix it in the
fbdev driver (which will know which registers the fbdev needs to backup)
or in the X driver (which will know about which register x needs to
backup).

Maybe it would be nice if the fbdev driver could save/restore the fbdev
used registers, and tell the X driver by a information hook that it did
do the saving, and then the X driver would not need to save/restore the
registers when UseFBDev was used.

> > So, i think something is wrong. The kernel was forked around the
> > 2.4.18-rc4 time in a messy way, i am actually working on bringing the
> > patch in sync with the newer ppc trees. Matroxfb also had problems and
> > Petr told me that it probably was an endianess issue back then. I am
> > using a Radeon 9000 board.
> 
> Ok, there is a problem with older radeonfb's on these regarding
> endianness, newer driver should work.

Ok, i will test again once i have finished the porting of the pegasos
patches.

> > So, since this is a pegasos, based on the pop specification, which in
> > turn are related to the chrp ones, and i was told that most chrp
> > motherboard did endianess inversion in the northbridge or something
> > such, and i believe that the pegasos doesn't do so, is it possible that
> > this is the cause, and that XFree86 know how to program the graphic card
> > to do endianess conversion, and fbdev knows not, or maybe that the
> > XFree86 radeon driver doesn't know how to act exactly and accidentally
> > reverts the endianess conversion or something such.
> > 
> > Using the fbdev driver in xfree86, i get a seemingly working X, but the
> > background X image is yellowish and the mode is not set correctly it is
> > correct, but the image is a bit smaller than the screen, and centered or
> > moved to the right.
> > 
> > Does someone know with more exactitude what the situation is exactly
> > with regard the kernel and endianess conversion with the different
> > powerpc subarches.
> 
> Endianness shouldn't be related to the subarch at all

Ah, so it is not true that one chrp, the northbridge did the endianess
conversion transparently ?

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Benjamin Herrenschmidt]

On Thu, 2003-06-05 at 10:19, Sven Luther wrote:

> Err, is that the same devel tree as the one in linuxppc_2_4_devel ?

No, it's linuxppc_2_4_benh bk, though you can use rsync to extract
just radeonfb from rsync.penguinppc.org::benh-devel.

> And no, i cannot really try it out, i need to port the pop+pegasos
> patches first.
> 
> BTW, i have some questions about this :
> 
>   1) i think the hackyiness nature of it was because they simply #if 0
>   ed out code that didn't fit them, so doing proper #if CONFIG_PEGASOS
>   should clean this out, or was there also other kind of hackiness.

Ì don't have it all in mind now, send me your patches when you are
done and I'll tell you more.

>   2) head.S has some code which i guess is for early serial logging or
>   something such. I guess such a thing can never be part of the official
>   tree, right ?

That depends... It can be done cleanly without hacking head.S I beleive,
but I need to look at the code to tell you exactly

>   3) arch/ppc/platforms/chrp_setup.c got patched about io_block_mapping,
>   but this doesn't seem to exist anymore in the current
>   linuxppc_2_4_devel tree. Whatever happened to it, and what replaces it ?

You probably don't need it. Just ioremap what need to be ioremap'ed and
avoid any hard coded virtual addresses and things should be just fine.

> > >   2) when running X with the UseFBDev option the colors are bad, i guess
> > >   it is an endianess problem. (with and without accel)
> > 
> > What radeon card is this ?
> 
> Radeon 9000 non-pro (and thus fanless).
> 
> > >   3) When running X without the UseFBDev option, the colors are good,
> > >   but i get garbage when i return to the console. Not exactly garbage,
> > >   at first it is ok, but when i enter a line or somehow pan the screen,
> > >   the corruption start. Doing a vt switch and back redraws a clean
> > >   screen.
> > 
> > Known problem. This is actually a bit nasty. X doesn't fully restore the
> > engine state (and it's in fact quite difficult to know in which state
> > it should restore it) and there's no hook in the fbdev layer for
> > restoring things like that when switching from KD_GRAPHICS back to
> > KD_TEXT. I'm thinking about adding such a hook in 2.5. Usually, a VT
> > switch will trigger a restore of the engine state, at least it will
> > with my version of the driver.
> 
> Mmm, so is this a problem in the X server or in the fbdev driver ? I
> understand that you will fix this in the fbdev since you have a more
> difficult time doing it in the X driver, but this does mean that the X
> driver will do a partial save/restore, and that fbdev will then do a
> full save/restore ? Seems overkill to me. We can either fix it in the
> fbdev driver (which will know which registers the fbdev needs to backup)
> or in the X driver (which will know about which register x needs to
> backup).

Not exactly. I'm not sure X can restore the engine state exactly
(maybe it can, but imho, it's a bit overkill). I tend to think that
the fbdev shall do it as it's very much easier. On one side, X would
have to backup & restore an insane amount of registers, on the other
side, fbdev can just re-init the engine to the state it wants in a few
dozen lines of code.

So my idea was to fix the fbdev interface so that fbdev's in general
have a hook when a console witch from KD_GRAPHICS to KD_TEXT (that
is basically when fbcon gets back control) so things can be reset
properly.  

> Maybe it would be nice if the fbdev driver could save/restore the fbdev
> used registers, and tell the X driver by a information hook that it did
> do the saving, and then the X driver would not need to save/restore the
> registers when UseFBDev was used.

X already save/restore things related to mode setting. The accel engine
is another problem (and not related to use of UseFBDev or not, the
problem is the same in both cases).

I don't think any of such 'hooks' in the fbdev<->X interface will be
ever accepted by X folks like Marc Aurele ;) (He never allowed fbdev
support to be added to the mach64 driver for example)

> Ah, so it is not true that one chrp, the northbridge did the endianess
> conversion transparently ?

No. There are strict rules on how endianess has to be dealt between 
a BE CPU and the PCI bus, and afaik, all PPCs do it properly.

Ben.


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Sven Luther]

On Thu, Jun 05, 2003 at 01:42:30PM +0200, Benjamin Herrenschmidt wrote:
> On Thu, 2003-06-05 at 10:19, Sven Luther wrote:
> 
> > Err, is that the same devel tree as the one in linuxppc_2_4_devel ?
> 
> No, it's linuxppc_2_4_benh bk, though you can use rsync to extract
> just radeonfb from rsync.penguinppc.org::benh-devel.

Mmm, i think i am just a bit lost with all the ppc kernel trees ...
Which one should i work on.


> > And no, i cannot really try it out, i need to port the pop+pegasos
> > patches first.
> > 
> > BTW, i have some questions about this :
> > 
> >   1) i think the hackyiness nature of it was because they simply #if 0
> >   ed out code that didn't fit them, so doing proper #if CONFIG_PEGASOS
> >   should clean this out, or was there also other kind of hackiness.
> 
> Ì don't have it all in mind now, send me your patches when you are
> done and I'll tell you more.

Ok.

> >   2) head.S has some code which i guess is for early serial logging or
> >   something such. I guess such a thing can never be part of the official
> >   tree, right ?
> 
> That depends... It can be done cleanly without hacking head.S I beleive,
> but I need to look at the code to tell you exactly

Mmm, anyway, once it work well, it is not needed that much anymore. I
will look into this once i have booted a more recent tree, and start
cleaning up patches.

> >   3) arch/ppc/platforms/chrp_setup.c got patched about io_block_mapping,
> >   but this doesn't seem to exist anymore in the current
> >   linuxppc_2_4_devel tree. Whatever happened to it, and what replaces it ?
> 
> You probably don't need it. Just ioremap what need to be ioremap'ed and
> avoid any hard coded virtual addresses and things should be just fine.

Ok, will do that.

> > > >   2) when running X with the UseFBDev option the colors are bad, i guess
> > > >   it is an endianess problem. (with and without accel)
> > > 
> > > What radeon card is this ?
> > 
> > Radeon 9000 non-pro (and thus fanless).
> > 
> > > >   3) When running X without the UseFBDev option, the colors are good,
> > > >   but i get garbage when i return to the console. Not exactly garbage,
> > > >   at first it is ok, but when i enter a line or somehow pan the screen,
> > > >   the corruption start. Doing a vt switch and back redraws a clean
> > > >   screen.
> > > 
> > > Known problem. This is actually a bit nasty. X doesn't fully restore the
> > > engine state (and it's in fact quite difficult to know in which state
> > > it should restore it) and there's no hook in the fbdev layer for
> > > restoring things like that when switching from KD_GRAPHICS back to
> > > KD_TEXT. I'm thinking about adding such a hook in 2.5. Usually, a VT
> > > switch will trigger a restore of the engine state, at least it will
> > > with my version of the driver.
> > 
> > Mmm, so is this a problem in the X server or in the fbdev driver ? I
> > understand that you will fix this in the fbdev since you have a more
> > difficult time doing it in the X driver, but this does mean that the X
> > driver will do a partial save/restore, and that fbdev will then do a
> > full save/restore ? Seems overkill to me. We can either fix it in the
> > fbdev driver (which will know which registers the fbdev needs to backup)
> > or in the X driver (which will know about which register x needs to
> > backup).
> 
> Not exactly. I'm not sure X can restore the engine state exactly
> (maybe it can, but imho, it's a bit overkill). I tend to think that
> the fbdev shall do it as it's very much easier. On one side, X would
> have to backup & restore an insane amount of registers, on the other
> side, fbdev can just re-init the engine to the state it wants in a few
> dozen lines of code.

I don't know about the radeon driver exactly but the glint driver i did
work on did a mode setup when comming from the VT switch, after having
saved the registers it touches for the consoles benefit. It then
proceeded to reinitialize the accel pipeline, complete with a sync and
all. I guess newer hardware have easier way to do this, and this doesn't
speak about the DRI case, but probably all the X driver do it such. When
switching back, they restore the registers they have touched, more
probably only the mode setting registers, and don't care about the accel
regs, since text mode don't touch them.

> So my idea was to fix the fbdev interface so that fbdev's in general
> have a hook when a console switch from KD_GRAPHICS to KD_TEXT (that
> is basically when fbcon gets back control) so things can be reset
> properly.  

Yep.

> > Maybe it would be nice if the fbdev driver could save/restore the fbdev
> > used registers, and tell the X driver by a information hook that it did
> > do the saving, and then the X driver would not need to save/restore the
> > registers when UseFBDev was used.
> 
> X already save/restore things related to mode setting. The accel engine
> is another problem (and not related to use of UseFBDev or not, the
> problem is the same in both cases).

Not really, because when the card is in vga text mode, it couldn't care
less about accel engine, right ?

> I don't think any of such 'hooks' in the fbdev<->X interface will be
> ever accepted by X folks like Marc Aurele ;) (He never allowed fbdev
> support to be added to the mach64 driver for example)

Well, There are fbdev specific Enter/Leave VT functions, which could be
different, but i also understand what you mean. Not all developpers
think like that though, and David even told me he was not against fbdev.

And then, there will be chance to change things for 5.0, if we have
specific needs.

> > Ah, so it is not true that one chrp, the northbridge did the endianess
> > conversion transparently ?
> 
> No. There are strict rules on how endianess has to be dealt between 
> a BE CPU and the PCI bus, and afaik, all PPCs do it properly.

Ok, so it must be another kind of problems, but then, my matrox board,
which Geert (or someone else) said did run on his chrp board, did not
work well for me.

Thanks,

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Benjamin Herrenschmidt]

On Thu, 2003-06-05 at 13:58, Sven Luther wrote:
> On Thu, Jun 05, 2003 at 01:42:30PM +0200, Benjamin Herrenschmidt wrote:
> > On Thu, 2003-06-05 at 10:19, Sven Luther wrote:
> > 
> > > Err, is that the same devel tree as the one in linuxppc_2_4_devel ?
> > 
> > No, it's linuxppc_2_4_benh bk, though you can use rsync to extract
> > just radeonfb from rsync.penguinppc.org::benh-devel.
> 
> Mmm, i think i am just a bit lost with all the ppc kernel trees ...
> Which one should i work on.

Yup, 2.4 is a mess ... For a new platform like that, I suggest 
working on linuxppc_2_4 or Marcelo tree directly

> .../...
>
> I don't know about the radeon driver exactly but the glint driver i did
> work on did a mode setup when comming from the VT switch, after having
> saved the registers it touches for the consoles benefit. It then
> proceeded to reinitialize the accel pipeline, complete with a sync and
> all. I guess newer hardware have easier way to do this, and this doesn't
> speak about the DRI case, but probably all the X driver do it such. When
> switching back, they restore the registers they have touched, more
> probably only the mode setting registers, and don't care about the accel
> regs, since text mode don't touch them.

Which is the problem ;) radeonfb do use the accel engine for text
rendering, which is why things aren't pretty when coming from X
(actually, I noticed X tends to fuckup the accel engine when quit
even while it's not the frontmost console, so there's probably also
a bug in X)


> Ok, so it must be another kind of problems, but then, my matrox board,
> which Geert (or someone else) said did run on his chrp board, did not
> work well for me.

Could be a problem with how the firmware did/did not initialize it

Ben.



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Sven Luther]

On Thu, Jun 05, 2003 at 02:27:23PM +0200, Benjamin Herrenschmidt wrote:
> On Thu, 2003-06-05 at 13:58, Sven Luther wrote:
> > On Thu, Jun 05, 2003 at 01:42:30PM +0200, Benjamin Herrenschmidt wrote:
> > > On Thu, 2003-06-05 at 10:19, Sven Luther wrote:
> > > 
> > > > Err, is that the same devel tree as the one in linuxppc_2_4_devel ?
> > > 
> > > No, it's linuxppc_2_4_benh bk, though you can use rsync to extract
> > > just radeonfb from rsync.penguinppc.org::benh-devel.
> > 
> > Mmm, i think i am just a bit lost with all the ppc kernel trees ...
> > Which one should i work on.
> 
> Yup, 2.4 is a mess ... For a new platform like that, I suggest 
> working on linuxppc_2_4 or Marcelo tree directly

Ok.

> > .../...
> >
> > I don't know about the radeon driver exactly but the glint driver i did
> > work on did a mode setup when comming from the VT switch, after having
> > saved the registers it touches for the consoles benefit. It then
> > proceeded to reinitialize the accel pipeline, complete with a sync and
> > all. I guess newer hardware have easier way to do this, and this doesn't
> > speak about the DRI case, but probably all the X driver do it such. When
> > switching back, they restore the registers they have touched, more
> > probably only the mode setting registers, and don't care about the accel
> > regs, since text mode don't touch them.
> 
> Which is the problem ;) radeonfb do use the accel engine for text
> rendering, which is why things aren't pretty when coming from X
> (actually, I noticed X tends to fuckup the accel engine when quit
> even while it's not the frontmost console, so there's probably also
> a bug in X)

Maybe a sync problem or somewhat related with DRI ?

> > Ok, so it must be another kind of problems, but then, my matrox board,
> > which Geert (or someone else) said did run on his chrp board, did not
> > work well for me.
> 
> Could be a problem with how the firmware did/did not initialize it

Actually, the OF has a x86 emulator which runs the x86 bios of the
graphic card. 

Anyway, i will look at it once i have ported the patches.

Friendly,

Sven Luther
> 
> Ben.


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Geert Uytterhoeven]

On Thu, 5 Jun 2003, Sven Luther wrote:
> On Thu, Jun 05, 2003 at 09:59:47AM +0200, Benjamin Herrenschmidt wrote:
> > On Wed, 2003-06-04 at 16:54, Sven Luther wrote:
> > > So, since this is a pegasos, based on the pop specification, which in
> > > turn are related to the chrp ones, and i was told that most chrp
> > > motherboard did endianess inversion in the northbridge or something
> > > such, and i believe that the pegasos doesn't do so, is it possible that
> > > this is the cause, and that XFree86 know how to program the graphic card
> > > to do endianess conversion, and fbdev knows not, or maybe that the
> > > XFree86 radeon driver doesn't know how to act exactly and accidentally
> > > reverts the endianess conversion or something such.
> > > 
> > > Using the fbdev driver in xfree86, i get a seemingly working X, but the
> > > background X image is yellowish and the mode is not set correctly it is
> > > correct, but the image is a bit smaller than the screen, and centered or
> > > moved to the right.
> > > 
> > > Does someone know with more exactitude what the situation is exactly
> > > with regard the kernel and endianess conversion with the different
> > > powerpc subarches.
> > 
> > Endianness shouldn't be related to the subarch at all
> 
> Ah, so it is not true that one chrp, the northbridge did the endianess
> conversion transparently ?

No, PCI is little endian. And fortunately the VLSI Golden Gate II in my
Longtrail doesn't try to outsmart the user, unlike some PCI host bridges in
some MIPS SoCs...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Geert Uytterhoeven]

On 5 Jun 2003, Benjamin Herrenschmidt wrote:
> On Thu, 2003-06-05 at 10:19, Sven Luther wrote:
> > > >   3) When running X without the UseFBDev option, the colors are good,
> > > >   but i get garbage when i return to the console. Not exactly garbage,
> > > >   at first it is ok, but when i enter a line or somehow pan the screen,
> > > >   the corruption start. Doing a vt switch and back redraws a clean
> > > >   screen.
> > > 
> > > Known problem. This is actually a bit nasty. X doesn't fully restore the
> > > engine state (and it's in fact quite difficult to know in which state
> > > it should restore it) and there's no hook in the fbdev layer for
> > > restoring things like that when switching from KD_GRAPHICS back to
> > > KD_TEXT. I'm thinking about adding such a hook in 2.5. Usually, a VT
> > > switch will trigger a restore of the engine state, at least it will
> > > with my version of the driver.
> > 
> > Mmm, so is this a problem in the X server or in the fbdev driver ? I
> > understand that you will fix this in the fbdev since you have a more
> > difficult time doing it in the X driver, but this does mean that the X
> > driver will do a partial save/restore, and that fbdev will then do a
> > full save/restore ? Seems overkill to me. We can either fix it in the
> > fbdev driver (which will know which registers the fbdev needs to backup)
> > or in the X driver (which will know about which register x needs to
> > backup).
> 
> Not exactly. I'm not sure X can restore the engine state exactly
> (maybe it can, but imho, it's a bit overkill). I tend to think that
> the fbdev shall do it as it's very much easier. On one side, X would
> have to backup & restore an insane amount of registers, on the other
> side, fbdev can just re-init the engine to the state it wants in a few
> dozen lines of code.

Yes, re-initting the engine is the correct way. IIRC, atyfb does this when text
mode acceleration is re-enabled in fb_var_screeninfo.accel_flags. I.e. when X
leaves graphics mode and switches VT.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Geert Uytterhoeven]

On Thu, 5 Jun 2003, Sven Luther wrote:
> On Thu, Jun 05, 2003 at 02:27:23PM +0200, Benjamin Herrenschmidt wrote:
> > On Thu, 2003-06-05 at 13:58, Sven Luther wrote:
> > > Ok, so it must be another kind of problems, but then, my matrox board,
> > > which Geert (or someone else) said did run on his chrp board, did not
> > > work well for me.

Not me, as I don't have any Matrox cards (just S3 and Mach64 GT).

> > Could be a problem with how the firmware did/did not initialize it
> 
> Actually, the OF has a x86 emulator which runs the x86 bios of the
> graphic card. 

Aha, so you get VGA text mode on bootup instead of linear graphics?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Sven Luther]

On Fri, Jun 06, 2003 at 08:02:23AM +0200, Geert Uytterhoeven wrote:
> On Thu, 5 Jun 2003, Sven Luther wrote:
> > On Thu, Jun 05, 2003 at 02:27:23PM +0200, Benjamin Herrenschmidt wrote:
> > > On Thu, 2003-06-05 at 13:58, Sven Luther wrote:
> > > > Ok, so it must be another kind of problems, but then, my matrox board,
> > > > which Geert (or someone else) said did run on his chrp board, did not
> > > > work well for me.
> 
> Not me, as I don't have any Matrox cards (just S3 and Mach64 GT).
> 
> > > Could be a problem with how the firmware did/did not initialize it
> > 
> > Actually, the OF has a x86 emulator which runs the x86 bios of the
> > graphic card. 
> 
> Aha, so you get VGA text mode on bootup instead of linear graphics?

Yep, Ralph (who wrote the OF or something such) is telling me that the
linear fb apperture doesn't fit in the vga aperture or something such,
and that graphic mode would need vesa 3.x cards.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Geert Uytterhoeven]

On Fri, 6 Jun 2003, Sven Luther wrote:
> On Fri, Jun 06, 2003 at 08:02:23AM +0200, Geert Uytterhoeven wrote:
> > On Thu, 5 Jun 2003, Sven Luther wrote:
> > > Actually, the OF has a x86 emulator which runs the x86 bios of the
> > > graphic card. 
> > 
> > Aha, so you get VGA text mode on bootup instead of linear graphics?
> 
> Yep, Ralph (who wrote the OF or something such) is telling me that the
> linear fb apperture doesn't fit in the vga aperture or something such,
> and that graphic mode would need vesa 3.x cards.

What about a similar solution to vesafb? Or does VESA 3.x mode switching
requires much more BIOS emulation code?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Sven Luther]

On Fri, Jun 06, 2003 at 08:35:49AM +0200, Geert Uytterhoeven wrote:
> On Fri, 6 Jun 2003, Sven Luther wrote:
> > On Fri, Jun 06, 2003 at 08:02:23AM +0200, Geert Uytterhoeven wrote:
> > > On Thu, 5 Jun 2003, Sven Luther wrote:
> > > > Actually, the OF has a x86 emulator which runs the x86 bios of the
> > > > graphic card. 
> > > 
> > > Aha, so you get VGA text mode on bootup instead of linear graphics?
> > 
> > Yep, Ralph (who wrote the OF or something such) is telling me that the
> > linear fb apperture doesn't fit in the vga aperture or something such,
> > and that graphic mode would need vesa 3.x cards.
> 
> What about a similar solution to vesafb? Or does VESA 3.x mode switching
> requires much more BIOS emulation code?

I don't know, i am not really familiar with vesa stuff, it could be a
solution. I don't know, but i feel that fixing the normal driver would
be easier for me, but maybe this is not always possible.

As for vesa 3.x, i guess they don't do it, because it would not work
with older vesa cards, or something such. I am not really all that
familiar with vesa code.

Friendly,

Sven Luther
> 
> Gr{oetje,eeting}s,
> 
> 						Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> 							    -- Linus Torvalds


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Sven Luther]

On Thu, Jun 05, 2003 at 09:59:47AM +0200, Benjamin Herrenschmidt wrote:
> On Wed, 2003-06-04 at 16:54, Sven Luther wrote:
> > Hello,
> > 
> > I finally have a working pegasos motherboard as well as a working kernel
> > with a 1.6 radeonfb. I have also installed Daniel Stone's X 4.3.0
> > debian/sid packages, and notice the following :
> > 
> >   1) radeonfb works fine in 8bpp and 32bpp but depth 15 and 16 only give
> >   me some very dark grey.
> 
> Can you try my devel tree version ?
> 
> (rsync.penguinppc.org::benh-devel)

Nope, it did fail with :

radeonfb.c: Dans la fonction « radeonfb_pci_register »:
radeonfb.c:1106: « FP2_GEN_CNTL » non déclaré (première utilisation dans cette fonction)
radeonfb.c:1106: (Chaque identificateur non déclaré est rapporté une seule fois
radeonfb.c:1106: pour chaque fonction dans laquelle il apparaît.)
radeonfb.c:1108: « TMDS_CNTL » non déclaré (première utilisation dans cette fonction)
radeonfb.c:1110: « DAC_CNTL2 » non déclaré (première utilisation dans cette fonction)
radeonfb.c: Dans la fonction « radeon_engine_init »:
radeonfb.c:1893: « DST_PITCH_OFFSET » non déclaré (première utilisation dans cette fonction)
radeonfb.c: Dans la fonction « radeon_setcolreg »:
radeonfb.c:2794: « DAC_CNTL2 » non déclaré (première utilisation dans cette fonction)
radeonfb.c:2795: « DAC2_PALETTE_ACCESS_CNTL » non déclaré (première utilisation dans cette fonction)
radeonfb.c: Dans la fonction « radeon_load_video_mode »:
radeonfb.c:3051: « NONSURF_AP1_SWP_16BPP » non déclaré (première utilisation dans cette fonction)
radeonfb.c:3056: « NONSURF_AP1_SWP_32BPP » non déclaré (première utilisation dans cette fonction)
radeonfb.c:3216: « TMDS_ICHCSEL » non déclaré (première utilisation dans cette fonction)

Altough i am not entirely sure which rsync tree i used, will check again
to make sure.

(Still confused about all the ppc kernel trees ...)

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: radeonfb on pegasos powerpc motherboard and X endianess problem

[Sven Luther]

On Tue, Jun 10, 2003 at 11:54:42AM +0200, Sven Luther wrote:
> On Thu, Jun 05, 2003 at 09:59:47AM +0200, Benjamin Herrenschmidt wrote:
> > On Wed, 2003-06-04 at 16:54, Sven Luther wrote:
> > > Hello,
> > > 
> > > I finally have a working pegasos motherboard as well as a working kernel
> > > with a 1.6 radeonfb. I have also installed Daniel Stone's X 4.3.0
> > > debian/sid packages, and notice the following :
> > > 
> > >   1) radeonfb works fine in 8bpp and 32bpp but depth 15 and 16 only give
> > >   me some very dark grey.
> > 
> > Can you try my devel tree version ?
> > 
> > (rsync.penguinppc.org::benh-devel)
> 
> Nope, it did fail with :
> 
> radeonfb.c: Dans la fonction « radeonfb_pci_register »:
> radeonfb.c:1106: « FP2_GEN_CNTL » non déclaré (première utilisation dans cette fonction)
> radeonfb.c:1106: (Chaque identificateur non déclaré est rapporté une seule fois
> radeonfb.c:1106: pour chaque fonction dans laquelle il apparaît.)
> radeonfb.c:1108: « TMDS_CNTL » non déclaré (première utilisation dans cette fonction)
> radeonfb.c:1110: « DAC_CNTL2 » non déclaré (première utilisation dans cette fonction)
> radeonfb.c: Dans la fonction « radeon_engine_init »:
> radeonfb.c:1893: « DST_PITCH_OFFSET » non déclaré (première utilisation dans cette fonction)
> radeonfb.c: Dans la fonction « radeon_setcolreg »:
> radeonfb.c:2794: « DAC_CNTL2 » non déclaré (première utilisation dans cette fonction)
> radeonfb.c:2795: « DAC2_PALETTE_ACCESS_CNTL » non déclaré (première utilisation dans cette fonction)
> radeonfb.c: Dans la fonction « radeon_load_video_mode »:
> radeonfb.c:3051: « NONSURF_AP1_SWP_16BPP » non déclaré (première utilisation dans cette fonction)
> radeonfb.c:3056: « NONSURF_AP1_SWP_32BPP » non déclaré (première utilisation dans cette fonction)
> radeonfb.c:3216: « TMDS_ICHCSEL » non déclaré (première utilisation dans cette fonction)
> 
> Altough i am not entirely sure which rsync tree i used, will check again
> to make sure.

No, it was not the right tree, now it builds, but with the following
warning :

gcc-3.2 -D__KERNEL__
-I/home/luther/pegasos/2.4.18-rc4/linuxpegasos/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common
-I/home/luther/pegasos/2.4.18-rc4/linuxpegasos/arch/ppc -fsigned-char
-msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring
-DKBUILD_BASENAME=radeonfb  -c -o radeonfb.o radeonfb.c
radeonfb.c:859: AVERTISSEMENT: « OUTMC » déclaré «static » mais n'a jamais été défiie
radeonfb.c:860: AVERTISSEMENT: « INMC » déclaré «static » mais n'a jamais été défiie
radeonfb.c:861: AVERTISSEMENT: « radeon_pm_disable_dynamic_mode » déclaré «static » mais n'a jamais été défiie
radeonfb.c:862: AVERTISSEMENT: « radeon_pm_enable_dynamic_mode » déclaré «static » mais n'a jamais été défiie
radeonfb.c:863: AVERTISSEMENT: « radeon_pm_yclk_mclk_sync » déclaré «static » mais n'a jamais été défiie
radeonfb.c:864: AVERTISSEMENT: « radeon_pm_program_mode_reg » déclaré «static » mais n'a jamais été défiie
radeonfb.c:865: AVERTISSEMENT: « radeon_pm_enable_dll » déclaré «static » mais n'a jamais été défiie
radeonfb.c:866: AVERTISSEMENT: « radeon_pm_full_reset_sdram » déclaré «static » mais n'a jamais été défiie

I suppose this is either harmless or due to the pegasos patch disabling
config_all_ppc or something such, will try it out, and look at it more
in detail this WE.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: X endianess problem

[Jochen Roth]

I just finished reading through the radeonfb/endianness thread. I am
working on an old IBM PReP thin client with an S3 Trio64V2/DX.

I started out with 2.4.19 from kernel.org and added startup code and
some patches for prep_pci.c etc. I am testing this under XFree86
4.1.0.1 with the fbdev module, current stable ppc off of debian.org.

I got the 16bit console stuff working by byte-swapping the packed
rgb words in the _setcolreg handler. Same code basically as in the
clgenfb.c, for instance.

Neither X nor fbi get the byte order right, though. I tried both the
0, 5, 10 and the 8, -3, 2 offsets for 5:5:5, and the equialents for
5:6:5 as well. (I understand the -3 conceptually, but I need to look
at the source for the library fbi uses.)

BTW, here is what happens after startx (xinit):
...
s3triofb_op_set_var con=6 1024x768-1024x768-16bpp mode=22271 56 8\
 41 0 176 8 -- act=2
fb_mmap() enter
fb_mmap() success
s3triofb_op_set_var con=6 1024x768-1024x768-16bpp mode=15385 160\
 24 29 3 136 6 AT act=0
...

The 22271 ps mode must get set by XFree, or it is the default for a
new VT. Then comes the mmap, followed by the proper mode switch -- this
order is not really safe, I would think.

BTW, based on my debug output X never turns off the accelerator. Is
that OK?

The hardware documentation for my chip says that there is supposed to
be an endian-swapped mapping for the frame buffer, essentially the
second 32MB of the 64MB total bar0. As far as I can tell this second
mapping does not byte-swap the video buffer.

Any suggestions on how best to proceed are greatly appreciated.

Jochen



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.

Re: X endianess problem

[Michel Dänzer]

On Tue, 2003-06-10 at 13:04, Jochen Roth wrote: 
> I just finished reading through the radeonfb/endianness thread. I am
> working on an old IBM PReP thin client with an S3 Trio64V2/DX.
> 
> I started out with 2.4.19 from kernel.org and added startup code and
> some patches for prep_pci.c etc. I am testing this under XFree86
> 4.1.0.1 with the fbdev module, current stable ppc off of debian.org.
> 
> I got the 16bit console stuff working by byte-swapping the packed
> rgb words in the _setcolreg handler. Same code basically as in the
> clgenfb.c, for instance.
> 
> Neither X nor fbi get the byte order right, though.

I think they just assume native byte order.


> BTW, based on my debug output X never turns off the accelerator. Is
> that OK?

fbdevHWMapMMIO() in 4.3.0 seems to disable it.


> The hardware documentation for my chip says that there is supposed to
> be an endian-swapped mapping for the frame buffer, essentially the
> second 32MB of the 64MB total bar0. As far as I can tell this second
> mapping does not byte-swap the video buffer.

Well, there's no single byte swapping working for all cases, maybe you
need to configure it by writing to some register(s)?

If there's indeed no way to have the hardware handle the byte order,
you'd probably have to fix each app. Should be relatively easy in the X
fbdev driver by using a special shadowUpdate function.


-- 
Earthling Michel Dänzer   \  Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast  \     http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: X endianess problem

[Jochen Roth]

> > Neither X nor fbi get the byte order right, though.
> 
> I think they just assume native byte order.

Yes -- Gerd Knorr set me straight on that one after I emailed him a
patch for fbi...

> > BTW, based on my debug output X never turns off the accelerator. Is
> > that OK?
> 
> fbdevHWMapMMIO() in 4.3.0 seems to disable it.

I will give that a try. I have not seen any negative side effects of
the accelerator being enabled, but it seems weird.

I also would have expected for the X server to just go and talk to
the fbdev kernel driver, instead of still mucking with the hardware
directly. At least the X server on exit at times seems to want to
reset my chip into 80x25 or 640x400 on occasion. Can't tell for sure,
my monitor does not digest the timing very well. I am fairly certain
that my driver does not do that, based on set_var() printks.

> > The hardware documentation for my chip says that there is supposed to
> > be an endian-swapped mapping for the frame buffer, essentially the
> > second 32MB of the 64MB total bar0. As far as I can tell this second
> > mapping does not byte-swap the video buffer.
> 
> Well, there's no single byte swapping working for all cases, maybe you
> need to configure it by writing to some register(s)?

Yes. I found the 2 bits 36 hours ago. X looks much nicer with BE pixels.

Thanks for your suggestions.

Jochen



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: X endianess problem

[Michel Dänzer]

On Fri, 2003-06-13 at 12:05, Jochen Roth wrote:
> 
> > > BTW, based on my debug output X never turns off the accelerator. Is
> > > that OK?
> > 
> > fbdevHWMapMMIO() in 4.3.0 seems to disable it.

Whoops, I just realize the fbdev driver doesn't use fbdevHWMapMMIO()...
maybe it's harmless to leave it enabled as long as you don't use the
accelerator yourself then.


> I also would have expected for the X server to just go and talk to
> the fbdev kernel driver, instead of still mucking with the hardware
> directly. 

That's the idea. The fbdev driver doesn't even know how to talk to any
hardware directly. On the other hand, the X server itself may still
insist on fiddling with things like the PCI config space, but I wouldn't
expect that to cause a mode change...


-- 
Earthling Michel Dänzer   \  Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast  \     http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5