Paint Pixels to Screen via Linux FrameBuffer
Asked Answered
T

7

43

I was recently struck by a curious idea to take input from /dev/urandom, convert relevant characters to random integers, and use those integers as the rgb/x-y values for pixels to paint onto the screen.

I've done some research (here on StackOverflow and elsewhere) and many suggest that you can simply write to /dev/fb0 directly as it is the file representation of the device. Unfortunately, this does not seem to produce any visually apparent results.

I found a sample C program that was from a QT tutorial (no longer available) that used an mmap to write to the buffer. The program runs successfully, but again, no output to the screen. Interestingly enough, when I placed my laptop into Suspend and later restored, I saw a momentary flash of the image (a red square) that was written to the framebuffer much earlier. Does writing to the framebuffer work anymore in Linux for painting to screen? Ideally, I'd like to write a (ba)sh script, but C or similar would work as well. Thanks!

EDIT: Here's the sample program...may look familiar to vets.

#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;
    int x = 0, y = 0;
    long int location = 0;

    // 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 = 100; y = 100;       // Where we are going to put the pixel

    // Figure out where in memory to put the pixel
    for (y = 100; y < 300; y++)
        for (x = 100; x < 300; 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;        // Some blue
                *(fbp + location + 1) = 15+(x-100)/2;     // A little green
                *(fbp + location + 2) = 200-(y-100)/5;    // A lot of red
                *(fbp + location + 3) = 0;      // No transparency
        //location += 4;
            } else  { //assume 16bpp
                int b = 10;
                int g = (x-100)/6;     // A little green
                int r = 31-(y-100)/16;    // A lot of red
                unsigned short int t = r<<11 | g << 5 | b;
                *((unsigned short int*)(fbp + location)) = t;
            }

        }
    munmap(fbp, screensize);
    close(fbfd);
    return 0;
}
Thuggee answered 14/2, 2011 at 20:12 Comment(7)
Ideally, this needs to work for most (all?) Linux systems (DE independent) and other compatibility is appreciated but optional.Thuggee
The framebuffer device is often (but not always) independent of X - try switching to a virtual console with ctrl-alt-f1 or ctrl-alt-f2 and running the demo there.Crutcher
Interesting...that seems to work. Is there any possibility that I would be able to set the display as tty7 (X server)?Thuggee
Note, Wikipedia link[/link] mentions some programs that use the framebuffer directly, like MPlayer. How do they attach the output to the desktop environment?Thuggee
@RichardMartinez: As it says, "Graphic programs avoiding the heavy overhead of the X Window System." Those programs can access it directly when they're not running under X Windows (e.g. on an embedded device with an LCD screen), I think.Final
I tried your pogram on raspberry pi without X Server, and it works! Awesome.Stamm
This is a useful link, with code that works: (Game Of Life)(worked in AMD Ryzen4, Tuxedo Pulse) github.com/dranga/GOL-framebuffer/tree/… The code from the link above is originally based on: #4997277Griego
C
9

If you're running X11, you MUST go through X11 APIs to draw to the screen. Going around the X server is very broken (and, often as you've seen, does not work). It may also cause crashes, or just general display corruption.

If you want to be able to run everywhere (both console & under X), look at SDL or GGI. If you only care about X11, you can use GTK, QT, or even Xlib. There are many, many options...

Cordelier answered 14/2, 2011 at 21:13 Comment(1)
Thanks for the tip. Between this and caf's comment above, I've realized just how low-level the framebuffer is. I think I'll stick with it for simplicity for this script, but I will definitely be using higher level systems (at least X) if I'm interesting in something more complex.Thuggee
G
14

I've had success with the following few experiments.

