Re: [pm2fb] update 990110 - first public release ;)

Re: [pm2fb] update 990110 - first public release ;)

[Geert Uytterhoeven]

On Wed, 20 Jan 1999, Sven LUTHER wrote:
> but then since i first booted in this mode, the bottom line of the
> screen don't get erased anymore, very anoying, particularly
> because it worked fine before.

I guess a problem with the clear_margins routine?

> also, Ilario and Geert, am i right in thinking that the pm2fb
> initialize the permedia2 chip correclty, and that, when trying to
> accelerate X i could use it directly, without having to do
> initialization.

Yes. The X server must not do video mode initialization, but call the frame
buffer device instead.

> also there is a whole part missing in the xfree pm2 accel servers,
> so i don't know if it would be a good idea to use them.
> 
> Ilario, you released the pm2 includes uinder the GPL to go into
> the kernel, is it ok to put them also in X ? 

I don't think that's a good idea: we want to be _integrated_ with XFree86, not
diverge from them. So IMHO we should use the XFree86 include definitions for
Permedia2.

BTW, Gerd Knorr added fbdev support to XF86_SVGA. Currently it supports Matrox
only (or no accel on other boards) in fbdev mode, but it's a good start.
Starting from that is probably the best way to have as much acceleration
support as possible. The unified XFree86 4.0 will be much more similar to the
current XF86_SVGA than to the other current accelerated servers like
XF86_{Mach64,S3,S3V}. Adding more accel code to XF68_FBDev is a waste of time.

Yes, I really should try to get XF86_SVGA working on my CHRP box. Once we have
it working for one chipset, the others should follow soon. XF86_SVGA does
support not only Permedia2, but also ATI Mach64, S3 Trio64 and S3 ViRGE.

The only things lacking in a fbdev'ed XF86_SVGA for us are the missing support
for Amiga and Atari bitplanes.

XF86_SVGA has another advantages for PPC: since it works on the `plain'
chipset, too, we can have a unified X server that uses fbdev where available,
and bangs the hardware completely where not (e.g. the PPC PReP boxes with S3 or
Cirrus Logic).

Sven: I'll forward Gerd's patches.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: [pm2fb] update 990110 - first public release ;)

[Sven LUTHER]

On Wed, Jan 20, 1999 at 01:17:16PM +0100, Geert Uytterhoeven wrote:
> On Wed, 20 Jan 1999, Sven LUTHER wrote:
> > but then since i first booted in this mode, the bottom line of the
> > screen don't get erased anymore, very anoying, particularly
> > because it worked fine before.
> 
> I guess a problem with the clear_margins routine?
> 
> > also, Ilario and Geert, am i right in thinking that the pm2fb
> > initialize the permedia2 chip correclty, and that, when trying to
> > accelerate X i could use it directly, without having to do
> > initialization.
> 
> Yes. The X server must not do video mode initialization, but call the frame
> buffer device instead.
> 
> > also there is a whole part missing in the xfree pm2 accel servers,
> > so i don't know if it would be a good idea to use them.
> > 
> > Ilario, you released the pm2 includes uinder the GPL to go into
> > the kernel, is it ok to put them also in X ? 
> 
> I don't think that's a good idea: we want to be _integrated_ with XFree86, not
> diverge from them. So IMHO we should use the XFree86 include definitions for
> Permedia2.

Yes, ... i guess you are right, ...

but half the stuff from hw/xfree86/accel/glint is missing, i am not even sure
you can build an accelerated server from the 3.3.3.1 source, i asked on the
xfree-glint list, but got no response yet, so ...

> 
> BTW, Gerd Knorr added fbdev support to XF86_SVGA. Currently it supports Matrox
> only (or no accel on other boards) in fbdev mode, but it's a good start.
> Starting from that is probably the best way to have as much acceleration
> support as possible. The unified XFree86 4.0 will be much more similar to the
> current XF86_SVGA than to the other current accelerated servers like
> XF86_{Mach64,S3,S3V}. Adding more accel code to XF68_FBDev is a waste of time.
> 
> Yes, I really should try to get XF86_SVGA working on my CHRP box. Once we have
> it working for one chipset, the others should follow soon. XF86_SVGA does
> support not only Permedia2, but also ATI Mach64, S3 Trio64 and S3 ViRGE.
> 
> The only things lacking in a fbdev'ed XF86_SVGA for us are the missing support
> for Amiga and Atari bitplanes.
> 
> XF86_SVGA has another advantages for PPC: since it works on the `plain'
> chipset, too, we can have a unified X server that uses fbdev where available,
> and bangs the hardware completely where not (e.g. the PPC PReP boxes with S3 or
> Cirrus Logic).
> 
> Sven: I'll forward Gerd's patches.

