I'm working in an embedded linux environment. I have a display setup with the linux framebuffer.

I can use the fbgrab to capture the contents of the framebuffer and store it in an image:

fbgrab myimage.png

I can use the fbv utility to set images to my screen:

fbv myimage.png

I can even write (raw) images directly to the framebuffer using :

 dd if=./myimage.raw of=/dev/fb0

However, if I launch :

[root@buildroot ~]# fbterm

It just sits there, does not exit. That's probably normal, however, I don't see anything come up on the display - and dumping the framebuffer contents again using fbgrab reveals nothing that looks like a terminal - it simply contains whatever it did before launching . In addition, no information is printed to the console.

Is this the expected behavior of when launching it directly from the console? Do I have to feed it more information or launch it in a different manner before I can view it on the display?

I've read many articles online about launching fbterm at startup - but I figured that I would need to get it to work at all before trying that?

In fact, I am not sure how to debug or troubleshoot the problem. I do not see any messages appear in the system logs when opening or closing . Any tips?

1 Answer 1


In order to use fbconsole, an input method must be set. As far as I could find the choices are between ucimfs, fcitx and ibus. From the man page the -v option can be used to show verbose information. More than this was hard to come by, and the project page is equally sparse from information, leaving the source code as the only option left.

The Linux Kernel has a frame buffer console that can be compiled in. If it is, con2fbmap is one tool that can be used to map a console to the frambuffer at runtime. Using this is probably a better solution.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.