[HN Gopher] Writing to the Framebuffer
___________________________________________________________________
Writing to the Framebuffer
Author : p4bl0
Score : 112 points
Date : 2020-06-02 15:38 UTC (7 hours ago)
(HTM) web link (seenaburns.com)
(TXT) w3m dump (seenaburns.com)
| amelius wrote:
| Isn't the graphics pipeline a bit more sophisticated nowadays?
| I.e., you could render your framebuffer on the side of a rotating
| cube, let hardware render fonts, etc.
| tachyonbeam wrote:
| Sure it is, but sometimes it's fun to dive into lower level
| stuff. Program your own software rasterizer or GUI just to see
| how that kind of thing can be engineered. Plus, modern CPUs are
| so fast, you can actually do a lot, easily get interactive
| performances with just software rendering.
|
| Also, I would personally say that I feel modern APIs are
| getting a bit too complex. There's a lot of surface area and
| platform-specific details that you wish were portable but
| aren't and you unfortunately have to worry about. The amount of
| boilerplate code you need just to do a Hello World on something
| like Vulkan seems daunting. It's kind of nice to be able to
| build your own framework that you can completely wrap your head
| around and tailor to your own needs in every way. Then, all you
| need to worry about in terms of interfacing is how to display
| pixels at the other end.
| buzzert wrote:
| Writing directly to the frame buffer is effectively the "CPU
| rendering" or "software rendering" approach. Most modern GUIs
| use a compositor, which usually renders the contents of each
| window using the CPU to textures stored in VRAM. The GPU then
| does the actual rendering, sampling the textures drawn by the
| CPU (the windows) as it fills in the polygons, defined as sets
| of vertices also defined by the CPU.
| ablu wrote:
| My understanding was that fbdev is deprecated (but I was unable
| to find good info on this) and that one should use dumb buffers
| (https://manpages.debian.org/testing/libdrm-dev/drm-memory.7....)
| for this simple stuff / somewhat portable software rendering. At
| least Qt allows to do this for embedded devices without hardware
| rendering.
| Jasper_ wrote:
| Yes. fbdev is kept alive for compatibility (and fbcon) reasons,
| but it's a really outdated API and drivers have to jump through
| hoops to support it. Please use dumb buffers when necessary.
| See a simple example here: https://github.com/magcius/drmdemo
| joezydeco wrote:
| Embedded developers still need fbdev. There are lots of
| display-enabled SoCs that don't have or need a GPU.
| zozbot234 wrote:
| But even then, not every display-enabled SoC is well modeled
| as a dumb framebuffer. The Raspberry Pi itself provides
| hardware overlays, and it's quite problematic to expose them
| under that kind of model. The DRM infrastructure seems to be
| a lot more general and flexible.
| joezydeco wrote:
| I wouldn't recommend an RPi for product development. There
| are better SoCs, like i.MX, with documented graphics
| pipelines and graphic/video/camera overlays that are easy
| to use.
| m00dy wrote:
| I just remembered Matrix 1 and Neo's framebuffer got hacked
| during the night when he got invited to the rave party.
| JosephRedfern wrote:
| A while back, a bunch of android devices (mainly cheap ones, low
| end Huaweis etc) had world readable frame buffers. Meant that an
| unprivileged app could read and process /dev/fb0 and snoop on the
| display. Same was sometimes true for /dev/input/eventN ---
| allowed touch screen to be read from and written to.
| stefan_ wrote:
| At some point Samsung flagship phones had world-writable
| /dev/mem
| rbanffy wrote:
| I really think it's a shame the framebuffer console can't do
| proper bold, italics and underlines...
| fabiensanglard wrote:
| Anybody knows why sudo did not work?
| kkielhofner wrote:
| I noticed this a while ago. I've always assumed it's because
| the redirection is being performed by the current shell running
| as $USER and not the new process launched as root by sudo.
| stragies wrote:
| Permission problem for the redirection.
|
| From https://stackoverflow.com/a/82278/5208540 , here's how to
| "redirect with sudo":
|
| Use "| sudo tee /dev/fb0"
| thequux wrote:
| tee will also write to stdout, which can often mean that you
| get a bunch of binary gubbish splattered all over your
| terminal.
|
| I recommend instead using "|sudo dd of=/dev/fb0", or, if you
| have moreutils installed, "|sudo sponge /dev/fb0"
| hackmiester wrote:
| But 'sponge' will put it all in RAM, so that's not ideal
| either. Lots of pitfalls here, wow.
| rbanffy wrote:
| Shouldn't `| sudo cat > /dev/fb0` work?
| megous wrote:
| Redirect to a file is done by the shell, not by sudo process.
|
| It even tells you that: > -bash: /dev/fb0:
| Permission denied ^^^^^
| drewbug wrote:
| it only runs `cat` as root, not the write operation
| doublej472 wrote:
| This will only run `cat /dev/urandom` as root, while the
| redirection is run as a normal user:
|
| sudo cat /dev/urandom > /dev/fb0
|
| This should work just fine (with a /dev/null redirection so
| your terminal doesn't get garbled):
|
| cat /dev/urandom | sudo tee /dev/fb0 > /dev/null
| OskarS wrote:
| When I encounter this limitation and can not quite remember
| the correct incantation to solve it, I usually do something
| like this in frustration: echo "cat
| /dev/urandom > /dev/fb0" | sudo sh
|
| I was quite proud of myself the first time I figured that out
| many years ago :)
| ChristianBundy wrote:
| Alternatively: sudo sh -c "cat
| /dev/urandom > /dev/fb0"
| nemothekid wrote:
| > _Another answer I found said no modern operating system will
| let you access the framebuffer directly. BUT LUCKILY THAT'S
| WRONG._
|
| I don't know why this works for OP, but my understanding is that
| the original assertion is true. Writing/Reading directly from fb0
| does not work on my machine.
| karatinversion wrote:
| Did you try what OP did to fix this for himself - i.e.
|
| > sudo adduser seena video
| amelius wrote:
| How do you select the video mode? (i.e. resolution, refreshrate,
| bits-per-pixel, etc.)
| zlynx wrote:
| https://stackoverflow.com/questions/34904763/linux-framebuff...
|
| And https://www.kernel.org/doc/html/v4.15/gpu/drm-kms.html
| prashnts wrote:
| (Not parent) Thanks! I needed this a while back for a bodge.
| Ended up stashing it, but this will help a lot!
| wmf wrote:
| The kernel modesetting (KMS) API.
| whalesalad wrote:
| This is such a cool blog post, and has pulled the covers back on
| something I have been curious about for some time.
|
| Makes me wonder why more people aren't abusing this. I can see
| the gold, silver and platinum level open source sponsors shoving
| some big logos down your throat by writing directly to the
| framebuffer during your next yarn add.
|
| (I realize it is more nuanced than that, since it requires
| elevated priviliges to write to the device ... but hey how many
| sudo curl bash scripts have you seen out there in the wild? time
| to pwn the framebuffer)
| bogwog wrote:
| You can't write to the framebuffer device while X11 is running
| because it will just get overwritten immediately. So that means
| you can only use it on a machine without a display server
| running. So... a web server maybe? Sure, but since _most_
| people use a web server by SSH 'ing into it, a program that
| writes to framebuffer devices is going to be useless, unless
| you have a physical display device connected to the server and
| want to display something on it remotely.
|
| So it's mostly a fun gimmick/curiosity. I wrote a realtime 3D
| rasterizer that renders to fbdev a while back. It was a fun
| project, but useless.
| grapeli23 wrote:
| Works even in JSlinux. https://bellard.org/jslinux/vm.html?ur
| l=buildroot-x86-xwin.c...
|
| Download old qemu. https://drive.google.com/file/d/1e6UJcTC9F
| fwO20xzvcasTToPoaT...
|
| Load into jslinux. And execute the following commands in
| xterm.
|
| gzip -dc qemu-0.9.1.tar.gz | tar xf - -C/
|
| mkdir /dev/shm && mount -t tmpfs tmpfs /dev/shm
|
| SDL_NOMOUSE=1 qemu -k en-us -m 4 pi.vfd
|
| Necessary condition, Xorg must work with the fbdev driver.
| jandrese wrote:
| One of the weird things is that writing to the framebuffer can
| be surprisingly slow. At least I've seen it in practice where a
| machine that can play a video just fine in X maxes out the CPU
| and drops frames when trying to write directly to the
| framebuffer. It seems like it should be the opposite and since
| it was just something I was trying out for fun I didn't dive
| too deeply into figuring out what was going on. It may have
| been something like X was using GPU accel or the video player
| was writing to the framebuffer in an inefficient way (one write
| call per pixel) or something.
| rowanG077 wrote:
| I believe most modern distributions have the framebuffer driver
| disabled. Embedded is an exception.
| sly010 wrote:
| Chances are you are running yarn in a virtual terminal (iterm,
| xterm, gterm, etc). The framebuffer device doesn't represent
| your terminal window, but your physical display output (sort
| of, nowadays the framebuffer itself is emulated).
___________________________________________________________________
(page generated 2020-06-02 23:00 UTC)