Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So I have a Palm Pre (original P100EWW) model that I enabled developer mode on, and installed a Debian Squeeze chroot. Works great. I have plans to use this for ANYTHING (bittorrent peer, web server) but a phone.

I noticed if I do a cat /dev/urandom > /dev/fb0 it actually writes random pixels to the screen until a No space left on device error is generated. Awesome, now I can use the display.

So what kind of utilites are there that will either A) let me use /dev/fb0 as a console I can output text to or B) render text on /dev/fb0 from the command line.

I don't know about recompiling the kernel for this yet (I'd love to eventually strip WebOS off entirely and turn this into a minimal ARM server) so userspace tools if they exist is what I'm asking about. Also would prefer to render directly to /dev/fb0 and not use X.

share|improve this question
    
Linux virtual consoles should work over a framebuffer driver. Virtual consoles are a powerful tool; since Linux 2.6 they permit to set different fonts for each console. But they are controlled (from userspace) via /dev/vcs n and /dev/vcsa n, not /dev/fb0. – Incnis Mrsi Aug 16 '15 at 9:34
up vote 6 down vote accepted

To use the framebuffer as console you need the fbdev module. You may have to recompile your kernel.

You may also be interested in the DirectFB project, which is a library that makes using the framebuffer easier. There are also applications and GUI environments written for it already.

