
Programming the Linux Framebuffer - mmphosis
https://cmcenroe.me/2018/01/30/fbclock.html
======
ComputerGuru
We had trouble getting Xorg to reliably work for all customers on a live cd
but after noting that the FreeBSD framebuffer always loaded and displayed info
OK and could even support different resolutions we wrote a solution that would
allow the frame buffer to serve as the x86/Xorg output device:
[https://github.com/neosmart/xf86-video-
scfb](https://github.com/neosmart/xf86-video-scfb)

Now all X-enabled windowing toolkits can use the rock-solid framebuffer
without modifications.

Linux's Xorg distribution already has a framebuffer driver for Xorg (or maybe
even two different ones) that ships with it, but we didn’t have the same
“works everywhere” experience we do with our custom solution (based off of
netBSD’s previous work), perhaps due to framebuffer bugs on Linux or maybe
something else entirely.

The drawback is that the higher the screen resolution (we weren’t happy with
800x600 due to LCD scaling blur from horrible on-controller scalers and
instead decode edid data from the monitor/adapter to find the native
resolution) the slower refreshes to the screen get. At high enough resolutions
there is a clear order of 10-100ms delay in updates.

------
megous
I'd say it's better to use DRM, it's more flexible, and you'll end up with
framebuffer in the end too. It will allow you to use different pixmap formats,
layers, double buffering, etc.

And even if you don't want GUI framework, and want to write your app
differently, you can start with cairo and pangocairo or something similar, so
that you don't have to care about low level drawing primitives.

~~~
zokier
Doesn't DRM take over the whole display, requiring you then to manage
delegating buffers to clients and essentially recreating Wayland?

Also, the whole clock is basically 100 lines of fairly straightforward code in
all its glory. How much would a DRM/Pango/Cairo soultion weight?

~~~
megous
My somewhat equivalent code for working with double-buffered version of
display code using DRM is about 200 lines of C. But that includes some
abstraction and a lot of error checking/logging.

I'm not sure why you'd need to replicate anything complicated like wayland.
You can use DRM API just like you'd use /dev/fb0, it just has more
options/features.

As for cairo, obviously it's a heavier solution, but also more featureful,
optimized and output neutral.

~~~
zokier
I guess the main question is can you simply overlay stuff on top of Linux
console (presumably fbcon) with DRM? That is kinda the key thing here, and the
examples I've seen have always just done full-screen stuff.

------
vesinisa
As a non-English speaker, my obvious question is how does the PSF2 format
encode fonts with more than 256 glyphs? How would one go about implementing
Unicode text rendering? Combine glyphs from multiple 8-bit codepages to get
the required characters?

Does the Linux system console support Unicode in the first place?

edit: the linked header file[1] explains that a single PSF2 can actually
encode any number of glyphs (not just 256), and additional meta-information
after the bitmaps spell out which Unicode code points OR combining character
sequences each bitmap corresponds to.

[1]:
[https://github.com/legionus/kbd/blob/master/src/psf.h](https://github.com/legionus/kbd/blob/master/src/psf.h)

~~~
jwilk
Linux console supports up to 512 glyphs and has only minimal Unicode support.

There are terminal emulators, such as fbterm or kmscon, that use framebuffer
and might have better Unicode support.

~~~
bringtheaction
kmscon looks pretty neat.

Anyone have any experience with it?

Was it easy to set up? Does it make for a comfortable environment? Is it
relatively easy to write your own applications that can output on top of the
frame buffer, e.g. if you are developing a game with OpenGL and want to
develop in this environment and to test your game from there as well?

------
contingencies
On Gentoo the font path is /usr/share/consolefonts/Lat2-Terminus16.psfu.gz

About the latency thing ... having recently switched back from OSX to Gentoo
as my laptop's native desktop, Linux is great. Latency on all operations even
in X11 are noticeably lower and more pleasant than even typing in iTerm2 on a
top end Macbook Pro, and root on ZFS is awesome :)

Primary issues with console are UTF-8 support and irritations around mode
setting, font resizing, and video chip (re-)initialization when booting and
coming to/from X11, since my laptop (Dell XPS15 9560) has two graphics chips
and they don't play perfectly nice together under many Linux kernel
configurations. Angband latency, though, is awesome :)

~~~
bitwize
Yes, X11 is very quick when you don't have compositing and special-effects
layers between the client window and the display. :) For best results use an
old-school, 90s style WM.

Enjoy it while it lasts; The Powers That Be (mainly Red Hat) have decided that
Wayland and compositing are the future.

------
mindleyhilner
Small typo:

    
    
        --- before      2018-01-31 17:12:13.626560688 -0800
        +++ after       2018-01-31 17:12:17.494580179 -0800
        @@ -1 +1 @@
        -uint32_t buf = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_SHARED, fb, 0);
        +uint32_t *buf = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_SHARED, fb, 0);

------
revelation
/dev/fb is a legacy interface that shouldn't be used.

~~~
floren
What's the new interface to the framebuffer? As someone who's actually used
/dev/fb (on Android devices), it's pretty damn easy, which makes it a great
baseline for getting some graphics on the screen.

~~~
revelation
The first thing, certainly on Android, is to forget the idea that there is one
framebuffer ;)

The current interface is DRM (drivers/gpu/drm) and there specifically, atomic
modesetting:

[https://lwn.net/Articles/653071/](https://lwn.net/Articles/653071/)

~~~
pjmlp
Regarding Android I am surprised it even worked, unless OP has rooted their
device or was using an old version.

Starting with Android N, Google has been locking down what is possible to do
via the NDK and apps can no longer directly read outside their own sandboxed
filesystem, so no /dev.

~~~
floren
This was back in 2011. We modified the init script to stop the zygote process
from launching, then used our own C code running as a normal Linux process to
work with /dev/fb. So yeah it was rooted and it was an old version, but we
were mostly outside of the Android ecosystem entirely.

~~~
pjmlp
I see, yep that way it surely worked. Thanks for jumping in.

------
vectorEQ
nice article this. :) thanks! been wanting to start on this for a little while
but didn't have time to research some basics, this sets up just nicely for
what i wanted to experiment with!

