Re: nosh: User-space virtual terminal test and questions

[Guillermo <gdiazhartusch@gmail.com>]

El dom., 6 ene. 2019 a las 8:27, Jonathan de Boyne Pollard escribió:
>
> > The combination of vboxvideo with |console-fb-realizer| was explosive,
> > I got a (guest) kernel panic.
> >
> [...]
> so I'm initially going to lay that one at the door of the driver.

Yeah, I'm suspicious about the kernel module too. I didn't spend too
much time with this, I just blacklisted the module for the
console-fb-realizer tests, which gave me the VESA framebuffer device.
But I thought I should mention that it happened in case anyone else
wanted to try that, or had not experienced it.

> Try the --80-columns option
> (which prevents console-fb-realizer trying to switch to some of the
> more exciting high-resolution modes)

The option is not present if console-fb-realizer is built on
[GNU/]Linux, right? 'console-fb-realizer --help' doesn't show it, and
the C++ source file seems to have the relevant code contained inside
an #if defined(__FreeBSD__) || defined(__DragonFly__) ||
defined(__OpenBSD__) - #endif block.

> > I [...] managed to deal with the BSDness of the requirements on font
> > and keyboard map files with the help of FreeBSD's SVN repository :)
> >
> For those reading this, there is a whole chapter in the Guide on the
> multiplicity of places whence one can obtain fonts, keyboard maps, and
> input methods.  The toolset does not come with them for two major
> reasons.

Oh, I don't expect nosh to ship font and keyboard map files. That was
a humorous remark about them either having to be in a BSD-specific
format, or in a format that a BSD program (vtfontcvt) outputs.

> First, it is a deliberate design decision to use existing
> formats and not require new ones be created from scratch.

That's fine.

> > 3) More strangely, Ctrl + x (e.g. to exit from GNU nano) did not work
> > with |console-termio-realizer|, but did with |console-fb-realizer|.
> >
> Control+X is ␘ (cancel, U+0018) which cancels an in-progress ECMA-48
> escape or control sequence.
> [...]
> console-termio-realizer decodes its input with a fully-fledged ECMA-48
> decoder, [...]

So, how does one get the control character delivered to the
application? Is it possible with console-termio-realizer?

> > 4) With console-termio-realizer, green is blue and blue is green :D
> >
> Part of my usual Z shell prompt is green, so I am confident that I would
> have noticed it being blue in error.  (-:

I noticed it with GNU ls's colorized output (directories showed up
green and executable files showed up blue), and Bash's prompt, which
also happens to be green and blue, and looked reversed. This is the
value of PS1:

\[\033[01;32m\]\u@\h\[\033[01;34m\] w $\[\033[00m\]

> What terminal type is console-termio-realizer outputting to?  Is this
> a GUI terminal emulator with a colour palette that has been altered from
> the standard colour set?

Straight to a kernel VT, and I don't think the color palette is
changed from the default. This is how I lauhched
console-termio-realizer:

/etc/inittab:
us2:3:respawn:/home/guillermo/bin/start-termio-realizer

/home/guillermo/bin/start-termio-realizer:
#!/bin/nosh
foreground sleep 1 ;
vc-get-tty tty8
open-controlling-tty
vc-reset-tty
/lib/nosh/setuidgid -s user-vt-realizer
console-termio-realizer /run/dev/vc1

(Yeah, that's van Smoorenburg init. Minimal setup for ease of
troubleshooting, remember :)  )

I didn't see a console-termio-realizer (or console-ncurses-realizer)
example in nosh-bundles, maybe simple file descriptor redirections
would have sufficed, but that worked, so...

>  Is it a 24-bit-colour-capable terminal? Use
> console-control-sequence --foreground blue|console-decode-ecma48 from
> version 1.39 on that terminal.  What do you see?  SGR 34?  SGR 38;5;4?
> Or SGR 38;2;... ?

I'd have to build in-development 1.39 for that. I'll post the result
when I do that.

Thanks,
G.