12 ms·

Fui: C library for interacting with the framebuffer in a TTY context

164 points by Bhulapi 1y ago

ivanbelenky 1y ago
Awesome
mouse_ 1y ago
Don't type commands from the Internet, especially as root, especially when dd is involved. That being said, If you're ever bored, from a TTY, type sudo dd if=/dev/urandom of=/dev/fb0 This provides a nifty demonstration of how both the framebuffer and urandom works. you can also take a sort of "screenshot" in a tty by typing dd if=/dev/fb0 of=./shot.fb and then you can view it by flipping those filenames around, so that the shot.fb is now the input and /dev/fb0 is now the output.
- deleted 1y ago
  [deleted]
- Bhulapi 1y ago
  Writing urandom to the framebuffer is a joy in and of itself. You actually reminded me to have users add themselves to the video and input group (which does require root privileges usually), but this way they can then run the library without sudo.
  - Retr0id 1y ago
    IDK about the video group, but being a member of the input group is a bit of a security concern, since it allows the user to monitor all keyboard input system-wide and even inject their own input events. No big deal if you're playing with a raspberry pi, but not something you'd want to do on your workstation.
- ddingus 1y ago
  Tagged by comment to play a little later. Thanks!
markisus 1y ago
Can someone explain what “the framebuffer” is? I’m familiar with OpenGL programming where the OS can provide a framebuffer for an application but I’m confused about whether there is a global framebuffer for the entire desktop. Is this a Linux specific concept?
- Bhulapi 1y ago
  As far as I know, a framebuffer can mean a lot of things depending on hardware and implementation, but it was used to refer to actual memory that would contain pixel values that would eventually be written to the screen. In Linux, this is abstracted by the framebuffer device, which is hardware independent (you can actually have several fbdevices, which if I'm not mistaken end up referring to different monitors usually). What's convenient about the implementation is that these devices still work as normal memory devices, which means you can read/write as you would any other memory. Some more info: https://www.kernel.org/doc/html/latest/fb/framebuffer.html https://www.kernel.org/doc/html/latest/fb/framebuffer.html
  - fc417fc802 1y ago
    I'll preface this by saying that I may have some misconceptions. Other people much more knowledgeable than I am have posted summaries of how modern graphics hardware works on HN before. My understanding is that modern hardware is significantly more complicated at the lowest levels and (at least generally) no longer has a dedicated framebuffer (at least in the same sense that old hardware did). My understanding of the memory access provided by fbdev is that it's an extremely simple API. In other words an outdated abstraction that's still useful so it's kept around. An example of this complexity is video streams utilizing hardware accelerated decoding. Those often won't show up in screenshots, or if they do they might be out of sync or otherwise not quite what you saw on screen because the driver is attempting to construct a single cohesive snapshot for you where one never actually existed in the first place. If I got anything wrong please let me know. My familiarity generally stops at the level of the various cross platform APIs (opengl, vulkan, opencl, etc).
    - 1y ago
clbrmbr 1y ago
Awesome! Reminds me of the good old days of QuickBasic and SCREEN 13, when you could write very small programs with fullscreen graphics. I still have not figured out how to do fullscreen graphics on my Mac.
- Bhulapi 1y ago
  My first experience with programming was with QuickBasic. You just brought back some memories, wish I still had all of those old programs around.
- krackers 1y ago
  >how to do fullscreen graphics on my Mac You can't, you don't have direct access to the framebuffer. Unless by "fullscreen" you just mean spanning from end-to-end in which case you can create an opengl or metal view and just set the fullscreen style mask.
  - jebarker 1y ago
    > You can't, you don't have direct access to the framebuffer. Why is this the case? What would be the problem with allowing it?
    - krackers 1y ago
      It fits Apple's modus operandi to enforce things UI/UX wise, I assume in this case they don't want end-apps to be able to bypass the compositor (and e.g. prevent alerts from showing on the screen or whatnot). They used to allow it, but they removed the API after 10.6 https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/QuartzDisplayServicesConceptual/Articles/DisplayCapture.html https://developer.apple.com/library/archive/documentation/Gr... I guess on modern macOS CGDisplayCapture() is the closest example that still works (although clearly there is still some compositing going on since the orange-dot microphone indicator still appears, and you can get the dock to appear over it if you activate mission control. I'm guessing it does the equivalent of a full-screen window but then tries to lock input somehow).
actionfromafar 1y ago
Any license on this?
- Bhulapi 1y ago
  Added MIT license
nimish 1y ago
Interesting, I guess you could port LVGL to this and get a full GUI?
- Bhulapi 1y ago
  I think trying to use anything from LVGL in this project would reduce to essentially just using LVGL. It's more of a project to try and build most of the components from "scratch", i.e. use as few external libraries as possible.
cellis 1y ago
Super cool! Looks small enough to still be grokkable!
kristianp 1y ago
What does "in a TTY" context mean here? It doesn't mean in a terminal window, right?
- freeone3000 1y ago
  It does. Terminals, including without X, are frequently graphical devices, allowing for full-color graphics without needing Xlib or Wayland. This allows you to more easily manipulate that capability.
  - geon 1y ago
    On all OSes?
    - freeone3000 1y ago
      No, on linux.
- o11c 1y ago
  The terminology around this is really confusing, unfortunately. Sometimes a distinction is made between "TTY" (teletype, traditionally separate hardware, now built into the kernel, accessed by ctrl-alt-f1, at /dev/tty1 etc.) and "PTY" (pseudo-teletype, terminal emulator programs running under X11 etc., at /dev/pts/0 etc. nowadays. Confusingly, the traditional paths used /dev/ptyxx for masters and /dev/ttyxx for slaves, which is not the same as the tty-vs-pty distinction here.) "VT" or "virtual console" are unambiguous and more commonly used terms than "TTY" in this sense. Serial, Parallel, and USB terminals don't really fit into this distinction properly, even though they're close to the original definition of teletype they don't support VT APIs. There are many things the kernel provides in a real TTY (raw keyboard, beeper control, VCS[A] buffers, etc.). "The" framebuffer at /dev/fb0 etc. is usually swapped out when the TTY is (assuming proper keyboard/event handling, which is really icky), so it counts. Actually it's more complicated than "framebuffer" since X11/Wayland actually use newer abstractions that the framebuffer is now built on top of (if I understand correctly; I've only dabbled here). Note that there are 3 special devices the kernel provides: /dev/tty0 is a sort-of alias for whichever /dev/tty1 etc. is currently active. This is not necessarily the one the program was started on; getting that is very hacky. /dev/tty is a sort-of alias for the current program's controlling terminal (see credentials(7)), which might be a PTY or a TTY or none at all. /dev/console is where the kernel logs stuff and single-user logins are done, which by default is /dev/tty0 but you can pass console= multiple times (the last will be used in contexts where a single device is needed). This is probably wrong but hopefully informative.
speed_spread 1y ago
Are we TempleOS yet?
abnercoimbre 1y ago
It's so cool to see more terminal(-adjacent) experiments! We're overdue in evolving this space. Self-plug: last month I demoed [0] my own terminal. The goal is to dispense with traditional shells and see what happens. It generated quite a bit of hooplah, with a 50-50 split on how people felt about it. I'll keep an eye on Fui; might come in handy for future Linux builds. [0] https://terminal.click/posts/2025/04/the-wizard-and-his-shell/ https://terminal.click/posts/2025/04/the-wizard-and-his-shel...
- shlomo_z 1y ago
  your terminal looks cool!
- pjmlp 1y ago
  Depends, I for one, am quite happy no longer having to use a computer like in 1986 - 1990.
  - f1shy 1y ago
    There is a big difference between "having to" and "being able to" (if you want, like, find it convenient or feel so, for some use case) Anyway unless you were a happy Genera user at that time, I would like what terminal did you use then with color highlighting, dynamic feedback, auto completion, transparency and the other features...
    - pjmlp 1y ago
      I used what Timex 2068, MS-DOS 3.3 - 5.0, CP/M, allowed me to do, until I was freed into Windows 3.x and Amiga 500, in 1990. Until 2005, I also had to put up with using Xenix, DG/UX, Aix, Solaris, HP-UX, GNU/Linux via telnet as development servers. Thankfully by 1996, X Win32 and Hummingbird came to rescue as my X Windows servers of choice, when possible. As for all those features, you could already do most of them in 4DOS (1989). https://en.m.wikipedia.org/wiki/4DOS https://en.m.wikipedia.org/wiki/4DOS It is like asking me about electronic typewriter features, when the World has moved on into digital printing.
RetroTechie 1y ago
This kind of thing begs to be run bare metal (no Linux fbdev using modern 3D GPU with a complex driver stack under the hood). Or some small RTOS at most.
- queuebert 1y ago
  Wouldn't that amount to essentially writing a video card driver?
  - RetroTechie 1y ago
    Sure, but targeting hardware suited for this purpose. That is: hardware that does not come with complex 3D GPU. Only some framebuffer(s), and -perhaps- a basic 2D accelerator. Then a driver (if needed at all!), would be trivial, you could take Linux out of the equation & collapse the software stack into a tiny amount of code.
anthk 1y ago
Remember SVGAlib and libggi? Maybe FUI it's like the last one.
antirez 1y ago
Related, at a different layer of abstraction: Kitty graphical protocol, implemented also by Ghostty terminal emulator.
yazantapuz 1y ago
Very nice!!! It remains me of the old days with pascal and msdos writing into A000:0000 :)

164 points by Bhulapi 1y ago

Awesome

Don't type commands from the Internet, especially as root, especially when dd is involved. That being said, If you're ever bored, from a TTY, type sudo dd if=/dev/urandom of=/dev/fb0 This provides a nifty demonstration of how both the framebuffer and urandom works. you can also take a sort of "screenshot" in a tty by typing dd if=/dev/fb0 of=./shot.fb and then you can view it by flipping those filenames around, so that the shot.fb is now the input and /dev/fb0 is now the output.

deleted 1y ago
[deleted]
Bhulapi 1y ago
Writing urandom to the framebuffer is a joy in and of itself. You actually reminded me to have users add themselves to the video and input group (which does require root privileges usually), but this way they can then run the library without sudo.
- Retr0id 1y ago
  IDK about the video group, but being a member of the input group is a bit of a security concern, since it allows the user to monitor all keyboard input system-wide and even inject their own input events. No big deal if you're playing with a raspberry pi, but not something you'd want to do on your workstation.
ddingus 1y ago
Tagged by comment to play a little later. Thanks!

markisus 1y ago

Can someone explain what “the framebuffer” is? I’m familiar with OpenGL programming where the OS can provide a framebuffer for an application but I’m confused about whether there is a global framebuffer for the entire desktop. Is this a Linux specific concept?

Bhulapi 1y ago
As far as I know, a framebuffer can mean a lot of things depending on hardware and implementation, but it was used to refer to actual memory that would contain pixel values that would eventually be written to the screen. In Linux, this is abstracted by the framebuffer device, which is hardware independent (you can actually have several fbdevices, which if I'm not mistaken end up referring to different monitors usually). What's convenient about the implementation is that these devices still work as normal memory devices, which means you can read/write as you would any other memory. Some more info: https://www.kernel.org/doc/html/latest/fb/framebuffer.html https://www.kernel.org/doc/html/latest/fb/framebuffer.html
- fc417fc802 1y ago
  I'll preface this by saying that I may have some misconceptions. Other people much more knowledgeable than I am have posted summaries of how modern graphics hardware works on HN before. My understanding is that modern hardware is significantly more complicated at the lowest levels and (at least generally) no longer has a dedicated framebuffer (at least in the same sense that old hardware did). My understanding of the memory access provided by fbdev is that it's an extremely simple API. In other words an outdated abstraction that's still useful so it's kept around. An example of this complexity is video streams utilizing hardware accelerated decoding. Those often won't show up in screenshots, or if they do they might be out of sync or otherwise not quite what you saw on screen because the driver is attempting to construct a single cohesive snapshot for you where one never actually existed in the first place. If I got anything wrong please let me know. My familiarity generally stops at the level of the various cross platform APIs (opengl, vulkan, opencl, etc).
  - 1y ago

clbrmbr 1y ago

Awesome! Reminds me of the good old days of QuickBasic and SCREEN 13, when you could write very small programs with fullscreen graphics. I still have not figured out how to do fullscreen graphics on my Mac.

Bhulapi 1y ago
My first experience with programming was with QuickBasic. You just brought back some memories, wish I still had all of those old programs around.
krackers 1y ago
>how to do fullscreen graphics on my Mac You can't, you don't have direct access to the framebuffer. Unless by "fullscreen" you just mean spanning from end-to-end in which case you can create an opengl or metal view and just set the fullscreen style mask.
- jebarker 1y ago
  > You can't, you don't have direct access to the framebuffer. Why is this the case? What would be the problem with allowing it?
  - krackers 1y ago
    It fits Apple's modus operandi to enforce things UI/UX wise, I assume in this case they don't want end-apps to be able to bypass the compositor (and e.g. prevent alerts from showing on the screen or whatnot). They used to allow it, but they removed the API after 10.6 https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/QuartzDisplayServicesConceptual/Articles/DisplayCapture.html https://developer.apple.com/library/archive/documentation/Gr... I guess on modern macOS CGDisplayCapture() is the closest example that still works (although clearly there is still some compositing going on since the orange-dot microphone indicator still appears, and you can get the dock to appear over it if you activate mission control. I'm guessing it does the equivalent of a full-screen window but then tries to lock input somehow).

actionfromafar 1y ago

Any license on this?

Bhulapi 1y ago
Added MIT license

nimish 1y ago

Interesting, I guess you could port LVGL to this and get a full GUI?

Bhulapi 1y ago
I think trying to use anything from LVGL in this project would reduce to essentially just using LVGL. It's more of a project to try and build most of the components from "scratch", i.e. use as few external libraries as possible.

cellis 1y ago

Super cool! Looks small enough to still be grokkable!

kristianp 1y ago

What does "in a TTY" context mean here? It doesn't mean in a terminal window, right?

freeone3000 1y ago
It does. Terminals, including without X, are frequently graphical devices, allowing for full-color graphics without needing Xlib or Wayland. This allows you to more easily manipulate that capability.
- geon 1y ago
  On all OSes?
  - freeone3000 1y ago
    No, on linux.
o11c 1y ago
The terminology around this is really confusing, unfortunately. Sometimes a distinction is made between "TTY" (teletype, traditionally separate hardware, now built into the kernel, accessed by ctrl-alt-f1, at /dev/tty1 etc.) and "PTY" (pseudo-teletype, terminal emulator programs running under X11 etc., at /dev/pts/0 etc. nowadays. Confusingly, the traditional paths used /dev/ptyxx for masters and /dev/ttyxx for slaves, which is not the same as the tty-vs-pty distinction here.) "VT" or "virtual console" are unambiguous and more commonly used terms than "TTY" in this sense. Serial, Parallel, and USB terminals don't really fit into this distinction properly, even though they're close to the original definition of teletype they don't support VT APIs. There are many things the kernel provides in a real TTY (raw keyboard, beeper control, VCS[A] buffers, etc.). "The" framebuffer at /dev/fb0 etc. is usually swapped out when the TTY is (assuming proper keyboard/event handling, which is really icky), so it counts. Actually it's more complicated than "framebuffer" since X11/Wayland actually use newer abstractions that the framebuffer is now built on top of (if I understand correctly; I've only dabbled here). Note that there are 3 special devices the kernel provides: /dev/tty0 is a sort-of alias for whichever /dev/tty1 etc. is currently active. This is not necessarily the one the program was started on; getting that is very hacky. /dev/tty is a sort-of alias for the current program's controlling terminal (see credentials(7)), which might be a PTY or a TTY or none at all. /dev/console is where the kernel logs stuff and single-user logins are done, which by default is /dev/tty0 but you can pass console= multiple times (the last will be used in contexts where a single device is needed). This is probably wrong but hopefully informative.

speed_spread 1y ago

Are we TempleOS yet?

abnercoimbre 1y ago

It's so cool to see more terminal(-adjacent) experiments! We're overdue in evolving this space. Self-plug: last month I demoed [0] my own terminal. The goal is to dispense with traditional shells and see what happens. It generated quite a bit of hooplah, with a 50-50 split on how people felt about it. I'll keep an eye on Fui; might come in handy for future Linux builds. [0] https://terminal.click/posts/2025/04/the-wizard-and-his-shell/ https://terminal.click/posts/2025/04/the-wizard-and-his-shel...

shlomo_z 1y ago
your terminal looks cool!
pjmlp 1y ago
Depends, I for one, am quite happy no longer having to use a computer like in 1986 - 1990.
- f1shy 1y ago
  There is a big difference between "having to" and "being able to" (if you want, like, find it convenient or feel so, for some use case) Anyway unless you were a happy Genera user at that time, I would like what terminal did you use then with color highlighting, dynamic feedback, auto completion, transparency and the other features...
  - pjmlp 1y ago
    I used what Timex 2068, MS-DOS 3.3 - 5.0, CP/M, allowed me to do, until I was freed into Windows 3.x and Amiga 500, in 1990. Until 2005, I also had to put up with using Xenix, DG/UX, Aix, Solaris, HP-UX, GNU/Linux via telnet as development servers. Thankfully by 1996, X Win32 and Hummingbird came to rescue as my X Windows servers of choice, when possible. As for all those features, you could already do most of them in 4DOS (1989). https://en.m.wikipedia.org/wiki/4DOS https://en.m.wikipedia.org/wiki/4DOS It is like asking me about electronic typewriter features, when the World has moved on into digital printing.

RetroTechie 1y ago

This kind of thing begs to be run bare metal (no Linux fbdev using modern 3D GPU with a complex driver stack under the hood). Or some small RTOS at most.

queuebert 1y ago
Wouldn't that amount to essentially writing a video card driver?
- RetroTechie 1y ago
  Sure, but targeting hardware suited for this purpose. That is: hardware that does not come with complex 3D GPU. Only some framebuffer(s), and -perhaps- a basic 2D accelerator. Then a driver (if needed at all!), would be trivial, you could take Linux out of the equation & collapse the software stack into a tiny amount of code.

anthk 1y ago

Remember SVGAlib and libggi? Maybe FUI it's like the last one.

antirez 1y ago

Related, at a different layer of abstraction: Kitty graphical protocol, implemented also by Ghostty terminal emulator.

yazantapuz 1y ago

Very nice!!! It remains me of the old days with pascal and msdos writing into A000:0000 :)