Re: Audio over hdmi
On Sat, Apr 25, 2020 at 05:16:03PM +0200, Damien Couderc wrote: > > > > I can see in the full dmesg that there are two different FTYPE results > > provided during azalia_codec_init and only the first one seems to be > > displayed in the mixerctl output. > > > > I think that maybe mixerctl does not recurse all the audio functions or > > that some bits aren't recorded. I'll take a look. > > Ok, I did a bit of reading and from what I understood there are 2 detected > codecs (0 and 2) for the same instance of azalia but the latest is deleted > in azalia_init_codecs() because there is only one that can be enabled. > > Alexandre could maybe tell us what is possible to do here. I think it's > maybe possible to keep all detected codecs but to change which one is > enabled. Hi, Sorry couldn't test your diff, my machines have one codec only. The azalia driver can handle only one codec at a time. Multiple codecs can't be presented as different devices because they can't be used at the same time. Quickly adding support for multiple codecs would need to expose "mixer" controls of all the codecs and the ability to switch between them. This may look difficult but in most (all?) real-world cases there is at most 1 analog and 1 digital codec and the latter has very few controls, if any. Independenty, support for the hdmi-only devices, present on certain graphics cards was removed as they were not useful, but used to attach as audio0, i.e. they took the place of the default audio device, which made audio not work by default. But this is not related to your patch. HTH
Re: acpi interrupt storm on HP EliteBook 840 G1
I dug a bit more into this and hopefully it will be more actionable
this way and so +tech@. The original details and references are still
below.
Since the last time I figured that suspend/resume is a reliable way to
trigger the interrupt storm.
So I recompiled 6.6-current with ACPI_DEBUG. Now once I wake up the
system it writes the following
non-stop into dmesg at ~1kHz (compared to 5kHz when the log is not written):
--== Eval Method [\\_GPE._L2A, 0 args] to t ==--
= Stack \\_GPE._L2A:Method
parsename: \\_SB_.PCI0.RP06.WKEN 1
--==Finished evaluating method: \\_GPE._L2A t
= Stack \\_GPE._L2A:Method
acpi thread going to sleep...
GPE block: 28 dd 04
queue gpe: 2a
handle gpe: 2a
handling GPE 2a
EVALNODE: \\_GPE._L2A 105b7c
--== Eval Method [\\_GPE._L2A, 0 args] to t ==--
...
Looking into the iasl-produced DSDT.dsl (full output below), this
seems to be relevant:
Scope (\_GPE)
{
Method (_L2A, 0, NotSerialized) // _Lxx: Level-Triggered
GPE, xx=0x00-0xFF
{
If (\_SB.PCI0.RP06.WKEN)
{
\_SB.GOWW (0x2A, 0x01)
Notify (\_SB.PCI0.RP06, 0x02) // Device Wake
}
}
}
Cursory searches indicate this kind of problem is typically handled by
people shutting off the interrupt,
but I don't think a knob corresponding to linux
/sys/firmware/acpi/interrupts/gpe2A exists in OpenBSD.
Any workarounds? Patches I can test?
Thanks
Greg
P.S. The relevant device to save indirection:
Device (RP06)
{
Method (_ADR, 0, NotSerialized) // _ADR: Address
{
Return (RPA5) /* \_SB_.PCI0.RPA5 */
}
Method (_INI, 0, NotSerialized) // _INI: Initialize
{
LTRE = LTR6 /* \LTR6 */
LMSL = PML6 /* \_SB_.PCI0.PML6 */
LNSL = PNL6 /* \_SB_.PCI0.PNL6 */
OBFF = OBF6 /* \OBF6 */
}
OperationRegion (PXCS, PCI_Config, 0x00, 0x0380)
Field (PXCS, AnyAcc, NoLock, WriteAsZeros)
{
VDID, 32,
Offset (0x50),
L0SE, 1,
, 3,
LDIS, 1,
Offset (0x51),
Offset (0x52),
, 13,
LASX, 1,
Offset (0x5A),
ABPX, 1,
, 2,
PDCX, 1,
, 2,
PDSX, 1,
Offset (0x5B),
LSCX, 1,
Offset (0x60),
Offset (0x62),
PSPX, 1,
Offset (0xA4),
D3HT, 2,
Offset (0xD8),
, 30,
HPEX, 1,
PMEX, 1,
, 30,
HPSX, 1,
PMSX, 1,
Offset (0xE2),
, 2,
L23E, 1,
L23R, 1,
Offset (0x324),
, 3,
LEDM, 1
}
Field (PXCS, AnyAcc, NoLock, Preserve)
{
Offset (0x42),
Offset (0x43),
SI, 1,
Offset (0x50),
, 4,
LD, 1,
Offset (0x58),
SCTL, 16,
SSTS, 16,
Offset (0xD8),
, 30,
HPCE, 1,
PMCE, 1
}
Method (HPLG, 0, Serialized)
{
If (_STA ())
{
If (HPSX)
{
Sleep (0x64)
If (PDCX)
{
PDCX = 0x01
HPSX = 0x01
Notify (^, 0x00) // Bus Check
}
Else
{
HPSX = 0x01
}
}
}
}
Method (PME, 0, Serialized)
{
If (_STA ())
{
If (PSPX)
{
While (PSPX)
{
PSPX = 0x01
}
PMSX = 0x01
Notify (^, 0x02) // Device Wake
Re: Update /etc/examples/doas.conf and doas.conf(5)
I use it regularily too, I don't like talking about stuff I don't use. Downsides I could see is just the general fun of moving documentation, which can be a huge problem for me and I'm guessing you too. Upsides are slightly, ever so small decrease in clutter and better access for the new age of open source types. I'm not pinning for a change, raising an idea that might help others but will hurt me when I forget the syntax of doas *and* to pull down www. After all I know for a fact I'm that much of an idiot. PS; apologies to Theo, as demonstrated I am a colossal moron. On Sun, Apr 26, 2020 at 10:52 AM Theo de Raadt wrote: > > My position is that the directory is fine, and helpful. > > I use it all the time to setup machines quickly. > > Maybe you don't. Then you can ignore it. > > > Louis Fredrickson wrote: > > > Was it ever floated to remove examples entirely and move them to www? > > I think it would be easier for the forgetful, new and muh power use types > > all alike, as worthless and unneccesary as my opinion may be. > > > > On Sun, 26 Apr 2020, 10:08 Ingo Schwarze, wrote: > > > > > Hi, > > > > > > clematis wrote on Sat, Apr 25, 2020 at 11:34:14PM +0200: > > > > > > > But then based on your feedback I wonder if there's even any > > > > value of an example file which gives not much more than an already > > > > well documented manpage? > > > > > > We had that discussion among developers at least twice in the past. > > > > > > If i were the only developer, which very fortunately i'm not, > > > i would probably go for fewer files in /etc/examples/. > > > > > > But there are also several developers who find it quite > > > convenient to have a larger number of small example files > > > around, for various reasons, for example because it is often > > > quicker to get a general feeling for the basic syntax by looking > > > at a concise example file compared to reading an abstract > > > description in the manual page, and because copy and paste > > > from manual pages is somewhat hindered by indentation (don't > > > suggest solutions for that, it is not really an issue that > > > needs solving). > > > > > > It hasn't been very productive when i proposed such files > > > for deletion, so i tend to not press such issues again. > > > > > > But that doesn't mean i'd gladly agree to start tripling or > > > quadrupling the sizes of existing files without good reasons. > > > > > > > And again, please don't get me wrong, I don't > > > > mean to play devil's advocate but do we even need an > > > > /etc/examples/doas.conf? > > > > (for all the very valid reasons you've mentioned as well, clarity, > > > > existing documentation etc...) > > > > > > If i remember correctly, there were quite a few developers > > > who considered it useful to keep a short examples/doas.conf > > > around and didn't like the idea of deleting it. > > > > > > > I would be tempted to put a few others in the same boat: > > > > > > Yes, there are certainly a few others were more or less the > > > same arguments apply like for doas.conf. > > > > > > Yours, > > > Ingo > > > > > >
Re: Update /etc/examples/doas.conf and doas.conf(5)
My position is that the directory is fine, and helpful. I use it all the time to setup machines quickly. Maybe you don't. Then you can ignore it. Louis Fredrickson wrote: > Was it ever floated to remove examples entirely and move them to www? > I think it would be easier for the forgetful, new and muh power use types > all alike, as worthless and unneccesary as my opinion may be. > > On Sun, 26 Apr 2020, 10:08 Ingo Schwarze, wrote: > > > Hi, > > > > clematis wrote on Sat, Apr 25, 2020 at 11:34:14PM +0200: > > > > > But then based on your feedback I wonder if there's even any > > > value of an example file which gives not much more than an already > > > well documented manpage? > > > > We had that discussion among developers at least twice in the past. > > > > If i were the only developer, which very fortunately i'm not, > > i would probably go for fewer files in /etc/examples/. > > > > But there are also several developers who find it quite > > convenient to have a larger number of small example files > > around, for various reasons, for example because it is often > > quicker to get a general feeling for the basic syntax by looking > > at a concise example file compared to reading an abstract > > description in the manual page, and because copy and paste > > from manual pages is somewhat hindered by indentation (don't > > suggest solutions for that, it is not really an issue that > > needs solving). > > > > It hasn't been very productive when i proposed such files > > for deletion, so i tend to not press such issues again. > > > > But that doesn't mean i'd gladly agree to start tripling or > > quadrupling the sizes of existing files without good reasons. > > > > > And again, please don't get me wrong, I don't > > > mean to play devil's advocate but do we even need an > > > /etc/examples/doas.conf? > > > (for all the very valid reasons you've mentioned as well, clarity, > > > existing documentation etc...) > > > > If i remember correctly, there were quite a few developers > > who considered it useful to keep a short examples/doas.conf > > around and didn't like the idea of deleting it. > > > > > I would be tempted to put a few others in the same boat: > > > > Yes, there are certainly a few others were more or less the > > same arguments apply like for doas.conf. > > > > Yours, > > Ingo > > > >
Re: Update /etc/examples/doas.conf and doas.conf(5)
Was it ever floated to remove examples entirely and move them to www? I think it would be easier for the forgetful, new and muh power use types all alike, as worthless and unneccesary as my opinion may be. On Sun, 26 Apr 2020, 10:08 Ingo Schwarze, wrote: > Hi, > > clematis wrote on Sat, Apr 25, 2020 at 11:34:14PM +0200: > > > But then based on your feedback I wonder if there's even any > > value of an example file which gives not much more than an already > > well documented manpage? > > We had that discussion among developers at least twice in the past. > > If i were the only developer, which very fortunately i'm not, > i would probably go for fewer files in /etc/examples/. > > But there are also several developers who find it quite > convenient to have a larger number of small example files > around, for various reasons, for example because it is often > quicker to get a general feeling for the basic syntax by looking > at a concise example file compared to reading an abstract > description in the manual page, and because copy and paste > from manual pages is somewhat hindered by indentation (don't > suggest solutions for that, it is not really an issue that > needs solving). > > It hasn't been very productive when i proposed such files > for deletion, so i tend to not press such issues again. > > But that doesn't mean i'd gladly agree to start tripling or > quadrupling the sizes of existing files without good reasons. > > > And again, please don't get me wrong, I don't > > mean to play devil's advocate but do we even need an > > /etc/examples/doas.conf? > > (for all the very valid reasons you've mentioned as well, clarity, > > existing documentation etc...) > > If i remember correctly, there were quite a few developers > who considered it useful to keep a short examples/doas.conf > around and didn't like the idea of deleting it. > > > I would be tempted to put a few others in the same boat: > > Yes, there are certainly a few others were more or less the > same arguments apply like for doas.conf. > > Yours, > Ingo > >
Re: Update /etc/examples/doas.conf and doas.conf(5)
Hi, clematis wrote on Sat, Apr 25, 2020 at 11:34:14PM +0200: > But then based on your feedback I wonder if there's even any > value of an example file which gives not much more than an already > well documented manpage? We had that discussion among developers at least twice in the past. If i were the only developer, which very fortunately i'm not, i would probably go for fewer files in /etc/examples/. But there are also several developers who find it quite convenient to have a larger number of small example files around, for various reasons, for example because it is often quicker to get a general feeling for the basic syntax by looking at a concise example file compared to reading an abstract description in the manual page, and because copy and paste from manual pages is somewhat hindered by indentation (don't suggest solutions for that, it is not really an issue that needs solving). It hasn't been very productive when i proposed such files for deletion, so i tend to not press such issues again. But that doesn't mean i'd gladly agree to start tripling or quadrupling the sizes of existing files without good reasons. > And again, please don't get me wrong, I don't > mean to play devil's advocate but do we even need an > /etc/examples/doas.conf? > (for all the very valid reasons you've mentioned as well, clarity, > existing documentation etc...) If i remember correctly, there were quite a few developers who considered it useful to keep a short examples/doas.conf around and didn't like the idea of deleting it. > I would be tempted to put a few others in the same boat: Yes, there are certainly a few others were more or less the same arguments apply like for doas.conf. Yours, Ingo
Re: Update /etc/examples/doas.conf and doas.conf(5)
Hi Stuart, Theo, I didn't really though about it from a "potentially risky command" perspective. I understand - that makes sense. On Sat, Apr 25, 2020 at 08:43:22PM +0200, Ingo Schwarze wrote: > clematis wrote on Sat, Apr 25, 2020 at 07:41:40PM +0200: > > The shorter the better. > > Yes, there are exceptions, when something is really complicated > and configuring it properly requires a lot of legwork, like for > bgpd.conf(5). Or if something is hard to explain in abstract > terms and easy to show with an example, like acme-challenge in > httpd.conf(5). > > > For example doas.conf doas.conf(5) contains more EXAMPLES > > than /etc/examples/doas.conf > > Which is good. The manual page is the ideal place for documentation. Hi Ingo, Agree with manual pages being the ideal place for documentation. And to leverage examples files for those cases, as you said, which are just easier to explain with an example. > > Please let me know if there is a prefered way. > > Keep it as short as possible, that's the most important point IMHO. I agree. But then based on your feedback I wonder if there's even any value of an example file which gives not much more than an already well documented manpage? And again, please don't get me wrong, I don't mean to play devil's advocate but do we even need an /etc/examples/doas.conf? (for all the very valid reasons you've mentioned as well, clarity, existing documentation etc...) I would be tempted to put a few others in the same boat: /etc/examples/exports: just points to the manpage. exports(5) is crystal clear and has examples. Only gives an extra warning that could be in the manpage. /etc/examples/rc.*: Nothing more than rc(8). There's not much example that could be given anyway. rc.shutdown(8) is also crystal clear (doesn't actually list /etc/examples in FILES btw) Plus it's mentioned in the welcome mail.root and afterboot(8). Sounds like plenty already. > I dislike the idea of a middle ground in this context. You're probably right - either it's something complex than can be clarified with examples or people just refer to the manpage... Thanks for the feedback - appreciated. -- clematis (0x7e96fd2400fe7b59)
Re: Update /etc/examples/doas.conf and doas.conf(5)
Hi, i strongly dislike what you are doing here. Not just because of one particular line, but in general. clematis wrote on Sat, Apr 25, 2020 at 07:41:40PM +0200: > Looking arround in /etc/examples/ I felt like some of those files > aren't as "verbose" as others. The shorter the better. Yes, there are exceptions, when something is really complicated and configuring it properly requires a lot of legwork, like for bgpd.conf(5). Or if something is hard to explain in abstract terms and easy to show with an example, like acme-challenge in httpd.conf(5). > For example doas.conf doas.conf(5) contains more EXAMPLES > than /etc/examples/doas.conf Which is good. The manual page is the ideal place for documentation. The program doas(1) is very well-designed. It is very simple and very easy to use yet quite powerful (even though it intentionally does not have all bells and whistles that some might need in special situations). Let's not obscure that good design by making the /etc/examples/ file excessively large and cumbersome. > Please let me know if there is a prefered way. Keep it as short as possible, that's the most important point IMHO. For a program as well designed as doas(1), the primary benefit of the file is to signal to somebody who looks into the directory: Look, this is a program you can configure with a file in /etc/. In addition to that, maybe it could also demonstrate: this is how a cmment looks like, and this is how the basic syntactic patterns look like. Repeating the content of the manual page would be detrimental. > And there's probably a middle ground that could be find as well. > I don't know if anyone has a strong opinion or recommandations. I dislike the idea of a middle ground in this context. > So if that makes sense for you, please find attached a patch for > examples/doas.conf adding the main examples from doas.conf(5) and > bsd.port.mk(5). Please, no. Yours, Ingo
maxrtc(4)
The cvs log tells me this driver was written to privide an alternative
clock for the Sun Fire V210. That is probably why it prints a message
about overwriting the rtc handler. But the driver was never enabled
on sparc64 (or anywhere else for that matter) and overwriting the rtc
is normal behaviour on arm64. So this diff removes that message.
The official device tree binding name for this device is
"dallas,ds1307" so check for that in the match function.
ok?
Index: dev/i2c/ds1307.c
===
RCS file: /cvs/src/sys/dev/i2c/ds1307.c,v
retrieving revision 1.1
diff -u -p -r1.1 ds1307.c
--- dev/i2c/ds1307.c20 Jun 2016 13:42:42 - 1.1
+++ dev/i2c/ds1307.c25 Apr 2020 18:05:37 -
@@ -96,7 +96,8 @@ maxrtc_match(struct device *parent, void
{
struct i2c_attach_args *ia = arg;
- if (strcmp(ia->ia_name, "ds1307") == 0)
+ if (strcmp(ia->ia_name, "dallas,ds1307") == 0 ||
+ strcmp(ia->ia_name, "ds1307") == 0)
return (1);
return (0);
@@ -123,12 +124,6 @@ maxrtc_attach(struct device *parent, str
if (maxrtc_set_24h_mode(sc) == -1)
return;
- /* register our time handlers */
- if (todr_handle != NULL) {
- printf("%s: overwriting existing rtc handler\n",
- sc->sc_dev.dv_xname);
- }
- /* XXX just overwrite existing rtc handler? */
todr_handle = >sc_todr;
}
Re: Update /etc/examples/doas.conf and doas.conf(5)
I do not think this risk-prone command (or any risk-prone subsystem) should be documented via example. People will copy. They won't understand. They won't try to understand. By not providing an example, we force them to learn, and only use the minimum. Giving people lines to "tweak" results in them over-selecting without study. clematis wrote: > Hello, > Looking arround in /etc/examples/ I felt like some of those files aren't > as "verbose" as others. For example doas.conf > doas.conf(5) contains more EXAMPLES than /etc/examples/doas.conf > > Please let me know if there is a prefered way. > 1/ document EXAMPLES in the manpage, only have examples config file for > daemon? (The relayd.conf example file is very verbose in comparaison, > which don't get me wrong is a very good thing) > 2/ or try to keep both aligned and consistent (they always point to each > others but yes one change in the EXAMPLES of a manpage could also > require a change in the example config file) so we could arguee it's > duplicating the effort. > > And there's probably a middle ground that could be find as well. > I don't know if anyone has a strong opinion or recommandations. > > So if that makes sense for you, please find attached a patch for > examples/doas.conf adding the main examples from doas.conf(5) and > bsd.port.mk(5). > Also a quick patch for doas.conf(5) to use an absolute path as > recommended. > > Cheers, > -- > clematis (0x7e96fd2400fe7b59)
Re: Update /etc/examples/doas.conf and doas.conf(5)
On 2020/04/25 19:41, clematis wrote:
> +permit nopass solene cmd /usr/bin/touch
> +permit nopass setenv { TRUSTED_PKG_PATH TERM } solene cmd \
> + /usr/sbin/pkg_add
> +permit nopass setenv { TERM } solene cmd /usr/sbin/pkg_delete
it is bad enough that the dangerous "nopass pkg_add" is in bsd.port.mk(5),
please don't copy it other places!
Update /etc/examples/doas.conf and doas.conf(5)
Hello,
Looking arround in /etc/examples/ I felt like some of those files aren't
as "verbose" as others. For example doas.conf
doas.conf(5) contains more EXAMPLES than /etc/examples/doas.conf
Please let me know if there is a prefered way.
1/ document EXAMPLES in the manpage, only have examples config file for
daemon? (The relayd.conf example file is very verbose in comparaison,
which don't get me wrong is a very good thing)
2/ or try to keep both aligned and consistent (they always point to each
others but yes one change in the EXAMPLES of a manpage could also
require a change in the example config file) so we could arguee it's
duplicating the effort.
And there's probably a middle ground that could be find as well.
I don't know if anyone has a strong opinion or recommandations.
So if that makes sense for you, please find attached a patch for
examples/doas.conf adding the main examples from doas.conf(5) and
bsd.port.mk(5).
Also a quick patch for doas.conf(5) to use an absolute path as
recommended.
Cheers,
--
clematis (0x7e96fd2400fe7b59)
Index: doas.conf
===
RCS file: /cvs/src/etc/examples/doas.conf,v
retrieving revision 1.1
diff -u -p -r1.1 doas.conf
--- doas.conf 3 Sep 2016 11:58:32 - 1.1
+++ doas.conf 25 Apr 2020 16:43:14 -
@@ -12,3 +12,28 @@
# Allow wheel by default
permit keepenv :wheel
+
+# Allow user aja to install packages from a prefered mirror via pkg_add(1)
+permit persist setenv { PKG_CACHE PKG_PATH } aja cmd /usr/sbin/pkg_add
+
+# Allow group wheel to execute commands as any user while keeping the
+# environment variables PS1 and SSH_AUTH_SOCK and unsetting ENV
+permit setenv { -ENV PS1=$DOAS_PS1 SSH_AUTH_SOCK } :wheel
+
+# Allow user tedu to run procmap(1) as root without a password
+permit nopass tedu as root cmd /usr/sbin/procmap
+
+# Allow root to run unrestricted commands as itself while retaining the
+# original PATH
+permit nopass keepenv setenv { PATH } root as root
+
+# Allow user solene to execute commands as BUILD_USER and FETCH_USER and
+# to run privileged commands without entering a password.
+# See bsd.port.mk(5)
+permit keepenv nopass solene as _pbuild
+permit keepenv nopass solene as _pfetch
+permit nopass solene cmd /usr/bin/touch
+permit nopass setenv { TRUSTED_PKG_PATH TERM } solene cmd \
+ /usr/sbin/pkg_add
+permit nopass setenv { TERM } solene cmd /usr/sbin/pkg_delete
+
Index: doas.conf.5
===
RCS file: /cvs/src/usr.bin/doas/doas.conf.5,v
retrieving revision 1.42
diff -u -p -r1.42 doas.conf.5
--- doas.conf.5 10 Feb 2020 13:18:20 - 1.42
+++ doas.conf.5 25 Apr 2020 16:46:11 -
@@ -133,7 +133,7 @@ permits tedu to run procmap as root with
and additionally permits root to run unrestricted commands as itself
while retaining the original PATH.
.Bd -literal -offset indent
-permit persist setenv { PKG_CACHE PKG_PATH } aja cmd pkg_add
+permit persist setenv { PKG_CACHE PKG_PATH } aja cmd /usr/sbin/pkg_add
permit setenv { -ENV PS1=$DOAS_PS1 SSH_AUTH_SOCK } :wheel
permit nopass tedu as root cmd /usr/sbin/procmap
permit nopass keepenv setenv { PATH } root as root
Re: resolv.conf(5) says options inet6 does nothing
Jeremie Courreges-Anglas wrote: > New proposal after discussing this with Theo. > > > Index: net/res_init.3 > === > RCS file: /cvs/src/lib/libc/net/res_init.3,v > retrieving revision 1.2 > diff -u -p -r1.2 res_init.3 > --- net/res_init.325 Apr 2020 14:30:05 - 1.2 > +++ net/res_init.325 Apr 2020 15:59:51 - > @@ -183,6 +183,10 @@ feature. > With this option > .Xr gethostbyname 3 > will return IPv6 addresses if available. > +This option is deprecated, software should use the > +.Xr getaddrinfo 3 > +interface instead of modifying the behavior of > +.Xr gethostbyname 3 . > On some operating systems this option also causes IPv4 addresses to be > returned as IPv4-mapped IPv6 addresses. > For example, 10.1.1.1 will be returned as :::10.1.1.1. I like this a lot better, because it is clear it is the OPTION which is deprecated, and subtly hints this option existed for a bad reason.
Re: resolv.conf(5) says options inet6 does nothing
On Sat, Apr 25 2020, Jeremie Courreges-Anglas wrote: > On Fri, Apr 24 2020, Jeremie Courreges-Anglas wrote: >> On Thu, Apr 23 2020, Eric Faurot wrote: >>> On Thu, Apr 23, 2020 at 10:34:39AM -0600, Theo de Raadt wrote: It says the keyword gets parsed, but then does performs no action. But that is different from not parsing it. Additionally, this explains an option which other systems support, and by explaining it this way, it is also explaining our behaviour in case of inet6 vs inet4 conditions. So... I think it should stay. Eric, do you have an opinion? >>> >>> The doc lies because the inet6 option does not set the RES_USE_INET6 >>> flag as stated. I think we should leave the entry in the doc but fix >>> the wording to say it's there for historical reasons and does nothing. >> >> In the diff below I document the behavior on other operating systems >> since this looks useful to Claudio. How does it read? >> >> (I really think this should go but if it doesn't I don't want it to stay >> misleading as it is now.) >> >>> If we want to resurrect that option at some point, maybe we can >>> consider making it set the RES_USE_INET6 flag but that feels like a >>> bad idea right now, and this flag is apparently deprecated. >> >> I wholeheartedly with this, in my book RES_USE_INET6 and "options inet6" >> are just early IPv6 experiments that went nowhere. >> "options inet6" would break most programs that use gethostbyname(3). >> >>> But we should also fix the manpage for res_init(3) as the description >>> of the flag is wrong too. >> >> Diff below. Thoughts, oks? > > Committed, thanks. > > Eric suggested that we mark this option as deprecated. Proposal: New proposal after discussing this with Theo. Index: net/res_init.3 === RCS file: /cvs/src/lib/libc/net/res_init.3,v retrieving revision 1.2 diff -u -p -r1.2 res_init.3 --- net/res_init.3 25 Apr 2020 14:30:05 - 1.2 +++ net/res_init.3 25 Apr 2020 15:59:51 - @@ -183,6 +183,10 @@ feature. With this option .Xr gethostbyname 3 will return IPv6 addresses if available. +This option is deprecated, software should use the +.Xr getaddrinfo 3 +interface instead of modifying the behavior of +.Xr gethostbyname 3 . On some operating systems this option also causes IPv4 addresses to be returned as IPv4-mapped IPv6 addresses. For example, 10.1.1.1 will be returned as :::10.1.1.1. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Audio over hdmi
Le 25/04/2020 à 13:33, Damien Couderc a écrit :
Le 25/04/2020 à 12:33, Damien Couderc a écrit :
Le 25/04/2020 à 12:13, Solene Rapenne a écrit :
Le Sat, 25 Apr 2020 11:36:12 +0200,
Damien Couderc a écrit :
Hi,
I decided to take a look at what was missing to make audio over hdmi
working on OpenBSD.
After enabling AZALIA_DEBUG in the kernel config I commented the code
that disables HDMI codecs like the following :
--- azalia.c.orig Thu Apr 23 11:44:52 2020
+++ azalia.c Fri Apr 24 12:53:15 2020
@@ -926,9 +926,11 @@
c = -1;
for (i = 0; i < az->ncodecs; i++) {
codec = >codecs[i];
+/*
if ((codec->audiofunc < 0) ||
(codec->codec_type == AZ_CODEC_TYPE_HDMI))
continue;
+*/
if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
if (c < 0)
c = i;
And after rebooting with the modified kernel audio over HDMI was
working out of the box (see the following diff).
I suspect that it is pure luck, what could I miss ?
Could someone test it on Intel based computers ?
hello,
I tried your diff but I'm not sure how to play sound on the screen.
From the FAQ i changed sndiod default output device
# rcctl set sndiod flags -f rsnd/1
# rcctl restart sndiod
but if I run aucat I get the error "default: couldn't open audio device"
Hi solene,
I don't think you need to change sndiod's settings as your device is
already audio0.
That said, I think the Intel audio chip has at least 3 outputs on your
laptop: headphones, speakers and HDMI. And the trick must be to set
the HDMI as default.
Could you show me your mixerctl output ?
Ok so I upgraded my laptop to current and connected it to the same audio
capable screen.
I can see in the dmesg the following (full dmesg provided at the end):
azalia0: unknown03
wcap=40778d
cap=994
[01/00] color=unknown device=digital-out conn=jack conntype=digital
location=spec1 chassis=internal special=hdmi
outamp: mute=1 size=0 steps=0 offset=0
connections=0x2; selected=0x2
azalia_codec_sort_pins: analog out pins:
azalia_codec_sort_pins: digital out pins: 0x03->0x02
azalia_codec_sort_pins: analog in pins:
azalia_codec_sort_pins: digital in pins:
azalia0: dacgroup[0]: 02
azalia0: codecs: Realtek/0x0293, Intel/0x2809, using Realtek/0x0293
audio0 at azalia0
The problem is that outputs.digital-out is not displayed by mixerctl :
inputs.dac-2:3=126,126
inputs.dac-0:1=126,126
record.adc-0:1_mute=off
record.adc-0:1=124,124
record.adc-2:3_mute=off
record.adc-2:3=124,124
record.adc-4:5_mute=off
record.adc-4:5=124,124
inputs.mix_source=mic2
inputs.mix_mic2=120,120
inputs.mix2_source=dac-2:3,mix
inputs.mix3_source=dac-0:1,mix
inputs.mic=85,85
outputs.spkr_source=mix2
outputs.spkr_mute=off
outputs.spkr_eapd=on
outputs.hp_source=mix3
outputs.hp_mute=off
outputs.hp_boost=off
outputs.hp_eapd=on
inputs.mic2=85,85
outputs.mic2_dir=input-vr80
record.adc-4:5_source=mic2
record.adc-2:3_source=mic2
record.adc-0:1_source=mic
outputs.hp_sense=unplugged
outputs.mic2_sense=unplugged
outputs.spkr_muters=hp
outputs.master=126,126
outputs.master.mute=off
outputs.master.slaves=dac-2:3,dac-0:1,spkr,hp
record.volume=124,124
record.volume.mute=off
record.volume.slaves=adc-0:1,adc-2:3,adc-4:5
record.enable=sysctl
I can see in the full dmesg that there are two different FTYPE results
provided during azalia_codec_init and only the first one seems to be
displayed in the mixerctl output.
I think that maybe mixerctl does not recurse all the audio functions or
that some bits aren't recorded. I'll take a look.
Ok, I did a bit of reading and from what I understood there are 2
detected codecs (0 and 2) for the same instance of azalia but the latest
is deleted in azalia_init_codecs() because there is only one that can be
enabled.
Alexandre could maybe tell us what is possible to do here. I think it's
maybe possible to keep all detected codecs but to change which one is
enabled.
Re: resolv.conf(5) says options inet6 does nothing
Jeremie Courreges-Anglas wrote: > On Sat, Apr 25 2020, "Theo de Raadt" wrote: > > This wording doesn't make any sense to me. > > > > When we use the term deprecate, we are talking about interfaces. > > But gethostbyname isn't actually deprecated. getaddrinfo is > > an alternative interface rather than gethostbyname. But gethostbyname > > isn't deprecated. > > I don't understand what the addition mean. > > "This option" kinda implies we're talking about RES_USE_INET6. > Why couldn't it be deprecated? > > What would you suggest? "Using this option together with > gethostbyname(3) is deprecated/discouraged in favor of getaddrinfo(3)"? It is becoming even worse. "because of A, B+C is deprecated" > > At most I think it can > > be said the option is ineffective? > > This option is effective, last commit just made this clear. So it doesn't work. Why document it?
Re: resolv.conf(5) says options inet6 does nothing
On Sat, Apr 25 2020, "Theo de Raadt" wrote: > This wording doesn't make any sense to me. > > When we use the term deprecate, we are talking about interfaces. > But gethostbyname isn't actually deprecated. getaddrinfo is > an alternative interface rather than gethostbyname. But gethostbyname > isn't deprecated. > I don't understand what the addition mean. "This option" kinda implies we're talking about RES_USE_INET6. Why couldn't it be deprecated? What would you suggest? "Using this option together with gethostbyname(3) is deprecated/discouraged in favor of getaddrinfo(3)"? > At most I think it can > be said the option is ineffective? This option is effective, last commit just made this clear. >> Index: net/res_init.3 >> === >> RCS file: /cvs/src/lib/libc/net/res_init.3,v >> retrieving revision 1.2 >> diff -u -p -r1.2 res_init.3 >> --- net/res_init.3 25 Apr 2020 14:30:05 - 1.2 >> +++ net/res_init.3 25 Apr 2020 14:38:39 - >> @@ -183,6 +183,9 @@ feature. >> With this option >> .Xr gethostbyname 3 >> will return IPv6 addresses if available. >> +This option is deprecated in favor of the >> +.Xr getaddrinfo 3 >> +interface. >> On some operating systems this option also causes IPv4 addresses to be >> returned as IPv4-mapped IPv6 addresses. >> For example, 10.1.1.1 will be returned as :::10.1.1.1. >> >> >> -- >> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE > -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: resolv.conf(5) says options inet6 does nothing
This wording doesn't make any sense to me. When we use the term deprecate, we are talking about interfaces. But gethostbyname isn't actually deprecated. getaddrinfo is an alternative interface rather than gethostbyname. But gethostbyname isn't deprecated. I don't understand what the addition mean. At most I think it can be said the option is ineffective? > Index: net/res_init.3 > === > RCS file: /cvs/src/lib/libc/net/res_init.3,v > retrieving revision 1.2 > diff -u -p -r1.2 res_init.3 > --- net/res_init.325 Apr 2020 14:30:05 - 1.2 > +++ net/res_init.325 Apr 2020 14:38:39 - > @@ -183,6 +183,9 @@ feature. > With this option > .Xr gethostbyname 3 > will return IPv6 addresses if available. > +This option is deprecated in favor of the > +.Xr getaddrinfo 3 > +interface. > On some operating systems this option also causes IPv4 addresses to be > returned as IPv4-mapped IPv6 addresses. > For example, 10.1.1.1 will be returned as :::10.1.1.1. > > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: resolv.conf(5) says options inet6 does nothing
On Fri, Apr 24 2020, Jeremie Courreges-Anglas wrote: > On Thu, Apr 23 2020, Eric Faurot wrote: >> On Thu, Apr 23, 2020 at 10:34:39AM -0600, Theo de Raadt wrote: >>> It says the keyword gets parsed, but then does performs no action. >>> >>> But that is different from not parsing it. >>> >>> Additionally, this explains an option which other systems support, and >>> by explaining it this way, it is also explaining our behaviour in case >>> of inet6 vs inet4 conditions. >>> >>> So... I think it should stay. Eric, do you have an opinion? >> >> The doc lies because the inet6 option does not set the RES_USE_INET6 >> flag as stated. I think we should leave the entry in the doc but fix >> the wording to say it's there for historical reasons and does nothing. > > In the diff below I document the behavior on other operating systems > since this looks useful to Claudio. How does it read? > > (I really think this should go but if it doesn't I don't want it to stay > misleading as it is now.) > >> If we want to resurrect that option at some point, maybe we can >> consider making it set the RES_USE_INET6 flag but that feels like a >> bad idea right now, and this flag is apparently deprecated. > > I wholeheartedly with this, in my book RES_USE_INET6 and "options inet6" > are just early IPv6 experiments that went nowhere. > "options inet6" would break most programs that use gethostbyname(3). > >> But we should also fix the manpage for res_init(3) as the description >> of the flag is wrong too. > > Diff below. Thoughts, oks? Committed, thanks. Eric suggested that we mark this option as deprecated. Proposal: Index: net/res_init.3 === RCS file: /cvs/src/lib/libc/net/res_init.3,v retrieving revision 1.2 diff -u -p -r1.2 res_init.3 --- net/res_init.3 25 Apr 2020 14:30:05 - 1.2 +++ net/res_init.3 25 Apr 2020 14:38:39 - @@ -183,6 +183,9 @@ feature. With this option .Xr gethostbyname 3 will return IPv6 addresses if available. +This option is deprecated in favor of the +.Xr getaddrinfo 3 +interface. On some operating systems this option also causes IPv4 addresses to be returned as IPv4-mapped IPv6 addresses. For example, 10.1.1.1 will be returned as :::10.1.1.1. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: smtpd: simplify aliases_get()
On Sat, 25 Apr 2020 13:49:59 +0200, Eric Faurot wrote: > The current code for aliases_get() is a bit contorted I think. > This diff makes it clearer. OK millert@ - todd
smtpd: simplify aliases_get()
Hi,
The current code for aliases_get() is a bit contorted I think.
This diff makes it clearer.
Eric.
Index: aliases.c
===
RCS file: /cvs/src/usr.sbin/smtpd/aliases.c,v
retrieving revision 1.77
diff -u -p -r1.77 aliases.c
--- aliases.c 28 Dec 2018 12:47:28 - 1.77
+++ aliases.c 25 Apr 2020 11:35:08 -
@@ -53,23 +53,18 @@ aliases_get(struct expand *expand, const
xlowercase(buf, username, sizeof(buf));
- /* first, check if entry has a user-part tag */
- pbuf = strchr(buf, *env->sc_subaddressing_delim);
- if (pbuf) {
- ret = table_lookup(mapping, K_ALIAS, buf, );
- if (ret < 0)
- return (-1);
- if (ret)
- goto expand;
+ /* First, check the username as given. */
+ ret = table_lookup(mapping, K_ALIAS, buf, );
+ if (ret == 0 && (pbuf = strchr(buf, *env->sc_subaddressing_delim))) {
+ /* Not found, retry without the tag if there is one. */
*pbuf = '\0';
+ ret = table_lookup(mapping, K_ALIAS, buf, );
}
- /* no user-part tag, try looking up user */
- ret = table_lookup(mapping, K_ALIAS, buf, );
+ /* Not found or error */
if (ret <= 0)
return ret;
-expand:
/* foreach node in table_alias expandtree, we merge */
nbaliases = 0;
RB_FOREACH(xn, expandtree, >tree) {
Re: Audio over hdmi
Le 25/04/2020 à 12:33, Damien Couderc a écrit :
Le 25/04/2020 à 12:13, Solene Rapenne a écrit :
Le Sat, 25 Apr 2020 11:36:12 +0200,
Damien Couderc a écrit :
Hi,
I decided to take a look at what was missing to make audio over hdmi
working on OpenBSD.
After enabling AZALIA_DEBUG in the kernel config I commented the code
that disables HDMI codecs like the following :
--- azalia.c.orig Thu Apr 23 11:44:52 2020
+++ azalia.c Fri Apr 24 12:53:15 2020
@@ -926,9 +926,11 @@
c = -1;
for (i = 0; i < az->ncodecs; i++) {
codec = >codecs[i];
+/*
if ((codec->audiofunc < 0) ||
(codec->codec_type == AZ_CODEC_TYPE_HDMI))
continue;
+*/
if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
if (c < 0)
c = i;
And after rebooting with the modified kernel audio over HDMI was
working out of the box (see the following diff).
I suspect that it is pure luck, what could I miss ?
Could someone test it on Intel based computers ?
hello,
I tried your diff but I'm not sure how to play sound on the screen.
From the FAQ i changed sndiod default output device
# rcctl set sndiod flags -f rsnd/1
# rcctl restart sndiod
but if I run aucat I get the error "default: couldn't open audio device"
Hi solene,
I don't think you need to change sndiod's settings as your device is
already audio0.
That said, I think the Intel audio chip has at least 3 outputs on your
laptop: headphones, speakers and HDMI. And the trick must be to set the
HDMI as default.
Could you show me your mixerctl output ?
Ok so I upgraded my laptop to current and connected it to the same audio
capable screen.
I can see in the dmesg the following (full dmesg provided at the end):
azalia0: unknown03
wcap=40778d
cap=994
[01/00] color=unknown device=digital-out conn=jack conntype=digital
location=spec1 chassis=internal special=hdmi
outamp: mute=1 size=0 steps=0 offset=0
connections=0x2; selected=0x2
azalia_codec_sort_pins: analog out pins:
azalia_codec_sort_pins: digital out pins: 0x03->0x02
azalia_codec_sort_pins: analog in pins:
azalia_codec_sort_pins: digital in pins:
azalia0: dacgroup[0]: 02
azalia0: codecs: Realtek/0x0293, Intel/0x2809, using Realtek/0x0293
audio0 at azalia0
The problem is that outputs.digital-out is not displayed by mixerctl :
inputs.dac-2:3=126,126
inputs.dac-0:1=126,126
record.adc-0:1_mute=off
record.adc-0:1=124,124
record.adc-2:3_mute=off
record.adc-2:3=124,124
record.adc-4:5_mute=off
record.adc-4:5=124,124
inputs.mix_source=mic2
inputs.mix_mic2=120,120
inputs.mix2_source=dac-2:3,mix
inputs.mix3_source=dac-0:1,mix
inputs.mic=85,85
outputs.spkr_source=mix2
outputs.spkr_mute=off
outputs.spkr_eapd=on
outputs.hp_source=mix3
outputs.hp_mute=off
outputs.hp_boost=off
outputs.hp_eapd=on
inputs.mic2=85,85
outputs.mic2_dir=input-vr80
record.adc-4:5_source=mic2
record.adc-2:3_source=mic2
record.adc-0:1_source=mic
outputs.hp_sense=unplugged
outputs.mic2_sense=unplugged
outputs.spkr_muters=hp
outputs.master=126,126
outputs.master.mute=off
outputs.master.slaves=dac-2:3,dac-0:1,spkr,hp
record.volume=124,124
record.volume.mute=off
record.volume.slaves=adc-0:1,adc-2:3,adc-4:5
record.enable=sysctl
I can see in the full dmesg that there are two different FTYPE results
provided during azalia_codec_init and only the first one seems to be
displayed in the mixerctl output.
I think that maybe mixerctl does not recurse all the audio functions or
that some bits aren't recorded. I'll take a look.
Here is the full dmesg:
OpenBSD 6.7-beta (GENERIC.MP) #3: Fri Apr 24 12:53:39 CEST 2020
damien@current.petrolan:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17012170752 (16224MB)
avail mem = 16483958784 (15720MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xd7082000 (65 entries)
bios0: vendor LENOVO version "N1KET41W (1.28 )" date 09/12/2018
bios0: LENOVO 20FH001FFR
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP TCPA SSDT UEFI SSDT SSDT ECDT HPET APIC MCFG
SSDT DBGP DBG2 BOOT BATB SLIC SSDT SSDT MSDM DMAR ASF! FPDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2195.76 MHz, 06-4e-03
cpu0:
Re: Audio over hdmi
Le 25/04/2020 à 12:13, Solene Rapenne a écrit :
Le Sat, 25 Apr 2020 11:36:12 +0200,
Damien Couderc a écrit :
Hi,
I decided to take a look at what was missing to make audio over hdmi
working on OpenBSD.
After enabling AZALIA_DEBUG in the kernel config I commented the code
that disables HDMI codecs like the following :
--- azalia.c.orig Thu Apr 23 11:44:52 2020
+++ azalia.cFri Apr 24 12:53:15 2020
@@ -926,9 +926,11 @@
c = -1;
for (i = 0; i < az->ncodecs; i++) {
codec = >codecs[i];
+/*
if ((codec->audiofunc < 0) ||
(codec->codec_type == AZ_CODEC_TYPE_HDMI))
continue;
+*/
if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
if (c < 0)
c = i;
And after rebooting with the modified kernel audio over HDMI was
working out of the box (see the following diff).
I suspect that it is pure luck, what could I miss ?
Could someone test it on Intel based computers ?
hello,
I tried your diff but I'm not sure how to play sound on the screen.
From the FAQ i changed sndiod default output device
# rcctl set sndiod flags -f rsnd/1
# rcctl restart sndiod
but if I run aucat I get the error "default: couldn't open audio device"
Hi solene,
I don't think you need to change sndiod's settings as your device is
already audio0.
That said, I think the Intel audio chip has at least 3 outputs on your
laptop: headphones, speakers and HDMI. And the trick must be to set the
HDMI as default.
Could you show me your mixerctl output ?
Regards,
Damien
dmesg
OpenBSD 6.7-beta (GENERIC.MP) #0: Sat Apr 25 12:02:14 CEST 2020
solene@solene.perso.local:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8323534848 (7937MB)
avail mem = 8058654720 (7685MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xaf07e000 (63 entries)
bios0: vendor LENOVO version "N24ET51W (1.26 )" date 08/30/2019
bios0: LENOVO 20L5CTO1WW
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT
SSDT SSDT BOOT BATB SLIC SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM
DMAR ASF! FPDT UEFI BGRT
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4)
RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4)
RP06(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.82 MHz, 06-8e-0a
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu3:
Re: Audio over hdmi
Le Sat, 25 Apr 2020 11:36:12 +0200,
Damien Couderc a écrit :
> Hi,
>
> I decided to take a look at what was missing to make audio over hdmi
> working on OpenBSD.
>
> After enabling AZALIA_DEBUG in the kernel config I commented the code
> that disables HDMI codecs like the following :
>
>
> --- azalia.c.orig Thu Apr 23 11:44:52 2020
> +++ azalia.c Fri Apr 24 12:53:15 2020
> @@ -926,9 +926,11 @@
> c = -1;
> for (i = 0; i < az->ncodecs; i++) {
> codec = >codecs[i];
> +/*
> if ((codec->audiofunc < 0) ||
> (codec->codec_type == AZ_CODEC_TYPE_HDMI))
> continue;
> +*/
> if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
> if (c < 0)
> c = i;
>
>
> And after rebooting with the modified kernel audio over HDMI was
> working out of the box (see the following diff).
>
> I suspect that it is pure luck, what could I miss ?
> Could someone test it on Intel based computers ?
>
hello,
I tried your diff but I'm not sure how to play sound on the screen.
From the FAQ i changed sndiod default output device
# rcctl set sndiod flags -f rsnd/1
# rcctl restart sndiod
but if I run aucat I get the error "default: couldn't open audio device"
dmesg
OpenBSD 6.7-beta (GENERIC.MP) #0: Sat Apr 25 12:02:14 CEST 2020
solene@solene.perso.local:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8323534848 (7937MB)
avail mem = 8058654720 (7685MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xaf07e000 (63 entries)
bios0: vendor LENOVO version "N24ET51W (1.26 )" date 08/30/2019
bios0: LENOVO 20L5CTO1WW
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT
SSDT SSDT BOOT BATB SLIC SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM
DMAR ASF! FPDT UEFI BGRT
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4)
RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4)
RP06(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.82 MHz, 06-8e-0a
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu3:
Re: acme-client(1) and Buypass Go SSL
I fixed warn() and changed certproc.c to be less confusing.
On 21/04/2020 21:17, Sebastian Benoit wrote:
Bartosz Kuzma(bartosz.ku...@release11.com) on 2020.04.21 20:59:54 +0200:
Hello,
thanks for looking at this!
On 21/04/2020 17:43, Florian Obser wrote:
Hi,
thanks for working on this and finding another acme implementor!
On Mon, Apr 20, 2020 at 06:51:17PM +0200, Bartosz Kuzma wrote:
Hello,
I've tried to get a certificate from Buypass Go SSL provider using
acme-client(1) but it ends with the following error:
acme-client: https://api.buypass.com/acme-v02/new-acct: bad HTTP: 400
acme-client: transfer buffer:
[{"type":"urn:ietf:params:acme:error:malformed","d
etail":"Email is a required
contact","code":400,"message":"MALFORMED_BAD_REQUEST
","details":"HTTP 400 Bad Request"}] (164 bytes)
Buypass Go SSL requires that optional field contact in Account Objects
will contain email address.
I've added new option "contact" to acme-client.conf to fullfil this
requirement. It is also required to change MARKER in certproc.c to fix
line
endings handling in pem files.
they are leaving out the last newline?
It seems that chain can be provided with "\n" or "\r\n" line separator.
I removed it from MARKER to handle both cases.
--
Kind regards, Bartosz Kuzma.
Index: usr.sbin/acme-client/acme-client.conf.5
===
RCS file: /cvs/src/usr.sbin/acme-client/acme-client.conf.5,v
retrieving revision 1.22
diff -u -p -r1.22 acme-client.conf.5
--- usr.sbin/acme-client/acme-client.conf.5 10 Feb 2020 13:18:21 -
1.22
+++ usr.sbin/acme-client/acme-client.conf.5 20 Apr 2020 16:24:46 -
@@ -98,6 +98,10 @@ It defaults to
Specify the
.Ar url
under which the ACME API is reachable.
+.It Ic contact Ar contact
+Optional
+.Ar contact
+URLs that the authority can use to contact the client for issues related
to this account.
I think we should call it emails. That's what people actually have.
According to the RFC it's a list of contacts, but I'm fine with having
only one.
For me one contact is also enough.
.El
.Sh DOMAINS
The certificates to be obtained through ACME.
Index: usr.sbin/acme-client/certproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/certproc.c,v
retrieving revision 1.12
diff -u -p -r1.12 certproc.c
--- usr.sbin/acme-client/certproc.c 7 Jun 2019 08:07:52 - 1.12
+++ usr.sbin/acme-client/certproc.c 20 Apr 2020 16:24:46 -
@@ -28,7 +28,7 @@
#include "extern.h"
-#define MARKER "-END CERTIFICATE-\n"
+#define MARKER "-END CERTIFICATE-"
int
certproc(int netsock, int filesock)
@@ -94,6 +94,12 @@ certproc(int netsock, int filesock)
}
chaincp += strlen(MARKER);
+
+ if ((chaincp = strchr(chaincp, '-')) == NULL) {
+ warn("strchr");
+ goto out;
+ }
+
I don't quite understand what this is doing.
Because I removed new line character from MARKER strchr() just move
pointer to -BEGIN CERTIFICATE to skip any new lines character
from chain. It can be replaced by strstr("-BEGIN CERTIFICATE-")
if this improve readability.
The warn() should be a warnx() then, because strchr() does not set errno.
When it returns NULL it just means that it did not find the string. So
warnx("invalid certificate chain");
would be a good error message here i think.
Index: etc/examples/acme-client.conf
===
RCS file: /cvs/src/etc/examples/acme-client.conf,v
retrieving revision 1.2
diff -u -p -r1.2 acme-client.conf
--- etc/examples/acme-client.conf 7 Jun 2019 08:08:30 - 1.2
+++ etc/examples/acme-client.conf 25 Apr 2020 09:52:11 -
@@ -11,6 +11,18 @@ authority letsencrypt-staging {
account key "/etc/acme/letsencrypt-staging-privkey.pem"
}
+authority buypass {
+api url "https://api.buypass.com/acme/directory;
+account key "/etc/acme/buypass-privkey.pem"
+contact "mailto:j...@example.net;
+}
+
+authority buypass-test {
+api url "https://api.test4.buypass.no/acme/directory;
+account key "/etc/acme/buypass-test-privkey.pem"
+contact "mailto:j...@example.net;
+}
+
domain example.com {
alternative names { secure.example.com }
domain key "/etc/ssl/private/example.com.key"
Index: usr.sbin/acme-client/acme-client.conf.5
===
RCS file: /cvs/src/usr.sbin/acme-client/acme-client.conf.5,v
retrieving revision 1.22
diff -u -p -r1.22 acme-client.conf.5
--- usr.sbin/acme-client/acme-client.conf.5 10 Feb 2020 13:18:21 -
1.22
+++ usr.sbin/acme-client/acme-client.conf.5 25 Apr 2020 09:52:11 -
@@ -98,6 +98,10 @@ It defaults to
Specify the
.Ar url
under which the ACME API is reachable.
+.It Ic contact Ar contact
+Optional
+.Ar contact
+URLs that the authority can
Audio over hdmi
Hi,
I decided to take a look at what was missing to make audio over hdmi
working on OpenBSD.
After enabling AZALIA_DEBUG in the kernel config I commented the code
that disables HDMI codecs like the following :
--- azalia.c.orig Thu Apr 23 11:44:52 2020
+++ azalia.cFri Apr 24 12:53:15 2020
@@ -926,9 +926,11 @@
c = -1;
for (i = 0; i < az->ncodecs; i++) {
codec = >codecs[i];
+/*
if ((codec->audiofunc < 0) ||
(codec->codec_type == AZ_CODEC_TYPE_HDMI))
continue;
+*/
if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
if (c < 0)
c = i;
And after rebooting with the modified kernel audio over HDMI was working
out of the box (see the following diff).
I suspect that it is pure luck, what could I miss ?
Could someone test it on Intel based computers ?
Here is the promised dmesg :
OpenBSD 6.7-beta (GENERIC.MP) #3: Fri Apr 24 12:53:39 CEST 2020
damien@current.petrolan:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34271739904 (32684MB)
avail mem = 33220448256 (31681MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xe94f0 (31 entries)
bios0: vendor American Megatrends Inc. version "P1.80" date 12/18/2018
bios0: ASRock B450 Gaming K4
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT CRAT CDIT SSDT MCFG
AAFT HPET SSDT UEFI IVRS SSDT SSDT WSMT
acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4)
GPP6(S4) GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4)
GPPE(S4) GPPF(S4) GP17(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 7 2700 Eight-Core Processor, 3194.61 MHz, 17-08-02
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, 16MB 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 99MHz
cpu0: mwait min=64, max=64, C-substates=1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Ryzen 7 2700 Eight-Core Processor, 3194.00 MHz, 17-08-02
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, 16MB 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 2700 Eight-Core Processor, 3194.01 MHz, 17-08-02
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, 16MB 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 2700 Eight-Core Processor, 3194.00 MHz, 17-08-02
cpu3:
