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.