* Re: [pm2fb] update 990110 - first public release ;) [not found] <19990120120240.B2072@maxime.u-strasbg.fr> @ 1999-01-20 12:17 ` Geert Uytterhoeven 1999-01-20 12:34 ` Sven LUTHER 1999-01-20 12:35 ` Sven LUTHER 0 siblings, 2 replies; 9+ messages in thread From: Geert Uytterhoeven @ 1999-01-20 12:17 UTC (permalink / raw) To: luther Cc: Michel Daenzer, nardinoc, Linux/APUS, Linux/PPC Development, Linux Frame Buffer Device Development 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 ]] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [pm2fb] update 990110 - first public release ;) 1999-01-20 12:17 ` [pm2fb] update 990110 - first public release ;) Geert Uytterhoeven @ 1999-01-20 12:34 ` Sven LUTHER 1999-01-20 12:35 ` Sven LUTHER 1 sibling, 0 replies; 9+ messages in thread From: Sven LUTHER @ 1999-01-20 12:34 UTC (permalink / raw) To: Geert Uytterhoeven, luther Cc: Michel Daenzer, nardinoc, Linux/APUS, Linux/PPC Development, Linux Frame Buffer Device Development 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 ]] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [pm2fb] update 990110 - first public release ;) 1999-01-20 12:17 ` [pm2fb] update 990110 - first public release ;) Geert Uytterhoeven 1999-01-20 12:34 ` Sven LUTHER @ 1999-01-20 12:35 ` Sven LUTHER 1999-01-20 12:46 ` Geert Uytterhoeven 1 sibling, 1 reply; 9+ messages in thread From: Sven LUTHER @ 1999-01-20 12:35 UTC (permalink / raw) To: Geert Uytterhoeven, luther Cc: Michel Daenzer, nardinoc, Linux/APUS, Linux/PPC Development, Linux Frame Buffer Device Development 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 ]] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [pm2fb] update 990110 - first public release ;) 1999-01-20 12:35 ` Sven LUTHER @ 1999-01-20 12:46 ` Geert Uytterhoeven 1999-01-20 12:54 ` Sven LUTHER 0 siblings, 1 reply; 9+ messages in thread From: Geert Uytterhoeven @ 1999-01-20 12:46 UTC (permalink / raw) To: luther Cc: Michel Daenzer, nardinoc, Linux/APUS, Linux/PPC Development, Linux Frame Buffer Device Development 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 ]] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [pm2fb] update 990110 - first public release ;) 1999-01-20 12:46 ` Geert Uytterhoeven @ 1999-01-20 12:54 ` Sven LUTHER 1999-01-20 13:37 ` Geert Uytterhoeven 0 siblings, 1 reply; 9+ messages in thread From: Sven LUTHER @ 1999-01-20 12:54 UTC (permalink / raw) To: Geert Uytterhoeven, luther Cc: Michel Daenzer, nardinoc, Linux/APUS, Linux/PPC Development, Linux Frame Buffer Device Development 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 ]] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [pm2fb] update 990110 - first public release ;) 1999-01-20 12:54 ` Sven LUTHER @ 1999-01-20 13:37 ` Geert Uytterhoeven 1999-01-20 13:49 ` Sven LUTHER 0 siblings, 1 reply; 9+ messages in thread From: Geert Uytterhoeven @ 1999-01-20 13:37 UTC (permalink / raw) To: luther Cc: Michel Daenzer, nardinoc, Linux/APUS, Linux/PPC Development, Linux Frame Buffer Device Development 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 ]] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [pm2fb] update 990110 - first public release ;) 1999-01-20 13:37 ` Geert Uytterhoeven @ 1999-01-20 13:49 ` Sven LUTHER 1999-01-20 14:17 ` Geert Uytterhoeven 0 siblings, 1 reply; 9+ messages in thread From: Sven LUTHER @ 1999-01-20 13:49 UTC (permalink / raw) To: Geert Uytterhoeven, luther Cc: Michel Daenzer, nardinoc, Linux/APUS, Linux/PPC Development, Linux Frame Buffer Device Development 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 ]] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [pm2fb] update 990110 - first public release ;) 1999-01-20 13:49 ` Sven LUTHER @ 1999-01-20 14:17 ` Geert Uytterhoeven 1999-01-20 14:43 ` Sven LUTHER 0 siblings, 1 reply; 9+ messages in thread From: Geert Uytterhoeven @ 1999-01-20 14:17 UTC (permalink / raw) To: luther Cc: Michel Daenzer, nardinoc, Linux/APUS, Linux/PPC Development, Linux Frame Buffer Device Development 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 ]] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [pm2fb] update 990110 - first public release ;) 1999-01-20 14:17 ` Geert Uytterhoeven @ 1999-01-20 14:43 ` Sven LUTHER 0 siblings, 0 replies; 9+ messages in thread From: Sven LUTHER @ 1999-01-20 14:43 UTC (permalink / raw) To: Geert Uytterhoeven, luther Cc: Michel Daenzer, nardinoc, Linux/APUS, Linux/PPC Development, Linux Frame Buffer Device Development 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 ]] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1999-01-20 14:43 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <19990120120240.B2072@maxime.u-strasbg.fr>
1999-01-20 12:17 ` [pm2fb] update 990110 - first public release ;) Geert Uytterhoeven
1999-01-20 12:34 ` Sven LUTHER
1999-01-20 12:35 ` Sven LUTHER
1999-01-20 12:46 ` Geert Uytterhoeven
1999-01-20 12:54 ` Sven LUTHER
1999-01-20 13:37 ` Geert Uytterhoeven
1999-01-20 13:49 ` Sven LUTHER
1999-01-20 14:17 ` Geert Uytterhoeven
1999-01-20 14:43 ` Sven LUTHER
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).