How to draw the graph in framebuffer using c language..? How to draw the graph in framebuffer using c language..? linux linux

How to draw the graph in framebuffer using c language..?


Use open() on the right file in /dev (eg. /dev/fb0), then use mmap() to map it into memory. Manpages will help for these syscalls if you do not know how to use them.

Then there are some structures and constants for some ioctl()s in <linux/fb.h>. Like many kernel headers, you can learn a lot simply browsing the file.

Particularly interesting is the ioctl FBIOGET_VSCREENINFO with struct fb_var_screeninfo. Note this has xres, yres (resolution) and bits_per_pixel. Then there's FBIOGET_FSCREENINFO and struct fb_fix_screeninfo which has further information like type and line_length.

So a pixel at (x, y) might be at mmap_base_address + x * bits_per_pixel/8 + y * line_length. The exact format of the pixels will depend on the structures you retrieve via ioctl; it's your job to decide how to read/write them.

It's been a while since I've worked with this so I'm a bit hazy on more details..

Here's a quick and dirty code sample just to illustrate how it's done... I haven't tested this.

#include <sys/types.h>#include <sys/ioctl.h>#include <sys/mman.h>#include <linux/fb.h>#include <unistd.h>#include <fcntl.h>#include <stdio.h>int main(){   struct fb_var_screeninfo screen_info;   struct fb_fix_screeninfo fixed_info;   char *buffer = NULL;   size_t buflen;   int fd = -1;   int r = 1;   fd = open("/dev/fb0", O_RDWR);   if (fd >= 0)   {      if (!ioctl(fd, FBIOGET_VSCREENINFO, &screen_info) &&          !ioctl(fd, FBIOGET_FSCREENINFO, &fixed_info))      {         buflen = screen_info.yres_virtual * fixed_info.line_length;         buffer = mmap(NULL,                       buflen,                       PROT_READ|PROT_WRITE,                       MAP_SHARED,                       fd,                       0);         if (buffer != MAP_FAILED)         {            /*             * TODO: something interesting here.             * "buffer" now points to screen pixels.             * Each individual pixel might be at:             *    buffer + x * screen_info.bits_per_pixel/8             *           + y * fixed_info.line_length             * Then you can write pixels at locations such as that.             */             r = 0;   /* Indicate success */         }         else         {            perror("mmap");         }      }      else      {         perror("ioctl");      }   }   else   {      perror("open");   }   /*    * Clean up    */   if (buffer && buffer != MAP_FAILED)      munmap(buffer, buflen);   if (fd >= 0)      close(fd);   return r;}


As an alternative to asveikau's answer, you could use DirectFB, which may greatly simplify things for you.


From my Synaptic on Rasbian: "DirectFB is a graphics library which was designed with embedded systems in mind. It offers maximum hardware accelerated performance at a minimum of resource usage and overhead."

Anyway, I haven't seen this work in a frame buffer yet but I'm hoping it's like I do most of my graphics. You have some linear address space, height * width * bytes per pixel number of bytes. If you want to write to a particular x,y location, the position in that space is given by (y * width * bytes per pixel) + (x * 3). Colors are adjacent bytes RGB (usually) so that gets you the address of the red pixel, add 1 for green, 2 for blue. You malloc(height * width * bytes per pixel) an address space, write into it, then pick your choice of libpng, libjpeg, libtiff to write that buffer out to a file. If you want to put text in it too you have to roll your own, so I stole one from an old libgif. I've reached the age and experience level where it's easier to do it myself than learn how somebody else thought it should be done. My graphics come out like this:data taken as CSV from rtl_power

I've been trying to use a framebuffer as described at http://raspberrycompote.blogspot.com/2014/04/low-level-graphics-on-raspberry-pi.html but something is wrong. I'm on a Pi 3, it was probably written for a Pi 1 since it was 2014, not 2017 then. But the Pi is different than traditional framebuffers because the GPU runs the show. Use this method: http://elinux.org/RPi_Framebuffer