On Thu, 2003-06-05 at 13:58, Sven Luther wrote:

On Thu, Jun 05, 2003 at 01:42:30PM +0200, Benjamin Herrenschmidt wrote:

quoted

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

quoted

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.