First, find out if X is using TrueColor RGB padded to 32 bits (or just assume this is the case). Then find out if you have write permission to fb0 (and that it exists). If these are true (and I expect many modern toolkits/desktops/PCs might use these as defaults), then you should be able to do the following (and if these defaults don't hold, then you probably can still have some success with the following tests though the details may vary):

Test 1: open up a virtual terminal (in X) and type in: $ echo "ddd ... ddd" >/dev/fb0 where the ... is actually a few screen-fulls of d. The result will be one or more (partial) lines of gray across the top of your screen, depending on how long is your echo string and what pixel resolution you have enabled. You can also pick any letters (the ascii values are all less than 0x80, so the color produced will be a dark gray.. and vary the letters if you want something besides gray). Obviously, this can be generalized to a shell loop or you can cat a large file to see the effect more clearly: eg: $ cat /lib/libc.so.6 >/dev/fb0 in order to see the true colors of some fsf supporters ;-P

Don't worry if a large chunk of your screen gets written over. X still has control of the mouse pointer and still has its idea of where windows are mapped. All you have to do is to grab any window and drag it around a bit to erase the noise.

Test 2: cat /dev/fb0 > xxx then change the appearance of your desktop (eg, open new windows and close others). Finally, do the reverse: cat xxx > /dev/fb0 in order to get your old desktop back!

Ha, well, not quite. The image of your old desktop is an illusion, and you will quickly dispense with it when you open any window to full screen.

Test 3: Write a little app that grabs a prior dump of /dev/fb0 and modifies the colors of the pixels, eg, to remove the red component or augment the blue, or flip the red and green, etc. Then write back these pixels into a new file you can look at later via the simple shell approach of test 2. Also, note that you will likely be dealing with B-G-R-A 4-byte quantities per pixel. This means that you want to ignore every 4th byte and also treat the first in each set as the blue component. "ARGB" is big-endian, so if you visit these bytes through increasing index of a C array, blue would come first, then green, then red.. ie, B-G-R-A (not A-R-G-B).

Test 4: write an app in any language that loops at video speed sending a non square picture (think xeyes) to a part of the screen so as to create an animation without any windows borders. For extra points, have the animation move all over the screen. You will have to make sure to skip a large space after drawing a small row's worth of pixels (to make up for the screen width that is likely much wider than the picture being animated).

Test 5: play a trick on a friend, eg, extend test 4 so that a picture of an animated person appears to pop up on their desktop (maybe film yourself to get the pixel data), then walks over to one of their important desktop folders, picks up the folder and shreds it apart, then starts laughing hysterically, and then have a fireball come out and engulf their entire desktop. Though this will all be an illusion, they may freak out a bit.. but use that as a learning experience to show off Linux and open source and show how its much scarier looking to a novice than it actually is. [the "virus" are generally harmless illusions on Linux]

Gaynell answered 8/5, 2011 at 12:39 Comment(5)
1. I've never been able to affect X with the framebuffer. It only works in a TTY. 2. It's actually BGRT. You'll see it referenced if you pay notice to the kernel messages around the time it sets up the fb device during boot. I don't know what the T means, but it certainly isn't alpha or "transparency". In fact, the fourth byte doesn't seem to do anything at all. I've tried drawing colors with the fourth byte ranging from 0 to 255, and it looks exactly the same. I guess they're just saving a fourth channel in case aliens introduce us to new colors or something.Klan
Edit: Found out that the T in BGRT actually is transparency. Also confirmed straight from the horse's mouth that it's BGRT and not BGRA. Though I still can't get transparency to make anything, well, transparent.Klan
@B1KMusic AIUI you're not getting transparency because the frame buffer is the "backmost" thing. There is nothing "behind" it. T is just a dummy value for most devices. If you had a special framebuffer device talking to a screen that supports transparency/opacity (e.g. a TFT that can also generate white pixels, not just transparent ones that let the backlight shine through) you'd see an effect. Also, you're overwriting the backbuffer, so you're smashing any previous values and would have to account for Alpha yourself.Lecythus
Yep, trying to set 0x00 to 0xFF for the first byte is not magically going to set it to 0x77 if the fourth byte is 0x77, or whatever would be interpreted as 50%. I do seem to recall implementing some sort of algorithm to take two colors and an alpha value, and return the resulting color. I believe I found said algorithm, so here's a demo showing what I'm talking about.Klan
(@Lecythus that comment was directed at you)Klan
C
9

If you're running X11, you MUST go through X11 APIs to draw to the screen. Going around the X server is very broken (and, often as you've seen, does not work). It may also cause crashes, or just general display corruption.