Does that mean that i could build a XF86_SVGA server that will work on with my bvision ?

but it still don't solve the problem of the missing glint stuff.

and playing with my stuff, will permit me to experiment, and later i can merge with the other stuff,
or maybee 4.0 (for when it is scheduled ?)

Friendly,

Sven LUTHER

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: [pm2fb] update 990110 - first public release ;)

[Sven LUTHER]

On Wed, Jan 20, 1999 at 01:17:16PM +0100, Geert Uytterhoeven wrote:
> On Wed, 20 Jan 1999, Sven LUTHER wrote:
> > but then since i first booted in this mode, the bottom line of the
> > screen don't get erased anymore, very anoying, particularly
> > because it worked fine before.
> 
> I guess a problem with the clear_margins routine?
> 
> > also, Ilario and Geert, am i right in thinking that the pm2fb
> > initialize the permedia2 chip correclty, and that, when trying to
> > accelerate X i could use it directly, without having to do
> > initialization.
> 
> Yes. The X server must not do video mode initialization, but call the frame
> buffer device instead.

what then is the stuff you initialize in the mach64 accel init stuff ?

Friendly,

Sven LUTHER

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: [pm2fb] update 990110 - first public release ;)

[Geert Uytterhoeven]

On Wed, 20 Jan 1999, Sven LUTHER wrote:
> On Wed, Jan 20, 1999 at 01:17:16PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 20 Jan 1999, Sven LUTHER wrote:
> > > but then since i first booted in this mode, the bottom line of the
> > > screen don't get erased anymore, very anoying, particularly
> > > because it worked fine before.
> > 
> > I guess a problem with the clear_margins routine?
> > 
> > > also, Ilario and Geert, am i right in thinking that the pm2fb
> > > initialize the permedia2 chip correclty, and that, when trying to
> > > accelerate X i could use it directly, without having to do
> > > initialization.
> > 
> > Yes. The X server must not do video mode initialization, but call the frame
> > buffer device instead.
> 
> what then is the stuff you initialize in the mach64 accel init stuff ?

Like you say, that's _accel_ _engine_ init stuff, not _graphics_ _engine_ init
stuff. The graphics engine takes care of the video mode (programmed in the
fbdev in the kernel), while the X server has to program the accel engine.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: [pm2fb] update 990110 - first public release ;)

[Sven LUTHER]

On Wed, Jan 20, 1999 at 01:46:05PM +0100, Geert Uytterhoeven wrote:
> On Wed, 20 Jan 1999, Sven LUTHER wrote:
> > On Wed, Jan 20, 1999 at 01:17:16PM +0100, Geert Uytterhoeven wrote:
> > > On Wed, 20 Jan 1999, Sven LUTHER wrote:
> > > > but then since i first booted in this mode, the bottom line of the
> > > > screen don't get erased anymore, very anoying, particularly
> > > > because it worked fine before.
> > > 
> > > I guess a problem with the clear_margins routine?
> > > 
> > > > also, Ilario and Geert, am i right in thinking that the pm2fb
> > > > initialize the permedia2 chip correclty, and that, when trying to
> > > > accelerate X i could use it directly, without having to do
> > > > initialization.
> > > 
> > > Yes. The X server must not do video mode initialization, but call the frame
> > > buffer device instead.
> > 
> > what then is the stuff you initialize in the mach64 accel init stuff ?
> 
> Like you say, that's _accel_ _engine_ init stuff, not _graphics_ _engine_ init
> stuff. The graphics engine takes care of the video mode (programmed in the
> fbdev in the kernel), while the X server has to program the accel engine.

