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

61–70 of 70 posts

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

#61

Post by RetroTechie »

queuebert wrote: post #56
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?

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.

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

#62

Post by fc417fc802 »

shakna wrote: post #43
pjmlp wrote: post #37

Earlier quoted context omitted.

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.

Epaper based "typewriters" that "print" to a text file on an SD card are a thing. Not useful to me since I'm not an author but I can appreciate the desire to get rid of unnecessary distractions. It's the same reason I use a terminal emulator.

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

#63

Post by f1shy »

pjmlp wrote: post #37
f1shy wrote: post #35

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

Now that you say it, I remember using command completion and color highlighting in the prompt with DOS4. I was liverated from the terminal a little bit before that.

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

#64

Post by fc417fc802 »

immibis wrote: post #51
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 co…

> Even with modern graphics cards there's a global framebuffer for the entire desktop. It's updated every frame by the operating system

Is there though?

https://docs.kernel.org/gpu/amdgpu/display/mpo-overview.html

> Plane independent page flips - No need to be tied to global compositor page-flip present rate, reduced latency, independent timing.

There's at least a buffer for scanout but that doesn't necessarily have to be larger than one line and I don't believe it's end use accessible.

As an example. Consider running a game at one refresh rate in windowed fullscreen (or whatever it's called) mode with your compositor at a different refresh rate. With your desktop spanning two monitors, one operating at 60 Hz the other at 50 Hz. And throw in a media player with a window that's split across those two monitors rendering a 29.97 fps (ie NTSC) video stream via hardware accelerated decoding.

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

#65

Post by abnercoimbre »

cryptonector wrote: post #60
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 h…

Thanks for the feedback! You definitely grok the (currently annoying) consequences of what I'm doing. I believe this is the gist of your point:

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

I think it's only awesome to those of us brought up on RTFM culture. If you read the commentary [0] from HN's little cousin they center the battle around this very subject, which is what I personally care for the most. So much so that I'm willing to smash the stack (heh) and persuade others it's worth reinventing even if we ultimately fail. We will preserve what we can; I'm not going at it blindly.

You'll never meaningfully convince newer generations to leverage man pages for discovering new commands/functions: "Oh oops add a 3 to read about that one. Why? Let me explain man sections to you." Ditto for environment updates: "Try putenv, which should not be confused with setenv! No no, run env first to dump what you have!"

I ALWAYS get blank stares from (imo competent) GenZ devs who were initially curious. They were willing to read and learn and discover but not like this. They tip toe away from me and switch back to IDEs. My examples were contrived but the general observation propagates across the entirety of workflows within classic terminals.

[0] https://lobste.rs/s/ndlwoh/wizard_his_shell

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

#66

Post by timewizard »

moron4hire wrote: post #44
timewizard wrote: post #42

Earlier quoted context omitted.

> contain pixel values the frame > eventually be written to the screen the buffer

Other way around

The buffer is between your pixels and the actual analog or digital output. It serves the conversion between the two formats.

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

#67

Post by cryptonector »

abnercoimbre wrote: post #65
cryptonector wrote: post #60

Earlier quoted context omitted.

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

Thanks for the feedback! You definitely grok the (currently annoying) consequences of what I'm doing. I believe this is the gist of your point: > Don't you see that a plain old terminal emulator + tmux + shell is just an awesome stack? I think it's only awesome to those of us brought up on RTFM culture. If you read the commentary [0] from HN's little cousin they center the battle around this very subject, which is wh…

Thanks for the thoughtful reply. I laughed. You're probably right. And just as one might never convince newer generations to RTFM, one will have a similarly difficult time convincing older generations to do the newfangled thing.

Although I should say that I work with colleagues in newer and older generations, and I find that the younger ones do end up learning how to RTFM.

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

#68

Post by ddingus »

mouse_ wrote: post #3

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

Tagged by comment to play a little later.

Thanks!

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

#69

Post by immibis »

phkahler wrote: post #57
immibis wrote: post #53

Earlier quoted context omitted.

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.

That's assuming you rewrite the whole screen every frame. Most productivity apps don't. Windows (and X11) had this whole infrastructure about managing dirty regions.

Computers with GPUs are now fast enough to blast through recomputing the entire screen's contents every frame, but perhaps for efficiency reasons we still shouldn't?

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

#70

Post by cstrahan »

kristianp wrote: post #18

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

The sibling comments are great; to add to those, I highly recommend giving “The TTY Demystified” a read:

https://www.linusakesson.net/programming/tty/

It’s a long read, but necessarily so: there is considerable complexity (and unfortunate overloading of terms) as a consequence of the transition from physical terminals as a separate hardware component to the emulated (warts and all) counterparts we have in modern OSes.

Post reply on HN