If you want to be able to run everywhere (both console & under X), look at SDL or GGI. If you only care about X11, you can use GTK, QT, or even Xlib. There are many, many options...

Cordelier answered 14/2, 2011 at 21:13 Comment(1)
Thanks for the tip. Between this and caf's comment above, I've realized just how low-level the framebuffer is. I think I'll stick with it for simplicity for this script, but I will definitely be using higher level systems (at least X) if I'm interesting in something more complex.Thuggee
E
3

I'd say be careful before trying writing to /dev/fb0, as suggested above. I tried it under X in ubuntu 10.04 and a) nothing happened visually, b) it wrecked all shell windows, even other ttys, leading to kernel errors and lack of functionality.

Eulogium answered 28/6, 2012 at 17:6 Comment(2)
That's interesting. I've performed this (cat /dev/urandom > /dev/fb0) on a few different systems, and I typically get no output while on X but a cool screen full of random pixels if I'm on one of the virtual tty's. I'm surprised that something like that would ruin other parts of the OS, but maybe X freaked when it say stuff was drawn on screen already.Thuggee
As I understand, if X uses the framebuffer and KMS is used, writing random values to the graphics memory (/dev/fd0) is more likely to work than if X uses its own way of managing graphics.Avrom
C
1

I'm thinking of writing a framebuffer-based program, just because I need to be able to scroll (SDR waterfall). See https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=232493&p=1425567#p1425567 The scroll test I consider successful. In those 2 structs we fetch by ioctl for info there's also stuff about color depth. You seem to have based your program on the same example I did. How to get pixel colour from framebuffer on linux (Raspberry Pi)

Mine works fine on my Raspberry Pi, either with X or not. It has no effect on the screen on my laptop. That has a /dev/fb0, the program runs and the numbers look right, but it does nothing visually. Maybe it's double buffered or something.

Under X it doesn't actually do any damage. If you drag some windows around so things redraw everything comes back. Then I decided to back up what's on the screen and put it back when I was done, that works too. A window that I moved and put back works the same as if I'd never touched it. X doesn't realize I've messed with the screen buffer, it knows what it put there and registers mouse clicks accordingly. If I moved a window and didn't put it back the clicks would still work where it was.

Clasping answered 4/2, 2019 at 14:18 Comment(0)
I
0

You should use fb_fix_screeninfo.smem_len for screensize instead of doing the multiplication yourself. The buffer might be align on 4 bytes or something else.

screensize = finfo.smem_len;
Imaginable answered 11/1, 2016 at 22:17 Comment(0)
T
0

if you debug your program, you will find the line:

 screensize = vinfo.xres * vinfo.yres * vinfo.bits_per_pixel / 8;

screensize is 0. because vinfo.xres is 0. you should change it to:

long ppc_fx = (((long)fixed_info.smem_start) - ((long) fixed_info.smem_start & ~(PAGE_SIZE-1)));
screensize = finfo.smem_len + ppc_fx;

since Linux 2.6.2? , the 2nd arguments of mmap(), screensize, must not be 0. otherwise mmap() will return MAP_FAILED.

Twotime answered 12/6, 2016 at 16:39 Comment(0)
C
-1

When I used this program to write full screen it had crashed that is due screen size calculation is wrong.

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

This supposed to be:

/* Calculate the size of the screen in bytes */   
screensize = vinfo.xres_virtual * vinfo.yres_virtual * (vinfo.bits_per_pixel / 8);
Camelliacamelopard answered 23/5, 2014 at 9:6 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.