Re: ggimesa
I've got glide/2d running under FB! :) [and yes ggi/glide target seems to work fine :] What is glide? I'm working on mesa/ggi, but after I make all in mesa. I cannot find any demo program built. When I make demo programs manually, I got many error messages about using X related funtion without linking related library. However, I'm not intended to use X. Which version of ggi do you use? Do you use kgi? Murphy
Re: ggimesa
On Wed, 26 Apr 2000, Murphy Chen wrote: I've got glide/2d running under FB! :) [and yes ggi/glide target seems to work fine :] What is glide? 3D acceleration library for 3Dfx graphics cards. The glide version I'm running is specifically for the 3Dfx/Banshee and 3Dfx/3 I'm working on mesa/ggi, but after I make all in mesa. I cannot find any demo program built. mesa root/ggi/demos (requires ggi/ggiglut) make 'gears' should work. When I make demo programs manually, I got many error messages about using X related funtion without linking related library. However, I'm not intended to use X. The demos are made to require libglut. Which is designed to work with X. Now ggiglut is a replacement for some programs - but a poor one. Which version of ggi do you use? current CVS. I keep up a lot. Do you use kgi? No. KGI doesn't support 3Dfx/Banshee. And isn't even potentially 3d-accelerated for my hardware in any event so it's uninteresting to me at this time. (now if I could convince Mesa that my glide didn't require X support, I'd be happier) G'day, eh? :) - Teunis
Re: GGI/FB PPC Crashes
Hi !
How did it look like ? Graphics garbge or text garbage ? I.e. simply colored
dots or strange colored characters ?
Starts off by displaying the text file catted to it, then in both cases at
the end of the file the screen has unending scrolling screens of characters
(unreadable) black and white. Mostly the solid block null character and
other strange ctl chars etc. Is this expected??
No. This is an indication of fb not working in graphics mode. If fb is in
graphics mode, you shouldn't get anything readable, but rather pixel
garbage.
You can see that a graphical fb console is running by looking at the cursor.
It should be a _block_, not an _underline_.
Don't worry stars definitely isn't going, (paradoxical statement), however I
tested demo instead and here is the debug output, looks like some infinite
looping to me. I pressed q to terminate out to a blank screen but there is
no associated debug info with this action.
Hmm - it repeats
LibGGI: display-fbdev: GGIdlcleanup start.
Terminating on signal 7
over and over ... This might well be a PPC specific problem, as signal 7 is
SIGBUS, which is generated on PPC when unaligned accesses are done.
Please use fbset to set a 32 bit wide mode and see if that helps.
For the others on the list - the relevant last few lines from the debug
trace are:
LibGGI: ggiSetMode: calling 0x162a4b4
LibGGI: ggiCheckMode(0x18158d8, 0x7fffea58) called
LibGGI: display-fbdev: checkmode 1024x768#1024x768F1[0x4000808]
LibGGI: display-fbdev: result 0 1024x768#1024x768F1[0x4000808]
LibGGI: display-fbdev: setmode 1024x768#1024x768F1[0x4000808]
LibGGI: display-fbdev: cannot get timing from /etc/fb.modes. Just hoping it
works.
LibGGI: display-fbdev: Change mode OK.
LibGGI: display-fbdev: frame_size=0xc fb_size=0xc
mmap_size=0x100
LibGGI: display-fbdev: FB_PTR=0x30027000
Terminating on signal 7
LibGGI: display-fbdev: GGIdlcleanup start.
I got to look in the sources where exactly it fails.
For smaller transmission size I deleted several thousand lines repeating on
the end despite the fact that the demo only ran/crashed for a few seconds..
obviously a pretty tight loop going on. Apparently my magic (SAK) key is not
actually working due to the fact the apple usb keyboard has a highly
non-standard configuration I have tried editing keyboard.h to no avail...
Did you make sure it isn't disabled by some nuts distribution script (Redhat
has these) on startup ?
Have a look at /proc/sys/kernel/sysrq. If it doesn't contain "1", you have
this problem.
Please run the "demo" demo and save away GGI_DEBUG%5 output (it comes out on
stderr, so use 2bla to redirect it to a file) and in another run strace
output (also on stderr) and send them along. Would give a clue where stuff
crashes.
Here is the strace output for demo, it end in a segmentation fault without
crashing the PPC (unlike actually running the demo) so obviously the program
behaves differently under strace.
execve("/home/davidc/cggi/degas/lib/libggi/programs/demos/.libs/lt-demo",
You got catched by a strangeness caused by libtool here. The programs it
generates are actually scripts that allow it to run without installing
first.
You have to "strace -f" them to really follow them.
I am now on the GGI developer mailing list so I will post further general
queries there.
Good. You will probably get this post twice, then, but so what - will
confirm the ML hookup works.
Hopefully you will have some ideas on how to fix this /dev/fb
GGI problem,
See above. I think there is still something wrong with the fb setup.
but let me no if you would rather I continue this thread on the
mailing list.
Please do so. Gives more people to think about your problem.
CU, ANdy
--
= Andreas Beck| Email : [EMAIL PROTECTED] =
Re: Memory Visual support?
I read the manual , it uses "display-visual" when opening the memory visual , however , in ggi_init , I see only string like "memory" , which one should I use? :) For programs: "display-*" - it is more specific and keeps room for future extensions. The shorter version is intended for commandline usage. And is there any constriants or differences using the ggi-frame-buffer visual and the memory one? The main ones are, that the memvisual isn't accelerated and it will accept about any mode. CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: Memory Visual support?
memory visual is for reading/writing to/from a memory block and treating it like a video display. frame-buffer visuals is for the core framebuffer driver support in systems such as linux. It's sometimes accelerated if the driver has been written for such (afaik Matrox cards). This is a kernel-level graphic driver. I'm not sure if the memory visual can be targetted at specific memory locations but both are intended for different purposes. though if I remember correctly, a memory visual could probably be used on an Amiga as a display window under some circumstances? :) Other than all of that, I'm not aware of any constraints on either barring that whatever mode the framebuffer is set to has to be valid for the driver it's talking to. ie: mine's only 640x480, all other modes on my card are corrupt or nonoperational for the framebuffer driver. On Wed, 26 Apr 2000, Eric , Yu-En Lue wrote: Hihi I read the manual , it uses "display-visual" when opening the memory visual , however , in ggi_init , I see only string like "memory" , which one should I use? :) And is there any constriants or differences using the ggi-frame-buffer visual and the memory one? thanks!
Re: GGI/FB PPC Crashes
Andreas Beck [EMAIL PROTECTED] writes: Don't worry stars definitely isn't going, (paradoxical statement), however I tested demo instead and here is the debug output, looks like some infinite looping to me. I pressed q to terminate out to a blank screen but there is no associated debug info with this action. Hmm - it repeats LibGGI: display-fbdev: GGIdlcleanup start. Terminating on signal 7 over and over ... This might well be a PPC specific problem, as signal 7 is SIGBUS, which is generated on PPC when unaligned accesses are done. Well, not really. All commonly used load/store instructions are emulated by the kernel for unaligned accesses, and LibGGI doesn't do unaligned accesses anyway. I believe this PPC problem was discussed here earlier. The problem is the dcbz (Data Cache Block Zero) instruction used by glibc memset(). dcbz doesn't work on un-cached regions. According to the manual it should be emulated properly by the OS in this case, but Linux doesn't do that. But even if this was fixed we shouldn't use memset() anyway, as the only reason we use it in the first place is performance. I'll try to fix this in a nice way this weekend. Please use fbset to set a 32 bit wide mode and see if that helps. For the others on the list - the relevant last few lines from the debug trace are: LibGGI: ggiSetMode: calling 0x162a4b4 LibGGI: ggiCheckMode(0x18158d8, 0x7fffea58) called LibGGI: display-fbdev: checkmode 1024x768#1024x768F1[0x4000808] LibGGI: display-fbdev: result 0 1024x768#1024x768F1[0x4000808] LibGGI: display-fbdev: setmode 1024x768#1024x768F1[0x4000808] LibGGI: display-fbdev: cannot get timing from /etc/fb.modes. Just hoping it works. LibGGI: display-fbdev: Change mode OK. LibGGI: display-fbdev: frame_size=0xc fb_size=0xc mmap_size=0x100 LibGGI: display-fbdev: FB_PTR=0x30027000 Terminating on signal 7 LibGGI: display-fbdev: GGIdlcleanup start. fbdev target tries to clear the framebuffer with memset. memset causes SIGBUS which is caught by our error handler, which tries to clean up after fbdev. Unfortunately part of the cleanup-process includes clearing the framebuffer, so we get a new SIGBUS. But as we already are in the SIGBUS handler the program will loop forever on the same dcbz instruction. Note that I've run LibGGI just fine on an embedded PPC card where the framebuffer is in main RAM, so there shouldn't be any other PPC problems than the dcbz in memset. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
RE: GGI/FB PPC Crashes
Thanks Marcus, Can you please let me know when you have fixed this. Regards, David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Marcus Sundberg Sent: Thursday, 27 April 2000 9:56 To: [EMAIL PROTECTED] Cc: David Craig Subject:Re: GGI/FB PPC Crashes Andreas Beck [EMAIL PROTECTED] writes: Don't worry stars definitely isn't going, (paradoxical statement), however I tested demo instead and here is the debug output, looks like some infinite looping to me. I pressed q to terminate out to a blank screen but there is no associated debug info with this action. Hmm - it repeats LibGGI: display-fbdev: GGIdlcleanup start. Terminating on signal 7 over and over ... This might well be a PPC specific problem, as signal 7 is SIGBUS, which is generated on PPC when unaligned accesses are done. Well, not really. All commonly used load/store instructions are emulated by the kernel for unaligned accesses, and LibGGI doesn't do unaligned accesses anyway. I believe this PPC problem was discussed here earlier. The problem is the dcbz (Data Cache Block Zero) instruction used by glibc memset(). dcbz doesn't work on un-cached regions. According to the manual it should be emulated properly by the OS in this case, but Linux doesn't do that. But even if this was fixed we shouldn't use memset() anyway, as the only reason we use it in the first place is performance. I'll try to fix this in a nice way this weekend. Please use fbset to set a 32 bit wide mode and see if that helps. For the others on the list - the relevant last few lines from the debug trace are: LibGGI: ggiSetMode: calling 0x162a4b4 LibGGI: ggiCheckMode(0x18158d8, 0x7fffea58) called LibGGI: display-fbdev: checkmode 1024x768#1024x768F1[0x4000808] LibGGI: display-fbdev: result 0 1024x768#1024x768F1[0x4000808] LibGGI: display-fbdev: setmode 1024x768#1024x768F1[0x4000808] LibGGI: display-fbdev: cannot get timing from /etc/fb.modes. Just hoping it works. LibGGI: display-fbdev: Change mode OK. LibGGI: display-fbdev: frame_size=0xc fb_size=0xc mmap_size=0x100 LibGGI: display-fbdev: FB_PTR=0x30027000 Terminating on signal 7 LibGGI: display-fbdev: GGIdlcleanup start. fbdev target tries to clear the framebuffer with memset. memset causes SIGBUS which is caught by our error handler, which tries to clean up after fbdev. Unfortunately part of the cleanup-process includes clearing the framebuffer, so we get a new SIGBUS. But as we already are in the SIGBUS handler the program will loop forever on the same dcbz instruction. Note that I've run LibGGI just fine on an embedded PPC card where the framebuffer is in main RAM, so there shouldn't be any other PPC problems than the dcbz in memset. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: Some questions on LibXMI
On Mon, 24 Apr 2000, Jon M. Taylor wrote:
On Sat, 22 Apr 2000, Rodolphe Ortalo wrote:
Is it possible to have several miPaintedSet per ggi_visual_t ?
Sure, in fact miPaintedSets are not tied to any one ggi_visual at
present, although this may change in the future (see below).
Hmm... Okay. But then, in LiXMI API, most functions take two
parameters: the ggi_visual_t AND the miPaintedSet
(or the ggi_visual_t and the miGC - or miCanvas).
Would it be possible to clean up the API and use only a single object ?
From what I understand of XMI, and of your future plans, it seems to me
that 'drawing functions' should operate over a paintedSet in fact, no ?
Can't you get rid of the ggi_visual_t then, except for the
miCopyPaintedSetToCanvas ?
Well, I don't really mind in fact -- but the question rose in my mind
while I was wrapping up the LibXMI functions in LibGWT: I wondered if it
was really needed to do repeatedly things like:
void gwtmiDrawPoints(gwt_window_t win, miPaintedSet *paintedSet,
const miGC *pGC, miCoordMode mode,
int npts, const miPoint *pPts)
{
miDrawPoints(win-visual, paintedSet, pGC, mode, npts, pPts);
}
Only gwtmiCopyPaintedSetToCanvas actually required some 'real' work
(ie: clipping to the window visible region rectangles). Note that I don't
mind at all to do 'unreal' work: 'tis pretty easy... :-)
Just my 0.02
Rodolphe
BTW: I have a polygon in a window now :-)
