Re: Audio control API, part 1: libsndio, sndiod bits
On Sun, Feb 09, 2020 at 12:13:02PM GMT, Alexandre Ratchov wrote: > +++ lib/libsndio/sioctl_aucat.c 8 Feb 2020 14:49:37 - > [...] > + * Copyright (c) 2010-2011 Alexandre Ratchov > > [...] > > +++ lib/libsndio/sioctl_open.38 Feb 2020 14:49:37 - > [...] > +.\" Copyright (c) 2011 Alexandre Ratchov > > [...] > > +++ lib/libsndio/sioctl_priv.h8 Feb 2020 14:49:38 - > [...] > + * Copyright (c) 2008 Alexandre Ratchov > > [...] > > +++ lib/libsndio/sioctl_sun.c 8 Feb 2020 14:49:38 - > [...] > + * Copyright (c) 2010-2011 Alexandre Ratchov > > [...] > > +++ lib/libsndio/sioctl.c 8 Feb 2020 14:49:37 - > [...] > + * Copyright (c) 2008 Alexandre Ratchov > > [...] > > +++ usr.bin/sndioctl/sndioctl.1 9 Feb 2020 11:05:02 - > [...] > +.\" Copyright (c) 2007 Alexandre Ratchov > > [...] > > +++ usr.bin/sndioctl/sndioctl.c 9 Feb 2020 11:05:02 - > [...] > + * Copyright (c) 2007-2011 Alexandre Ratchov > > [...] > > +++ usr.bin/sndiod/dev_sioctl.c 8 Feb 2020 14:49:38 - > [...] > + * Copyright (c) 2014 Alexandre Ratchov > > [...] > > +++ usr.bin/sndiod/dev_sioctl.h 8 Feb 2020 14:49:38 - > [...] > + * Copyright (c) 2014 Alexandre Ratchov > > [...] > Hi Alexandre, Shouldn't all of these dates be adjusted? Regards, Raf
Re: Audio control API, part 2: add new sndioctl(1) utility
On Mon, Feb 10, 2020 at 09:14:57PM GMT, Alexandre Ratchov wrote:
> On Mon, Feb 10, 2020 at 09:59:09AM +, Raf Czlonka wrote:
> > On Sun, Feb 09, 2020 at 12:14:47PM GMT, Alexandre Ratchov wrote:
> > > Here's a new sndioctl utility similar to mixerctl(1) but using the new
> > > sndio API. Example:
> > >
> > > $ sndioctl
> > > output.level=127
> > > app/aucat0.level=127
> > > app/firefox0.level=127
> > > app/firefox1.level=12
> > > app/midisyn0.level=127
> > > app/mpv0.level=127
> > > app/prog5.level=127
> > > app/prog6.level=127
> > > app/prog7.level=127
> > > hw/input.level=62
> > > hw/input.mute=0
> > > hw/output.level=63
> > > hw/output.mute=0
> > >
> >
> > Hi Alexandre,
> >
> > Just a quick question.
> >
> > Is there a good reason to have the above using "slash" ('/') as the
> > first separator instead of the, more familiar, "dot" ('.') known
> > from sysctl(8)'s MIB (Management Information Base) style names or
> > even the "pseudo" MIB know from mixerctl(1)?
>
> Hi,
>
> I don't know if the following qualifies as a "good reason". The first
> part (the group) is a prefix of the control identifier. The identifier
> itself has a strict "[channel]." format. The prefix
> is not always present, examples:
>
> output.level<- sndiod volume knob
> hw/output.level <- underlying hardware volume knob
>
> I tried to avoid the group part, but as mixers may be nested it seems
> necessary to avoid name clashes.
>
> In the sndioctl syntax, we could replace '/' by '.' but this looks
> confusing as the syntax doesn't map directly to the underlying
> model. But maybe we should hide such developer-centric details and
> just use only dots to make this look as a MIB.
>
> Another option I've considered is to drop the group concept in the API
> and simply prefix the stream name to make it unique; in turn we obtain
> a flat control list. It's uglier and seems to complicate GUIs
> task. For instance the group part could be used to represent controls
> of different groups in different sections or to filter-out certain
> groups).
Hi Alexandre,
I honestly can't tell which one of these would be "better" - best
if others chime in.
I was thinking only from a "uniform" interface angle, i.e. if (some
of) these are to be set from the command line, and its similarity
to MIB-like mixerctl(1) variables, I suspect it might cause some
"muscle memory"-related issues ;^)
If no one else shares it, then I rest my case.
Either way, thanks for the explanation.
Regards,
Raf
Re: Audio control API, part 1: libsndio, sndiod bits
On Tue, Feb 11, 2020 at 07:15:00PM GMT, Alexandre Ratchov wrote: > On Tue, Feb 11, 2020 at 07:01:28PM +0100, Florian Obser wrote: > > I've been running the base diffs since you posted them. Firefox, > > chrome and mpv still make noise :) > > > > I'm puzzled by this: > > > > $ cat /etc/mixerctl.conf > > > > outputs.master=255,255 > > record.enable=off > > > > $ mixerctl outputs.master > > > > outputs.master=255,255 > > > > $ sndioctl > > output.level=127 > > > > I don't understand how they relate and why one goes to 255 and the > > other to 127. > > The error reporting is confusing, too: > > > > $ sndioctl output.level=128 > > > > integer overflow > > > > But no regressions to report :) > > > > Thanks, the code is base on MIDI bits, which uses the 0..127 range; > sndiod, aucat and many codecs also use the 0..127 range. Anyway, > replaced the error message by: > > $ sndioctl output.level=128 > 128: expected integer in the 0..127 range > > [...] > > I'm wondering if persents or floating points in the [0:1] range would > be less confusing and solve most "units" problems. > Hi Alexandre, I have to say that I also find the two ranges mildly confusing, i.e. 0-255 in one place, and 0-127 in another. In terms of units, personally, I'm used to, and quite like, the granularity of 0-255. Again, not my place so others will certainly be more help here. One more point regarding the interface, though. This is the way mixerctl(1) currently behaves: $ mixerctl outputs.master outputs.master=255,255 $ mixerctl outputs.master=100 outputs.master: 255,255 -> 100,100 $ mixerctl outputs.master=300 outputs.master: 100,100 -> 255,255 Should sndioctl(1) behave the same way? Cheers, Raf
Re: [PATCH] make cwm parse /etc/ssh/ssh_known_hosts (global known hosts) as well as user's known_hosts
On Wed 2020.02.12 at 22:03 +0100, Solene Rapenne wrote: > On Wed, Feb 12, 2020 at 07:15:36PM +0100, Franz Bettag wrote: > > Dear OpenBSD folks, > > > > appended you will find a patch allowing cwm to also parse the contents > > of /etc/ssh/ssh_known_hosts and thus extend the ssh menu. > > > > the diff was taken against the latest source on the github xenocara repo. > > > > comments and/or feedback is much appreciated. > > > > thanks for considering this. :) > > > > best regards > > seems people agreed to remove this feature 3 weeks ago but it's still > not committed. > > https://marc.info/?l=openbsd-tech=157972423522573=2 There's a lot of private diapproval; one person gave an alternative (thank you), which might be feasible in some way, but I'm still unconvinced any of this belongs in a wm. At this point I don't care enough - it is not getting in the way, but I object to giving it more features; once this thing gets in the way, it's another story.
Re: apmd: fix autoaction timeout
On Wed, Feb 12, 2020 at 01:35:22PM +0100, Jeremie Courreges-Anglas wrote: > On Wed, Feb 12 2020, Jeremie Courreges-Anglas wrote: > > On Sat, Jan 25 2020, Jeremie Courreges-Anglas wrote: > >> The diff below improves the way apmd -z/-Z may trigger. > >> > >> I think the current behavior is bogus, incrementing and checking > >> apmtimeout like this doesn't make much sense. > >> > >> Here's a proposal: > >> - on APM_POWER_CHANGE events, check the battery level and trigger > >> autoaction if needed. This should be enough to make autoaction just > >> work with drivers like acpibat(4). > >> - on kevent timeout (10mn by default now, maybe too long), also check > >> the battery level and suspend if needed. This should be useful only > >> if your battery driver doesn't send any APM_POWER_CHANGE event. > >> > >> While here I also tweaked the warning. > > > > This has been committed, thanks Ted. > > > >> Some more context: > >> - a subsequent diff would reorder the code to handle similarly the "!rv" > >> and "ev->ident == ctl_fd" paths > > > > Diff below. > > > >> - I think we want some throttling mechanism, like wait for 1mn after we > >> resume before autosuspending again. But I want to fix obvious > >> problems first. > > On top of the previous diff, here's a diff to block autoaction for 60 > seconds after: > - autoaction triggers; this prevents apmd from sending multiple suspend > requests before the system goes to sleep > - a resume happens; this gives you 60 seconds to fetch and plug your AC > cable if you notice you're low on power > > A side effect is that apmd now ignores stale acpiac(4) data at resume > time, so it apmd doesn't suspend the system again when you resume with > a low battery and AC plugged. > > cc'ing Scott since he has a thing for everything time-related. :) For the first case, is there any way you can detect that a suspend is in-progress but not done yet? I think that'd be cleaner (in some ways) than an autoaction cooldown timer. Whenever I want to add an arbitrary delay that isn't per se required by an interface I wonder whether I'm working around a deficiency in the state machine instead of addressing the root cause. Sometimes it can't be helped, but I have to ask. For the second case, I thought the design of autoaction was to (a) note that the battery was below a particular threshold and (b) take action to avert data loss. If you resume from suspend with battery below the threshold and no AC I think you would *want* autoaction to trigger. Like, it sounds like the state machine is working as designed. If the machine is immediately suspending after resume shouldn't you just plug it in before reattempting resume? Isn't that better than having the battery die on you?
Re: nep(4) rx error interrupts
On Tue, Feb 11, 2020 at 06:44:12AM +1000, Jonathan Matthew wrote:
> On Mon, Feb 10, 2020 at 02:04:06PM +0100, Mark Kettenis wrote:
> > Jonathan Matthew schreef op 2020-02-10 13:19:
> > > I'm trying to use aggr on top of nep(4), which has turned up a few bugs.
> > > Firstly, the nic appears to report rx errors in the second interrupt
> > > state vector, which the driver doesn't expect, so I get this:
> > >
> > > nep3: nep_intr 0 8 0
> > >
> > > and then, since the interrupt wasn't rearmed, the interface stops.
> > >
> > > Then, the driver doesn't clear rx error interrupt sources, so rearming
> > > results in an interrupt storm. The illumos nxge driver masks off
> > > read-only
> > > bits in the rx status register and writes it back, clearing all active
> > > interrupt sources, so I've done that here too.
> > >
> > > ok?
> > >
> > >
> > > Index: if_nep.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/pci/if_nep.c,v
> > > retrieving revision 1.31
> > > diff -u -p -r1.31 if_nep.c
> > > --- if_nep.c 9 Nov 2018 14:14:31 - 1.31
> > > +++ if_nep.c 10 Feb 2020 11:57:44 -
> > > @@ -333,11 +333,24 @@
> > > #define RX_DMA_ENT_MSK(chan) (DMC + 0x00068 + (chan) * 0x00200)
> > > #define RX_DMA_ENT_MSK_RBR_EMPTY(1ULL << 3)
> > > #define RX_DMA_CTL_STAT(chan)(DMC + 0x00070 + (chan) * 0x00200)
> > > +#define RX_DMA_CTL_STAT_DC_FIFO_ERR (1ULL << 48)
> > > #define RX_DMA_CTL_STAT_MEX (1ULL << 47)
> > > #define RX_DMA_CTL_STAT_RCRTHRES(1ULL << 46)
> > > #define RX_DMA_CTL_STAT_RCRTO (1ULL << 45)
> > > +#define RX_DMA_CTL_STAT_PORT_DROP_PKT (1ULL << 42)
> > > +#define RX_DMA_CTL_STAT_WRED_DROP (1ULL << 41)
> > > +#define RX_DMA_CTL_STAT_RBR_PRE_EMTY(1ULL << 40)
> > > +#define RX_DMA_CTL_STAT_RCR_SHDW_FULL (1ULL << 39)
> > > #define RX_DMA_CTL_STAT_RBR_EMPTY (1ULL << 35)
> > > #define RX_DMA_CTL_STAT_PTRREAD_SHIFT 16
> > > +#define RX_DMA_CTL_STAT_WR1C_BITS (RX_DMA_CTL_STAT_RBR_EMPTY | \
> > > + RX_DMA_CTL_STAT_RCR_SHDW_FULL | \
> > > + RX_DMA_CTL_STAT_RBR_PRE_EMTY | \
> > > + RX_DMA_CTL_STAT_WRED_DROP | \
> > > + RX_DMA_CTL_STAT_PORT_DROP_PKT | \
> > > + RX_DMA_CTL_STAT_RCRTO | \
> > > + RX_DMA_CTL_STAT_RCRTHRES | \
> > > + RX_DMA_CTL_STAT_DC_FIFO_ERR)
> > > #define RX_DMA_CTL_STAT_DBG(chan) (DMC + 0x00098 + (chan) * 0x00200)
> > >
> > > #define TX_LOG_PAGE_VLD(chan)(FZC_DMC + 0x4 + (chan) * 0x00200)
> > > @@ -959,7 +972,7 @@ nep_intr(void *arg)
> > > rearm = 1;
> > > }
> > >
> > > - if (sv0 & (1ULL << LDN_RXDMA(sc->sc_port))) {
> > > + if ((sv0 | sv1) & (1ULL << LDN_RXDMA(sc->sc_port))) {
> >
> > This doesn't make sense to me.
> >
> > I suppose you see a bit getting set in sv1. Which bit is that?
>
> The same bit that gets set in sv0 under normal rx conditions.
> For nep3, sv1 is 8, on nep1 it's 2. You can see the illumos driver
> doing the same thing here:
>
> https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/io/nxge/nxge_hw.c#L274
Or, we could mask off the non-fatal rx error interrupts,
which also fixes the problem I'm seeing.
Does this look better to you?
Index: if_nep.c
===
RCS file: /cvs/src/sys/dev/pci/if_nep.c,v
retrieving revision 1.31
diff -u -p -r1.31 if_nep.c
--- if_nep.c9 Nov 2018 14:14:31 - 1.31
+++ if_nep.c12 Feb 2020 22:10:56 -
@@ -332,12 +332,29 @@
#define RX_DMA_ENT_MSK(chan) (DMC + 0x00068 + (chan) * 0x00200)
#define RX_DMA_ENT_MSK_RBR_EMPTY (1ULL << 3)
+#define RX_DMA_ENT_MSK_WRED_DROP (1ULL << 9)
+#define RX_DMA_ENT_MSK_PTDROP_PKT (1ULL << 10)
+#define RX_DMA_ENT_MSK_RBR_PRE_PAR(1ULL << 11)
+#define RX_DMA_ENT_MSK_RCR_SHA_PAR(1ULL << 12)
#define RX_DMA_CTL_STAT(chan) (DMC + 0x00070 + (chan) * 0x00200)
+#define RX_DMA_CTL_STAT_DC_FIFO_ERR (1ULL << 48)
#define RX_DMA_CTL_STAT_MEX (1ULL << 47)
#define RX_DMA_CTL_STAT_RCRTHRES (1ULL << 46)
#define RX_DMA_CTL_STAT_RCRTO (1ULL << 45)
+#define RX_DMA_CTL_STAT_PORT_DROP_PKT (1ULL << 42)
+#define RX_DMA_CTL_STAT_WRED_DROP (1ULL << 41)
+#define RX_DMA_CTL_STAT_RBR_PRE_EMTY (1ULL << 40)
+#define RX_DMA_CTL_STAT_RCR_SHDW_FULL (1ULL << 39)
#define RX_DMA_CTL_STAT_RBR_EMPTY (1ULL << 35)
#define RX_DMA_CTL_STAT_PTRREAD_SHIFT 16
+#define RX_DMA_CTL_STAT_WR1C_BITS (RX_DMA_CTL_STAT_RBR_EMPTY | \
+RX_DMA_CTL_STAT_RCR_SHDW_FULL | \
+RX_DMA_CTL_STAT_RBR_PRE_EMTY | \
+RX_DMA_CTL_STAT_WRED_DROP | \
+
Re: Audio control API, part 1: libsndio, sndiod bits
On Feb 12 21:38:56, a...@caoua.org wrote: > On Wed, Feb 12, 2020 at 09:22:20PM +0100, Jan Stary wrote: > > Hi, > > > > On Feb 09 13:13:02, a...@caoua.org wrote: > > > cd /usr/src > > > patch -p0 <1.diff > > > patch -p0 <2.diff > > > patch -p0 <3.diff > > > cd /usr/src/include && doas make includes > > > cd /usr/src/lib/libsndio && make obj && make && doas make install > > > cd /usr/src/lib/libossaudio && make obj && make && doas make install > > > cd /usr/src/usr.bin/sndiod && make obj && make && doas make install > > > cd /usr/src/usr.bin/sndioctl && make obj && make && doas make install > > > doas rcctl restart sndiod > > > > > > I'm very interested in any regression. > > > > After restarting sndiod (with empty flags), > > starting sndioctl -m makes sndiod crash with > > > > Feb 12 21:02:31 box /bsd: sndiod[95433]: pledge "tty", syscall 54 > > > > That's ioctl(2). I don't see that in any of the three pledge(2) calls > > revealed by a grep in (the patched) .../sndiod/, but apparently > > the new code does call ioctl(). > > sndiod does unauthorized ioctls on this kernel, see below > > > > > Strangely, this happens on > > > > OpenBSD 6.6-current (GENERIC.MP) #0: Tue Feb 4 17:33:19 CET 2020 > > h...@box.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > but not on > > > > OpenBSD 6.6-current (GENERIC.MP) #0: Sun Feb 9 17:30:47 CET 2020 > > h...@dell.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > (Did I miss somethong pledge() related in that window?) > > > > Yes, there was a kernel commit to allow programs with the "audio" > promise (like sndiod) to use the mixer ioctl()s. Indeed, the problem disappears with the current curent. Sorry for the noise. Jan
Re: macppc base-clang -msvr4-struct-return
This is the everything diff: it includes the clang diff that I sent to tech@, plus the major version bumps for libLLVM libc++ libc++abi. - distrib/sets/lists: put the new versions in the base sets. - gnu/llvm/tools/clang: -msvr4-struct-return - gnu/usr.bin/clang/libLLVM, lib/libcxx, lib/libcxxabi: new versions Index: distrib/sets/lists/base/md.amd64 === RCS file: /cvs/src/distrib/sets/lists/base/md.amd64,v retrieving revision 1.875 diff -u -p -r1.875 md.amd64 --- distrib/sets/lists/base/md.amd6430 Dec 2019 02:20:33 - 1.875 +++ distrib/sets/lists/base/md.amd6412 Feb 2020 20:52:32 - @@ -81,9 +81,9 @@ ./usr/lib/gcc-lib/amd64-unknown-openbsd6.6/4.2.1/collect2 ./usr/lib/gcc-lib/amd64-unknown-openbsd6.6/4.2.1/libgcc.a ./usr/lib/gcc-lib/amd64-unknown-openbsd6.6/4.2.1/specs -./usr/lib/libLLVM.so.1.0 -./usr/lib/libc++.so.3.0 -./usr/lib/libc++abi.so.1.0 +./usr/lib/libLLVM.so.2.0 +./usr/lib/libc++.so.4.0 +./usr/lib/libc++abi.so.2.0 ./usr/lib/libcompiler_rt.a ./usr/lib/libstdc++.so.57.0 ./usr/libdata/perl5/amd64-openbsd Index: distrib/sets/lists/base/md.arm64 === RCS file: /cvs/src/distrib/sets/lists/base/md.arm64,v retrieving revision 1.22 diff -u -p -r1.22 md.arm64 --- distrib/sets/lists/base/md.arm6430 Dec 2019 02:20:34 - 1.22 +++ distrib/sets/lists/base/md.arm6412 Feb 2020 20:52:32 - @@ -37,9 +37,9 @@ ./usr/lib/crtbeginS.o ./usr/lib/crtend.o ./usr/lib/crtendS.o -./usr/lib/libLLVM.so.1.0 -./usr/lib/libc++.so.3.0 -./usr/lib/libc++abi.so.1.0 +./usr/lib/libLLVM.so.2.0 +./usr/lib/libc++.so.4.0 +./usr/lib/libc++abi.so.2.0 ./usr/lib/libcompiler_rt.a ./usr/libdata/perl5/aarch64-openbsd ./usr/libdata/perl5/aarch64-openbsd/.packlist Index: distrib/sets/lists/base/md.armv7 === RCS file: /cvs/src/distrib/sets/lists/base/md.armv7,v retrieving revision 1.284 diff -u -p -r1.284 md.armv7 --- distrib/sets/lists/base/md.armv730 Dec 2019 02:20:34 - 1.284 +++ distrib/sets/lists/base/md.armv712 Feb 2020 20:52:32 - @@ -37,9 +37,9 @@ ./usr/lib/crtbeginS.o ./usr/lib/crtend.o ./usr/lib/crtendS.o -./usr/lib/libLLVM.so.1.0 -./usr/lib/libc++.so.3.0 -./usr/lib/libc++abi.so.1.0 +./usr/lib/libLLVM.so.2.0 +./usr/lib/libc++.so.4.0 +./usr/lib/libc++abi.so.2.0 ./usr/lib/libcompiler_rt.a ./usr/libdata/perl5/arm-openbsd ./usr/libdata/perl5/arm-openbsd/.packlist Index: distrib/sets/lists/base/md.i386 === RCS file: /cvs/src/distrib/sets/lists/base/md.i386,v retrieving revision 1.1254 diff -u -p -r1.1254 md.i386 --- distrib/sets/lists/base/md.i386 30 Dec 2019 02:20:34 - 1.1254 +++ distrib/sets/lists/base/md.i386 12 Feb 2020 20:52:32 - @@ -78,9 +78,9 @@ ./usr/lib/crtbeginS.o ./usr/lib/crtend.o ./usr/lib/crtendS.o -./usr/lib/libLLVM.so.1.0 -./usr/lib/libc++.so.3.0 -./usr/lib/libc++abi.so.1.0 +./usr/lib/libLLVM.so.2.0 +./usr/lib/libc++.so.4.0 +./usr/lib/libc++abi.so.2.0 ./usr/lib/libcompiler_rt.a ./usr/libdata/perl5/i386-openbsd ./usr/libdata/perl5/i386-openbsd/.packlist Index: distrib/sets/lists/base/md.loongson === RCS file: /cvs/src/distrib/sets/lists/base/md.loongson,v retrieving revision 1.456 diff -u -p -r1.456 md.loongson --- distrib/sets/lists/base/md.loongson 30 Dec 2019 02:20:34 - 1.456 +++ distrib/sets/lists/base/md.loongson 12 Feb 2020 20:52:32 - @@ -48,9 +48,9 @@ ./usr/lib/gcc-lib/mips64el-unknown-openbsd6.6/4.2.1/collect2 ./usr/lib/gcc-lib/mips64el-unknown-openbsd6.6/4.2.1/libgcc.a ./usr/lib/gcc-lib/mips64el-unknown-openbsd6.6/4.2.1/specs -./usr/lib/libLLVM.so.1.0 -./usr/lib/libc++.so.3.0 -./usr/lib/libc++abi.so.1.0 +./usr/lib/libLLVM.so.2.0 +./usr/lib/libc++.so.4.0 +./usr/lib/libc++abi.so.2.0 ./usr/lib/libcompiler_rt.a ./usr/lib/libstdc++.so.57.0 ./usr/libdata/perl5/mips64el-openbsd Index: distrib/sets/lists/base/md.macppc === RCS file: /cvs/src/distrib/sets/lists/base/md.macppc,v retrieving revision 1.1023 diff -u -p -r1.1023 md.macppc --- distrib/sets/lists/base/md.macppc 30 Dec 2019 02:20:34 - 1.1023 +++ distrib/sets/lists/base/md.macppc 12 Feb 2020 20:52:32 - @@ -78,9 +78,9 @@ ./usr/lib/gcc-lib/powerpc-unknown-openbsd6.6/4.2.1/collect2 ./usr/lib/gcc-lib/powerpc-unknown-openbsd6.6/4.2.1/libgcc.a ./usr/lib/gcc-lib/powerpc-unknown-openbsd6.6/4.2.1/specs -./usr/lib/libLLVM.so.1.0 -./usr/lib/libc++.so.3.0 -./usr/lib/libc++abi.so.1.0 +./usr/lib/libLLVM.so.2.0 +./usr/lib/libc++.so.4.0 +./usr/lib/libc++abi.so.2.0 ./usr/lib/libcompiler_rt.a ./usr/lib/libstdc++.so.57.0 ./usr/libdata/perl5/powerpc-openbsd Index: distrib/sets/lists/base/md.octeon === RCS
Re: [PATCH] make cwm parse /etc/ssh/ssh_known_hosts (global known hosts) as well as user's known_hosts
On Wed, Feb 12, 2020 at 07:15:36PM +0100, Franz Bettag wrote: > Dear OpenBSD folks, > > appended you will find a patch allowing cwm to also parse the contents > of /etc/ssh/ssh_known_hosts and thus extend the ssh menu. > > the diff was taken against the latest source on the github xenocara repo. > > comments and/or feedback is much appreciated. > > thanks for considering this. :) > > best regards seems people agreed to remove this feature 3 weeks ago but it's still not committed. https://marc.info/?l=openbsd-tech=157972423522573=2
Re: Audio control API, part 1: libsndio, sndiod bits
On Wed, Feb 12, 2020 at 09:28:38PM +0100, Jan Stary wrote: > Hi, > > On Feb 09 13:13:02, a...@caoua.org wrote: > > cd /usr/src > > patch -p0 <1.diff > > patch -p0 <2.diff > > patch -p0 <3.diff > > cd /usr/src/include && doas make includes > > cd /usr/src/lib/libsndio && make obj && make && doas make install > > cd /usr/src/lib/libossaudio && make obj && make && doas make install > > cd /usr/src/usr.bin/sndiod && make obj && make && doas make install > > cd /usr/src/usr.bin/sndioctl && make obj && make && doas make install > > doas rcctl restart sndiod > > cd /usr/ports > > patch -p0 <4.diff > > cd /usr/ports/audio/gqmpeg && make && make install > > cd /usr/ports/sysutils/tray-app && make && make install > > > > Feedback about the new features > > is of course welcome as well. > > sndioctl -m works fine with e.g. mplayer, > i.e. sndioctl notices the "added" app, > and reports the volume changes. great :) > With ffplay and firefox:youtube, volume changes are not reported. > Is that expected? Do they tweak their "internal" volume knob > but not the volume they register with sndio? As opposed to mplayer? Yes exactly. I haven't checked ffplay, but firefox uses an internal volume control because its internal API has no "getter", this is explained here: https://marc.info/?l=openbsd-ports=152641946326955
Re: Audio control API, part 1: libsndio, sndiod bits
On Wed, Feb 12, 2020 at 09:22:20PM +0100, Jan Stary wrote: > Hi, > > On Feb 09 13:13:02, a...@caoua.org wrote: > > cd /usr/src > > patch -p0 <1.diff > > patch -p0 <2.diff > > patch -p0 <3.diff > > cd /usr/src/include && doas make includes > > cd /usr/src/lib/libsndio && make obj && make && doas make install > > cd /usr/src/lib/libossaudio && make obj && make && doas make install > > cd /usr/src/usr.bin/sndiod && make obj && make && doas make install > > cd /usr/src/usr.bin/sndioctl && make obj && make && doas make install > > doas rcctl restart sndiod > > > > I'm very interested in any regression. > > After restarting sndiod (with empty flags), > starting sndioctl -m makes sndiod crash with > > Feb 12 21:02:31 box /bsd: sndiod[95433]: pledge "tty", syscall 54 > > That's ioctl(2). I don't see that in any of the three pledge(2) calls > revealed by a grep in (the patched) .../sndiod/, but apparently > the new code does call ioctl(). sndiod does unauthorized ioctls on this kernel, see below > > Strangely, this happens on > > OpenBSD 6.6-current (GENERIC.MP) #0: Tue Feb 4 17:33:19 CET 2020 > h...@box.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > but not on > > OpenBSD 6.6-current (GENERIC.MP) #0: Sun Feb 9 17:30:47 CET 2020 > h...@dell.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > (Did I miss somethong pledge() related in that window?) > Yes, there was a kernel commit to allow programs with the "audio" promise (like sndiod) to use the mixer ioctl()s.
Re: Audio control API, part 1: libsndio, sndiod bits
Hi, On Feb 09 13:13:02, a...@caoua.org wrote: > cd /usr/src > patch -p0 <1.diff > patch -p0 <2.diff > patch -p0 <3.diff > cd /usr/src/include && doas make includes > cd /usr/src/lib/libsndio && make obj && make && doas make install > cd /usr/src/lib/libossaudio && make obj && make && doas make install > cd /usr/src/usr.bin/sndiod && make obj && make && doas make install > cd /usr/src/usr.bin/sndioctl && make obj && make && doas make install > doas rcctl restart sndiod > cd /usr/ports > patch -p0 <4.diff > cd /usr/ports/audio/gqmpeg && make && make install > cd /usr/ports/sysutils/tray-app && make && make install > > Feedback about the new features > is of course welcome as well. sndioctl -m works fine with e.g. mplayer, i.e. sndioctl notices the "added" app, and reports the volume changes. With ffplay and firefox:youtube, volume changes are not reported. Is that expected? Do they tweak their "internal" volume knob but not the volume they register with sndio? As opposed to mplayer? At any rate, thanks for the new tool! Jan
[PATCH] make cwm parse /etc/ssh/ssh_known_hosts (global known hosts) as well as user's known_hosts
Dear OpenBSD folks,
appended you will find a patch allowing cwm to also parse the contents
of /etc/ssh/ssh_known_hosts and thus extend the ssh menu.
the diff was taken against the latest source on the github xenocara repo.
comments and/or feedback is much appreciated.
thanks for considering this. :)
best regards
Franz Bettag
diff --git app/cwm/calmwm.h app/cwm/calmwm.h
index 008c16e1..445dab9e 100644
--- app/cwm/calmwm.h
+++ app/cwm/calmwm.h
@@ -305,6 +305,7 @@ struct conf {
int xrandr_event_base;
char*conf_file;
char*known_hosts;
+ char*global_known_hosts;
char*wm_argv;
int debug;
};
diff --git app/cwm/conf.c app/cwm/conf.c
index c84be55b..62994b11 100644
--- app/cwm/conf.c
+++ app/cwm/conf.c
@@ -318,6 +318,7 @@ conf_init(struct conf *c)
}
xasprintf(>conf_file, "%s/%s", home, ".cwmrc");
xasprintf(>known_hosts, "%s/%s", home, ".ssh/known_hosts");
+ xasprintf(>global_known_hosts, "/etc/ssh/ssh_known_hosts");
}
void
@@ -365,6 +366,7 @@ conf_clear(struct conf *c)
free(c->conf_file);
free(c->known_hosts);
+ free(c->global_known_hosts);
free(c->font);
free(c->wmname);
}
diff --git app/cwm/cwm.1 app/cwm/cwm.1
index fc8f0ece..ddadea0e 100644
--- app/cwm/cwm.1
+++ app/cwm/cwm.1
@@ -146,6 +146,8 @@ Spawn
dialog.
This parses
.Pa $HOME/.ssh/known_hosts
+and
+.Pa /etc/ssh/ssh_known_hosts
to provide host auto-completion.
.Xr ssh 1
will be executed via the configured terminal emulator.
diff --git app/cwm/kbfunc.c app/cwm/kbfunc.c
index 48404874..6b4c05dc 100644
--- app/cwm/kbfunc.c
+++ app/cwm/kbfunc.c
@@ -670,6 +670,34 @@ kbfunc_menu_ssh(void *ctx, struct cargs *cargs)
if ((fp = fopen(Conf.known_hosts, "r")) == NULL) {
warn("%s: %s", __func__, Conf.known_hosts);
+ goto global;
+ }
+
+ lbuf = NULL;
+ len = 0;
+ while ((slen = getline(, , fp)) != -1) {
+ buf = lbuf;
+ if (buf[slen - 1] == '\n')
+ buf[slen - 1] = '\0';
+
+ /* skip hashed hosts */
+ if (strncmp(buf, HASH_MARKER, strlen(HASH_MARKER)) == 0)
+ continue;
+ for (p = buf; *p != ',' && *p != ' ' && p != buf + slen; p++)
+ ;
+ /* ignore badness */
+ if (p - buf + 1 > sizeof(hostbuf))
+ continue;
+ (void)strlcpy(hostbuf, buf, p - buf + 1);
+ menuq_add(, NULL, "%s", hostbuf);
+ }
+ free(lbuf);
+ if (ferror(fp))
+ err(1, "%s", path);
+ (void)fclose(fp);
+global:
+ if ((fp = fopen(Conf.global_known_hosts, "r")) == NULL) {
+ warn("%s: %s", __func__, Conf.global_known_hosts);
goto menu;
}
Re: Audio control API, part 1: libsndio, sndiod bits
Hi, On Feb 09 13:13:02, a...@caoua.org wrote: > cd /usr/src > patch -p0 <1.diff > patch -p0 <2.diff > patch -p0 <3.diff > cd /usr/src/include && doas make includes > cd /usr/src/lib/libsndio && make obj && make && doas make install > cd /usr/src/lib/libossaudio && make obj && make && doas make install > cd /usr/src/usr.bin/sndiod && make obj && make && doas make install > cd /usr/src/usr.bin/sndioctl && make obj && make && doas make install > doas rcctl restart sndiod > > I'm very interested in any regression. After restarting sndiod (with empty flags), starting sndioctl -m makes sndiod crash with Feb 12 21:02:31 box /bsd: sndiod[95433]: pledge "tty", syscall 54 That's ioctl(2). I don't see that in any of the three pledge(2) calls revealed by a grep in (the patched) .../sndiod/, but apparently the new code does call ioctl(). Strangely, this happens on OpenBSD 6.6-current (GENERIC.MP) #0: Tue Feb 4 17:33:19 CET 2020 h...@box.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP but not on OpenBSD 6.6-current (GENERIC.MP) #0: Sun Feb 9 17:30:47 CET 2020 h...@dell.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP (Did I miss somethong pledge() related in that window?) Jan
Re: amdgpu (and possible radeondrm) fix
This fixes suspend and resume on my T495 ! OpenBSD 6.6-current (GENERIC.MP) #644: Tue Feb 11 12:34:52 MST 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 23478439936 (22390MB) avail mem = 22754394112 (21700MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xb9ecc000 (63 entries) bios0: vendor LENOVO version "R12ET46W(1.16 )" date 10/28/2019 bios0: LENOVO 20NJCTO1WW acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT TPM2 SSDT MSDM SLIC BATB HPET APIC MCFG SBST WSMT IVRS SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI acpi0: wakeup devices GPP0(S3) GPP1(S3) GPP2(S3) GPP3(S3) GPP4(S3) L850(S3) GPP5(S3) GPP6(S3) GP17(S3) XHC0(S3) XHC1(S3) GP18(S3) LID_(S3) SLPB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 7 PRO 3700U w/ Radeon Vega Mobile Gfx, 2296.07 MHz, 17-18-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 7 PRO 3700U w/ Radeon Vega Mobile Gfx, 2295.66 MHz, 17-18-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 7 PRO 3700U w/ Radeon Vega Mobile Gfx, 2295.66 MHz, 17-18-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 7 PRO 3700U w/ Radeon Vega Mobile Gfx, 2295.66 MHz, 17-18-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu3: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: smt 1, core 1, package 0 cpu4 at mainbus0: apid 4 (application processor) cpu4: AMD Ryzen 7 PRO 3700U w/ Radeon Vega Mobile Gfx, 2295.66 MHz, 17-18-01 cpu4:
Re: Audio control API, part 4: switch ports to sndio API
On Sun, Feb 09, 2020 at 01:27:27PM +0100, Alexandre Ratchov wrote:
> There are two ports only using the kernel-based API, this diff updates
> them to use new libsndio-based API:
> - sysutils/tray-app
> - audio/gqmpeg
>
> As a side effect, this fixes gqmpeg crashes, makes these programs use
> the right device, and make them work on many uaudio(4) and envy(4)
> devices with no hardware master level knob. Also when one program
> changes the volume, slider of other programs are properly updated.
>
I forgot x11/i3status; below is a diff to make it use sndio.
Index: Makefile
===
RCS file: /cvs/ports/x11/i3status/Makefile,v
retrieving revision 1.58
diff -u -p -r1.58 Makefile
--- Makefile27 Sep 2019 20:33:22 - 1.58
+++ Makefile12 Feb 2020 13:55:43 -
@@ -5,7 +5,7 @@ ONLY_FOR_ARCHS= ${APM_ARCHS}
COMMENT= generate a statusbar for use with i3/xmobar/dzen2
DISTNAME= i3status-2.13
-REVISION= 1
+REVISION= 2
CATEGORIES=x11 sysutils
HOMEPAGE= https://i3wm.org/i3status/
@@ -28,7 +28,9 @@ BUILD_DEPENDS=textproc/asciidoc>=8.6.8
LIB_DEPENDS= devel/libconfuse \
devel/libyajl
-CONFIGURE_STYLE = gnu
+AUTOCONF_VERSION = 2.69
+AUTOMAKE_VERSION = 1.16
+CONFIGURE_STYLE = autoreconf
SEPARATE_BUILD = Yes
FAKE_FLAGS += sysconfdir=${PREFIX}/share/examples/i3status/
Index: patches/patch-Makefile_am
===
RCS file: patches/patch-Makefile_am
diff -N patches/patch-Makefile_am
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-Makefile_am 12 Feb 2020 13:55:43 -
@@ -0,0 +1,37 @@
+$OpenBSD$
+
+Index: Makefile.am
+--- Makefile.am.orig
Makefile.am
+@@ -1,5 +1,3 @@
+-@CODE_COVERAGE_RULES@
+-
+ echo-version:
+ @echo "@I3STATUS_VERSION@"
+
+@@ -30,6 +28,7 @@ i3status_CFLAGS = \
+ $(PULSE_CFLAGS) \
+ $(NLGENL_CFLAGS) \
+ $(ALSA_CFLAGS) \
++ $(SNDIO_CFLAGS) \
+ $(PTHREAD_CFLAGS)
+
+ i3status_CPPFLAGS = \
+@@ -42,6 +41,7 @@ i3status_LDADD = \
+ $(PULSE_LIBS) \
+ $(NLGENL_LIBS) \
+ $(ALSA_LIBS) \
++ $(SNDIO_LIBS) \
+ $(PTHREAD_LIBS)
+
+ i3status_SOURCES = \
+@@ -69,7 +69,8 @@ i3status_SOURCES = \
+ src/print_wireless_info.c \
+ src/print_file_contents.c \
+ src/process_runs.c \
+- src/pulse.c
++ src/pulse.c \
++ src/sndio.c
+
+ dist_sysconf_DATA = \
+ i3status.conf
Index: patches/patch-Makefile_in
===
RCS file: patches/patch-Makefile_in
diff -N patches/patch-Makefile_in
--- patches/patch-Makefile_in 6 Jul 2019 20:20:27 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,15 +0,0 @@
-$OpenBSD: patch-Makefile_in,v 1.1 2019/07/06 20:20:27 jasper Exp $
-
-The CODE_COVERAGE_RULES fragment contains an unmatched "if" clause.
-
-Index: Makefile.in
Makefile.in.orig
-+++ Makefile.in
-@@ -1851,7 +1851,6 @@ uninstall-man: uninstall-man1
-
- .PRECIOUS: Makefile
-
--@CODE_COVERAGE_RULES@
-
- echo-version:
- @echo "@I3STATUS_VERSION@"
Index: patches/patch-configure_ac
===
RCS file: patches/patch-configure_ac
diff -N patches/patch-configure_ac
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-configure_ac 12 Feb 2020 13:55:43 -
@@ -0,0 +1,19 @@
+$OpenBSD$
+
+Index: configure.ac
+--- configure.ac.orig
configure.ac
+@@ -91,6 +91,13 @@ case $host_os in
+ ;;
+ esac
+
++# if sndio is available, define USE_SNDIO
++AC_CHECK_HEADER(sndio.h,
++ [AC_CHECK_LIB([sndio], [sio_open], [
++ AC_SUBST(SNDIO_LIBS, "-lsndio")
++ AC_DEFINE([USE_SNDIO], [], [Use sndio])
++ ], [])], [])
++
+ dnl TODO: check for libbsd for GNU/kFreeBSD
+
+ # Checks for programs.
Index: patches/patch-include_i3status_h
===
RCS file: patches/patch-include_i3status_h
diff -N patches/patch-include_i3status_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-include_i3status_h12 Feb 2020 13:55:43 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+
+Index: include/i3status.h
+--- include/i3status.h.orig
include/i3status.h
+@@ -232,6 +232,7 @@ int volume_pulseaudio(uint32_t sink_idx, const char *s
+ bool description_pulseaudio(uint32_t sink_idx, const char *sink_name, char
buffer[MAX_SINK_DESCRIPTION_LEN]);
+ bool pulse_initialize(void);
+ void print_file_contents(yajl_gen json_gen, char *buffer, const char *title,
const char *path, const char *format, const char *format_bad, const int
max_chars);
++int volume_sndio(void);
+
+ /* socket file descriptor for general purposes */
+ extern int general_socket;
Index: patches/patch-src_print_volume_c
Re: apmd: fix autoaction timeout
On Wed, Feb 12 2020, Jeremie Courreges-Anglas wrote:
> On Sat, Jan 25 2020, Jeremie Courreges-Anglas wrote:
>> The diff below improves the way apmd -z/-Z may trigger.
>>
>> I think the current behavior is bogus, incrementing and checking
>> apmtimeout like this doesn't make much sense.
>>
>> Here's a proposal:
>> - on APM_POWER_CHANGE events, check the battery level and trigger
>> autoaction if needed. This should be enough to make autoaction just
>> work with drivers like acpibat(4).
>> - on kevent timeout (10mn by default now, maybe too long), also check
>> the battery level and suspend if needed. This should be useful only
>> if your battery driver doesn't send any APM_POWER_CHANGE event.
>>
>> While here I also tweaked the warning.
>
> This has been committed, thanks Ted.
>
>> Some more context:
>> - a subsequent diff would reorder the code to handle similarly the "!rv"
>> and "ev->ident == ctl_fd" paths
>
> Diff below.
>
>> - I think we want some throttling mechanism, like wait for 1mn after we
>> resume before autosuspending again. But I want to fix obvious
>> problems first.
On top of the previous diff, here's a diff to block autoaction for 60
seconds after:
- autoaction triggers; this prevents apmd from sending multiple suspend
requests before the system goes to sleep
- a resume happens; this gives you 60 seconds to fetch and plug your AC
cable if you notice you're low on power
A side effect is that apmd now ignores stale acpiac(4) data at resume
time, so it apmd doesn't suspend the system again when you resume with
a low battery and AC plugged.
cc'ing Scott since he has a thing for everything time-related. :)
ok?
Index: apmd.c
===
--- apmd.c.orig
+++ apmd.c
@@ -380,6 +380,7 @@ main(int argc, char *argv[])
int powerstatus = 0, powerbak = 0, powerchange = 0;
int noacsleep = 0;
struct timespec ts = {TIMO, 0}, sts = {0, 0};
+ struct timespec autoaction_timestamp = { 0, 0 };
struct apm_power_info pinfo;
const char *sockname = _PATH_APM_SOCKET;
const char *errstr;
@@ -566,6 +567,7 @@ main(int argc, char *argv[])
powerstatus = powerbak;
powerchange = 1;
}
+ clock_gettime(CLOCK_MONOTONIC, _timestamp);
resumes++;
break;
case APM_POWER_CHANGE:
@@ -577,6 +579,8 @@ main(int argc, char *argv[])
if (!powerstatus && autoaction &&
autolimit > (int)pinfo.battery_life) {
+ struct timespec delay, now;
+
logmsg(LOG_NOTICE,
"estimated battery life %d%%"
" below configured limit %d%%",
@@ -584,10 +588,17 @@ main(int argc, char *argv[])
autolimit
);
- if (autoaction == AUTO_SUSPEND)
- suspends++;
- else
- hibernates++;
+ delay = autoaction_timestamp;
+ delay.tv_sec += 60;
+ clock_gettime(CLOCK_MONOTONIC, );
+ if (timespeccmp(, , >)) {
+ if (autoaction == AUTO_SUSPEND)
+ suspends++;
+ else
+ hibernates++;
+ clock_gettime(CLOCK_MONOTONIC,
+ _timestamp);
+ }
}
break;
default:
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: apmd: fix autoaction timeout
On Sat, Jan 25 2020, Jeremie Courreges-Anglas wrote:
> The diff below improves the way apmd -z/-Z may trigger.
>
> I think the current behavior is bogus, incrementing and checking
> apmtimeout like this doesn't make much sense.
>
> Here's a proposal:
> - on APM_POWER_CHANGE events, check the battery level and trigger
> autoaction if needed. This should be enough to make autoaction just
> work with drivers like acpibat(4).
> - on kevent timeout (10mn by default now, maybe too long), also check
> the battery level and suspend if needed. This should be useful only
> if your battery driver doesn't send any APM_POWER_CHANGE event.
>
> While here I also tweaked the warning.
This has been committed, thanks Ted.
> Some more context:
> - a subsequent diff would reorder the code to handle similarly the "!rv"
> and "ev->ident == ctl_fd" paths
Diff below.
> - I think we want some throttling mechanism, like wait for 1mn after we
> resume before autosuspending again. But I want to fix obvious
> problems first.
[...]
Further unify the handling of kevent(2) timeouts and apm events:
fake an APM_POWER_CHANGE event on timeouts.
I think assert(3) is appropriate here but could be convinced otherwise.
ok?
Index: apmd.c
===
--- apmd.c.orig
+++ apmd.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -497,7 +498,7 @@ main(int argc, char *argv[])
error("kevent", NULL);
for (;;) {
- int rv;
+ int rv, event, index;
sts = ts;
@@ -528,6 +529,46 @@ main(int argc, char *argv[])
continue;
} else if (rv == 0) {
/* wakeup for timeout: take status */
+ event = APM_POWER_CHANGE;
+ index = -1;
+ } else {
+ assert(rv == 1 && ev->ident == ctl_fd);
+ event = APM_EVENT_TYPE(ev->data);
+ index = APM_EVENT_INDEX(ev->data);
+ }
+
+ logmsg(LOG_DEBUG, "apmevent %04x index %d", event, index);
+
+ switch (event) {
+ case APM_SUSPEND_REQ:
+ case APM_USER_SUSPEND_REQ:
+ case APM_CRIT_SUSPEND_REQ:
+ case APM_BATTERY_LOW:
+ suspends++;
+ break;
+ case APM_USER_STANDBY_REQ:
+ case APM_STANDBY_REQ:
+ standbys++;
+ break;
+ case APM_USER_HIBERNATE_REQ:
+ hibernates++;
+ break;
+#if 0
+ case APM_CANCEL:
+ suspends = standbys = 0;
+ break;
+#endif
+ case APM_NORMAL_RESUME:
+ case APM_CRIT_RESUME:
+ case APM_SYS_STANDBY_RESUME:
+ powerbak = power_status(ctl_fd, 0, );
+ if (powerstatus != powerbak) {
+ powerstatus = powerbak;
+ powerchange = 1;
+ }
+ resumes++;
+ break;
+ case APM_POWER_CHANGE:
powerbak = power_status(ctl_fd, 0, );
if (powerstatus != powerbak) {
powerstatus = powerbak;
@@ -548,63 +589,9 @@ main(int argc, char *argv[])
else
hibernates++;
}
- } else if (ev->ident == ctl_fd) {
- logmsg(LOG_DEBUG, "apmevent %04x index %d",
- (int)APM_EVENT_TYPE(ev->data),
- (int)APM_EVENT_INDEX(ev->data));
-
- switch (APM_EVENT_TYPE(ev->data)) {
- case APM_SUSPEND_REQ:
- case APM_USER_SUSPEND_REQ:
- case APM_CRIT_SUSPEND_REQ:
- case APM_BATTERY_LOW:
- suspends++;
- break;
- case APM_USER_STANDBY_REQ:
- case APM_STANDBY_REQ:
- standbys++;
- break;
- case APM_USER_HIBERNATE_REQ:
- hibernates++;
- break;
-#if 0
- case APM_CANCEL:
- suspends = standbys = 0;
- break;
-#endif
- case APM_NORMAL_RESUME:
- case APM_CRIT_RESUME:
- case APM_SYS_STANDBY_RESUME:
- powerbak = power_status(ctl_fd, 0, );
- if (powerstatus !=
