Make screen resizable

[daniilfigasystems]

Is your feature request related to a problem? Please describe. I always wanted resizable screen in OC2

Describe the solution you'd like Make screen resizable by adding blocks to it

Describe alternatives you've considered Able to run X window on that

Additional context

[hickorysb]

This likely will not happen in OC2 purely due to how it's written. It would require a fairly large rewrite of the systems to make this work.

[perkinslr]

Enlarging the drawn area in the world with adjascent screens is orthogonal to changing the number of rows or columns in the VTT. That would likely best be done like in the original OC mod via a dedicated monitor block, but the existence of the projector largely removes the need for it. That leaves just changing the logical size of the VTT.

There are a few options here that might do what you want. Changing the size of the virtual terminal is easy, just change a couple constants and recompile. You can even do that at runtime by echoing the right characters back to the kernel. The problem is the display logic. The problem is the block enttity / screen side of things. It implements basically a VT220 serial terminal, which expects a fixed size. Even if you change it at compile time, you're stuck with the new size.

So the first option would be to teach the block entity to be a smarter TTY. At the extrema, this would mean expanding it into a full xterm-256color or xterm-direct terminal. This is conceptually simple, but xterm (color or otherwise) is a fiddly protocol, so expect a fair amount of annoyance. It also would require upgrading the renderer, both the in-world renderer and the gui overlay renderer, to support colors and dynamically sized glyhps. Not difficult, but not dead simple. The obvious advantage to the approach is it requires no modification within the VM or kernel layer, all the changes are contained to the VTT logic.

The second option would be to implement a VESA EGA/VGA card. This was the route I went when implementing x86 emulation on top of the original OC mod. Once again, this would best be done via a new block, so the existing system continues as-is (it could probably be a modal switch on the projector, though). VGA itself is not too complex, it defaults to text mode, where it operates much like the existing VTT, but then has a switch for "graphics" mode, which opens the door to required blitting and other per-pixel operations. This would require a new block device, and figuring out where and how to attach it to the VM so we can re-use existing swrast/vga drivers. The VGA protocol implementation is tedious, but not difficult. The VGA rendering is quite starightforward (your virtual VGA terminal has an RGB buffer, you convert it to the format MC wants and draw it). For someone who has a deep understanding of the sedna layer, it's probably straightforward enough to hook them together, but figuring that part out is likely to be a challenge otherwise.

The third option, the one I've been toying with, is to leverage the software/fake framebuffer support in the kernel to implement a software framebuffer suitable for running programs in directfb mode (qt supports this). This could then be exposed via a dumb memory-mapped device for rendering. This can't entirely leverage existing drivers, but isn't too far off of how the old Kindle keyboard works, so I have some familiarity with it already. It also requires a new rendering frontend, but that should be fairly simple.