#uservt — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #uservt, aggregated by home.social.
-
Just for fun I created a Shavian QWERTY keyboard map for #FreeBSD.
The hard part turned out to be that I had to work from pictures of layout diagrams, and tiny ones at that, cross-referencing them by eye against a Unicode chart. No-one has a text list of what Shavian alphabet characters go with what keys.
I named it gb-shaw, of course.
-
Just for fun I created a Shavian QWERTY keyboard map for #FreeBSD.
The hard part turned out to be that I had to work from pictures of layout diagrams, and tiny ones at that, cross-referencing them by eye against a Unicode chart. No-one has a text list of what Shavian alphabet characters go with what keys.
I named it gb-shaw, of course.
-
Just for fun I created a Shavian QWERTY keyboard map for #FreeBSD.
The hard part turned out to be that I had to work from pictures of layout diagrams, and tiny ones at that, cross-referencing them by eye against a Unicode chart. No-one has a text list of what Shavian alphabet characters go with what keys.
I named it gb-shaw, of course.
-
The #nosh Guide has a whole chapter going into a lot more detail on HID configuration; which can range at the administrator's discretion from explicitly choosing accept-all-HIDs to a strong stance on supernumerary, misbehaving, or downright malicious #HumanInputDevices.
Given that I was one of several people who proposed going this way in the 1990s, it is long past the time that recompiling one's kernel was the way to choose what #HumanInputDevices to trust.
http://jdebp.info/Softwares/nosh/guide/user-virtual-terminal-configuration.html
-
The #nosh Guide has a whole chapter going into a lot more detail on HID configuration; which can range at the administrator's discretion from explicitly choosing accept-all-HIDs to a strong stance on supernumerary, misbehaving, or downright malicious #HumanInputDevices.
Given that I was one of several people who proposed going this way in the 1990s, it is long past the time that recompiling one's kernel was the way to choose what #HumanInputDevices to trust.
http://jdebp.info/Softwares/nosh/guide/user-virtual-terminal-configuration.html
-
The #nosh Guide has a whole chapter going into a lot more detail on HID configuration; which can range at the administrator's discretion from explicitly choosing accept-all-HIDs to a strong stance on supernumerary, misbehaving, or downright malicious #HumanInputDevices.
Given that I was one of several people who proposed going this way in the 1990s, it is long past the time that recompiling one's kernel was the way to choose what #HumanInputDevices to trust.
http://jdebp.info/Softwares/nosh/guide/user-virtual-terminal-configuration.html
-
Just so that anyone coming across this #OpenBSD idea has any questions about the #nosh user-space virtual terminals:
In nosh uservts, USB HIDs are opt-in; whereas with most kernel VTs & X11, USB HIDs are opt-out.
The administrator has to explicitly choose (in the ways laid out in user-vt-realizer-configuration(5) which allow various combinations of address, class, and ID matching) to have a #YubiKey realized as a keyboard HID on the #uservt.
-
Just so that anyone coming across this #OpenBSD idea has any questions about the #nosh user-space virtual terminals:
In nosh uservts, USB HIDs are opt-in; whereas with most kernel VTs & X11, USB HIDs are opt-out.
The administrator has to explicitly choose (in the ways laid out in user-vt-realizer-configuration(5) which allow various combinations of address, class, and ID matching) to have a #YubiKey realized as a keyboard HID on the #uservt.
-
Just so that anyone coming across this #OpenBSD idea has any questions about the #nosh user-space virtual terminals:
In nosh uservts, USB HIDs are opt-in; whereas with most kernel VTs & X11, USB HIDs are opt-out.
The administrator has to explicitly choose (in the ways laid out in user-vt-realizer-configuration(5) which allow various combinations of address, class, and ID matching) to have a #YubiKey realized as a keyboard HID on the #uservt.
-
Right.
I've got Debian and FreeBSD systems with both the system and service manager running things, and a NetBSD system with just the service manager; all of the services under service management; a sprinkling of many of the #djbwares services running, including regular clock synchronization with sntpclock, dnscache, and tinydns private roots; and my test HP USB 104-key keyboard auto-connecting to the #uservt system when plugged in.
I'm running out of release blockers. (-:
-
Right.
I've got Debian and FreeBSD systems with both the system and service manager running things, and a NetBSD system with just the service manager; all of the services under service management; a sprinkling of many of the #djbwares services running, including regular clock synchronization with sntpclock, dnscache, and tinydns private roots; and my test HP USB 104-key keyboard auto-connecting to the #uservt system when plugged in.
I'm running out of release blockers. (-:
-
Right.
I've got Debian and FreeBSD systems with both the system and service manager running things, and a NetBSD system with just the service manager; all of the services under service management; a sprinkling of many of the #djbwares services running, including regular clock synchronization with sntpclock, dnscache, and tinydns private roots; and my test HP USB 104-key keyboard auto-connecting to the #uservt system when plugged in.
I'm running out of release blockers. (-:
-
It's actually a bit wild sitting at a full-screen non-X11 system with a monitor, mouse, and keyboard and being able to type things like the interrobang with AltGr+Shift+? as a matter of course.
No more cumbersome gymnastics with NeoVIM. I can just type the damn character. (-:
-
It's actually a bit wild sitting at a full-screen non-X11 system with a monitor, mouse, and keyboard and being able to type things like the interrobang with AltGr+Shift+? as a matter of course.
No more cumbersome gymnastics with NeoVIM. I can just type the damn character. (-:
-
It's actually a bit wild sitting at a full-screen non-X11 system with a monitor, mouse, and keyboard and being able to type things like the interrobang with AltGr+Shift+? as a matter of course.
No more cumbersome gymnastics with NeoVIM. I can just type the damn character. (-:
-
It's actually a bit wild sitting at a full-screen non-X11 system with a monitor, mouse, and keyboard and being able to type things like the interrobang with AltGr+Shift+? as a matter of course.
No more cumbersome gymnastics with NeoVIM. I can just type the damn character. (-:
-
It's actually a bit wild sitting at a full-screen non-X11 system with a monitor, mouse, and keyboard and being able to type things like the interrobang with AltGr+Shift+? as a matter of course.
No more cumbersome gymnastics with NeoVIM. I can just type the damn character. (-:
-
There are some things that are going to be known problems with the new releases, because they'd been planned for a subsequent release back before COVID Lockdown, and I really do not want to hold up what is already years late with writing new features.
So the realizers for user-space virtual terminals will only work on dumb framebuffers for this release; because using dri was one such after-this-coming-release items.
-
There are some things that are going to be known problems with the new releases, because they'd been planned for a subsequent release back before COVID Lockdown, and I really do not want to hold up what is already years late with writing new features.
So the realizers for user-space virtual terminals will only work on dumb framebuffers for this release; because using dri was one such after-this-coming-release items.
-
There are some things that are going to be known problems with the new releases, because they'd been planned for a subsequent release back before COVID Lockdown, and I really do not want to hold up what is already years late with writing new features.
So the realizers for user-space virtual terminals will only work on dumb framebuffers for this release; because using dri was one such after-this-coming-release items.
-
There are some things that are going to be known problems with the new releases, because they'd been planned for a subsequent release back before COVID Lockdown, and I really do not want to hold up what is already years late with writing new features.
So the realizers for user-space virtual terminals will only work on dumb framebuffers for this release; because using dri was one such after-this-coming-release items.
-
There are some things that are going to be known problems with the new releases, because they'd been planned for a subsequent release back before COVID Lockdown, and I really do not want to hold up what is already years late with writing new features.
So the realizers for user-space virtual terminals will only work on dumb framebuffers for this release; because using dri was one such after-this-coming-release items.
-
It doesn't look quite right on a 16:9 HDMI display with a 16 by 16 font. It lacks the pixellation and CRT blurring. And the cursor is wrong. So @ColinHaynes still has the better. (-:
But it's not bad for a non-X11 framebuffer Unicode-capable terminal emulator on a #RaspberryPi running #NetBSD with the #CommodorePET and BBC character sets.
-
It doesn't look quite right on a 16:9 HDMI display with a 16 by 16 font. It lacks the pixellation and CRT blurring. And the cursor is wrong. So @ColinHaynes still has the better. (-:
But it's not bad for a non-X11 framebuffer Unicode-capable terminal emulator on a #RaspberryPi running #NetBSD with the #CommodorePET and BBC character sets.
-
It doesn't look quite right on a 16:9 HDMI display with a 16 by 16 font. It lacks the pixellation and CRT blurring. And the cursor is wrong. So @ColinHaynes still has the better. (-:
But it's not bad for a non-X11 framebuffer Unicode-capable terminal emulator on a #RaspberryPi running #NetBSD with the #CommodorePET and BBC character sets.
-
(That was the BBC font. This is the #CommodorePET font.)
The various tools from #djbwares are operational and run happily as managed services, including local DNS service, some publicfile services, and synchronizing the #RaspberryPi's clock using Bernstein's sntpclock fed into clockadd.
-
(That was the BBC font. This is the #CommodorePET font.)
The various tools from #djbwares are operational and run happily as managed services, including local DNS service, some publicfile services, and synchronizing the #RaspberryPi's clock using Bernstein's sntpclock fed into clockadd.
-
(That was the BBC font. This is the #CommodorePET font.)
The various tools from #djbwares are operational and run happily as managed services, including local DNS service, some publicfile services, and synchronizing the #RaspberryPi's clock using Bernstein's sntpclock fed into clockadd.
-
A #nosh user-space virtual terminal being realized onto the HDMI display of a #RaspberryPi running #NetBSD.
The realizer is console-kvt-realizer, and the framebuffer was dumped to PPM format with framebuffer-dump (to be converted to JFIF using netpbm tools). The login screen is a ttylogin@vc3-tty service, managed by service-manager, and using login-envuidgid.
Yes, it is being multiplexed with two others, and has an input method layered on top.
-
A #nosh user-space virtual terminal being realized onto the HDMI display of a #RaspberryPi running #NetBSD.
The realizer is console-kvt-realizer, and the framebuffer was dumped to PPM format with framebuffer-dump (to be converted to JFIF using netpbm tools). The login screen is a ttylogin@vc3-tty service, managed by service-manager, and using login-envuidgid.
Yes, it is being multiplexed with two others, and has an input method layered on top.
-
A #nosh user-space virtual terminal being realized onto the HDMI display of a #RaspberryPi running #NetBSD.
The realizer is console-kvt-realizer, and the framebuffer was dumped to PPM format with framebuffer-dump (to be converted to JFIF using netpbm tools). The login screen is a ttylogin@vc3-tty service, managed by service-manager, and using login-envuidgid.
Yes, it is being multiplexed with two others, and has an input method layered on top.
-
I have been writing doco.
https://jdebp.uk/Softwares/nosh/guide/user-virtual-terminal-configuration.html
-
I have been writing doco.
https://jdebp.uk/Softwares/nosh/guide/user-virtual-terminal-configuration.html
-
I have been writing doco.
https://jdebp.uk/Softwares/nosh/guide/user-virtual-terminal-configuration.html
-
My code (because of the way that #USB #HumanInputDevices work) has to store button/key press information as an array of boolean flags in two distinct places (1 local and 1 shared), so of course it has array bounds checks.
The Elecom Deft's report descriptor bug had me looking for quite a time for where I'd accidentally put the wrong bounds check on mouse button values.
-
My code (because of the way that #USB #HumanInputDevices work) has to store button/key press information as an array of boolean flags in two distinct places (1 local and 1 shared), so of course it has array bounds checks.
The Elecom Deft's report descriptor bug had me looking for quite a time for where I'd accidentally put the wrong bounds check on mouse button values.
-
My code (because of the way that #USB #HumanInputDevices work) has to store button/key press information as an array of boolean flags in two distinct places (1 local and 1 shared), so of course it has array bounds checks.
The Elecom Deft's report descriptor bug had me looking for quite a time for where I'd accidentally put the wrong bounds check on mouse button values.
-
Here's what I invented:
It's the #ECMA48 FNK control sequence with leading parameter characters for private extensions:
USB keyboard page keys have a leading '?' (modelled after DEC extensions).
USB consumer page keys have a leading '=' (modelled after SCO extensions).
Key numbers are the USB usage codes in those pages. Modifiers are encoded as a sub-parameter, DEC values minus 1, allowing multiple keys per control sequence. Sub-parameters default to 0.
-
Here's what I invented:
It's the #ECMA48 FNK control sequence with leading parameter characters for private extensions:
USB keyboard page keys have a leading '?' (modelled after DEC extensions).
USB consumer page keys have a leading '=' (modelled after SCO extensions).
Key numbers are the USB usage codes in those pages. Modifiers are encoded as a sub-parameter, DEC values minus 1, allowing multiple keys per control sequence. Sub-parameters default to 0.
-
Here's what I invented:
It's the #ECMA48 FNK control sequence with leading parameter characters for private extensions:
USB keyboard page keys have a leading '?' (modelled after DEC extensions).
USB consumer page keys have a leading '=' (modelled after SCO extensions).
Key numbers are the USB usage codes in those pages. Modifiers are encoded as a sub-parameter, DEC values minus 1, allowing multiple keys per control sequence. Sub-parameters default to 0.
-
I feel very much at the cutting edge of 1996 with console-usb-ugen-realizer supporting the actual USB HID usages of both [00] and [±] on calculator keypads, as well as a whole load of other such keys e.g. [%], [⌦], [(], and [)].
I get the impression from my test devices not sending even [00] that operating systems have not generally done this; and that today in 2025 I am in the vanguard of supporting things that have been on electronic calculators since the 1970s.
-
I feel very much at the cutting edge of 1996 with console-usb-ugen-realizer supporting the actual USB HID usages of both [00] and [±] on calculator keypads, as well as a whole load of other such keys e.g. [%], [⌦], [(], and [)].
I get the impression from my test devices not sending even [00] that operating systems have not generally done this; and that today in 2025 I am in the vanguard of supporting things that have been on electronic calculators since the 1970s.
-
I feel very much at the cutting edge of 1996 with console-usb-ugen-realizer supporting the actual USB HID usages of both [00] and [±] on calculator keypads, as well as a whole load of other such keys e.g. [%], [⌦], [(], and [)].
I get the impression from my test devices not sending even [00] that operating systems have not generally done this; and that today in 2025 I am in the vanguard of supporting things that have been on electronic calculators since the 1970s.
-
I feel very much at the cutting edge of 1996 with console-usb-ugen-realizer supporting the actual USB HID usages of both [00] and [±] on calculator keypads, as well as a whole load of other such keys e.g. [%], [⌦], [(], and [)].
I get the impression from my test devices not sending even [00] that operating systems have not generally done this; and that today in 2025 I am in the vanguard of supporting things that have been on electronic calculators since the 1970s.
-
I feel very much at the cutting edge of 1996 with console-usb-ugen-realizer supporting the actual USB HID usages of both [00] and [±] on calculator keypads, as well as a whole load of other such keys e.g. [%], [⌦], [(], and [)].
I get the impression from my test devices not sending even [00] that operating systems have not generally done this; and that today in 2025 I am in the vanguard of supporting things that have been on electronic calculators since the 1970s.
-
I had a moment sort of like that the other day when I put myself into the input method editor without the Japanese keyboard plugged in, and I couldn't immediately remember without reading my own manual page what the old IMLIB way of exiting an input method editor in ASCII control sequences was. (-:
I had forgotten because normally I just mouse click on the TUI widgets that I get over SSH; but I was locally using the machine's physical keyboard.
-
I had a moment sort of like that the other day when I put myself into the input method editor without the Japanese keyboard plugged in, and I couldn't immediately remember without reading my own manual page what the old IMLIB way of exiting an input method editor in ASCII control sequences was. (-:
I had forgotten because normally I just mouse click on the TUI widgets that I get over SSH; but I was locally using the machine's physical keyboard.
-
I had a moment sort of like that the other day when I put myself into the input method editor without the Japanese keyboard plugged in, and I couldn't immediately remember without reading my own manual page what the old IMLIB way of exiting an input method editor in ASCII control sequences was. (-:
I had forgotten because normally I just mouse click on the TUI widgets that I get over SSH; but I was locally using the machine's physical keyboard.
-
I had a moment sort of like that the other day when I put myself into the input method editor without the Japanese keyboard plugged in, and I couldn't immediately remember without reading my own manual page what the old IMLIB way of exiting an input method editor in ASCII control sequences was. (-:
I had forgotten because normally I just mouse click on the TUI widgets that I get over SSH; but I was locally using the machine's physical keyboard.
-
I had a moment sort of like that the other day when I put myself into the input method editor without the Japanese keyboard plugged in, and I couldn't immediately remember without reading my own manual page what the old IMLIB way of exiting an input method editor in ASCII control sequences was. (-:
I had forgotten because normally I just mouse click on the TUI widgets that I get over SSH; but I was locally using the machine's physical keyboard.