ugfx linux framebuffer

[Sting]

I am having trouble getting the SDL2 board/driver to build so I thought I might just go to the framebuffer board.  I used the example Makefile and added the appropriate parts and it seems to build, doesn't complain about anything.  When I try to run it on the remote machine I get GDISP Framebuffer: Failed to set video mode.  i trued with sudo and still no result.  I can actually see the ioctl call where it fails, do I need to do something different?  

[Joel Bodenmann]

There's a lot of stuff that can go wrong with initializing the Linux framebuffer. The obvious stuff (that is also mentioned in the documentation) is that you lack permission to access the framebuffer device if running from user space or that the framebuffer devices is accessible through a different path than then two default ones in the Linux-Framebuffer board files. For the former, fix the permissions - for the latter, modify the framebuffer device path(s) in the board file as described in the wiki.

After that there's a lot more that can go wrong. The easiest and most efficient way of figuring out what's happening is to open the board file (the file /boards/base/Linux-Framebuffer/board_framebuffer.h) and simply looking (CTRL+F) for the error message you are getting. For example, the one you are describing appears in line 102 and is related to changing the video properties. It's likely that your system doesn't allow doing that. As you can see there's a #define around that that allows to turn that off. The corresponding documentation/comment at the top of the file where the macro gets defined helps to understand what is going on.

I hope that helps you to get it working.
I'd like to explicitly note again that you cannot use the framebuffer driver if you are running a desktop environment on the same system. As far as I know (and I might be wrong) it is not possible to use the framebuffer while running an X server.

[inmarket]

Yes. The linux framebuffer is designed for situations where ugfx is the only application writing to the display (no X or other gui). It is ideal for embedded application situations where linux is the operating system but you want absolutely minimal disk footprint and minimal opportunity for the user to "get around" your provided gui. Eg Ctrl Shift Backspace will kill X and drop to a text command shell on most linux boxes with X.

 

[Sting]

Thats what I figured.  I rarely run the lightdm because it uses too many resources.  I did not know about Ctrl Shift Backspace, it doesn't work on the bbb anyway.  I usually just sudo chmod -x /usr/sbin/lightdm.

It looks like the sld driver doesn't work on the beaglebone so I have to find another test platform so I will have to get more serious about the framebuffer solution.

Thanks for your help.

[Sting]

I modified the board_framebuffer.h to write the errorno when the put failed.

if (ioctl(fb, FBIOPUT_VSCREENINFO, &fb_var) == -1 ){
	fprintf(stderr, "GDISP Framebuffer: Failed to put video mode: %d, %d\n", sizeof(fb_var), errno);
	exit(-1);
}
if (ioctl (fb, FBIOGET_VSCREENINFO, &fb_var) == -1) {
	fprintf(stderr, "GDISP Framebuffer: Failed to get video mode: %d\n", errno);
	exit(-1);
}

errno is 22, invalid argument.  so I thought maybe the wrong set of includes are being read.  in my makefile I have the INCPATH as 

INCPATH  = /usr/local/arm/arm-linux-gnueabihf/libc/usr/include

and when I make -n I see that this is the first entry on the compile line.  I can include this if it is interesting.  I ran the program and the same result, errno = 22;  I then removed the INCPATH from the makefile and it built with no trouble, no missing includes?  and when I ran the newly built program I get the same value for errno and the same size of the fb_var struct.  I looked at all of the elements of the compile include path and there is no file "linux/fb.h" to find when I remove my incpath from the makefile.
 

[inmarket]

If you are getting error 22 the most likely causes are:

1. Your kernel does not have a framebuffer driver installed. You may be able to recompile the kernel to include it or you may be able to load it dynamically.

2. Your kernel framebuffer does not support the video mode you are trying to set.

One of the easiest ways to test this is to add the flags to the linux kernel bootloader to start the kernel in graphics rather than text mode. Whatever video mode that ends up using set your ugfx parameters to match as the linux graphics boot internally uses the framebuffer driver.

[Joel Bodenmann]

Hello @Sting,

We worked a bit with the Linux framebuffer board ourselves yesterday and we found a bug that prevented using it on some systems. We fixed that bug now. You might want to retry using the framebuffer driver on your embedded Linux device.

 

[cchilumbu]

Hello Sting,

Did you resolve this issue? I am facing the same problem here.

Thanks.

[Joel Bodenmann]

Hello @cchilumbu and welcome to the µGFX community!

This topic is very old and there has been a lot of improvements in all corners of µGFX. Please make sure that you're using the latest master branch from the official git repository. If you keep having problems, please don't hesitate to open a dedicated forum topic to ask your questions. We're happy to help wherever we can