in the case of the permedia 2, the engine is only one long pipeline, so the graphic and
accel engine are the same ?

but better would be to take another approach to my questions, ...

when are the init and renint function called ?

i guess init is the first time the Xserver is launched, and reinit is each time 
you return from some console switch ?

should we save the previous state and reset it on exiting X or something like that ?
Or will the fbdev driver automatically reinitialize the pm2 when you switch back to console mode ?

Friendly,

Sven LUTHER

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: [pm2fb] update 990110 - first public release ;)

[Geert Uytterhoeven]

On Wed, 20 Jan 1999, Sven LUTHER wrote:
> > > > Yes. The X server must not do video mode initialization, but call the frame
> > > > buffer device instead.
> > > 
> > > what then is the stuff you initialize in the mach64 accel init stuff ?
> > 
> > Like you say, that's _accel_ _engine_ init stuff, not _graphics_ _engine_ init
> > stuff. The graphics engine takes care of the video mode (programmed in the
> > fbdev in the kernel), while the X server has to program the accel engine.
> 
> in the case of the permedia 2, the engine is only one long pipeline, so the graphic and
> accel engine are the same ?

Are you sure about that?

> but better would be to take another approach to my questions, ...
> 
> when are the init and renint function called ?
> 
> i guess init is the first time the Xserver is launched, and reinit is each time 
> you return from some console switch ?

Right.

> should we save the previous state and reset it on exiting X or something like that ?
> Or will the fbdev driver automatically reinitialize the pm2 when you switch back to console mode ?

The X server may restore the video mode by calling the FBIOPUT_VSCREENINFO
ioctl with the `var' it got on startup.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: [pm2fb] update 990110 - first public release ;)

[Sven LUTHER]

On Wed, Jan 20, 1999 at 02:37:20PM +0100, Geert Uytterhoeven wrote:
> On Wed, 20 Jan 1999, Sven LUTHER wrote:
> > > > > Yes. The X server must not do video mode initialization, but call the frame
> > > > > buffer device instead.
> > > > 
> > > > what then is the stuff you initialize in the mach64 accel init stuff ?
> > > 
> > > Like you say, that's _accel_ _engine_ init stuff, not _graphics_ _engine_ init
> > > stuff. The graphics engine takes care of the video mode (programmed in the
> > > fbdev in the kernel), while the X server has to program the accel engine.
> > 
> > in the case of the permedia 2, the engine is only one long pipeline, so the graphic and
> > accel engine are the same ?
> 
> Are you sure about that?

I think yes, all units are in one pipeline, the same for 2D and 3D, and only this units are documented in
the TI docs, but then i guess by graphic engine you mean the one responsible for 
sending data to the monitor ? it is the last unit of the pipeline.

anyway, Ilario told me that he initialized everything nicely in the fbdev, that is, he 
switch off every unused part of the pipeline. 

i will have to switch on the part i will need ( altough for X accel, i guess it is only
the copy stuff that is really important, and they are already used in the fbdev driver
for console acceleration, so ...). or do i have to switch on this stuff only when doing the 
actual moves ?

> 
> > but better would be to take another approach to my questions, ...
> > 
> > when are the init and renint function called ?
> > 
> > i guess init is the first time the Xserver is launched, and reinit is each time 
> > you return from some console switch ?
> 
> Right.
> 
> > should we save the previous state and reset it on exiting X or something like that ?
> > Or will the fbdev driver automatically reinitialize the pm2 when you switch back to console mode ?
> 
> The X server may restore the video mode by calling the FBIOPUT_VSCREENINFO
> ioctl with the `var' it got on startup.
> 

but there is no accel specific stuff that get launched on exiting X, isnt'it, there is only the the init
function that get called when you go to X. I could, for starting, have a empty such function,
that is i just copy the info from the fbdev info structs to the glint_info structs, like
you do at the begining of the mach64 init functions ?

I will try to work on this this week end, and hope that i don't get the same problems as last time ...

Friendly,

Sven LUTHER

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: [pm2fb] update 990110 - first public release ;)

