Keep in mind that /dev/fb, on a modern system, isn't an actual framebuffer on your GPU. It's a land of make-believe, mostly supported to get the kernel console ("fbcon") working. Going back for at least 10 years, the kernel mode-setting API (KMS) is used to display buffers, and there's compatibility code which sets up a user-space buffer in the KMS subsystem [0] which is swapped to when fbcon happens through a large chain of strange events that are hard to describe. This explains why you can't write to a /dev/fb during an active X11 session and have it show up: it's a fake buffer that only shows up when KMS isn't in use.<p>[0] <a href="https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_fb_helper.c" rel="nofollow">https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...</a>
The reason why sudo wasn't working is that it runs the command with root privileges, but redirecting to a file with > is done through the shell, which is running under your normal user level privileges. If you want to redirect to a file that only root can write to, you can use the tee command. That command will write anything passed to it via stdin to the file given as an arg.<p>For example, echo "foo" | sudo tee /path/to/file<p>or any of the other ways listed here: <a href="https://stackoverflow.com/questions/82256/how-do-i-use-sudo-to-redirect-output-to-a-location-i-dont-have-permission-to-wr" rel="nofollow">https://stackoverflow.com/questions/82256/how-do-i-use-sudo-...</a>
> one horizontal line at a time, with one byte for Blue,Green,Red,Alpha(?) per pixel (seems like 24-bit true color).<p>You can (and should if you are writing software not only for yourself) ask the kernel about the framebuffer layout using FBIOGET_FSCREENINFO and FBIOGET_VSCREENINFO ioctls.<p><a href="https://www.kernel.org/doc/Documentation/fb/api.txt" rel="nofollow">https://www.kernel.org/doc/Documentation/fb/api.txt</a>
There may be more than just one simultaneous framebuffer per display on the hardware level.<p>GPUs can actually scan to a display from <i>multiple overlapping framebuffers</i> in different resolutions and color formats <i>in the same time</i>. Alpha blending and rotations are often supported as well.<p>A bit like a very large mouse cursor. In a way, mouse cursors are also framebuffers. Or like hardware video layers in the nineties.
Worth noting that the framebuffer works really well on the Raspberry Pi; you can switch between console and X, all while using the framebuffer. It's even happy switching between bit depths (using 'fbset') at the same time.<p>If you want a really fast framebuffer system, get something like an old Nvidia 7600GT and use 'nvidiafb'; while this won't work with X at the same time, it's blazingly fast and gives brilliant console text output (modern GPUs are super-slow by comparison).
Is /dev/fb writing directly to the framebuffer or is there translation going on kernel side? Is the card in VESA / BIOS mode when on a virtual console without X?
I have a feeling that framebuffer must be something very slow. When I used both Windows and Linux without proprietary drivers for a video card (so they use some generic VGA or VESA driver), GUI would be slower. For example, scrolling in a window was laggy. Or dragging a window around the screen. Why it could be so? Do video card vendors intentionally slow down video memory access or is VGA or VESA some poorly designed standard?<p>I was not using Compiz or something like this so it cannot be explained with the lack of 3D acceleration.<p>Also, with generic VGA driver you cannot have 100Hz frame rate on high resolutions.
In DOS, in real mode, the framebuffer was just mapped directly into memory. If you wanted to put something on the screen, you wrote to that memory address (often segment A000). For text modes, you would write ASCII characters straight into the buffer. For bitmap modes, your bytes would be interpreted as colors (or shades of gray, depending on the mode.) It was very exciting when I figured out how to use extended memory to draw high-resolution (640x480) graphics.
Brings back memories. When I started coding graphical applications, writing directly to the graphic card's memory was the only way I understood. As I didn't know any better I had to recode stuff like line, circle and sprite drawing on my own. It was super slow but a very fun way to get into coding.<p>Maybe it's just me but I have the impression that drawing arbitrary things on screen has become harder since then.
I am trying to run as root user ::
cat /dev/graphics/fb0 in my android (oreo) phone. But showing 'No such device' error.
Could anyone guide me on how to make it work so that I could take screenshot directly and do some graphics stuff on my phone directly.
note: I don't know linux...<p>Is it possible to get the GPU to copy kernel / system memory to the framebuffer, then read that back with user space app? I.e. can we convince the GPU or framebuffer to give us the contents of protected system memory?
I have this C project based on CodingTrain videos that also ships an fbdev_runner: <a href="https://github.com/mar77i/cgbp" rel="nofollow">https://github.com/mar77i/cgbp</a>