Live data from Hacker News

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

github.com

31–40 of 70 posts

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

#31
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?

See some details here: https://lwn.net/Articles/955708/

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

#32

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

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.

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

#34

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…

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

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

#35
post #30

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…

Depends, I for one, am quite happy no longer having to use a computer like in 1986 - 1990.

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

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

#36

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

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.

On all OSes?

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

#37
post #35
post #30

Earlier quoted context omitted.

Depends, I for one, am quite happy no longer having to use a computer like in 1986 - 1990.

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 in 4DOS (1989).

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.

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

#38
post #34

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…

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

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

#39

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…

There’s a lot of parallels between what you’re working on and my projects. In fact nearly all of your features exist in my projects too.

It’s great to see others working in this field. When I started out (nearly a decade ago now) there was a lot more resistance to these kinds of concepts than there are now.

Post reply on HN