"FreeBASIC program in Linux text mode Error?

[caseih]

Galea did you ever compile your app with the -exx? That way the graphics library won't just fail silently, but hopefully offer an error message.

[dkl]

Seeing ScreenControl(fb.SET_DRIVER_NAME, "VESA") here, I checked GfxLib - apparently there is no such driver for Linux FB. But I think it will automatically fall back to one that works anyways.

[petan]

@caseih
That's mine crucial skills with programming in graphics mode in FB, for big stats&sports apps .
Without it - SURE troubles, you don't know WHY it's not working.
Similar when in sGUI code is omitted line INITgfx, you see on terrible result..

As I wrote I don't use console compiling, only full graphics; so it interest me if there are some functionality differences when compiled under different FB versions.
Is there visible window with picture ? This is base question to see properly working code!
If screen is blank/black/no decorations/no graphics/no window - we don't know at all what we are seeing on..
If screen 13 code works and screenres not !??, it's time to check this code on FB versions from 0.90.

@ Andy
What OS you have installed now ?
Note - by me the best way to check screen/screenres resolution & working graphics is to draw diagonal lightgreen line on dark blue background thru coordinates obtained via 'screeninfo'

[caseih]

@caseih
That's mine crucial skills with programming in graphics mode in FB, for big stats&sports apps .
Without it - SURE troubles, you don't know WHY it's not working.
Similar when in sGUI code is omitted line INITgfx, you see on terrible result..

I'm not understanding you. If you look at fbgfx.bi, you can see exactly what it has in it. Lots of constants, some user-defined types. I can understand why sGUI would require them, but in that case, sGUI's .bi files should include fbgfx if it's required. If your own code doesn't need the constants and UDTs, then you shouldn't need to include it in your own code.

As I wrote I don't use console compiling, only full graphics; so it interest me if there are some functionality differences when compiled under different FB versions.
Is there visible window with picture ? This is base question to see properly working code!
If screen is blank/black/no decorations/no graphics/no window - we don't know at all what we are seeing on..
If screen 13 code works and screenres not !??, it's time to check this code on FB versions from 0.90.

When using the frame buffer mode in Linux, the app should run full screen, with no visible windows. The problem is that unless you turn on all the runtime checking when you compile, if the frame buffer mode cannot initialize, FB's graphics runtime fails silently and reverts to text mode (IE the graphics commands simply do nothing). In Gabea's case it's not possible for any of us to tell which is happening, without replicating the exact circumstances (which I can't do on my end as my Linux installation doesn't support the framebuffer mode). And experience on MS Windows isn't applicable to this either.

I've tried to help diagnose the problem but unfortunately I think we've done about all we can. The real solution is to use an X Server as the framebuffer is depricated, but for whatever reason his USB input wedges don't work properly under X (which we have been unable to help him diagnose either). There's no reason I can think of for this not to work, but unless I can sit down with Gablea and watch what is happening and assist in the debugging steps I don't know what to recommend.

[petan]

@ caseih
1/ This gives error "aTestAndy.bas(2) error 41: Variable not declared, FB in 'ScreenRes 300,500,32,2,FB.GFX_windowed'"
rem #include "fbgfx.bi"
ScreenRes 300,500,32,2,FB.GFX_windowed


2/ This gives error "aTestAndy.bas(2) error 41: Variable not declared, GFX_windowed in 'ScreenRes 300,500,32,2,GFX_windowed'"
rem #include "fbgfx.bi"
ScreenRes 300,500,32,2,GFX_windowed

sothat, #include "fbgfx.bi" MUST BE included in testin code (as you can see, Andy uses GFX flags in his code !)

Code: Select all

#include "fbgfx.bi"
ScreenRes 300,500,32,,FB.GFX_windowed	
color rgb(0,255,255),rgb(128,0,0)
cls
line (0,0)-(300,500),
?:?:? ,"Hello"
sleep
end

(BTW, I got also black window when 32 bit color depth is omitted in screen/screenres)

s'shot on Slax 7, all is OK at me

[Gablea]

I am using Debian 7.9 now until I can sort this issue out with the text interface.

I do include the fbgfx.bi

I shall compile the program with the exx option when I get home tonight and let you all know the outcome.


UPDATE
I have downloaded 1.01 and installed that and also complied with the -exx tag same problem

i also have tried this code

Code: Select all

ScreenRes 800,600,32 
Print "Screen Set to 800x600"
color rgb(0,255,255),rgb(128,0,0)
cls
line (0,0)-(800,600), 
?:?:? ,"Hello"
sleep

and I get this screen

[St_W]

[...] #include "fbgfx.bi" MUST BE included in testin code (as you can see, Andy uses GFX flags in his code !)

fbgfx.bi only contains type and constant definitions like these ones, so it is only required if you want to use them. In general it is not required for FB graphics, as caseih already said.

@Gablea:
I doubt that -exx would help as it's probably either a configuration issue on your side (e.g. some default settings that changed in the new Debian version) or an internal implementation issue in gfxlib2. Trying different FB versions could help, but I doubt that it worked in previous versions of FB.
I'd suggest compiling a debug version of gfxlib2 and stepping through the graphics initialization using a debugger - that's quite easy to do. As well as that ensure that your framebuffer device exists AND is working, e.g. with a small example program in C:

Code: Select all

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>
#include <linux/fb.h>
#include <sys/mman.h>
#include <sys/ioctl.h>

int main()
{
	int fbfd = 0;
	struct fb_var_screeninfo vinfo;
	struct fb_fix_screeninfo finfo;
	long int screensize = 0;
	char *fbp = 0;
	long int location = 0;
	int x, y, xm, ym;

	// Open the file for reading and writing
	fbfd = open("/dev/fb0", O_RDWR);
	if (fbfd == -1) {
	 perror("Error: cannot open framebuffer device");
	 exit(1);
	}
	printf("The framebuffer device was opened successfully.\n");

	// Get fixed screen information
	if (ioctl(fbfd, FBIOGET_FSCREENINFO, &finfo) == -1) {
		perror("Error reading fixed information");
		exit(2);
	}

	// Get variable screen information
	if (ioctl(fbfd, FBIOGET_VSCREENINFO, &vinfo) == -1) {
		perror("Error reading variable information");
		exit(3);
	}

	printf("%dx%d, %dbpp\n", vinfo.xres, vinfo.yres, vinfo.bits_per_pixel);

	// Figure out the size of the screen in bytes
	screensize = vinfo.xres * vinfo.yres * vinfo.bits_per_pixel / 8;

	// Map the device to memory
	fbp = (char *)mmap(0, screensize, PROT_READ | PROT_WRITE, MAP_SHARED, fbfd, 0);
	if ((int)fbp == -1) {
		perror("Error: failed to map framebuffer device to memory");
		exit(4);
	}
	printf("The framebuffer device was mapped to memory successfully.\n");

	x = 0; y = 0;
	xm = vinfo.xres;
	ym = vinfo.yres;

	// Put the pixels in memory
	for (y=0; y < ym; y++) {
		for (x=0; x < xm; x++) {

			location = (x+vinfo.xoffset) * (vinfo.bits_per_pixel/8) + (y+vinfo.yoffset) * finfo.line_length;

			if (vinfo.bits_per_pixel == 32) {
				*(fbp + location) = 100;             // blue
				*(fbp + location + 1) = x*255/xm;    // green
				*(fbp + location + 2) = y*255/ym;    // red
				*(fbp + location + 3) = 0;      // No transparency
			} else  { //assume 16bpp
				int b = 10;
				int g = x*64/xm;
				int r = y*32/ym;
				unsigned short int t = r<<11 | g << 5 | b;
				*((unsigned short int*)(fbp + location)) = t;
			}

		}
	}
	munmap(fbp, screensize);
	close(fbfd);
	return 0;
}

That should fill your screen with a gradient. I've used (variations of) that code several times on different devices so I'm quite sure that it can tell you whether your framebuffer works.

[petan]

Good , and now try windowed code with GFX windowed flag and #include as I posted ;)
We will see if colors and graphics commands works as needed.

