Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

51–60 of 70 posts

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

#51

Post by immibis »

markisus wrote: post #6

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?

Most generally, it's a place you can buffer a frame. Old-school computers usually have an area of memory set aside and they're continually reading this area and sending its contents to the TV screen, so if you set bytes in this area they instantly appear as pixels on the TV.

Even with modern graphics cards there's a global framebuffer for the entire desktop. It's updated every frame by the operating system sending commands to the graphics card to copy data from all over the place from different programs.

Linux's fbdev API (/dev/fb0) provides a framebuffer that looks like a file - you can read, write and mmap it. This is deprecated, not because it's obsolete functionality, but because the API is obsolete as they want to replace it with DRM dumb buffers (that's Direct Rendering Manager, not the evil thing). You have to use the whole DRM system, which lets you select which graphics card to use, which video ports to use if your card has more than one, which resolution, etc. You can then allocate a frame buffer and tell it to display that buffer. You can also allocate more than one buffer and tell the card when to switch to a different one (i.e. double-buffering).

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

#52

Post by immibis »

abnercoimbre wrote: post #27

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-wi…

I've thought that if I did this, the one thing I'd like to change is the intermixing of command and output. The command line should be an entirely separate part of the GUI from the output area. Possibly separate output areas for different commands, if they're running concurrently. There's no reason anything other than my input should ever need to appear in the middle of my input box.

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

#53

Post by immibis »

zozbot234 wrote: post #50
clbrmbr wrote: post #8

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.

> 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 ge…

CPUs are also not slower than they were in the days of software-rendered Quake, so you can render things in software if you don't want to add a whole bunch of complexity to your software stack.

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

#54

Post by Jasper_ »

ordu wrote: post #48
fc417fc802 wrote: post #23

Earlier quoted context omitted.

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 vi…

Most GPU drivers these days are DRM drivers, which implement fbdev support for backwards compatibility only [0]. The fbdev API is primarily "fake" these days.

DRM/KMS using dumb buffers are the preferred API if you want to do software rendering and modesetting. You can find several examples of this online if you search for drm_mode_create_dumb.

[0] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds...

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

#55

Post by queuebert »

clbrmbr wrote: post #8

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.

I'm using that combo in a DOS emulator to teach my kids how to code. They love being able to draw right out of the box. And the best part is no distractions. No updates to apply, no popup notifications, and no crashes -- everything just works.

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

#56

Post by queuebert »

RetroTechie wrote: post #33

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.

Wouldn't that amount to essentially writing a video card driver?

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

#57

Post by phkahler »

immibis wrote: post #53
zozbot234 wrote: post #50

Earlier quoted context omitted.

> 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 ge…

CPUs are also not slower than they were in the days of software-rendered Quake, so you can render things in software if you don't want to add a whole bunch of complexity to your software stack.

Yeah, a 4K display is about 8 megapixels so at 60fps you need to write 480M pixels per second. That's feasible with a single CPU depending on the complexity of the rendering. Multi-core can get more work done per pixel. You'd still be writing highly optimized code to render fairly simple things if they require a full screen update.

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

#58

Post by titaphraz »

abnercoimbre wrote: post #27

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-wi…

That's very interesting, two comments:

- Automatic black box with autocomplete is a deal breaker for me. It'll drive me mad.

- I only use the mouse in the terminal if I have to (it disturbs and slows my flow!). So anything that helps me NOT using the mouse would be better. At the moment I think it's only text select/copy I use the mouse for. And resize the window. So a magic quick way to select text and copy from the keyboard would be very nice.

But I do realize I'm not the intended audience.

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

#60

Post by cryptonector »

abnercoimbre wrote: post #27

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-wi…

The very first video there is about setting opacity and picking a theme and a background. I don't care about those things. I want only a dark background color palette, which every modern terminal emulator has.

The rest is all about how smart the terminal is and lets you do things without your shell having to be involved. But... now I have to know _two_ major things: the shell and the terminal. Ugh. Why can't I just have a better shell to do all of that?

How does this stuff work over ssh/mosh? Answer: it doesn't:

> Can’t Shells Do All This Stuff Too?

> Maybe. You could extend the TTY protocol or add new escape codes to mimic some of these features. But as Terminal Click evolves this argument gets sillier. [...]

But if you don't want to add escapes then now you have to define new protocols to make this work across the network. Or give up on the network. Or continue to insist on the terminal interpreting what it sees and being a layer completely detached from the shell, though now it can't see the PATH on the remote end and other such problems.

Don't you see that a plain old terminal emulator + tmux + shell is just an awesome stack?

Now maybe we should never need remote shells. In a zero-touch world it really has to be the case that there are very few places to ssh/mosh over to, though even then we'd need this terminal to be so smart as to understand that this shell is a Windows PowerShell and now whoops we're in a WSL2 bash shell (which is a lot like ssh'ing over to a Linux box).

I just don't have high hopes that these things can make my life easier.

Post reply on HN