Re: efi(4): Support for EFI variables and tables in the kernel
Hi,
On Wed, 04 Jan 2023 21:52:35 +0100
Mark Kettenis wrote:
> Dear Sergii and others,
>
> I've committed the change that passes the ESRT from the bootloader to
> the kernel. So now it is time to add the interfaces to the kernel to
> read it. And add the interfaces to manipulate EFI variables.
>
> For those out of the loop: this could allow us to run fwupd on
> OpenBSD, bringing us a way to update the firmware on many machines
> without running through several hoops like booting Windows.
>
> What it will also allow us to do is properly set a boot option for
> OpenBSD and place it at the fron of the list. Setting EFI variables
> is only allowed at securelevel 0 and below.
>
> This diff is an adaptation of the code that Sergii wrote:
>
> https://marc.info/?l=openbsd-tech=166405001006952=2
>
> A few notable changes I made to that code:
>
> * This also adds support for arm64
>
> * Uses a different device major for /dev/efi since I used an unused
> number in the middle of the table.
>
> * Renumbered some of the ioctls to avoid leaving a gap
>
> * Made self-contained.
>
> * Fixed the copyright on to match the FreeBSD file
> from which significant chunks were copied.
>
> * Reworked the error handling a bit, reducing the errors to those that
> actually can happen according to the EFI spec.
>
> Other than the location of the header file, this should all be
> consistent with the interfaces that FreeBSD and NetBSD provide.
>
> ok?
I tested the diff roughly with the test programs from
https://github.com/3mdeb/openbsd-src/tree/efivars-api on my vaio.
There is 2 tiny feedbacks. Other than these, ok yasuoka
Thanks,
>
>
> Index: etc/MAKEDEV.common
> ===
> RCS file: /cvs/src/etc/MAKEDEV.common,v
> retrieving revision 1.118
> diff -u -p -r1.118 MAKEDEV.common
> --- etc/MAKEDEV.common10 Nov 2022 09:50:00 - 1.118
> +++ etc/MAKEDEV.common4 Jan 2023 19:44:01 -
> @@ -533,3 +533,5 @@ __devitem(dt, dt, Dynamic Tracer)dnl
> _mkdev(dt, dt, {-M dt c major_dt_c 0 600-})dnl
> __devitem(kstat, kstat, Kernel Statistics)dnl
> _mkdev(kstat, kstat, {-M kstat c major_kstat_c 0 640-})dnl
> +__devitem(efi, efi, EFI runtime services)dnl
> +_mkdev(efi, efi, {-M efi c major_efi_c 0 600-})dnl
> Index: etc/etc.amd64/MAKEDEV
> ===
> RCS file: /cvs/src/etc/etc.amd64/MAKEDEV,v
> retrieving revision 1.138
> diff -u -p -r1.138 MAKEDEV
> --- etc/etc.amd64/MAKEDEV 10 Nov 2022 11:02:26 - 1.138
> +++ etc/etc.amd64/MAKEDEV 4 Jan 2023 19:44:01 -
> @@ -75,6 +75,7 @@
> #dt Dynamic Tracer
> #diskmap Disk mapper
> #dri Direct Rendering Infrastructure
> +#efi EFI runtime services
> #fd fd/* nodes
> #fuseUserland Filesystem
> #gpio* General Purpose Input/Output
> @@ -358,6 +359,10 @@ fd)
> MKlist[${#MKlist[*]}]=";chmod 555 fd"
> ;;
>
> +efi)
> + M efi c 84 0 600
> + ;;
> +
> dri)
> RMlist[${#RMlist[*]}]=";mkdir -p dri;rm -f"
> n=0
> @@ -593,19 +598,19 @@ local)
> ;;
>
> all)
> - R ipmi0 ttyVI00 ttyVI10 ttyVI20 ttyVI30 ttyVI40 dri nvram
> - R gpio0 gpio1 gpio2 bktr0 vnd0 vnd1 vnd2 vnd3 sd0 sd1 sd2 sd3
> - R sd4 sd5 sd6 sd7 sd8 sd9 cd0 cd1 rd0 tap0 tap1 tap2 tap3 tun0
> - R tun1 tun2 tun3 bio pty0 fd1 fd1B fd1C fd1D fd1E fd1F fd1G
> - R fd1H fd0 fd0B fd0C fd0D fd0E fd0F fd0G fd0H diskmap vscsi0
> - R ch0 audio0 audio1 audio2 audio3 kstat dt kcov bpf pvbus0
> - R pvbus1 vmm fuse pppac pppx hotplug ptm local wscons pci0
> - R pci1 pci2 pci3 uall rmidi0 rmidi1 rmidi2 rmidi3 rmidi4
> - R rmidi5 rmidi6 rmidi7 tuner0 radio0 speaker video0 video1 uk0
> - R random lpa0 lpa1 lpa2 lpt0 lpt1 lpt2 tty00 tty01 tty02 tty03
> - R tty04 tty05 tty06 tty07 tty08 tty09 tty0a tty0b ttyc0 ttyc1
> - R ttyc2 ttyc3 ttyc4 ttyc5 ttyc6 ttyc7 apm pf pctr wd0 wd1 wd2
> - R wd3 std st0 st1 fd
> + R efi0 ipmi0 ttyVI00 ttyVI10 ttyVI20 ttyVI30 ttyVI40 dri
> + R nvram gpio0 gpio1 gpio2 bktr0 vnd0 vnd1 vnd2 vnd3 sd0 sd1
> + R sd2 sd3 sd4 sd5 sd6 sd7 sd8 sd9 cd0 cd1 rd0 tap0 tap1 tap2
> + R tap3 tun0 tun1 tun2 tun3 bio pty0 fd1 fd1B fd1C fd1D fd1E
> + R fd1F fd1G fd1H fd0 fd0B fd0C fd0D fd0E fd0F fd0G fd0H
> + R diskmap vscsi0 ch0 audio0 audio1 audio2 audio3 kstat dt kcov
> + R bpf pvbus0 pvbus1 vmm fuse pppac pppx hotplug ptm local
> + R wscons pci0 pci1 pci2 pci3 uall rmidi0 rmidi1 rmidi2 rmidi3
> + R rmidi4 rmidi5 rmidi6 rmidi7 tuner0 radio0 speaker video0
> + R video1 uk0 random lpa0 lpa1 lpa2 lpt0 lpt1 lpt2 tty00 tty01
> + R tty02 tty03 tty04 tty05 tty06 tty07 tty08 tty09 tty0a tty0b
> + R ttyc0 ttyc1 ttyc2 ttyc3 ttyc4 ttyc5 ttyc6 ttyc7 apm pf pctr
> + R wd0 wd1 wd2 wd3 std st0 st1 fd
> ;;
>
> wd*|sd*)
> Index: etc/etc.amd64/MAKEDEV.md
>
Re: sparc64: normalize prom mappings
On 2023-01-05 12:59 p.m., Miod Vallat wrote: > tl;dr: if you have a sparc64 machine, please try this diff and report if >your system no longer works with it. Tried it on a sunblade 100; machine still boots. -- Ted Bullock
vmm: mask WAITPKG cpuid feature to hide TPAUSE
Bringing this to tech@ to increase my chance of someone testing my
diff.
As reported in this thread on misc@ [1], I believe newer Intel hardware
may be experiencing issues hosting Linux guests under vmm/vmd. It looks
like there are some newer instructions Intel added (TPAUSE specifically)
that also involve some new MSR(s).
I don't have 12th gen Intel hardware to test this on (I think that's
Alder Lake). I'd like to mask this feature from vmm guests since it's
related to an MSR we don't yet pass through or emulate and has to do
with the TSC (which has it's own challenges in vmm).
For someone testing, you should be able to grab an Alpine Linux iso
(-virt flavor) and boot it with vmd with the diff. (Without it should
"hang" and spike CPU or just die.) Also check that WAITPKG shows up in
your dmesg on the cpu feature output.
-dv
[1] https://marc.info/?l=openbsd-misc=167305289410551=2
diff refs/heads/master refs/heads/vmm-tsleep
commit - 515b7b0d87d9ff8cd5eae1449555f3d6e625fa49
commit + 6343cff9c1cfbbf9ba2cb06cfeca507caa06fc8c
blob - 001a437045be145322be30288c1f47d63fb07634
blob + 0bd908e273a1c0e6324e1bc9f8c8ca921555c86f
--- sys/arch/amd64/amd64/identcpu.c
+++ sys/arch/amd64/amd64/identcpu.c
@@ -208,6 +208,7 @@ const struct {
{ SEFF0ECX_AVX512VBMI, "AVX512VBMI" },
{ SEFF0ECX_UMIP,"UMIP" },
{ SEFF0ECX_PKU, "PKU" },
+ { SEFF0ECX_WAITPKG, "WAITPKG" },
}, cpu_seff0_edxfeatures[] = {
{ SEFF0EDX_AVX512_4FNNIW, "AVX512FNNIW" },
{ SEFF0EDX_AVX512_4FMAPS, "AVX512FMAPS" },
blob - cbde6cf9b02fc882a8ed17aa6adb5c43249e0302
blob + b26bd32e2d9ea7386b1f58960dea40b787d6a341
--- sys/arch/amd64/include/specialreg.h
+++ sys/arch/amd64/include/specialreg.h
@@ -201,6 +201,7 @@
#define SEFF0ECX_AVX512VBMI0x0002 /* AVX-512 vector bit inst */
#define SEFF0ECX_UMIP 0x0004 /* UMIP support */
#define SEFF0ECX_PKU 0x0008 /* Page prot keys for user mode */
+#define SEFF0ECX_WAITPKG 0x0010 /* UMONITOR/UMWAIT/TPAUSE insns */
/* SEFF EDX bits */
#define SEFF0EDX_AVX512_4FNNIW 0x0004 /* AVX-512 neural network insns */
#define SEFF0EDX_AVX512_4FMAPS 0x0008 /* AVX-512 mult accum single prec */
blob - 6b4802abf4b508495cdbc961bd799d3fa83b9c36
blob + bbe10bd4cfd7e778132eca1d97594e10513ac172
--- sys/arch/amd64/include/vmmvar.h
+++ sys/arch/amd64/include/vmmvar.h
@@ -672,7 +672,12 @@ struct vm_mprotect_ept_params {
SEFF0EBX_AVX512IFMA | SEFF0EBX_AVX512PF | \
SEFF0EBX_AVX512ER | SEFF0EBX_AVX512CD | \
SEFF0EBX_AVX512BW | SEFF0EBX_AVX512VL)
-#define VMM_SEFF0ECX_MASK ~(SEFF0ECX_AVX512VBMI)
+/*
+ * Copy from host minus:
+ * AVX-512 vector bit (SEFF0ECX_AVX512VBMI)
+ * UMONITOR/UMWAIT/TPAUSE (SEFF0ECX_WAITPKG)
+ */
+#define VMM_SEFF0ECX_MASK ~(SEFF0ECX_AVX512VBMI | SEFF0ECX_WAITPKG)
/* EDX mask contains the bits to include */
#define VMM_SEFF0EDX_MASK (SEFF0EDX_MD_CLEAR)
blob - 310208ac4cdb262aaedfa9b78d869fd5911607b2
blob + ccf1164fd658a69dc383e1602ae0ce1f269de4e4
--- sys/arch/i386/i386/machdep.c
+++ sys/arch/i386/i386/machdep.c
@@ -1038,6 +1038,7 @@ const struct cpu_cpuid_feature cpu_seff0_ecxfeatures[]
{ SEFF0ECX_UMIP,"UMIP" },
{ SEFF0ECX_AVX512VBMI, "AVX512VBMI" },
{ SEFF0ECX_PKU, "PKU" },
+ { SEFF0ECX_WAITPKG, "WAITPKG" },
};
const struct cpu_cpuid_feature cpu_seff0_edxfeatures[] = {
blob - 392b4ff412e2dd3c4c48ed6c9c84aa2358721c6a
blob + 7ce77ca3fdc6bd1a51571dd0b5dbf5afc311a138
--- sys/arch/i386/include/specialreg.h
+++ sys/arch/i386/include/specialreg.h
@@ -190,6 +190,7 @@
#define SEFF0ECX_AVX512VBMI0x0002 /* AVX-512 vector bit inst */
#define SEFF0ECX_UMIP 0x0004 /* UMIP support */
#define SEFF0ECX_PKU 0x0008 /* Page prot keys for user mode */
+#define SEFF0ECX_WAITPKG 0x0010 /* UMONITOR/UMWAIT/TPAUSE insns */
/* SEFF EDX bits */
#define SEFF0EDX_AVX512_4FNNIW 0x0004 /* AVX-512 neural network insns */
#define SEFF0EDX_AVX512_4FMAPS 0x0008 /* AVX-512 mult accum single prec */
[patch 3/3] towards TERM=xterm
# Obviously :) --- /etc/ttys.dist Fri Dec 23 13:58:58 2022 +++ /etc/ttys Sat Jan 7 14:44:26 2023 @@ -3,19 +3,19 @@ # # name getty typestatus comments # -console"/usr/libexec/getty std.9600" vt220 off secure -ttyC0 "/usr/libexec/getty std.9600" vt220 on secure -ttyC1 "/usr/libexec/getty std.9600" vt220 on secure -ttyC2 "/usr/libexec/getty std.9600" vt220 on secure -ttyC3 "/usr/libexec/getty std.9600" vt220 on secure -ttyC4 "/usr/libexec/getty std.9600" vt220 off secure -ttyC5 "/usr/libexec/getty std.9600" vt220 on secure -ttyC6 "/usr/libexec/getty std.9600" vt220 off secure -ttyC7 "/usr/libexec/getty std.9600" vt220 off secure -ttyC8 "/usr/libexec/getty std.9600" vt220 off secure -ttyC9 "/usr/libexec/getty std.9600" vt220 off secure -ttyCa "/usr/libexec/getty std.9600" vt220 off secure -ttyCb "/usr/libexec/getty std.9600" vt220 off secure +console"/usr/libexec/getty std.9600" xterm off secure +ttyC0 "/usr/libexec/getty std.9600" xterm on secure +ttyC1 "/usr/libexec/getty std.9600" xterm on secure +ttyC2 "/usr/libexec/getty std.9600" xterm on secure +ttyC3 "/usr/libexec/getty std.9600" xterm on secure +ttyC4 "/usr/libexec/getty std.9600" xterm off secure +ttyC5 "/usr/libexec/getty std.9600" xterm on secure +ttyC6 "/usr/libexec/getty std.9600" xterm off secure +ttyC7 "/usr/libexec/getty std.9600" xterm off secure +ttyC8 "/usr/libexec/getty std.9600" xterm off secure +ttyC9 "/usr/libexec/getty std.9600" xterm off secure +ttyCa "/usr/libexec/getty std.9600" xterm off secure +ttyCb "/usr/libexec/getty std.9600" xterm off secure tty00 "/usr/libexec/getty std.9600" unknown off tty01 "/usr/libexec/getty std.9600" unknown off tty02 "/usr/libexec/getty std.9600" unknown off
[patch 2/3] towards TERM=xterm
# New escape sequences and two one-line bugfixes
--- dev/wscons/wsemul_vt100_subr.c.dist Mon May 25 06:55:49 2020
+++ dev/wscons/wsemul_vt100_subr.c Sat Jan 7 12:39:58 2023
@@ -231,7 +231,7 @@
switch (A3(edp->modif1, edp->modif2, c)) {
case A3('>', '\0', 'c'): /* DA secondary */
wsdisplay_emulinput(edp->cbcookie, WSEMUL_VT_ID2,
- sizeof(WSEMUL_VT_ID2));
+ sizeof(WSEMUL_VT_ID2)-1);
break;
case A3('\0', '\0', 'J'): /* ED selective erase in display */
@@ -461,6 +461,9 @@
edp->ccol -= min(DEF1_ARG(0), edp->ccol);
edp->flags &= ~VTFL_LASTCHAR;
break;
+ case 'G': /* HPA */
+ edp->ccol = min(DEF1_ARG(0)-1, edp->ncols-1);
+ break;
case 'H': /* CUP */
case 'f': /* HVP */
if (edp->flags & VTFL_DECOM)
@@ -502,16 +505,37 @@
WSEMULOP(rc, edp, >abortstate, erasecols,
ERASECOLS(NCOLS - n, n, edp->bkgdattr));
break;
+ case 'S': /* INDN */
+ wsemul_vt100_scrollup (edp,DEF1_ARG(0));
+ break;
+ case 'T': /* RIN */
+ wsemul_vt100_scrolldown (edp,DEF1_ARG(0));
+ break;
case 'X': /* ECH erase character */
n = min(DEF1_ARG(0), COLS_LEFT + 1);
WSEMULOP(rc, edp, >abortstate, erasecols,
ERASECOLS(edp->ccol, n, edp->bkgdattr));
break;
+ case 'Z': /* KCBT */
+ if (!edp->ccol)
+ break;
+ if (edp->tabs) {
+ for (n=edp->ccol-1 ; n>0; n--)
+ if (edp->tabs[n])
+ break;
+ } else {
+ n=((edp->ccol - 1) & 8);
+ }
+ edp->ccol=n;
+ break;
case 'c': /* DA primary */
if (ARG(0) == 0)
wsdisplay_emulinput(edp->cbcookie, WSEMUL_VT_ID1,
- sizeof(WSEMUL_VT_ID1));
+ sizeof(WSEMUL_VT_ID1)-1);
break;
+ case 'd': /* VPA */
+ edp->crow = min(DEF1_ARG(0)-1, edp->nrows-1);
+ break;
case 'g': /* TBC */
if (edp->tabs != NULL)
switch (ARG(0)) {
@@ -549,6 +573,12 @@
case 1: /* bold */
flags |= WSATTR_HILIT;
break;
+ case 2: /* dim */
+ flags |= WSATTR_DIM;
+ break;
+ case 3: /* italic */
+ flags |= WSATTR_ITALIC;
+ break;
case 4: /* underline */
flags |= WSATTR_UNDERLINE;
break;
@@ -558,11 +588,31 @@
case 7: /* reverse */
flags |= WSATTR_REVERSE;
break;
- case 22: /* ~bold VT300 only */
+ /*
+* Invisible text only makes the _glyph_ invisible.
+*
+* Other active attributes such as underlining and
+* strikeout are still displayed in the character cell.
+*/
+ case 8: /* invisible */
+ flags |= WSATTR_INVISIBLE;
+ break;
+ case 9: /* strike */
+ flags |= WSATTR_STRIKE;
+ break;
+ case 21: /* double underline */
+ flags |= WSATTR_DOUBLE_UNDERLINE;
+ break;
+ case 22: /* ~bold ~dim VT300 only */
flags &= ~WSATTR_HILIT;
+ flags &= ~WSATTR_DIM;
break;
+ case 23: /* ~italic */
+ flags &= ~WSATTR_ITALIC;
+ break;
case 24: /* ~underline VT300 only */
flags &= ~WSATTR_UNDERLINE;
+ flags &= ~WSATTR_DOUBLE_UNDERLINE;
break;
case 25: /* ~blink VT300 only */
flags &= ~WSATTR_BLINK;
@@ -570,12 +620,76 @@
case 27: /* ~reverse VT300 only */
flags &= ~WSATTR_REVERSE;
break;
+ case 28: /* ~invisible */
+ flags &= ~WSATTR_INVISIBLE;
+
[patch 1/3] towards TERM=xterm
# New key function key definitions
--- dev/wscons/wsemul_vt100_keys.c.dist Sat Mar 14 00:38:50 2015
+++ dev/wscons/wsemul_vt100_keys.c Mon Jan 2 16:01:42 2023
@@ -37,11 +37,9 @@
#include
#include
+#define vt100_fkeys_len(x) (5+(x>=8)+(x>=12))
+
static const u_char *vt100_fkeys[] = {
- "\033[11~", /* F1 */
- "\033[12~",
- "\033[13~", /* F1-F5 normally don't send codes */
- "\033[14~",
"\033[15~", /* F5 */
"\033[17~", /* F6 */
"\033[18~",
@@ -50,18 +48,18 @@
"\033[21~",
"\033[23~", /* VT100: ESC */
"\033[24~", /* VT100: BS */
- "\033[25~", /* VT100: LF */
- "\033[26~",
- "\033[28~", /* help */
- "\033[29~", /* do */
- "\033[31~",
- "\033[32~",
- "\033[33~",
- "\033[34~", /* F20 */
- "\033[35~",
- "\033[36~",
- "\033[37~",
- "\033[38~"
+ "\033[1;2P",/* VT100: LF */
+ "\033[1;2Q",
+ "\033[1;2R",/* help */
+ "\033[1;2S",/* do */
+ "\033[15;2~",
+ "\033[17;2~",
+ "\033[18;2~",
+ "\033[19;2~", /* F20 */
+ "\033[20;2~",
+ "\033[21;2~",
+ "\033[23;2~",
+ "\033[24;2~"
};
static const u_char *vt100_pfkeys[] = {
@@ -96,14 +94,22 @@
edp->translatebuf, edp->flags & VTFL_UTF8));
}
- if (in >= KS_f1 && in <= KS_f24) {
- *out = vt100_fkeys[in - KS_f1];
- return (5);
+ if (in >= KS_f1 && in <= KS_f4) {
+ *out = vt100_pfkeys[in - KS_f1];
+ return (3);
}
- if (in >= KS_F1 && in <= KS_F24) {
- *out = vt100_fkeys[in - KS_F1];
- return (5);
+ if (in >= KS_F1 && in <= KS_F4) {
+ *out = vt100_pfkeys[in - KS_F1];
+ return (3);
}
+ if (in >= KS_f5 && in <= KS_f24) {
+ *out = vt100_fkeys[in - KS_f5];
+ return vt100_fkeys_len(in - KS_f5);
+ }
+ if (in >= KS_F5 && in <= KS_F24) {
+ *out = vt100_fkeys[in - KS_F5];
+ return vt100_fkeys_len(in - KS_F5);
+ }
if (in >= KS_KP_F1 && in <= KS_KP_F4) {
*out = vt100_pfkeys[in - KS_KP_F1];
return (3);
@@ -148,12 +154,12 @@
}
switch (in) {
case KS_Help:
- *out = vt100_fkeys[15 - 1];
+ *out = vt100_fkeys[15 - 1 + 4]; /* vt100_fkeys starts at F5 */
return (5);
case KS_Execute: /* "Do" */
- *out = vt100_fkeys[16 - 1];
+ *out = vt100_fkeys[16 - 1 + 4]; /* vt100_fkeys starts at F5 */
return (5);
- case KS_Find:
+ case KS_Find: /* Not defined in xterm
terminfo */
*out = "\033[1~";
return (4);
case KS_Insert:
@@ -163,7 +169,7 @@
case KS_KP_Delete:
*out = "\033[3~";
return (4);
- case KS_Select:
+ case KS_Select: /* Not defined in xterm
terminfo */
*out = "\033[4~";
return (4);
case KS_Prior:
@@ -174,14 +180,27 @@
case KS_KP_Next:
*out = "\033[6~";
return (4);
+ case KS_Backtab:
+ *out = "\033[Z";
+ return (3);
+ /*
+* Unlike insert, delete, page up, and page down, we purposely don't
+* send the same sequence of \033OE for the non-keypad 'begin' key.
+*
+* This is because the terminfo xterm entry is mapping this to kb2,
+* which is defined as 'centre of keypad'.
+*/
+ case KS_KP_Begin:
+ *out = "\033OE";
+ return (3);
case KS_Home:
case KS_KP_Home:
- *out = "\033[7~";
- return (4);
+ *out = "\033OH";
+ return (3);
case KS_End:
case KS_KP_End:
- *out = "\033[8~";
- return (4);
+ *out = "\033OF";
+ return (3);
case KS_Up:
case KS_KP_Up:
if (edp->flags & VTFL_APPLCURSOR)
--- dev/wscons/wsksymdef.h.dist Mon Sep 20 14:32:39 2021
+++ dev/wscons/wsksymdef.h Mon Jan 2 15:48:18 2023
@@ -626,6 +626,7 @@
#define KS_Open0xf393
#define KS_Paste 0xf394
#define KS_Cut 0xf395
+#define KS_Backtab 0xf396
#define KS_Menu0xf3c0
#define KS_Pause 0xf3c1
--- dev/pckbc/wskbdmap_mfii.c.dist Sat May 1 13:11:16 2021
+++ dev/pckbc/wskbdmap_mfii.c Mon Jan 2 13:51:12 2023
@@ -59,7 +59,7 @@
KC(12),KS_minus, KS_underscore,
KC(13),
[patch 0/3] towards TERM=xterm
On Sat, Jan 07, 2023 at 02:46:04PM +, Nicholas Marriott wrote: > If possible can you now give me your latest patches without 256 colours and > I will test them and see if we can get them in. Sure, here is the latest version with _most_ of the 256 colour stuff removed. I've left in the CSI 38/48 parsing, because it's effectively a bug fix - not having it will break programs that assume it's there without checking terminfo, because they will set unwanted attributes as we discussed earlier. I first noticed this running telescope -C with TERM=xterm, and got bold, underline, dim, etc, instead of colours in the colour picker. However, even on plain 7.2-release, you get bold if you send CSI [ 38;5;1m which is a bug. It will currently only ever set colours 0-7, not even the bright versions. The only other 256 thing in there is a new define in wsdisplayvar.h for a flag which is checked by the 38/48 code, but in this version will always be unset, (because I've removed the code that sets it if bpp==32). Note that I've left the 90/100 code parsing in, to set the 'bright' colours directly, because this is expected of normal 16-colour xterm. So even with this patch we can use TERM=xterm-16color instead of TERM=xterm. If this code can go in and get plenty of testing then hopefully we can add the 256 colour stuff back in afterwards. But I'm quietly confident that this first step shouldn't cause any serious breakage. Patches are in three separate emails to follow.
Re: Making wscons a bit more like xterm
Some programs will always ignore terminfo and make their own guesses, that's just the nature of terminfo, not much to be done about it. I meant ignore bold in combination with 256 colours, not ignore it entirely. But if you can come up with some scheme to display it then go for it. If possible can you now give me your latest patches without 256 colours and I will test them and see if we can get them in. Probably best to split them into three: new escape sequences, additional key sequences, and bug fixes to existing code. On Sat, 7 Jan 2023, 12:05 Crystal Kolipe, wrote: > On Sat, Jan 07, 2023 at 11:09:00AM +, Nicholas Marriott wrote: > > As far as SGR 38/48 with anything except 2 and 5 goes - the only > terminals > > I have at hand do not discard but I think either of discarding or not > > discarding would be reasonable. What does xterm do here? It would > probably > > be best to do the same. > > Xterm only ignores the unknown argument immediately following the 38/48, > but > interprets the rest. So SGR 38;9;1m sets bold. > > I've changed my code to do the same. > > > On terminals with fewer than 256 colours, I think the sequence should > > probably do nothing. > > I've seen one program that uses it when colours <= 8, but that seems to > have > been an oversight. > > > I would be inclined to just ignore bold together with 256 colours (that > is, > > don't make bold change anything) as the terminal only supports bright and > > not true bold. > > Hummm. That would break existing behaviour in a few cases. > > Although most users are not seeing colour at all on the console, anyone who > has set TERM=pccon currently has working bold in programs that parse > terminfo. > > Also there are obviously programs that just assume ansi sequences are > recognised. Bold is such an old and basic attribute that it's pretty > reasonable to assume that it is implemented somehow on any modern terminal > that implements any ansi sequences. > > > Making an alternative colour map which is brighter would be > > possible, although I haven't seen any terminals that do that. > > That's interesting. Although it would be nicer to have a real bold font. > Maybe just printing the exising font twice, offset one pixel to the right > would work for that? > > Regarding 256 colour support in general, this is very much a late addition > to > the whole project of making the console usable with the xterm terminfo > entry. > > I'm quite enthusiastic about adding it now, but if it's going to make the > original goal of s/vt220/xterm in /etc/ttys less attractive because it > causes > breakage in obscure corner cases, then I can always drop the 256 colour > part. > > Although to be honest, I think that the rest of the patchset without the > 256 colour support is already very close to being usable. Even as it is, > it's > an overall improvement because it fixes several exising bugs. > > In any case, I'll post an updated version with 256 in an hour or so. >
Re: Making wscons a bit more like xterm
Ah, here is a trivial program to demo the new 256 color palette on the console:
#include
int main()
{
int i;
printf ("\x1b[m\n");
for (i=0;i<256;i++) {
printf ("\x1b[38;5;%dm#%03d %s",i,i, ((i+1) % 16 ? "" : "\n"));
}
printf ("\x1b[m\n");
for (i=0;i<256;i++) {
printf ("\x1b[48;5;%dm#%03d %s",i,i, ((i+1) % 16 ? "" : "[m\n"));
}
printf ("\x1b[m\n");
}
Re: Making wscons a bit more like xterm
On Sat, Jan 07, 2023 at 09:05:21AM -0300, Crystal Kolipe wrote:
> In any case, I'll post an updated version with 256 in an hour or so.
It's here!
NEW - 256 colour support! (Not extensively tested yet).
NEW - Interpret SGR 38/48 sequences instead of just discarding the following
parameters.
NEW - Implement SGR 9x and 10x sequences to select 'bright' foreground and
background colours, (I.E. colours 8 - 15), directly.
- All the features of the previous patches.
So this version is mostly to add 256 colour support. This was mainly a
consequence of needing to do something with SGR 38/48 in order to avoid
programs that use them directly setting unwanted attributes.
Resume of code changes:
* Adds a new WSSCREEN_256COL capability which is currently set for 32bpp
displays only.
* When running in 32bpp, the device colour map is re-programmed for colours
16 - 255.
* Several 4-bit fields have been expanded to 8-bit.
* Resizes ri_devcmap from 16 to 256 entries.
* Bold, which is implemented as higher intensity, is limited to the eight
'normal' colours. (This might change in a later version.)
Notes:
* Please test for regressions and breakage.
* The plain 'xterm' terminfo entry doesn't support 256 colours, so you
probably want to use TERM=xterm-256color instead.
* However testing with plain TERM=xterm is definitely still needed!
* Programs that ignore terminfo and send ansi sequences directly will also
benefit from testing.
Question:
There is a comment in rasops.c saying that the last 16 colours should be the
inverse of the first 16. However, from reading the code this seems to apply
only if we are both using a palletised display _and_ using rasops_do_cursor
instead of rasops_wronly_do_cursor.
(The comment pre-dates the addition of rasops_wronly_do_cursor by many years.)
Or have I missed something? Should I update the comment?
--- dev/wscons/wsemul_vt100_keys.c.dist Sat Mar 14 00:38:50 2015
+++ dev/wscons/wsemul_vt100_keys.c Mon Jan 2 16:01:42 2023
@@ -37,11 +37,9 @@
#include
#include
+#define vt100_fkeys_len(x) (5+(x>=8)+(x>=12))
+
static const u_char *vt100_fkeys[] = {
- "\033[11~", /* F1 */
- "\033[12~",
- "\033[13~", /* F1-F5 normally don't send codes */
- "\033[14~",
"\033[15~", /* F5 */
"\033[17~", /* F6 */
"\033[18~",
@@ -50,18 +48,18 @@
"\033[21~",
"\033[23~", /* VT100: ESC */
"\033[24~", /* VT100: BS */
- "\033[25~", /* VT100: LF */
- "\033[26~",
- "\033[28~", /* help */
- "\033[29~", /* do */
- "\033[31~",
- "\033[32~",
- "\033[33~",
- "\033[34~", /* F20 */
- "\033[35~",
- "\033[36~",
- "\033[37~",
- "\033[38~"
+ "\033[1;2P",/* VT100: LF */
+ "\033[1;2Q",
+ "\033[1;2R",/* help */
+ "\033[1;2S",/* do */
+ "\033[15;2~",
+ "\033[17;2~",
+ "\033[18;2~",
+ "\033[19;2~", /* F20 */
+ "\033[20;2~",
+ "\033[21;2~",
+ "\033[23;2~",
+ "\033[24;2~"
};
static const u_char *vt100_pfkeys[] = {
@@ -96,14 +94,22 @@
edp->translatebuf, edp->flags & VTFL_UTF8));
}
- if (in >= KS_f1 && in <= KS_f24) {
- *out = vt100_fkeys[in - KS_f1];
- return (5);
+ if (in >= KS_f1 && in <= KS_f4) {
+ *out = vt100_pfkeys[in - KS_f1];
+ return (3);
}
- if (in >= KS_F1 && in <= KS_F24) {
- *out = vt100_fkeys[in - KS_F1];
- return (5);
+ if (in >= KS_F1 && in <= KS_F4) {
+ *out = vt100_pfkeys[in - KS_F1];
+ return (3);
}
+ if (in >= KS_f5 && in <= KS_f24) {
+ *out = vt100_fkeys[in - KS_f5];
+ return vt100_fkeys_len(in - KS_f5);
+ }
+ if (in >= KS_F5 && in <= KS_F24) {
+ *out = vt100_fkeys[in - KS_F5];
+ return vt100_fkeys_len(in - KS_F5);
+ }
if (in >= KS_KP_F1 && in <= KS_KP_F4) {
*out = vt100_pfkeys[in - KS_KP_F1];
return (3);
@@ -148,12 +154,12 @@
}
switch (in) {
case KS_Help:
- *out = vt100_fkeys[15 - 1];
+ *out = vt100_fkeys[15 - 1 + 4]; /* vt100_fkeys starts at F5 */
return (5);
case KS_Execute: /* "Do" */
- *out = vt100_fkeys[16 - 1];
+ *out = vt100_fkeys[16 - 1 + 4]; /* vt100_fkeys starts at F5 */
return (5);
- case KS_Find:
+ case KS_Find: /* Not defined in xterm
terminfo */
*out = "\033[1~";
return (4);
case KS_Insert:
@@ -163,7 +169,7 @@
case KS_KP_Delete:
*out = "\033[3~";
return (4);
- case KS_Select:
+ case KS_Select:
Re: Making wscons a bit more like xterm
On Sat, Jan 07, 2023 at 11:09:00AM +, Nicholas Marriott wrote: > As far as SGR 38/48 with anything except 2 and 5 goes - the only terminals > I have at hand do not discard but I think either of discarding or not > discarding would be reasonable. What does xterm do here? It would probably > be best to do the same. Xterm only ignores the unknown argument immediately following the 38/48, but interprets the rest. So SGR 38;9;1m sets bold. I've changed my code to do the same. > On terminals with fewer than 256 colours, I think the sequence should > probably do nothing. I've seen one program that uses it when colours <= 8, but that seems to have been an oversight. > I would be inclined to just ignore bold together with 256 colours (that is, > don't make bold change anything) as the terminal only supports bright and > not true bold. Hummm. That would break existing behaviour in a few cases. Although most users are not seeing colour at all on the console, anyone who has set TERM=pccon currently has working bold in programs that parse terminfo. Also there are obviously programs that just assume ansi sequences are recognised. Bold is such an old and basic attribute that it's pretty reasonable to assume that it is implemented somehow on any modern terminal that implements any ansi sequences. > Making an alternative colour map which is brighter would be > possible, although I haven't seen any terminals that do that. That's interesting. Although it would be nicer to have a real bold font. Maybe just printing the exising font twice, offset one pixel to the right would work for that? Regarding 256 colour support in general, this is very much a late addition to the whole project of making the console usable with the xterm terminfo entry. I'm quite enthusiastic about adding it now, but if it's going to make the original goal of s/vt220/xterm in /etc/ttys less attractive because it causes breakage in obscure corner cases, then I can always drop the 256 colour part. Although to be honest, I think that the rest of the patchset without the 256 colour support is already very close to being usable. Even as it is, it's an overall improvement because it fixes several exising bugs. In any case, I'll post an updated version with 256 in an hour or so.
Re: Making wscons a bit more like xterm
On terminals with fewer than 256 colours, I think the sequence should probably do nothing. I would be inclined to just ignore bold together with 256 colours (that is, don't make bold change anything) as the terminal only supports bright and not true bold. Making an alternative colour map which is brighter would be possible, although I haven't seen any terminals that do that. On Fri, 6 Jan 2023, 18:42 Crystal Kolipe, wrote: > On Fri, Jan 06, 2023 at 06:21:41PM +, Nicholas Marriott wrote: > > You should strictly only discard the following two arguments or stuff > like > > SGR 38;5;100;1 won't work. > > Well I was initially in two minds about that, because I thought there > might be > other un-official extensions that used 38 with a varying number of > parameters. > > But I haven't found any apart from 5 followed by one argument, and 2 > followed > by three RGB values, so yes I agree with you on this. > > However, since this morning I've been working on actually implementing 256 > colour support so the next version of the patch will parse SGR 38;5 > sequences > correctly. > > Presumably though, if we see SGR 38;X where X is neither 2 nor 5, we still > have to discard everything, right? Because that would be an invalid > sequence > and we don't know for sure whether anything that comes after it is actually > intended as regular control codes or parameters for something else. > > I.E. > > SGR 38;5;X - we set colour X. > SGR 38;2;X;X;X - we discard three parameters, then continue parsing. > SGR 38;Y; - where Y is 'something else', we ignore everything until the > 'm'. > > Or is there a better way? > > Regarding 256 colour support, I've got it working, (on 32bpp displays > only), > but there are two open questions: > > 1. On displays that don't support 256 colours, (e.g. VGA console), what > should >SGR 38;5;X do? I currently have it set so that it selects colours 0-7, > and >for 8-255 just does nothing, (leaves the current colour). > > 2. We implement bold as brighter text rather than a bold font. This > doesn't >work very well with a 256 colour palette. We can't just +8 to get a > bright >version of the colour. How should bold work with arbitrary colours? > > > This is why some people prefer the : form but the ship has rather sailed > on > > that. > > I'm assuming that we don't really need to implement the : form? > > Thanks again for the feedback. >
Re: Making wscons a bit more like xterm
IIRC xterm-direct uses the : form for RGB colour but xterm-256color does not use it for 256 colours, so for 256 colours you can no doubt get away without it. As far as SGR 38/48 with anything except 2 and 5 goes - the only terminals I have at hand do not discard but I think either of discarding or not discarding would be reasonable. What does xterm do here? It would probably be best to do the same. On Fri, 6 Jan 2023, 18:42 Crystal Kolipe, wrote: > On Fri, Jan 06, 2023 at 06:21:41PM +, Nicholas Marriott wrote: > > You should strictly only discard the following two arguments or stuff > like > > SGR 38;5;100;1 won't work. > > Well I was initially in two minds about that, because I thought there > might be > other un-official extensions that used 38 with a varying number of > parameters. > > But I haven't found any apart from 5 followed by one argument, and 2 > followed > by three RGB values, so yes I agree with you on this. > > However, since this morning I've been working on actually implementing 256 > colour support so the next version of the patch will parse SGR 38;5 > sequences > correctly. > > Presumably though, if we see SGR 38;X where X is neither 2 nor 5, we still > have to discard everything, right? Because that would be an invalid > sequence > and we don't know for sure whether anything that comes after it is actually > intended as regular control codes or parameters for something else. > > I.E. > > SGR 38;5;X - we set colour X. > SGR 38;2;X;X;X - we discard three parameters, then continue parsing. > SGR 38;Y; - where Y is 'something else', we ignore everything until the > 'm'. > > Or is there a better way? > > Regarding 256 colour support, I've got it working, (on 32bpp displays > only), > but there are two open questions: > > 1. On displays that don't support 256 colours, (e.g. VGA console), what > should >SGR 38;5;X do? I currently have it set so that it selects colours 0-7, > and >for 8-255 just does nothing, (leaves the current colour). > > 2. We implement bold as brighter text rather than a bold font. This > doesn't >work very well with a 256 colour palette. We can't just +8 to get a > bright >version of the colour. How should bold work with arbitrary colours? > > > This is why some people prefer the : form but the ship has rather sailed > on > > that. > > I'm assuming that we don't really need to implement the : form? > > Thanks again for the feedback. >
Re: ifconfig.c - redundancy
On Fri, Jan 06, 2023 at 09:46:13PM +0100, Mathias Koehler wrote: > lines 1911 - 1913 and 1917 - 1919 are code blocks that are looking > identical. I cannot imagine that that is on purpose. What do you > really wanna express here? Just quoting line numbers does not help a lot. You were looking at the code, so quote the lines, making things easier for the readers of the list. Looking at the cvs history it seems it was simply overlooked the two blocks are the same. The best way to approach this is to come up with a diff. The makes your message explicit and helps to improve the code base. If the two blocks should *not* be the same, it is very likely a developer with knowledge of this area will be triggered by a diff as well. In short: we prefer to talk in diffs, because there are explicit, actionable, not ambiguous and so focus the discourse. -Otto
