Aw, come on. You ought to be more charitable and optimistic! :) GitHub shows the last commit as 5 hours ago. No, you can’t daily drive it and log into your bank’s website yet, but this is a marathon, not a sprint.
On my phone when you scroll down to the first video you can’t click play. It turns out that the substack subscription box popup covers the entire screen and disables interaction other than scrolling even though it’s not visible yet. So you have to scroll down past the video, click “continue reading” and then scroll back up to click play.
You are now equipped with the basics to write graphical applications on a NetBSD system (and maybe OpenBSD too) without running X11.
Btw. another way of showing some graphics (ofc not nearly as powerful as writing to the fb directly) would be using mlterm - a terminal emulator that can run directly on top of various framebuffers, and supports unicode, emoji, sixel, etc. - https://i.imgur.com/rERnsK9.png
I’m wondering if I can use this example along with a Raspberry Pi and a 7” touchscreen to display temporary WiFi guest codes without relying on X11. It’s fairly straightforward to achieve using feh, X11, LightDM, and xinput, but without X11, I haven’t been able to display high-quality QR codes so far.
For sure. The video at the end of the article is precisely showing this :) A Raspberry Pi 3 with a 7” touchscreen, and I’ve gotten boot times from power up to showing graphics down to about ~5 seconds. It should be easy to render the QR codes.
But actually, the point of creating the “dev box” I show at the end is to support use cases like this one. There is quite a bit of work to implement APIs in EndBASIC to interact with the host OS, but they are on my mind these days…
I’d be very curious to see a writeup on your boot time optimizations. I have spent a good amount of time in that area with Pi’s, especially with Balena.io and Diet Pi. I eventually got into my own bare metal kernel development for some projects as opposed to stripping down Linux.
I didn’t do anything fancy yet. I just compiled a slimmed down kernel, which avoids some devices that take significant time during boot (WiFi is one of them, and I want to convert that to a module later) and also avoided the flickering of the Raspberry “BIOS” (because it is able to load the kernel image faster).
I also modified /etc/rc to start my program immediately without waiting for any of the other stuff in the system: I let file system checks and network initialization happen in the background. A big hack, but for now it’s great. NetBSD’s rcorder is nice, but it’s too slow and does not support any sort of parallelization, which is important when some services just take a long time to start. I’ve been tempted to replace it all with a custom “script” that just initializes the very few things I need instead.
Not as fast as it could be if it were bare metal, but I’ve gotten it to be fast enough. Combined with a splash screen to cover the kernel logs (which I removed from the recorded video), it almost feels as if the pause is intentional :)
Nice, great info. I’m a longtime FreeBSD user, but the one machine I keep it on, a 90s era PC I keep around for format conversions & testing, is falling out of favor in a couple releases, so I have been meaning to spend more time with NetBSD. This gives me two reasons. I’m pretty familiar with the BSD-style startup.
On Linux you also have the option of using cage, which is a Wayland compositor that gives apps a single fullscreen window whether they like it or not. It will run directly from the console with DRI (though you can also run it inside an existing Wayland or X session, which is useful for debugging).
Takes about half a second to start on a Pi 4, which isn’t quite as snappy as I hoped, but it’s better than X — and you get GPU acceleration within that context.
At least… when things work out right, but that’s a whole other story. Suffice it to say I’m not too happy with Raspberry Pi bookworm at the moment, but I’ve managed to find joy with Manjaro-ARM.
There is DRM (not the bad, proprietary kind, but the Linux subsystem), which is pretty much meant to be the way to display stuff on Linux. I recommend it much more so than the legacy framebuffers.
The mentioned cage is also a great direction, if you would rather use some graphical framework for the actual drawing.
No, actually. They’re the same size/dimensions, but NetBSD console has a sans serif pixel font with dotted zeroes, and the endbasic console on the right there has a serif pixel font with slashed zeroes.
Heh, you know… I copied the font data from NetBSD and, on the small screen I used, it looked “similar enough” so I didn’t give it a second thought and didn’t pay enough attention. But it looks like I copied the wrong font!
Have you measured where the ‘x11 xorg startup tax’ actually comes from? I am in the process of instrumenting that for other reasons, but when I did it last a few years ago in a Linux context, it all boiled down to how it shells out and runs the keymap compiler(!) to get the keymap to seed to clients. This was assuming the desired modeset matched the one set through previous stages in boot, since that can impose seconds of blocking waiting for displays to continue being terrible.
I used wscons in OpenBSD to make SerenityOS’s GUI run on top of OpenBSD’s kernel. The actual changes were 1 2 3 (adding DRM/GPU support) and 4.
I am now sad that SerenityOS went nowhere :(
Aw, come on. You ought to be more charitable and optimistic! :) GitHub shows the last commit as 5 hours ago. No, you can’t daily drive it and log into your bank’s website yet, but this is a marathon, not a sprint.
I haven’t really been keeping up on things, but I wasn’t aware SerenityOS had stalled. Has the project really slowed down since Ladybird broke off?
On my phone when you scroll down to the first video you can’t click play. It turns out that the substack subscription box popup covers the entire screen and disables interaction other than scrolling even though it’s not visible yet. So you have to scroll down past the video, click “continue reading” and then scroll back up to click play.
That’s pretty cool!
Btw. another way of showing some graphics (ofc not nearly as powerful as writing to the fb directly) would be using mlterm - a terminal emulator that can run directly on top of various framebuffers, and supports unicode, emoji, sixel, etc. - https://i.imgur.com/rERnsK9.png
I’m wondering if I can use this example along with a Raspberry Pi and a 7” touchscreen to display temporary WiFi guest codes without relying on X11. It’s fairly straightforward to achieve using feh, X11, LightDM, and xinput, but without X11, I haven’t been able to display high-quality QR codes so far.
For sure. The video at the end of the article is precisely showing this :) A Raspberry Pi 3 with a 7” touchscreen, and I’ve gotten boot times from power up to showing graphics down to about ~5 seconds. It should be easy to render the QR codes.
But actually, the point of creating the “dev box” I show at the end is to support use cases like this one. There is quite a bit of work to implement APIs in EndBASIC to interact with the host OS, but they are on my mind these days…
I’d be very curious to see a writeup on your boot time optimizations. I have spent a good amount of time in that area with Pi’s, especially with Balena.io and Diet Pi. I eventually got into my own bare metal kernel development for some projects as opposed to stripping down Linux.
I didn’t do anything fancy yet. I just compiled a slimmed down kernel, which avoids some devices that take significant time during boot (WiFi is one of them, and I want to convert that to a module later) and also avoided the flickering of the Raspberry “BIOS” (because it is able to load the kernel image faster).
I also modified
/etc/rcto start my program immediately without waiting for any of the other stuff in the system: I let file system checks and network initialization happen in the background. A big hack, but for now it’s great. NetBSD’s rcorder is nice, but it’s too slow and does not support any sort of parallelization, which is important when some services just take a long time to start. I’ve been tempted to replace it all with a custom “script” that just initializes the very few things I need instead.Not as fast as it could be if it were bare metal, but I’ve gotten it to be fast enough. Combined with a splash screen to cover the kernel logs (which I removed from the recorded video), it almost feels as if the pause is intentional :)
Nice, great info. I’m a longtime FreeBSD user, but the one machine I keep it on, a 90s era PC I keep around for format conversions & testing, is falling out of favor in a couple releases, so I have been meaning to spend more time with NetBSD. This gives me two reasons. I’m pretty familiar with the BSD-style startup.
On Linux you also have the option of using cage, which is a Wayland compositor that gives apps a single fullscreen window whether they like it or not. It will run directly from the console with DRI (though you can also run it inside an existing Wayland or X session, which is useful for debugging).
Takes about half a second to start on a Pi 4, which isn’t quite as snappy as I hoped, but it’s better than X — and you get GPU acceleration within that context.
At least… when things work out right, but that’s a whole other story. Suffice it to say I’m not too happy with Raspberry Pi bookworm at the moment, but I’ve managed to find joy with Manjaro-ARM.
There is DRM (not the bad, proprietary kind, but the Linux subsystem), which is pretty much meant to be the way to display stuff on Linux. I recommend it much more so than the legacy framebuffers.
The mentioned cage is also a great direction, if you would rather use some graphical framework for the actual drawing.
Minor nitpick, but…
No, actually. They’re the same size/dimensions, but NetBSD console has a sans serif pixel font with dotted zeroes, and the endbasic console on the right there has a serif pixel font with slashed zeroes.
Heh, you know… I copied the font data from NetBSD and, on the small screen I used, it looked “similar enough” so I didn’t give it a second thought and didn’t pay enough attention. But it looks like I copied the wrong font!
I think you forgot to mention that it’s possible to actually run x11 on top of this frame buffer :-)
Not directly, but I do mention the drivers for it at the end though :P
Have you measured where the ‘
x11xorg startup tax’ actually comes from? I am in the process of instrumenting that for other reasons, but when I did it last a few years ago in a Linux context, it all boiled down to how it shells out and runs the keymap compiler(!) to get the keymap to seed to clients. This was assuming the desired modeset matched the one set through previous stages in boot, since that can impose seconds of blocking waiting for displays to continue being terrible.