Mini TTY In Development For The Linux Kernel

[crazyloglad]

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

[caligula]

Well I run several pcengines routers without any graphic card but only a serial port and the only way to set them up is by a nullmodem cable an minicom. But maybe KMSCON would support that, too.

You're doing it wrong. A router without 4k / 10bits per channel capable 2048-core GPU is nothing but a joke. So you're claiming that you use the console without even 3d rendered texture mapped font glyphs?

[timtas]

You're doing it wrong. A router without 4k / 10bits per channel capable 2048-core GPU is nothing but a joke. So you're claiming that you use the console without even 3d rendered texture mapped font glyphs?

Yes, sorry, I know it's not the way it should be done nowadays. I thought I could get away with it, as I only use the console for the OS installation and networking setup and then connect with ssh. And they are so cheap, performant and reliable. But that's no excuse, of course.

[ssokolow]

Meh, I've read stuff from the 80s that still has punched cards for navigation computers in a nonspecified future which is well beyond what we have now.

The depiction of computers in fiction is rarely better than readout screens or control panels or "digital archives" (pure databases) or other simple stuff.
True computers and automation kill off the story by removing the whole need of men in too many places.
Zeroth rule of fiction is that the story must be about fallible men, not infallible mindless automated systems.

Until they become self-aware. Then you wind up with stuff like the Minds from Iain M. Banks's Culture series, which are very entertaining characters in their own right and have self-chosen names such as "Why don't you give me the gun and say that again" (a member of the defense fleet).

[starshipeleven]

Until they become self-aware. Then you wind up with stuff like the Minds from Iain M. Banks's Culture series, which are very entertaining characters in their own right and have self-chosen names such as "Why don't you give me the gun and say that again" (a member of the defense fleet).

Again the zeroth law of fiction in effect. These AGIs need to have pointless features that make them (look or actually be to some extent) fallible and human, so he can write a story where they are (high-power) characters and they don't just flat-out close tons of plot opportunities with hyperintelligence-fueled perfect efficience.

Btw, these are what I've seen called "tin men". That is, a human being/mind with a different exterior appearance. More used for sapient robots like their Drones, but applies also to classical AIs in immobile mainframes.

[hax0r]

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

Sounds rad, do you have a blog or something? I'm interested in hearing more of your ideas.

I feel that there's need for UNIX 2.0 and it has been long overdo, there's need to modernize framebuffers and vt*, time for bringing more plan9 ideas.

[crazyloglad]

Sounds rad, do you have a blog or something? I'm interested in hearing more of your ideas.

I feel that there's need for UNIX 2.0 and it has been long overdo, there's need to modernize framebuffers and vt*, time for bringing more plan9 ideas.

Sorry for the slow reply, I only really check forums in small bursts. The blog is the https://arcan-fe.com page. Incidentally, it was just updated with a very plan9 inspired UI experiment, https://arcan-fe.com/2017/04/17/one-...os-from-plan9/
I also aim for a longer video presentation once a year or so. The last one was too much on the overview/technical side though, the one that's coming sometime this summer hopefully goes into more of the interesting stuff that's going on.