4 ms·

I wonder how the screenshots were taken. The installer run in a VM?

JdeBP 1y ago
That would be one way to do it, certainly. It's boring, though. (-: There is another. In NetBSD one can, at least according to the manual, open the wsdisplay of the relevant terminal and read out the display contents, with the WSDISPLAYIO_GETWSCHAR I/O control. sysinst is just a full-screen TUI program. * https://man.netbsd.org/wsdisplay.4 https://man.netbsd.org/wsdisplay.4 (The manual says that character values are "ASCII", but the data structure uses a 16-bit unsigned integer for them. So I wonder whether this is UCS-2 or NetBSD has been saddled with some 512-entry character set mess from back in the 1990s.) Presumably there is a third one if the virtual terminal's wsdisplay is in graphics mode and one can access its frame buffer. There was also a fourth for the serial console screenshots, although they were clearly done the boring way by screenshotting a GUI window, as its scrollbars are visible in the images. Presumably the terminal emulator at the other end of the connection had some sort of direct screen shotting functionality. That was definitely something that serial device DTE emulator programs in the days of yore used to have. That's an interesting thought, actually. I wonder whether one could do that at all with many Unix/Linux tools, like GNU screen in its serial terminal mode. One could with (some of) the terminal emulators that used to be available for MS/PC/DR-DOS. There would be some "dump screen to file" menu option, or in extremis a TSR program that could do that. (-:
- actionfromafar 1y ago
  Did not have "being jelaous of NetBSD wscons framework" on my bingo card. How does one make a "screenshot" of a TUI program? The classic terminal APIs don't have a "framebuffer" (or "textbufffer" I guess) from what I can tell. I could use such a mechanism to create automated screenshots of a TUI program (using Terminal.GUI in this case) for documentation generation.
  - fredoralive 1y ago
    I assume NetBSD supports some sort of multiplexing for the local console? In which case it will need to have some sort of text buffer for each virtual terminal to maintain state when it’s off screen, and I guess they’ve decided to expose it to the outside world?
  - JdeBP 1y ago
    Don't be too envious. Linux kernel virtual terminals have "vcsa" devices that one can read for this sort of thing. And it's right there in the manual page how one does this. * https://man7.org/linux/man-pages/man4/vcsa.4.html https://man7.org/linux/man-pages/man4/vcsa.4.html They suffer from being straight copies of CGA, which has historically had a lot of conflation of boldness and brightness, as well as a very limited colour gamut that will make you weep at what your 256-colour TUI programs are reduced to. The NetBSD ioctl supposedly has a bold attribute in a separate field of the structure to a bright colour. Which in the backwards-thinking world of terminals where some people still have the CGA Think that bold=bright, is almost heresy. Still. In 2025. (-: If you are looking for this sort of thing in a GUI/TUI terminal emulator that is a user application program, rather than the terminal emulators that are built into the NetBSD kernel or into Linux, then that's a different kettle of fish entirely. I know of one that provides a direct vcsa workalike. I wrote it. * http://jdebp.info./Softwares/nosh/guide/commands/user-vt.xml http://jdebp.info./Softwares/nosh/guide/commands/user-vt.xml GNU screen works by having a server maintaining a buffer, and a client that attaches to the server and then renders that buffer's contents onto the client's own terminal. So in theory one might be able to access the display of GNU screen in a similar manner by making something that pretends to be a client. But how much of this mechanism even operates when GNU screen is in serial terminal mode, I don't know off the top of my head. The same goes for tmux, of course. And indeed mosh. Although the documentation of the actual protocol was a not-done to-do item, promised in the early publicity for mosh but never delivered, for years. I kept checking back for quite a while to see whether they'd documented it as promised. There's at least one GUI terminal emulator that stores its scrollback area to file, but only the scrollback area. GUI terminal emulators generally do not expose this sort of thing, though. It's some complex private data structure in the emulator process's memory, usually. All that said, wscons is a fairly good-looking API. Certainly better than the undocumented mess that is fbio.
    - actionfromafar 1y ago
      Thank you very much. I'll go back to this and do some testing. Maybe also something like tmux capture-pane -pS -1000 > tui_snapshot.txt will work
