5 ms·

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 abus

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)

rowanG077 6y ago
I believe most modern distributions have the framebuffer driver disabled. Embedded is an exception.
bogwog 6y ago
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 6y ago
  Works even in JSlinux. https://bellard.org/jslinux/vm.html?url=buildroot-x86-xwin.cfg&graphic=1 https://bellard.org/jslinux/vm.html?url=buildroot-x86-xwin.c... Download old qemu. https://drive.google.com/file/d/1e6UJcTC9FfwO20xzvcasTToPoaTs9yr_/view?usp=sharing https://drive.google.com/file/d/1e6UJcTC9FfwO20xzvcasTToPoaT... 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.
- oldsklgdfth 6y ago
  You can login to a tty terminal and run your program that way. Ctrl + Alt + F1-F5 on linux.
- Jasper_ 6y ago
  > You can't write to the framebuffer device while X11 is running because it will just get overwritten immediately. You can't write to fbdev because that's not what X11 is using to display buffers to the screen, it uses the newer kernel mode-setting (KMS) API. It's only when you switch away to a VT that the "KMS master" drops its session, the kernel switches back to fbcon, and you can see the "raw fbdev" buffer again, which is usually a fake framebuffer. If you then write to the fbdev framebuffer, you'll see your changes, but fbcon will come in and overwrite them with the kernel console, unless you ioctl(KDSETMODE, KD_GRAPHICS); to turn off fbcon from drawing.
jandrese 6y ago
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.
- oldsklgdfth 6y ago
  That sounds a bit off to me. > writing to the framebuffer in an inefficient way Fun fact you can memory map /dev/fb0 and make changes to it directly. Decoding video frames is much more expensive, than rendering them. The source of the slowdown could be software decoding the video frame. Where the X video player might have been using a specialized chip for this, i.e. GPU or Intel graphics, depending on the setup.
- fl0wenol 6y ago
  For most video cards and driver combinations, the fbdev interface is an emulated, legacy interface. DRI and X have the intended fast path to the device, and you have to jump through some hoops to get to an API and handle that behaves like mmap'd /dev/fbX.
sly010 6y ago
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).

rowanG077 6y ago

I believe most modern distributions have the framebuffer driver disabled. Embedded is an exception.

bogwog 6y ago

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 6y ago
Works even in JSlinux. https://bellard.org/jslinux/vm.html?url=buildroot-x86-xwin.cfg&graphic=1 https://bellard.org/jslinux/vm.html?url=buildroot-x86-xwin.c... Download old qemu. https://drive.google.com/file/d/1e6UJcTC9FfwO20xzvcasTToPoaTs9yr_/view?usp=sharing https://drive.google.com/file/d/1e6UJcTC9FfwO20xzvcasTToPoaT... 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.
oldsklgdfth 6y ago
You can login to a tty terminal and run your program that way. Ctrl + Alt + F1-F5 on linux.
Jasper_ 6y ago
> You can't write to the framebuffer device while X11 is running because it will just get overwritten immediately. You can't write to fbdev because that's not what X11 is using to display buffers to the screen, it uses the newer kernel mode-setting (KMS) API. It's only when you switch away to a VT that the "KMS master" drops its session, the kernel switches back to fbcon, and you can see the "raw fbdev" buffer again, which is usually a fake framebuffer. If you then write to the fbdev framebuffer, you'll see your changes, but fbcon will come in and overwrite them with the kernel console, unless you ioctl(KDSETMODE, KD_GRAPHICS); to turn off fbcon from drawing.

jandrese 6y ago

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.

oldsklgdfth 6y ago
That sounds a bit off to me. > writing to the framebuffer in an inefficient way Fun fact you can memory map /dev/fb0 and make changes to it directly. Decoding video frames is much more expensive, than rendering them. The source of the slowdown could be software decoding the video frame. Where the X video player might have been using a specialized chip for this, i.e. GPU or Intel graphics, depending on the setup.
fl0wenol 6y ago
For most video cards and driver combinations, the fbdev interface is an emulated, legacy interface. DRI and X have the intended fast path to the device, and you have to jump through some hoops to get to an API and handle that behaves like mmap'd /dev/fbX.

sly010 6y ago

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).