Re: kernel goes dark on boot
On Mon, Jan 16, 2023 at 09:08:20AM +, Emmanuel Dreyfus wrote: > On Mon, Jan 16, 2023 at 06:50:18AM +, Emmanuel Dreyfus wrote: > > > Clearly broken firmware - is there an update available? > > Perhaps I can have more luck booting through grub, I will > > try that. > > Same problem, grub works fine, and display goes dark as soon as > the kernel is supposed to display something. I also tried NetBSD's netive EFI bootstrap with Xen and latest netbsd-XEN3_DOM0. Xen displays boot messages until xen is relinquishing vga console (not sure about the last two words, it goes really fast), then a dark screen. -- Emmanuel Dreyfus m...@netbsd.org
Add five new escape sequences to wscons
Here is a patch to implement five additional escape sequences in the wscons
vt100 emulation.
This is a port of some code that I originally wrote for OpenBSD, and which was
recently accepted into CVS there.
It's useful, because these sequences correspond to the terminfo capabilities
rin, indn, vpa, hpa, and cbt as defined in the xterm terminfo entry. With
these sequences implemented, it becomes slightly more practical to set
TERM=xterm when connecting to remote systems that don't have a comprehensive
terminfo database.
The current lack of support for cbt, vpa, and hpa is actually mentioned in
the comments in the terminfo file, (see line 2533).
--- dev/wscons/wsemul_vt100_subr.c.dist 2018-12-05 22:42:20.0 -0300
+++ dev/wscons/wsemul_vt100_subr.c 2023-01-16 08:35:17.292084228 -0300
@@ -188,7 +188,7 @@
void
wsemul_vt100_handle_csi(struct vt100base_data *edp, u_char c)
{
- int n, help, flags, fgcol, bgcol;
+ int n, m, help, flags, fgcol, bgcol;
long attr, bkgdattr;
#define A3(a, b, c) (((a) << 16) | ((b) << 8) | (c))
@@ -410,6 +410,9 @@
edp->ccol -= uimin(DEF1_ARG(edp, 0), edp->ccol);
edp->flags &= ~VTFL_LASTCHAR;
break;
+ case 'G': /* CHA */
+ edp->ccol = uimin(DEF1_ARG(edp, 0)-1, edp->ncols-1);
+ break;
case 'H': /* CUP */
case 'f': /* HVP */
if (edp->flags & VTFL_DECOM)
@@ -445,15 +448,40 @@
COPYCOLS(edp, edp->ccol + n, edp->ccol, help);
ERASECOLS(edp, NCOLS(edp) - n, n, edp->bkgdattr);
break;
+ case 'S': /* SU */
+ wsemul_vt100_scrollup (edp,DEF1_ARG(edp, 0));
+ break;
+ case 'T': /* SD */
+ wsemul_vt100_scrolldown (edp,DEF1_ARG(edp, 0));
+ break;
case 'X': /* ECH erase character */
n = uimin(DEF1_ARG(edp, 0), COLS_LEFT(edp) + 1);
ERASECOLS(edp, edp->ccol, n, edp->bkgdattr);
break;
+ case 'Z': /* CBT */
+ if (edp->ccol == 0)
+ break;
+ for (m = 0; m < DEF1_ARG(edp, 0); m++) {
+ if (edp->tabs) {
+ for (n = edp->ccol - 1; n > 0; n--) {
+ if (edp->tabs[n])
+ break;
+ }
+ } else
+ n = (edp->ccol - 1) & ~7;
+ edp->ccol = n;
+ if (n == 0)
+ break;
+ }
+ break;
case 'c': /* DA primary */
if (ARG(edp, 0) == 0)
wsdisplay_emulinput(edp->cbcookie, WSEMUL_VT_ID1,
sizeof(WSEMUL_VT_ID1));
break;
+ case 'd': /* VPA */
+ edp->crow = uimin(DEF1_ARG(edp, 0)-1, edp->nrows-1);
+ break;
case 'g': /* TBC */
KASSERT(edp->tabs != 0);
switch (ARG(edp, 0)) {
Re: Add five new escape sequences to wscons
> Here is a patch to implement five additional escape sequences in the > wscons vt100 emulation. Not to pick on this particular addition...but is it really still appropriate to call it "vt100"? It's not a very good VT-100 emulation, handling a bunch of sequences differently from VT-100s (mostly things wscons implements but VT-100s don't) and having a handful of other mismatches (such as supporting sizes other than 80x24 and 132x24). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Add five new escape sequences to wscons
On Mon, Jan 16, 2023 at 09:31:35AM -0500, Mouse wrote: > > Here is a patch to implement five additional escape sequences in the > > wscons vt100 emulation. > > Not to pick on this particular addition...but is it really still > appropriate to call it "vt100"? Not really :-). > It's not a very good VT-100 emulation, > handling a bunch of sequences differently from VT-100s (mostly things > wscons implements but VT-100s don't) and having a handful of other > mismatches (such as supporting sizes other than 80x24 and 132x24). A lot of the sequences that it supports are from later VT-series terminals.
Re: Add five new escape sequences to wscons
On Mon, Jan 16, 2023 at 09:18:53 -0300, Crystal Kolipe wrote: > It's useful, because these sequences correspond to the terminfo > capabilities rin, indn, vpa, hpa, and cbt as defined in the xterm > terminfo entry. With these sequences implemented, it becomes > slightly more practical to set TERM=xterm when connecting to remote > systems that don't have a comprehensive terminfo database. Why is is desirable to set specifically TERM=xterm instead of, say, vt220, or whichever vt entry describes wscons the closest? For multi-line scroll the patch just calls scrollup/scrolldown, but that's not what the single-line scroll commands do (see wsemul_vt100.c) I'm actually not entirely convinced that it's even correct to describe vt220 as having sf/ind scrolling capabilities, b/c the vt220 scrolling sequences take the scrolling region into account and the terminfo capabilities for scrolling are defined to operate on the whole screen as far as I can tell. So in its current form I don't think this patch is suitable and I'm not convinced it's needed at all. -uwe
Re: Add five new escape sequences to wscons
>> [wscons's "vt100" is] not a very good VT-100 emulation, handling a >> bunch of sequences differently from VT-100s (mostly things wscons >> implements but VT-100s don't) and having a handful of other >> mismatches (such as supporting sizes other than 80x24 and 132x24). > A lot of the sequences that it supports are from later VT-series > terminals. Sure, and other things from X3.64. When I did the X3.64 (and, if turned on, ISO 6429 colour SGR values) mode for my terminal emulator, I called the emulation types "ansi" and "decansi" for basically this reason. (The difference between ansi and decansi is support for various DEC extensions, such as scrolling regions or ?-flagged arguments to CSI h and CSI l.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Add five new escape sequences to wscons
On Mon, Jan 16, 2023 at 08:20:35PM +0300, Valery Ushakov wrote: > On Mon, Jan 16, 2023 at 09:18:53 -0300, Crystal Kolipe wrote: > > > It's useful, because these sequences correspond to the terminfo > > capabilities rin, indn, vpa, hpa, and cbt as defined in the xterm > > terminfo entry. With these sequences implemented, it becomes > > slightly more practical to set TERM=xterm when connecting to remote > > systems that don't have a comprehensive terminfo database. > > Why is is desirable to set specifically TERM=xterm instead of, say, > vt220, or whichever vt entry describes wscons the closest? The xterm entry supports colour, which vt220 does not. Remote systems vary in the entries they have available in their terminfo database. In the vast majority of cases it can be expected that they will have an accurate entry for xterm. Wscons is already almost usable with the xterm control sequences, and the five I've added are enough to make many curses based programs just work. > For multi-line scroll the patch just calls scrollup/scrolldown, but > that's not what the single-line scroll commands do (see > wsemul_vt100.c) The single-line scroll commands are concerned with moving the cursor. The multi-line scroll commands, as far as I understand, are supposed to scroll the entire screen, (or the scrolling region). With my patch, the behaviour of wscons matches that of xterm for these sequences. > I'm actually not entirely convinced that it's even correct to describe > vt220 as having sf/ind scrolling capabilities, b/c the vt220 scrolling > sequences take the scrolling region into account and the terminfo > capabilities for scrolling are defined to operate on the whole screen > as far as I can tell. Again, xterm does take into account the scrolling region when interpreting these sequences, so I patched wscons to do the same. > So in its current form I don't think this patch is suitable and I'm > not convinced it's needed at all. If there is really no interest then I'll drop further work on this. I've got other patches in progress for wscons so it would be nice to know. But I don't think that your arguments are very convincing, unless you are saying that xterm is also wrong in it's emulation, or there is a bug in my patch that I am not aware of.
Re: Add five new escape sequences to wscons
On Mon, Jan 16, 2023 at 15:10:06 -0300, Crystal Kolipe wrote: > On Mon, Jan 16, 2023 at 08:20:35PM +0300, Valery Ushakov wrote: > > On Mon, Jan 16, 2023 at 09:18:53 -0300, Crystal Kolipe wrote: > > > > > It's useful, because these sequences correspond to the terminfo > > > capabilities rin, indn, vpa, hpa, and cbt as defined in the xterm > > > terminfo entry. With these sequences implemented, it becomes > > > slightly more practical to set TERM=xterm when connecting to remote > > > systems that don't have a comprehensive terminfo database. > > > > Why is is desirable to set specifically TERM=xterm instead of, say, > > vt220, or whichever vt entry describes wscons the closest? > > The xterm entry supports colour, which vt220 does not. As someone who routinely runs xterm with TERM=vt220 I'm probably not qualified to comment further. > The multi-line scroll commands, as far as I understand, are supposed to > scroll the entire screen, (or the scrolling region). It's the "or the scrolling region" part that I'm not sure about. The terminfo documentation seems to indicate that the scrolling capabilities like "ind" are to operate on the whole screen. E.g. X/Open Curses, Issue 7 (p.353): To scroll text up, a program goes to the bottom left CORNER OF THE SCREEN and sends the ind (index) string. To scroll text down, a program goes to the top left CORNER OF THE SCREEN and sends the ri (reverse index) string. The strings ind and ri are undefined when not on their respective corners of the screen. On the other hand a few pages later the same document says (p.356): To determine whether a terminal has destructive scrolling regions or non-destructive scrolling regions, create a scrolling region in the middle of the screen, place data on the bottom line of the scrolling region, move the cursor to the top LINE OF THE SCROLLING REGION, and do a reverse index (ri) followed by a delete line (dl1) or index (ind). If the data that was originally on the bottom line of the scrolling region was restored into the scrolling region by dl1 or ind, then the terminal has non-destructive scrolling regions. Otherwise, it has destructive scrolling regions. I cannot find any passages that would explicitly say how ind/ri and csr interact. (Note, I'm not talking about the observed behaviour of specific xterm/vt commands, but about the semantic of terminfo capabilities as abstractly defined in the ETI). May be it's so obvious to everyone involved that "ind" and "ri" and to operate on the scrolling region that no-one even realizes that the current wording does actually say something different and you need to do exegetics on an tangential remark elsewhere in the document to be kinda able to infer that it's "screen (or the scrolling region)" -uwe
