1. 34
  1. 4

    This is really neat! It makes me want to dive into writing my own framebuffer utilities. Some thoughts:

    For things like a clock or a battery indicator, tmux has a ‘status’ option and screen has a ‘hardstatus’ option. Both of these tools make the a console-sans-xorg experience quite enjoyable.

    For other framebuffer tools, try jfbview (pdf viewer) or libxine’s fbxine (video player).

    1. 3

      I’ve forgone tmux and screen because (at least tmux) adds noticeable input lag, and I find neovim’s terminal emulator more convenient (one set of keys for managing windows, unified “clipboard” vim registers). If I really need a detachable session, I wrote another simple tool for that.

      I’ve used jfbview (or maybe a fork) to read Intel manuals. I don’t think there are sound drivers for my Chromebook so watching videos probably isn’t going to happen. Framebuffer tools really don’t get enough love, though!

      1. 3

        (at least tmux) adds noticeable input lag

        I’m not sure if it’s the only input lag you were noticing, but the biggest annoyance in this respect for me goes away if you add

        set -s escape-time 0

        to your .tmux.conf. By default tmux pauses for a half-second after ESC before sending it through, in order to allow using ESC+key as equivalent to Meta+key for tmux bindings (like emacs does). Which is probably fine if you don’t use vim, but is very annoying in vim. Setting the delay to 0 does of course mean that you can’t use ESC+key sequences for tmux bindings.

    2. 3

      Remember when being Unix-like meant “everything was a file”? It was nice.

      Linux is still better than most, honestly (sysctl talks to /sys, for example, instead of being its own thing) but Linux still has netlink and other stuff that aren’t files.

      Of course, it’s easy to judge, but X and Wayland solve hard problems: it’s not enough to write to a file to put pixels on the screen, you have to multiplex/mediate access, allow for manipulation of potentially broken clients, etc.

      Plan 9 was really the only one who got it right, and even then it got a few things wrong.

      1. 5

        Why is it nice?

        I hate Linux’s “everything is a virtual filesystem” approach. Looking at mount output on a modern Linux box just feels disgusting. 12 lines (!) of cgroups spam, and then devpts pstore securityfs debugfs configfs hugetlbfs OMGWTFfs. And how could I forget the infamous efivarfs!

        Also, most files in sysfs are text, so you have the overhead of parsing strings just to read system information.

        1. 1

          Also, most files in sysfs are text, so you have the overhead of parsing strings just to read system information.

          That’s the advantage. I can grep for information, cat it, sort it, etc, etc using tools that I already know how to use, because they’re just files containing text.

          In the vast majority of applications the slight overhead for doing the string parsing isn’t going to have a significant effect on performance.

          1. 4

            Sure, but then when you want to do something less ad-hoc with it, it becomes a pain. The canonical source of that information shouldn’t be text, it should be structured data that can be dumped to text when necessary.

            1. 3

              But I can do the same with the output of sysctl(8). I don’t need a hundred mounts for that.

        2. 3

          Dunno why would someone not just use libSDL in this situation? And then, of course libSDL_grafx, etc.

          1. 12
            SDL2-2.0.7$ cloc src | grep SUM | grep -o '\d\+$'
            bin$ cloc fbclock.c | grep -o '\d\+$'


            1. 10

              I see several reasons, one being education. I had no idea how linux framebuffer system was working before reading this post.

              Great post, thanks for writing it!

              1. 1

                This is a different post right?

                1. 4

                  Yes. This post is somewhat of a followup to that one.

              2. 1

                Question about something tangentially related: does anyone have source code to show what it takes to boot a program (no OS) and draw into the UEFI framebuffer?