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=0xc0000 fb_size=0xc0000
mmap_size=0x1000000
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 2>bla 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]> =
