Live data from Hacker News

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

github.com

11–20 of 70 posts

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

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

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

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

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

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

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

#15
post #10

Interesting, I guess you could port LVGL to this and get a full GUI?

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.

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

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

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

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

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

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

> You can't, you don't have direct access to the framebuffer.

Why is this the case? What would be the problem with allowing it?

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

#20

Earlier quoted context omitted.

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

> You can't, you don't have direct access to the framebuffer. Why is this the case? What would be the problem with allowing it?

It fits Apple's modus operandi to enforce things UI/UX wise, I assume in this case they don't want end-apps to be able to bypass the compositor (and e.g. prevent alerts from showing on the screen or whatnot).

They used to allow it, but they removed the API after 10.6

https://developer.apple.com/library/archive/documentation/Gr...

I guess on modern macOS CGDisplayCapture() is the closest example that still works (although clearly there is still some compositing going on since the orange-dot microphone indicator still appears, and you can get the dock to appear over it if you activate mission control. I'm guessing it does the equivalent of a full-screen window but then tries to lock input somehow).

Post reply on HN