topsecret 1y ago
The installer was run in a VM, so presumably that's how screenshots were taken. > Both installations will be in VMs just for the sake of convenience.
- gawa 1y ago
  That's what I understood as well. Also, the author mentions: > The installation succeeded, but the system would panic during boot. *Bhyve is more of a niche thing and not among the hypervisors supported by NetBSD*, [...] I am guessing what he meant was rather "the support of NetBSD (as a guest OS) by the hypervisor Bhyve", because Bhyve is an hypervisor running on FreeBSD. Given the other posts on the blog, it would not be surprising if the author was daily driving FreeBSD while doing this experiment, and Bhyve is well maintained and probably the best fit in the BSD world for this. I don't even know if OpenBSD's vmm can virtualize something else than OpenBSD. From https://wiki.freebsd.org/bhyve https://wiki.freebsd.org/bhyve : > Q: What VM operating systems does bhyve support? > A: bhyve supports any version of FreeBSD i386/amd64. OpenBSD, NetBSD, illumos and GNU/Linux are supported using the UEFI and the sysutils/grub2-bhyve port.
ho_schi 1y ago
On Linux there is the handy fbgrab. I guess they have something similar. https://github.com/GunnarMonell/fbgrab https://github.com/GunnarMonell/fbgrab You also can set timeouts and switch between virtual terminals. PS: I’m love good TUIs. Clean and concise and it is surprising how well user can use them. If - they’re well made. I think the installer of Debian or Linux menuconfig are good examples.
numpad0 1y ago
Cheapest HDMI splitters are ~$10 and compressing capture cards are ~$5, it's not hard or expensive anymore to capture display contents at emergency or illustrative use quality if these weren't VM screenshots or taken through OS feature.

That would be one way to do it, certainly. It's boring, though. (-: There is another. In NetBSD one can, at least according to the manual, open the wsdisplay of the relevant terminal and read out the display contents, with the WSDISPLAYIO_GETWSCHAR I/O control. sysinst is just a full-screen TUI program. * https://man.netbsd.org/wsdisplay.4 https://man.netbsd.org/wsdisplay.4 (The manual says that character values are "ASCII", but the data structure uses a 16-bit unsigned integer for them. So I wonder whether this is UCS-2 or NetBSD has been saddled with some 512-entry character set mess from back in the 1990s.) Presumably there is a third one if the virtual terminal's wsdisplay is in graphics mode and one can access its frame buffer. There was also a fourth for the serial console screenshots, although they were clearly done the boring way by screenshotting a GUI window, as its scrollbars are visible in the images. Presumably the terminal emulator at the other end of the connection had some sort of direct screen shotting functionality. That was definitely something that serial device DTE emulator programs in the days of yore used to have. That's an interesting thought, actually. I wonder whether one could do that at all with many Unix/Linux tools, like GNU screen in its serial terminal mode. One could with (some of) the terminal emulators that used to be available for MS/PC/DR-DOS. There would be some "dump screen to file" menu option, or in extremis a TSR program that could do that. (-:

actionfromafar 1y ago
Did not have "being jelaous of NetBSD wscons framework" on my bingo card. How does one make a "screenshot" of a TUI program? The classic terminal APIs don't have a "framebuffer" (or "textbufffer" I guess) from what I can tell. I could use such a mechanism to create automated screenshots of a TUI program (using Terminal.GUI in this case) for documentation generation.
- fredoralive 1y ago
  I assume NetBSD supports some sort of multiplexing for the local console? In which case it will need to have some sort of text buffer for each virtual terminal to maintain state when it’s off screen, and I guess they’ve decided to expose it to the outside world?
