Re: MANPAGER
Hi Heinrich, Heinrich Rebehn wrote on Sun, May 30, 2021 at 10:02:41AM +0200: > I did see LESS_IS_MORE, but there were probably good reasons for > the OpenBSD devs to switch to less(1). Prosaic as it may seem, and featurism indeed feeling not too typical for OpenBSD, my reason for switching basically was that less(1) has more features and more(1) feels slightly antiquated. Besides, our implementation of more(1) is less(1) anyway under the hood, so there is little reason to artificially restrict its functionality. Also, having :t tagging enabled by default and yet calling it "more" felt a bit weird. Finally, POSIX allows using an implementation-specific pager by default as long as that is documented: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/man.html see the "PAGER" entry below "ENVIRONMENT VARIABLES": If the PAGER variable is null or not set, the command shall be either "more" or another paginator utility documented in the system documentation. > 'MANPAGER="less -X" does the trick, I was not aware that "termcap > initialization and deinitialization" is responsible for clrscreen. > I hope that disabling it completely will not have any adverse side > affects. Reading less/opttbl.c, -X sets the global no_init variable, and judging from "grep -RF no_init /usr/src/usr.bin/less/", that's only used at two places in less/screen.c, using tputs(3) to send the enter_ca_mode and exit_ca_mode strings defined in . According to terminfo(5), these two capabilities are terminal-dependent. So -X has different effects depending on which terminal or teminal emulator you are using and with which setting of the TERM variable. The worst that might happen on some terminals is that less(1) might display gibberish and/or leave the terminal in an unusable state when exiting. But i assume you will notice if -X has undesirable effects on the terminal you are using. Theoretically, fiddling with such low-level options might have security implications, putting the terminal into a state where it interprets what you are typing afterwards in a way you never intended. Then again, while printing random binary data to a terminal can definitely have security implications depending on how the terminal is configured - the default configuration of xterm(1) being quite sane on OpenBSD - i never heard about real-world security issues caused by partially skipping terminal initialization or de-initialization, so they seem somewhat unlikely. This isn't a definite statement that none exist on any terminal, though. In any case, whether less(1) clears the screen when exiting is terminal- dependent. I just tried at the PC console (Strg-Alt-F2) on the same amd64-current machine where less(1) in xterm(1) does clear the screen: at the console, at least with TERM=vt220, it does not. Yours, Ingo
Re: pflow on PE router
On 2021/06/03 15:04, Chris Cappuccio wrote: > Stuart Henderson [s...@spacehopper.org] wrote: > > > > Oh watch out with sloppy. Keep an eye on your state table size. > > Really? Wouldn't sloppy keep the state table smaller if anything since it's > tracking less specifically? > > Anyways I use sloppy across four boxes that run in parallel with pfsync. > There could easily be 10,000 devices behind it at any given time. I keep my > state table limit at 1,000,000. It's around 300,000 during this lighter > traffic period today. I had to do sloppy after moving to several boxes in > parallel, I didn't notice sloppy making any significant difference? > > Chris The problem I had was in conjunction with synfloods. I didn't get captures for everything to figure it out (it was in 2018 and my network was in flames, with the full state table bgp sessions were getting dropped / not reestablishing) but I think what happened was this, spoofed SYN to real server behind PF SYN+ACK from server and the state entry ended up as ESTABLISHED:ESTABLISHED where it remained until the tcp.established timer expired (24h default or 5h with "set optimization aggressive"). My "fix" was to move as much as possible to "pass XX flags any no state" but that's clearly not going to help with what Denis would like to do. (fwiw - I'm not doing flow monitoring regularly, but when I do it's usually via sflow on switches instead, which solves some problems, though it's only possible in some situations).
Re: Mute, FnLock keyboard LEDs don't work
On 2021-06-03, Subhaditya Nath wrote:
> Hi
>
> I have noticed that the Speaker Mute LED and the FnLock LED doesn't work on my
> Thinkpad E495.
>
>
> Behaviour of Speaker mute button -
> ---
> When pressed, it toggles the output.mute parameter in sndioctl.
> The sound is muted/unmuted.
> The LED doesn't light up in either case.
>
>
> Behaviour of FnLock button -
> -
> (I am not aware of any command to toggle FnLock from the command line)
> When pressed, it toggles the state of FnLock. (ie. the button is working)
> The LED doesn't normally light up. But, if the laptop resumes from sleep with
> FnLock enabled, then the FnLock LED lights up. But, it doesn't turn off until
> the next sleep-resume cycle.
>
> ie. effectively, the FnLock LED does work, but it is not getting refreshed. It
> only gets refreshed when the laptop is sleep and then resume.
> (Sorry for my bad english)
>
> The "refresh" issue of FnLock LED was also persistent in the Linux kernel
> till a
> few months ago. It was resolved only recently. See this -
> https://bugzilla.kernel.org/show_bug.cgi?id=207841
>
>
>
> How can these issues be fixed?
>
>
I believe this is a firmware bug.
Untested (I don't have hardware) but from the comments in the kernel.org
bug ticket and other related discussion something like this might do the
trick for fnlock. Seems like it should be safe for older thinkpads too.
I wonder if running GMKS may possibly also update the speaker mute led
too, if so it could be called from the relevant code for that too.
Index: sys/dev/acpi/acpithinkpad.c
===
RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
retrieving revision 1.68
diff -u -p -r1.68 acpithinkpad.c
--- sys/dev/acpi/acpithinkpad.c 31 Dec 2019 01:38:33 - 1.68
+++ sys/dev/acpi/acpithinkpad.c 4 Jun 2021 10:06:38 -
@@ -166,6 +166,7 @@ int thinkpad_brightness_up(struct acpith
intthinkpad_brightness_down(struct acpithinkpad_softc *);
intthinkpad_adaptive_change(struct acpithinkpad_softc *);
intthinkpad_activate(struct device *, int);
+intthinkpad_get_mediakey_status(struct acpithinkpad_softc *);
/* wscons hook functions */
void thinkpad_get_thinklight(struct acpithinkpad_softc *);
@@ -465,6 +466,10 @@ thinkpad_hotkey(struct aml_node *node, i
sc->sc_sens[THINKPAD_SENSOR_PORTREPL].status =
SENSOR_S_OK;
break;
+ case THINKPAD_BUTTON_FN_TOGGLE:
+ /* force status led to update */
+ thinkpad_get_mediakey_status(sc);
+ break;
default:
/* unknown or boring event */
DPRINTF(("%s: unhandled event 0x%03llx\n", DEVNAME(sc),
@@ -642,6 +647,18 @@ thinkpad_activate(struct device *self, i
break;
}
return (0);
+}
+
+int
+thinkpad_get_mediakey_status(struct acpithinkpad_softc *sc)
+{
+ int ret;
+ int64_t res;
+
+ ret = aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "GMKS", 0, NULL,
+ );
+
+ return ret;
}
void
Re: gaming extensions to the kernel
On 2021-06-04, Alessandro Pistocchi wrote: > I have managed to create some exciting, gaming-specific extensions to > the OpenBSD kernel, specifically for an arm64 raspberry pi 4. > > I would like to turn this into a product that people enjoy if possible > and I would be happy to make something that benefits the OpenBSD > community as well somehow. I am enjoying working on OpenBSD and am > genuinely happy to give something back if I can. > > I started a discussion on other channels about this and got quite a > bit of resistance, mainly because I wasn't planning to send diffs for > what I am doing. > > My reasoning for not sending them is that the changes I made could > create security issues for ordinary users, and I think that it would > be a nightmare to maintain only to be able to play smoother games on a > single platform, which in the grand scheme of things is quite small. > > To give you an idea, I am giving exclusive access to 3 out of 4 cpu > cores to a game and I give the game quite a few pages of contiguous > memory for the framebuffer. I give all that back to openbsd when the > game ends. OpenBSD cannot interrupt the game on those 3 cores, it can > only kill the game if needed. That's not stuff that should go into the > official kernel, right? Seems unlikely. > What I was thinking was more like "I go on and try to make and sell my > product and when I make money I donate a percentage of the profits to > the OpenBSD Foundation". > > Is that acceptable? Or alternatively, what is the "right" way of doing > something like that? I don't think there's any issue with that. The license on the code is deliberately non-restrictive. No requirement to make a donation but that certainly would be a nice thing to do.
Re: Mic mute button doesn't work
Hello,
On 2021-06-03 21:32:40 Thu, Subhaditya Nath wrote:
> Hi
>
> I have noticed that the Microphone Mute button on my Thinkpad E495 doesn't
> actually cause the Microphone to be muted.
Some time ago I noticed too that some of my Multimedia Function Keys didn't
work either on my newish Thinkpad X270 --- including the Mute Microphone one.
Even, when you try some of those keys with xev(1), nothing at all will show
up.
The expected behaviour with xev(1) for a working Multimedia Function Key would
be, for instance with F1/Mute Audio Key:
KeyRelease event, serial 33, synthetic NO, window 0x2a1,
root 0x5a6, subw 0x0, time 221798031, (150,103), root:(395,196),
state 0x0, keycode 160 (keysym 0x1008ff12, XF86AudioMute), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
When I try with F4/Mute Microphone Key, and some others, I just have nothing.
For information, the working one on the Thinkpad X270 are XF86AudioMute,
XF86AudioLowerVolume, XF86AudioRaiseVolume, plus the two for Brightness (even
if xev(1) doesn't show nothing for them).
I had the chance and opportunity to directly talk to jcs@ who explained to me
that on some relatively recent Thinkpad those missing Multimedia Keys might
not pass through since they just aren't implemented. You can check what is
available for now in `sys/dev/acpi/acpithinkpad.c'.
Unfortunately I don't have the skills to properly understand that file, not
even talking about implementing my missing keys. But if you do have those
skills, you could implement, test, and kindly send a diff to jcs@.
Sincerly,
-f6k
--
~{,_,"> gopher://shl.huld.re/1/~f6k
