For what it's worth, something similar to kmscon has been possible and used in the arcan project [1] for a few years.
It builds on the same vt***-state machine and virtual display as kmscon, libtsm (quite nice, kudos to dvdhrm) - adding some additional ESC/OSC/... sequences like 24-bit colors. The minimal example script looks like [2] though one would likely want to pad that with more stuff like mouse support (maybe ~10 lines of code), "alt+Fn" switching (~20 loc), external clients (wayland etc. maybe ~10 loc), clipboard (~20 loc), multi-display support (~100-150loc) and so on, but after a while like that you get dangerously close to just reimplementing a small WM.
Eventually, you'll run into something like the kmscon-issue at [3] though and that's where you start to see the outline of a game-over screen: you're in the seventh circle of hell trying to work with that in a legacy compatible and sane way. Everyone wants to be a display server at this intersection and none of them has any real way to settle disputes. The closest I've come is [4] with Xorg as an alt+Fn map to [4] (the _EXTERNAL bits) but it opens up an ugly race condition (though that one exist in current-day VT _TEXT/_GRAPHICS/VT_RELDISP/VT_ACKACQ as well) but with the added disadvantage of Xorg being unable to hand back state without terminating - but that's fine for my own use cases. There's a reason Windows still just "it's a desktop, who gives a damn? yolo!" and run like 95% of all this crap in the kernel...
Personally, I'm much more enticed by the prospect of being able to eventually toggle-disable vt- emulation entirely and talk directly with the shell without the terminal emulator middleman - since all this boils down to is a really crappy mutant display server protocol, the product of generations of inbreeding.
[1] https://arcan-fe.com
[2] https://pastebin.com/NK5ZzaYU
[3] https://github.com/dvdhrm/kmscon/issues/65
[4] https://github.com/letoram/arcan/blo...nch_target.lua
It builds on the same vt***-state machine and virtual display as kmscon, libtsm (quite nice, kudos to dvdhrm) - adding some additional ESC/OSC/... sequences like 24-bit colors. The minimal example script looks like [2] though one would likely want to pad that with more stuff like mouse support (maybe ~10 lines of code), "alt+Fn" switching (~20 loc), external clients (wayland etc. maybe ~10 loc), clipboard (~20 loc), multi-display support (~100-150loc) and so on, but after a while like that you get dangerously close to just reimplementing a small WM.
Eventually, you'll run into something like the kmscon-issue at [3] though and that's where you start to see the outline of a game-over screen: you're in the seventh circle of hell trying to work with that in a legacy compatible and sane way. Everyone wants to be a display server at this intersection and none of them has any real way to settle disputes. The closest I've come is [4] with Xorg as an alt+Fn map to [4] (the _EXTERNAL bits) but it opens up an ugly race condition (though that one exist in current-day VT _TEXT/_GRAPHICS/VT_RELDISP/VT_ACKACQ as well) but with the added disadvantage of Xorg being unable to hand back state without terminating - but that's fine for my own use cases. There's a reason Windows still just "it's a desktop, who gives a damn? yolo!" and run like 95% of all this crap in the kernel...
Personally, I'm much more enticed by the prospect of being able to eventually toggle-disable vt- emulation entirely and talk directly with the shell without the terminal emulator middleman - since all this boils down to is a really crappy mutant display server protocol, the product of generations of inbreeding.
[1] https://arcan-fe.com
[2] https://pastebin.com/NK5ZzaYU
[3] https://github.com/dvdhrm/kmscon/issues/65
[4] https://github.com/letoram/arcan/blo...nch_target.lua
Comment