[Geert Uytterhoeven]

On Wed, 20 Jan 1999, Sven LUTHER wrote:
> On Wed, Jan 20, 1999 at 02:37:20PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 20 Jan 1999, Sven LUTHER wrote:
> > > > > > Yes. The X server must not do video mode initialization, but call the frame
> > > > > > buffer device instead.
> > > > > 
> > > > > what then is the stuff you initialize in the mach64 accel init stuff ?
> > > > 
> > > > Like you say, that's _accel_ _engine_ init stuff, not _graphics_ _engine_ init
> > > > stuff. The graphics engine takes care of the video mode (programmed in the
> > > > fbdev in the kernel), while the X server has to program the accel engine.
> > > 
> > > in the case of the permedia 2, the engine is only one long pipeline, so the graphic and
> > > accel engine are the same ?
> > 
> > Are you sure about that?
> 
> I think yes, all units are in one pipeline, the same for 2D and 3D, and only this units are documented in
> the TI docs, but then i guess by graphic engine you mean the one responsible for 
> sending data to the monitor ? it is the last unit of the pipeline.

I don't have the Permedia2 docs here, but I don't see any reason why the
graphics engine is supposed to be at the end of the pipeline. You don't change
the graphics engine configuration when drawing data, you have to initialize the
video mode (pixel clock, resolution, timings) only once.

> > The X server may restore the video mode by calling the FBIOPUT_VSCREENINFO
> > ioctl with the `var' it got on startup.
> 
> but there is no accel specific stuff that get launched on exiting X, isnt'it, there is only the the init

Not 100% true: the fbdev has to reinit the accel engine if it wants to use
accelerated fbcon-* routines for the text console.

> function that get called when you go to X. I could, for starting, have a empty such function,
> that is i just copy the info from the fbdev info structs to the glint_info structs, like
> you do at the begining of the mach64 init functions ?

Yes. But if you want to use the accel engine in X, you have to implement the
reinit function. Well, that's XF68_FBDev, XF86_SVGA automagically does this :-)

> I will try to work on this this week end, and hope that i don't get the same problems as last time ...

Good luck!

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: [pm2fb] update 990110 - first public release ;)

[Sven LUTHER]

On Wed, Jan 20, 1999 at 03:17:26PM +0100, Geert Uytterhoeven wrote:
> On Wed, 20 Jan 1999, Sven LUTHER wrote:
> > On Wed, Jan 20, 1999 at 02:37:20PM +0100, Geert Uytterhoeven wrote:
> > > On Wed, 20 Jan 1999, Sven LUTHER wrote:
> > > > > > > Yes. The X server must not do video mode initialization, but call the frame
> > > > > > > buffer device instead.
> > > > > > 
> > > > > > what then is the stuff you initialize in the mach64 accel init stuff ?
> > > > > 
> > > > > Like you say, that's _accel_ _engine_ init stuff, not _graphics_ _engine_ init
> > > > > stuff. The graphics engine takes care of the video mode (programmed in the
> > > > > fbdev in the kernel), while the X server has to program the accel engine.
> > > > 
> > > > in the case of the permedia 2, the engine is only one long pipeline, so the graphic and
> > > > accel engine are the same ?
> > > 
> > > Are you sure about that?
> > 
> > I think yes, all units are in one pipeline, the same for 2D and 3D, and only this units are documented in
> > the TI docs, but then i guess by graphic engine you mean the one responsible for 
> > sending data to the monitor ? it is the last unit of the pipeline.
> 
> I don't have the Permedia2 docs here, but I don't see any reason why the
> graphics engine is supposed to be at the end of the pipeline. You don't change
> the graphics engine configuration when drawing data, you have to initialize the
> video mode (pixel clock, resolution, timings) only once.

i guess we are not speaking about the same things then, ... i will have to look at the docs again.

> Yes. But if you want to use the accel engine in X, you have to implement the
> reinit function. Well, that's XF68_FBDev, XF86_SVGA automagically does this :-)

One more reason to go with XF86_SVGA, isn't it ?

Friendly,

Sven LUTHER

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]