On Sun, Sep 13, 2026 at 1:31 AM Devon H. O'Dell <[email protected]> wrote:
> It seems to me one of the differences here is that, in traditional plan 9,
> the multiplexing to terminals would be in drawterm.
I'm not sure I understand this statement: I think of drawterm as a
user-space program for non-Plan 9 systems that emulates enough of a
Plan 9 terminal kernel and associated software that it allows a user
to effect the equivalent of `cpu` into some CPU server; one then runs
the window system, shells, and so on on the CPU server, and drawterm
merely synthesizes and provides a conduit for the devices those
programs use. For graphics, for example, this translates /dev/draw
into whatever native package the local system uses: X, Wayland, the
macOS or Windows toolkits, etc.
On the other hand, a "native" plan 9 terminal runs a normal Plan 9
kernel, and drives the local hardware. But unlike drawterm, one can
run a number of useful programs directly on the terminal: the window
system and shells are obvious, but subject to the limits of the
hardware, one can run arbitrary programs: text editors, compilers,
document formatters, and so on, are all candidates for running
locally. A Plan 9 terminal machine is a fully functional computer on a
Plan 9 network, whereas drawterm just provides the interface to
connect to another machine.
As an aside, a potentially interesting idea might be an evolution of
drawterm into some kind of type-2 hypervisor kind of thing similar to
gVisor, that let a user program load other programs and run them as
"processes" under the control of supervisory code that scheduled them,
handled plan 9 system calls, and so on, in a way that was transparent
to those programs but that translated them into calls to the
underlying system. It would almost certainly require support from the
host operating system to do that, though, but then one could run (say)
`rio` and `rc` locally inside this drawterm+.
> Whereas here, the ask is how to multiplex terminals across multiple different
> hdmi (say) outputs given some discrete USB inputs. Maybe I’m understanding
> the ask backwards, but I’m understanding a question like “how do you make a
> drawterm environment to local consoles that isn’t purely over network”
I'm still not quite tracking. There are a few different scenarios:
1. A "multi-seat" configuration for a single shared machine, where
multiple video outputs are configured together with one of a set of
keyboard/mouse/whatever user interaction devices, the aggregate of
which supports multiple users using the machine simultaneously.
2. Independent of (1), users would like to allow other users to "log
in" to a terminal without rebooting it (right now, Plan 9 terminals
take on the user who logs in when they initially boot up as the "host
owner"; the only way to change the host owner is to reset the
terminal. This is by design), so that if Fred joes to lunch, Jane can
use the terminal, leaving Fred's state alone, until Fred comes back,
at which point Jane can "suspend" her session and Fred can resume.
3. For a single user, support multiple terminal "sessions"
simultaneously; kind of like virtual desktops.
(3) is just a small matter of programming. I'm not aware of any plan 9
systems that currently do this, but I don't see why it couldn't be
done. A fine simulacrum would be to start up a single copy of `rio`,
and then "sweep out" a big window and run a second copy of `rio` in
that (plan 9 window systems can be run recursively); do this $n$ times
for each "virtual desktop".
(1) is sort of the odd one; I find it helpful to understand this
conceptually by framing it in terms of an example. Suppose I have a
CPU server that has one or more local video adapters providing (in
total) $n$ outputs; call it 4. Furthermore, suppose I have also
attached four pairs of keyboards and mice locally. In aggregate, this
provides something like 4 physical "seats" that could be used by four
different users simultaneously, as each of the 4 video outputs could
be attached to a separate monitor. Is the question, then, how would
one implement such a thing? I suspect it would require some
modification to the system, so that each video output could be
presented as a separate device tree (I don't know whether any existing
graphics drivers already do this); similarly, the drivers for whatever
hardware was used for the keyboards and mice (oh, let's be honest:
it's going to be USB) would have to support that kind of multiplexing,
but for those, you could probably write a user-space program that took
ownership of all USB devices and muxed them in the usual way. The
remaining question is how you authenticate everything; for that, I'd
just run a CPU server kernel and write a little program that ran on
each display/keyboard/mouse pair, that mimicked the login sequence on
a terminal: this would authenticate the user and work with whatever
video drivers and the USB mux program to arrange for that user to take
"ownership" of those devices, and then just run normally.
(2) then emerges as kind of a variation on (1) and (3), with some
supervisor program "owning" the actual devices and letting users them,
but only one at a time access the actual device; probably aided by the
drivers/USB mux. It may be useful to stress that this wasn't exactly
how the designers envisioned things, though: terminals were supposed
to be cheap enough that everyone just had one. Put another way, why
would Jane *want* to use Fred's terminal while he was away at lunch?
Jane would just use Jane's terminal. I suppose if these are the super
high-end "terminals" on the big machine, which are a more limited
resource, that question becomes more interesting.
> No idea if I’m hitting the mark; is this the question being asked?
Same.
- Dan C.
> On Sat, Sep 12, 2026 at 23:05 Dan Cross <[email protected]> wrote:
>>
>> On Sat, Sep 12, 2026 at 1:23 PM C <[email protected]> wrote:
>> > I think, a terminal is just a cpu server you access directly, and its just
>> > a cpu server when you use it remotely.
>>
>> No, but you're not too far off.
>>
>> Technically, CPU servers and terminals run different kernels, though
>> they are built from the same set of sources, and the differences are
>> very minor; they amount to a difference between how much RAM is
>> reserved for the system versus user processes, how they authenticate
>> at boot, and settings things up so that the system starts
>> /rc/bin/cpurc or /rc/bin/termrc depending on which is which.
>> Generically, CPU servers are configured so that they run network
>> servers that allow multiple authenticated users to log into the
>> machine and make use of its resources; terminals tend not to do that,
>> but rather, run things locally as the host owner (the user who logged
>> in when the system first booted up).
>>
>> Traditionally, CPU servers either provided substantial computation
>> resources and fast network connections (particularly to the file
>> server machine), or were more modest machines that filled specific
>> roles (like running the authentication services), while terminals
>> tended to be smaller and diskless, but have excellent graphics
>> hardware, decent sound, and really nice keyboards and mice: these were
>> the machines users interacted with when they logged into a plan 9
>> network, that ran their window system, text editors, mail clients, and
>> so on: they're not really meant to be shared in a meaningful way, as
>> that would be mostly uninteresting unless you were sitting right in
>> front of one.
>>
>> > So, including your cpu and terminal nodes, you now basically have two cpu
>> > servers depending on how it's setup.
>>
>> I wouldn't think of a terminal as a "cpu server" per se, but nothing
>> prevents you from running programs that provide services to other
>> users on the network on one, provided you are ok with those things
>> running as your user, etc.
>>
>> > Perhaps I'm incorrect about this abstraction?
>>
>> As above, because the kernels are so similar, it's not too far off.
>> But in the Plan 9 model of the world, the idea is that you construct
>> your environment on your terminal, and you dynamically construct the
>> environment you are using by importing resources that are shared with
>> the network from other machines; thus, the way to think of a CPU
>> server isn't so much that you use one by logging into a remote
>> machine, but rather, you import its resources into your local
>> terminal's environment. Of course under the covers you are actually
>> connecting to a remote machine and running programs on it, but as a
>> conceptual model, this is better than thinking about e.g. using `ssh`
>> to log into a remote Unix machine or something.
>>
>> I wrote about this a bit here: https://pub.gajendra.net/2016/05/plan9part1
>>
>> (One of these years I'll get around to writing the other parts)
>>
>> - Dan C.
>>
>> > On Fri, Sep 11, 2026, 9:27 PM plat via 9fans <[email protected]> wrote:
>> >>
>> >> a, I want something more like HDMI out, but an HDMI in feature is also
>> >> pretty interesting so thank you for telling me about that. Also, a, could
>> >> you kindly check my personal email to you?
>> >>
>> >>
>> >> Dan, On Friday, September 11, 2026, at 10:25 PM, Dan Cross wrote:
>> >>
>> >> and maybe audio? unclear
>> >>
>> >> I knew how to export audio between machines, but had trouble with
>> >> graphics or control and so I requested help, and you did help me, so
>> >> thank you!
>> >>
>> >> On Friday, September 11, 2026, at 10:25 PM, Dan Cross wrote:
>> >>
>> >> or any graphical application, I suppose
>> >>
>> >> yes
>> >>
>> >> On Friday, September 11, 2026, at 10:25 PM, Dan Cross wrote:
>> >>
>> >> The idea would be that your slower speed HID devices are being accessed
>> >> remotely via 9P, while the high-bandwidth, fast video signals are using
>> >> their native electrical or optical path via whatever signaling protocol
>> >> (HDMI, DP; whatever the kids are into these days), correct?
>> >>
>> >> exactly
>> >>
>> >> On Friday, September 11, 2026, at 10:25 PM, Dan Cross wrote:
>> >>
>> >> you could `cpu` into the server machine, and then `bind
>> >> /mnt/term/dev/kbdin /dev/kbdin; bind /mnt/term/dev/mouse /dev/mouse; bind
>> >> -b '#i' /dev` (possibly others; I may have forgot something) and then
>> >> invoke `rio`; perhaps `aux/vga` as well.
>> >>
>> >> This was literally it. Thank you for the solution! I had no idea it could
>> >> work like that. Now I know
>> >>
>> >> On Friday, September 11, 2026, at 10:25 PM, Dan Cross wrote:
>> >>
>> >> It does beg the question, though: why not also just run a long USB (or
>> >> whatever) cable to the server and use it as a terminal?
>> >>
>> >> I would respond, but I got very confused as to how you would go about
>> >> connecting a second terminal in the same manner to the same server. If
>> >> you could show me an example of connecting a second terminal, I would be
>> >> very grateful. I assume if it is possible, then it is equally possible to
>> >> do it entirely without a terminal too
>> >>
>> >>
>> >> On Saturday, September 12, 2026, at 12:07 AM, C wrote:
>> >>
>> >> A question i have is where is the keyboard and mouse plugged-in that you
>> >> want bound to the namespace that is running your * video cable to
>> >> display?
>> >>
>> >> C, view my response above. Keyboard and mice are at term, video cable is
>> >> coming out of cpu
>> >>
>> >>
>> >> Thanks everyone, especially Dan Cross! But I am still interested whether
>> >> multiplexing is possible here
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T248f62cc83f47b6d-Ma3ced5f247bdffff1706427c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