share|improve this answer
1  
Looks like when I installed Directfb (webos-internals.org/wiki/Directfb), it came with a utility called dfbg which lets me put a picture on there (and doesn't remove it upon completion like fbi). I know I can likely find a utility to create a .png or similar from a block text so this might just work... – LawrenceC Sep 11 '11 at 1:57

Several people have answered the parts of your question dealing with the kernel and putting images (rather than text) onto the framebuffer, but so far the rest remains unaddressed. Yes, you can use the kernel virtual terminal subsystem to make a so-called framebuffer console. But there are several tools that allow you to use the framebuffer device to make user-space virtual terminals. These include:

  • zhcon (Debian) — a userspace virtual terminal geared towards handling CJK I/O far better than the kernel subsystem. Its particular strength is in handling ISO 2022 non-UTF encodings; its particular weakness is UTF encodings.
  • fbterm (Debian) — a userspace virtual terminal that has spawned several forks including jfbterm. It has a bunch of CJK input method plug-ins.
  • bogl-bterm (Debian) — a userspace virtual terminal that has spawned forks such as niterm.
  • Ali Gholami Rudi's fbpad — a minimalist userspace virtual terminal that has no dependencies on X libraries.
  • The console-terminal-emulator and console-fb-realizer tools in nosh — a userspace virtual terminal aimed at replicating Linux and FreeBSD/PC-BSD kernel virtual terminals. It too has no dependencies on X libraries.
  • kmscon — a userspace virtual terminal that is closely linked to the logind server in systemd and its notions of "seats".

Ali Gholami Rudi in particular has produced more than just a terminal emulator for framebuffer work. He also wrote a direct-to-framebuffer PDF viewer, VNC viewer, media player, and Quran reader.

A full side-by-side comparison is outwith the scope of this answer; but here are some points that are relevant to the question:

  • As noted, several of the user-space virtual terminal programs make use of X libraries for font handling, keyboard mapping, CJK input methods, and so forth. They are not X clients, but they have dependencies from X libraries. fbpad and the nosh tools by design do not make use of any X libraries.
  • The programs that use X libraries for font handling do of course use X fonts. The others make other arrangements.
    • bogl-bterm and fbpad both have their own idiosyncratic font formats. One converts BDF fonts to BOGL fonts with the bdftobogl tool; and one converts TTF to the "tinyfont" fonts that are used by fbpad with the ft2tf (Arch) tool.
    • The nosh console-fb-realizer tool uses the same "vt" fonts as the new FreeBSD 10.1 kernel virtual terminal subsystem does, and thus shares the FreeBSD font manipulation tool vtfontcvt for converting BDF fonts.
  • The programs that use X libraries use X keyboard mapping. As for the others:
    • The nosh tools have their own idiosyncratic keyboard map format, intended to provide a full ISO 9995-3 capable keyboard with the ISO "common" group 2. One converts BSD kbdmap files to this format with the console-convert-kbdmap tool. Again, these kbdmap files are the ones used with the FreeBSD/PC-BSD vt subsystem.
    • fbpad doesn't do its own keyboard mapping at all, and relies upon the presence of the kernel virtual terminal subsystem and its keyboard mapping mechanism for that.
  • There's some variance in invocation and required privileges:
    • zhcon, fbterm, bogl-bterm, fbpad, and kmscon work on the basis that the terminal emulator spawns the shell/login program on the terminal, directly, as a child process. They need superuser privileges in order to spawn login.
    • The nosh tools were designed to integrate with an existing /etc/ttys (BSD), /etc/inittab (Linux system 5 init), or other system, to which they leave the job of spawning getty/login/shell. console-fb-realizer only needs enough privileges to open the framebuffer and input event devices, which need not be superuser privileges, and to access the FIFOs and ordinary files maintained by console-terminal-emulator, which in turn doesn't need any special privileges at all.

All of these are terminal emulators of course. If you want to take the terminal emulation out and put text on the framebuffer more directly, you have some choices:

  • bogl-bterm is of course based upon Ben Pfaff's Ben's Own Graphics Library a framebuffer I/O library designed for use in system setup/rescue environments (and "for GUIs in PDAs"). You can of course write programs that use that directly.
  • For a halfway house between writing a program that makes use of a framebuffer library to do its own rendering and a program that spits out escape sequences to what it thinks is a terminal: The nosh user-space virtual terminal is modular, and splits apart into component pieces. One can simply not use console-terminal-emulator.

    console-fb-realizer uses a display file with a character cell array, like /dev/vcsa* but an ordinary file (not a character special device file) and with Unicode code points, ECMA-48 attributes, and 24-bit RGB colour. So one can run it up and just write character+attribute+colour directly into the character cell array file, letting console-fb-realizer do the font rendering to the framebuffer.

    As an aside: Observe that this is the opposite of integration with BRLTTY, which uses console-terminal-emulator but doesn't run console-fb-realizer.

share|improve this answer
    
This is an amazing answer. The Enlightenment libraries claim framebuffer support on a linux fbcon - depending on compile-time options‌​. This is also true of their dependent terminal emulator Terminology: Works directly in the linux framebuffer (fbcon). Other than terminology, I second the kmscon (and other work of David Herrmann's ) recommendation myself. – mikeserv Jan 3 '15 at 18:53

For the console side, you can echo stuff to /dev/console or you can use syslog, and depending on various other settings, it may show up on the console.

For images, I just tried catting a bmp file to fb0 and it actually worked! (sortof - multiple copies, smaller size)

I found a bmp-to-framebuffer program here. That should be a perfect example of the format the fb0 is expecting. There is also fbi, a program for writing directly to the frame buffer.

share|improve this answer
    
fbi allows me to put a picture on the screen, which is useful, but it clears the framebuffer once it exits. – LawrenceC Sep 11 '11 at 2:00

If you can cat /dev/urandom > /dev/fb0 and get random pixels on the screen, you have all you need. In my case I needed to dump some text info. I tested this in busybox and raspi, so it might work for you. The answer might be a little bit long, since if you don't use some console you will need to print the pixels of chars yourself. Luckily someone have done the hard job, so we just need to combine it.

In busybox or in your raspi you should have a fbset binary. This might help you to find out your settings as screen dimensions.

In my embedded looks like this:

~ # fbset

mode "480x272-1"
    # D: 0.104 MHz, H: 0.207 kHz, V: 0.657 Hz
    geometry 480 272 480 272 16
    timings 9600000 3 3 0 32 17 11
    accel false
    rgba 5/0,6/5,5/11,0/0
endmode

The important part here is the width 480 and heigh 272 pixels.

As you mentioned, you can fulfil the screen with cat /dev/urandom > /dev/fb0, and you can clear it with cat /dev/zeros > /dev/fb0.

Than clear your screen, we must assure you get the dimensions properly.

By chance my Busybox had a fbsplash binary that get as input a .ppm file.

Correct if I am wrong, but it seems that fb0 accepts this format. Taking a look on wikipedia - Portable_Anymap, there are several "subformats"... fbsplash uses a fancy one with color, and so on... but we want to be able to just print something readable. Lets use the P1 coded in ascii for the sake of simplicity. If we could print a vertical line, we would know our dimensions are correct. Lets try it:

A vertical line in a ppm type P1 should look like this:

P1
480 272
f 0 0 0 0 ... 0 
f 0 0 0 0 ... 0
... 
f 0 0 0 0 ... 0

So, there will be 272 lines, 959 chars wide. The documentation says it should be 1 instead of f... on busybox and raspi f was brighter.

It is important that you have no space after the 0's... This task can be a bit tedious... you better use a text editor that helps you. In vim, you can copy the first two lines, go to command mode (esc), than type the following chars:

of(esc)479a 0(esc)yy271p

Of course, I am using my dimensions, you should use yours. Cat this file to /dev/fb0, it should looks like: enter image description here

Ok, I am cheating... it is not just one line there... its about 8... but when it does not work (we have wrong dimensions or we have space at the end, to have just one line is much easier).

If you got that far, we have just to print the right pixels to see as chars. Thanks to Marcel Sondaar we won't need to draw each char:

https:// github.com / dhepper / font8x8

With a small tweak one expand his simple program to print f instead of X and 0 instead of spaces, insert spaces between each char, add the header and we have a .ppm file with the letter corresponding its charcode.

One small step further and you don't get a char as input, but a line. Cat a file, pipe to your program and output to /dev/fb0 and you get a text output:

enter image description here

I test this solution also on a raspberry pi and it worked. The system tells me I don't have reputation to post more than 2 links. Until I get this, you must rely on my word :D

share|improve this answer

It's an old post but I understand normally you need framebuffer console (fbcon) to run console on framebuffer. It's in the configuration. (device drivers/graphics/console display..)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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