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

[Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM>]

[-- Attachment #1: Type: text/plain, Size: 4570 bytes --]

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;... ?