Related, at a different layer of abstraction: Kitty graphical protocol, implemented also by Ghostty terminal emulator.
Fui: C library for interacting with the framebuffer in a TTY context
41–50 of 70 posts
Re: Fui: C library for interacting with the framebuffer in a TTY context
#42Can 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?
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 usuall…
> contain pixel values
the frame
> eventually be written to the screen
the buffer
Re: Fui: C library for interacting with the framebuffer in a TTY context
#43Earlier quoted context omitted.
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...
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 i…
Some of the authors in my circles still use typewriters. Some don't. That's fine. But people do enjoy going back to older techniques, sometimes.
I've seen many debates about the correct carriage return. The world does not move on uniformly.
Re: Fui: C library for interacting with the framebuffer in a TTY context
#44Earlier quoted context omitted.
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 usuall…
> contain pixel values the frame > eventually be written to the screen the buffer
Other way around
Re: Fui: C library for interacting with the framebuffer in a TTY context
#45Don'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 th…
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.
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.
Re: Fui: C library for interacting with the framebuffer in a TTY context
#46Earlier quoted context omitted.
This is amazing... I'm asking to have those features (which were available in Genera) all this time! The hard distinction between Terminal/Text and GUI can be somewhat diluted. I wanted to download it, but I see there is contribution needed. I will see how I can convince you :)
Thank you! Yes it's currently in closed beta (the project is TempleOS-level crazy, which means it's too easy to get it wrong.) If someone thinks they're a good fit to test experimental terminals, an email will suffice: abner at terminal dot click
It doesn't seem that radical from the Github readme, I must say. That's not a criticism, nor at all a high bar! What you're doing appears to be trying to exist within a category that ever has had or will have any other member - so, definitionally, not "TempleOS-level crazy." :D
(Not interested in testing, sad to say. I've spent the last fifteen years trapping "I wish this shell/terminal had X feature" to "time to find a tool for X that isn't as garbage as a shell and a terminal." But I have also used Emacs for about the same length of time, and that implements its own terminal emulators, anyway.)
Re: Fui: C library for interacting with the framebuffer in a TTY context
#47It'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-wi…
Depends, I for one, am quite happy no longer having to use a computer like in 1986 - 1990.
On the other hand, I'm also sad that I don't longer have a computer interface like I had from 1995 - 2010, i.e. that everything is webflat and image-heavy. So weighing the timeline options, I'm not sure I'd pick the look and feel of the post-optimal time frame on a given day ;)
Re: Fui: C library for interacting with the framebuffer in a TTY context
#48Earlier quoted context omitted.
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 usuall…
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…
> My understanding of the memory access provided by fbdev is that it's an extremely simple API.
Maybe some of fbdev are like that, but most of them are not. They use vga/vesa interfaces to get a real video memory and write into it. A text console is also using vga video memory to write character data into it.
I still wonder do there any ways to use VGA at its full. Like loading sprites into invisible on the screen video memory and copying them into their right place on the screen. VGA allowed to copy 8 of 4-bit pixels by copying one byte, for example. Were these things just dropped off for a nice abstraction, or maybe there is some ioctls to switch modes for read/writes into video memory? I don't know and never was interested enough to do a research.
> In other words an outdated abstraction that's still useful so it's kept around.
Yes, it is kinda like this, but the outdated abstraction is realized on video card, kernel just gives access to it.
In Linux fbdev is more like a fallback device when drivers for a specific video card are not accessible. fbdevs are used to make a text console with more than 80x25 characters. Video acceleration or opengl can work on fbdev only as a software implementation.
Re: Fui: C library for interacting with the framebuffer in a TTY context
#49Re: Fui: C library for interacting with the framebuffer in a TTY context
#50Awesome! 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.
> Awesome! Reminds me of the good old days of QuickBasic and SCREEN 13, when you could write very small programs with fullscreen graphics.
That's a very inefficient approach nowadays. Modern hardware uses accelerated graphics throughout, including for simple 2D rendering the sort of which you would've written in QuickBasic back in the day. Even more complex 2D (where the 3D-render pipeline doesn't help as much) is generally best achieved by resorting to GPU-side compute, as seen e.g. in the Linebender Vello project. This is especially relevant at higher resolutions, color depths and frame rates, where the approach of pushing pixels via the CPU becomes even more clearly an unworkable one.