IIUC your boot was into the graphics, Xserver works, LXDE works.System OK.
What is physical screen resolution of your IBM Thinkpad notebook ? 800x600?
If yes, surely use smaller screenres to be visible created window, my 300x500 must be good.
My test from console and KDE on Slax works as expected, GFX flag no_frame works too.

[Gablea]

@petan
my IBM thinkpad is 1024x768 screen size

I have tried windows mode as well (inside the normal GUI desktop) and this works perfectly)

my problem is when it is in NON GUI mode (plan text mode no Desktop environment running) if you press ctrl + alt+ F2 you should see a tty screen this is where I test my program (as on the PoS it has only tty screen) (and ctrl + alt + F7 to return to the GUI desktop)

This is the print out of the ldd on my ./NPoS

• root@ibm-thinkpad:~/FreeBASIC/NPoS# ldd ./NPoS
  linux-gate.so.1 => (0xb777c000)
  libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb7632000)
  libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb7620000)
  libXpm.so.4 => /usr/lib/i386-linux-gnu/libXpm.so.4 (0xb760e000)
  libXrandr.so.2 => /usr/lib/i386-linux-gnu/libXrandr.so.2 (0xb7606000)
  libXrender.so.1 => /usr/lib/i386-linux-gnu/libXrender.so.1 (0xb75fc000)
  libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb75e3000)
  libmysqlclient.so.18 => /usr/lib/i386-linux-gnu/libmysqlclient.so.18 (0xb72bf000)
  libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xb729e000)
  libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb7278000)
  libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb7274000)
  libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb710c000)
  libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb70e9000)
  /lib/ld-linux.so.2 (0xb777d000)
  libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb70cf000)
  librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xb70c6000)
  libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb6fda000)
  libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6fbd000)
  libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb6fba000)
  libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb6fb3000)
  root@ibm-thinkpad:~/FreeBASIC/NPoS#

[caseih]

Any result with the C test program that St_W posted?

I do think trying -exx would be helpful because it will prevent the graphics library from failing silently if it's not initializing properly for some reason.

[Gablea]

I have done the test app and I get 16 columns of color and back on the screen in Non GUI mode

in GUI I get a message saying

The framebuffer device was opened Successfully.
1024x768 8bpp
The framebuffer device was mapped to memory successfully.

[caseih]

That's good news then. It means you are correct and that the framebuffer is working in Linux. So your hunch about something changing in the version of the FB compiler is probably correct. If you can identify which version of the compiler works and which does not, we can try to see what changed between them.

[St_W]

I have done the test app and I get 16 columns of color and back on the screen in Non GUI mode

in GUI I get a message saying

The framebuffer device was opened Successfully.
1024x768 8bpp
The framebuffer device was mapped to memory successfully.

Okay, the framebuffer device exists and is working, so we have to find the error in gfxlib2 or your program. The strange output of the testapp is a result of the 8bpp color depth, which is not supported by the little program.

Could you try whether that (FreeBasic) works:

Code: Select all

screenres 1024,768,8
print "test"
line (100,100)-(200,200),4,BF
sleep

[petan]

On Slax I am not able easily jump to text mode and back, nor install/test framebuffer driver, other things etc.
Dmesg report about no VESA framebuffer, /dev/fb0 missing; switching to text mode needs login and then typing 'startx' for return; memory is permanently blocked up&up.Best result after install some things is 8 colors text in text mode.Longer browsing the web goes to nowhere about framebuffer solid infos, obsolete links, deleted, missing files/drivers, stopped developing...Maybe built-in framebuffer support in linux kernel now ??Not good feeling..
Console color depth to 16/24 bit you can set in Grub/Lilo boot config file in "VGA=..." parameter, save/load screen shot you can do via 'shell cat ..' command to/from /dev/fb0.Too many problems to test/set.

Seems that searching for bug in Freebasic linux framebuffer driver as St_W said, is good idea.

[Gablea]

if it helps i can upload the source code to my server

I have tried that Program and nothing works in the text interface