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

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.

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

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.

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.

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.

your terminal looks cool!

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

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

Unless you're deep in a conversation with a graphics nerd, when "the framebuffer" is referenced, what the person normally means is some area of memory, accessible programmatically, that directly represents the pixels displayed on the screen. No fancy windows, vectors, coordinates, just raw memory and values that are the literal values the screen is showing.

In practice, it's not literally that, but in practice, it acts/works like that.

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

On Linux and on other operating systems that have reused the Linux DRM drivers, you can run OpenGL applications from a virtual terminal text console. Examples are kmscube [1] and the glmark2 benchmark suite.

[1] https://gitlab.freedesktop.org/mesa/kmscube

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

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

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.

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

My first experience with programming was with QuickBasic. You just brought back some memories, wish I still had all of those old programs around.

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.

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.

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.

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.

Tagged by comment to play a little later.

Thanks!

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

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.

Added MIT license