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

From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups_at_NTLWorld.COM>
Date: Sun, 6 Jan 2019 11:27:47 +0000

Guillermo:

> The combination of vboxvideo with |console-fb-realizer| was explosive,
> I got a (guest) kernel panic.
>
|console-fb-realizer| does not employ the arcana of framebuffer I/O, it
just using little more than the mode setting API and memory mapped I/O,
so I'm initially going to lay that one at the door of the driver. I
have had poor experiences with it myself. Try the |--80-columns| option
(which prevents |console-fb-realizer| trying to switch to some of the
more exciting high-resolution modes) and ensure that your driver exactly
matches your kernel version.

I currently test |console-fb-realizer| on real hardware. (-:

Guillermo:

> 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. First, it is a deliberate design decision to use existing
formats and not require new ones be created from scratch. Second, they
come under a variety of copyright licences, and it is simpler to just
keep those separate. Quite a few of them are already packaged up for
operating systems. I discovered /yet another/ collection of input
method files just recently ... in a Debian package.

Guillermo:

> 1) What is the proper way (if any) to switch between kernel VTs and
> user-space VTs?
>
|console-fb-realizer| does not have hot key chords for initiating KVT
switching that get stripped out of input processing and enacted
locally. All such chords are sent down the input FIFO to a /user-space/
VT multiplexor. It could have, as there is room for such a specialized
type of actions in the keyboard map. Since I need to do more work on
having multiple keyboard maps in a single |console-fb-realizer|
instance, I might look into it. But at the moment
|console-multiplexor-control| pointed at a KVT is the tool, and I am not
going to hold off 1.39 specifically for this. I was going to do that
work in 1.40.

Guillermo:

> 2) Key combinations with Alt (e.g. Alt + f or Alt + b to move forward
> or backward one word on Bash) did not work with neither
> |console-fb-realizer| nor |console-termio-realizer|. Any idea why, or
> does this just happen to me?
>
I have an idea why. I have put improving it on the to-do list. It's not
you. (-:

Guillermo:

> 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. This is documented in ECMA-48:1991 § 8.3.6
and in § 4.3.5 of DEC's _VT520/VT525 Video Terminal Programmer Information_.

|console-termio-realizer| decodes its input with a fully-fledged ECMA-48
decoder, that implements the DEC/ECMA-documented behaviours of both ␘
and ␛ on the decoding state machine; rather than with a perennially
incomplete collection of ad-hoc pattern recognitions as
|console-ncurses-realizer| does. It's the same decoder that
|console-terminal-emulator| uses for output. You can see ␘ in action
with the new |console-decode-ecma48| tool in 1.39, which also uses the
same decoder. Type in an incomplete CSI sequence by hand, and cancel it
with ␘. It will be discarded. The same will happen if you print one
and cancel it, as output to the terminal emulator.

Although it would be entirely legitimate for a terminal to send ␘ in the
middle of (say) a DECFNK control sequence in order to cancel it, it
would be unusual, so I'll add another exception to ECMA-48 decoding for
this, that |console-termio-realizer| can select.

ECMA-48 is of course nothing to do with the input protocols that
|console-fb-realizer| speaks with its input devices.

Guillermo:

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

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? 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;... ?
Received on Sun Jan 06 2019 - 11:27:47 UTC