- JdeBP 1y ago
  Don't be too envious. Linux kernel virtual terminals have "vcsa" devices that one can read for this sort of thing. And it's right there in the manual page how one does this. * https://man7.org/linux/man-pages/man4/vcsa.4.html https://man7.org/linux/man-pages/man4/vcsa.4.html They suffer from being straight copies of CGA, which has historically had a lot of conflation of boldness and brightness, as well as a very limited colour gamut that will make you weep at what your 256-colour TUI programs are reduced to. The NetBSD ioctl supposedly has a bold attribute in a separate field of the structure to a bright colour. Which in the backwards-thinking world of terminals where some people still have the CGA Think that bold=bright, is almost heresy. Still. In 2025. (-: If you are looking for this sort of thing in a GUI/TUI terminal emulator that is a user application program, rather than the terminal emulators that are built into the NetBSD kernel or into Linux, then that's a different kettle of fish entirely. I know of one that provides a direct vcsa workalike. I wrote it. * http://jdebp.info./Softwares/nosh/guide/commands/user-vt.xml http://jdebp.info./Softwares/nosh/guide/commands/user-vt.xml GNU screen works by having a server maintaining a buffer, and a client that attaches to the server and then renders that buffer's contents onto the client's own terminal. So in theory one might be able to access the display of GNU screen in a similar manner by making something that pretends to be a client. But how much of this mechanism even operates when GNU screen is in serial terminal mode, I don't know off the top of my head. The same goes for tmux, of course. And indeed mosh. Although the documentation of the actual protocol was a not-done to-do item, promised in the early publicity for mosh but never delivered, for years. I kept checking back for quite a while to see whether they'd documented it as promised. There's at least one GUI terminal emulator that stores its scrollback area to file, but only the scrollback area. GUI terminal emulators generally do not expose this sort of thing, though. It's some complex private data structure in the emulator process's memory, usually. All that said, wscons is a fairly good-looking API. Certainly better than the undocumented mess that is fbio.
  - actionfromafar 1y ago
    Thank you very much. I'll go back to this and do some testing. Maybe also something like tmux capture-pane -pS -1000 > tui_snapshot.txt will work

topsecret 1y ago

The installer was run in a VM, so presumably that's how screenshots were taken. > Both installations will be in VMs just for the sake of convenience.

gawa 1y ago
That's what I understood as well. Also, the author mentions: > The installation succeeded, but the system would panic during boot. *Bhyve is more of a niche thing and not among the hypervisors supported by NetBSD*, [...] I am guessing what he meant was rather "the support of NetBSD (as a guest OS) by the hypervisor Bhyve", because Bhyve is an hypervisor running on FreeBSD. Given the other posts on the blog, it would not be surprising if the author was daily driving FreeBSD while doing this experiment, and Bhyve is well maintained and probably the best fit in the BSD world for this. I don't even know if OpenBSD's vmm can virtualize something else than OpenBSD. From https://wiki.freebsd.org/bhyve https://wiki.freebsd.org/bhyve : > Q: What VM operating systems does bhyve support? > A: bhyve supports any version of FreeBSD i386/amd64. OpenBSD, NetBSD, illumos and GNU/Linux are supported using the UEFI and the sysutils/grub2-bhyve port.

ho_schi 1y ago

On Linux there is the handy fbgrab. I guess they have something similar. https://github.com/GunnarMonell/fbgrab https://github.com/GunnarMonell/fbgrab You also can set timeouts and switch between virtual terminals. PS: I’m love good TUIs. Clean and concise and it is surprising how well user can use them. If - they’re well made. I think the installer of Debian or Linux menuconfig are good examples.

numpad0 1y ago

Cheapest HDMI splitters are ~$10 and compressing capture cards are ~$5, it's not hard or expensive anymore to capture display contents at emergency or illustrative use quality if these weren't VM screenshots or taken through OS feature.