petan wrote:By my point of view (after all research), everybody who is coding FB graphic app for linux text mode must be familiar with this parts:
Also, after quick seeing on gfxlib linux source from posted link (THX for it !) seems, that /dev/fb0 MUST be ON for proper GFX job (even I am not C coder).
I didn't check if this relevant detail, IMHO, is written in GFX documentation, in case the gfxlib is OK.
The Linux Framebuffer (fbdev) is just one one graphics backend supported by FreeBasic's gfxlib2. Normally people use X11 as graphics backend so people don't have to care about all that stuff. If they use the framebuffer graphics (btw I don't like the term "text mode" for fbdev as it's all about graphic so "text mode" is IMHO an inappropriate term for it) people have to be familiar with that, but I wouldn't consider that abnormal. While probably most entries in your requirements list are probably not needed in most cases the remaining one describe just basic knowledge about the used graphics system (e.g. comparable to knowing how to change the display resolution / color depth in Windows if you'd use that).
/dev/fb0 is the default framebuffer device in the gfxlib2 implementation, but it can be overridden by setting an environment variable (see implementation for more detail). Of course the framebuffer device must be working to use the framebuffer as graphics backend :-)
I don't know whether there's any documentation about the different backends supported by gfxlib2 like DirectX and GDI on Windows or X11 and fbdev on Linux, but it would be definitely good to have one. Honestly I didn't know that gfxlib2 supports fbdev before this thread and was surprised that there's an implementation for that.
As far as we know (e.g. by writing urandom to fbdev or running the C program I posted earlier) the graphics hardware works correctly, so there's no need to run any program like lynx for additional testing. Btw I doubt that the other mentioned programs could use framebuffer graphics. (And again, framebuffer is about graphics, not a "text-mode").Tourist Trap wrote:I still don't understand why not launching some apps that would theorically try to display images even in text-mode. Why not testing osome:
Hopefully all of this will be just a switch to activate at boot sequence and a software designed for text-mode may be able to say something about this in its documentation or even as an error message.
Of course it's hard to say and we can only give an educated guess, but from Gablea's description the issue is probably a bug in gfxlib2. Still a configuration problem or even a bug in the framebuffer driver of the used Linux system are absolutely possible as well as many other reasons. The problem is that it's very hard to debug if we can't reproduce the issue.