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.
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
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 als
# 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 s
# 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
# 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[] = {
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/
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 ca
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 ("\
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.
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 b
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
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
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
14 matches
Mail list logo
