I just noticed that our make(1) supports VPATH, but is not
documented.
OK?
Index: make.1
===
RCS file: /cvs/src/usr.bin/make/make.1,v
diff -u -p -r1.141 make.1
--- make.1 10 Aug 2023 10:56:34 - 1.141
+++ make.1 25
On Sun, Sep 24, 2023 at 11:03:54PM +0300, Vitaliy Makkoveev wrote:
> Please test this diff, I have no midi(4) devices.
>
> midi(4) already uses `audio_lock' mutex(9) for filterops, but they are
> still kernel locked. Wipe out old selwakeup API and make them MP safe.
> knote_locked(9) will not
On Mon, Sep 25, 2023 at 04:58:56PM +0300, Vitaliy Makkoveev wrote:
> On Mon, Sep 25, 2023 at 05:39:34AM +, Visa Hankala wrote:
> > On Sun, Sep 24, 2023 at 11:03:54PM +0300, Vitaliy Makkoveev wrote:
> > > Please test this diff, I have no midi(4) devices.
> > >
> > > midi(4) already uses
ntext and diff below:
- Forwarded message from Andreas Bartelt -
Date: Sat, 4 Mar 2023 16:12:22 +0100
From: Andreas Bartelt
To: Alexandre Ratchov , b...@openbsd.org
Subject: Re: audio(4) output doesn't work yet on ASUS ProArt X670E-CREATOR WIFI
mainboard (ALC1220
CODEC)
User-Age
Sometimes sndiod closes the device sponteneously and, unless -F is
used, programs need to be restarted. If -F is used, sndiod will switch
to another device (ex. from usb headphones to internal speakers),
which might be a privacy problem.
The cause is that libsndio uses the kernel underrun
On Tue, Jan 03, 2023 at 09:51:46PM -0400, Jose Maldonado wrote:
> Hi, everyone!
>
> Right now I'm using OBSD 7.2 (my first time in OBSD) and the only issue is
> my onboard audio. The audio randomly stuck (listen music or not, with high
> CPU use or not) and only a hard reboot give me back audio
On Sat, Dec 10, 2022 at 09:39:41AM +, Edd Barrett wrote:
> I agree with ratchov that in this instance, precise timing isn't important.
>
So, are we OK with this or there are still objections?
On Fri, Dec 09, 2022 at 12:43:31PM -0600, Scott Cheloha wrote:
> On Fri, Dec 09, 2022 at 12:10:59PM +0100, Alexandre Ratchov wrote:
> > This diff adds an option to display variables periodically. Basically
> > it replaces this usage:
> >
> > while sleep 1; do
On Fri, Dec 09, 2022 at 04:24:03PM +, Edd Barrett wrote:
> On Fri, Dec 09, 2022 at 12:10:59PM +0100, Alexandre Ratchov wrote:
> > -Display the number of bytes of silence inserted during play buffer
> > -underruns since device started:
> > +Once per second, displa
This diff adds an option to display variables periodically. Basically
it replaces this usage:
while sleep 1; do audioctl play.errors; done
by
audioctl -w 1 play.errors
The purpose of above audioctl commands is to debug underruns, so we
don't want to fork a new process and
On Wed, Nov 30, 2022 at 09:20:26AM -0600, Scott Cheloha wrote:
> Couple related things:
>
> - Use err(3) everywhere.
>
> For many of these errors we are not currently printing the errno
> string. Is there any reason not to do so? The errno string is
> useful.
>
> - Set ifile/ofile to
On Sun, Oct 30, 2022 at 11:02:39AM +, Klemens Nanni wrote:
> Only five legacy half-duplex hardware drivers require this function to
> change between playing and recording:
> i386: ess(4), gus(4), pas(4), sb(4)
> luna88k: nec86(4)
>
> If defined, it is always called early in
On Thu, Oct 27, 2022 at 08:35:31PM +, Klemens Nanni wrote:
> On Thu, Oct 27, 2022 at 03:51:05PM +0200, Alexandre Ratchov wrote:
> > On Thu, Oct 27, 2022 at 01:08:57PM +, Klemens Nanni wrote:
> > > @@ -1040,6 +1041,9 @@ ad1848_open(void *addr, int flags)
>
On Thu, Oct 27, 2022 at 08:28:53PM +, Klemens Nanni wrote:
> On Thu, Oct 27, 2022 at 03:49:55PM +0200, Alexandre Ratchov wrote:
> > On Thu, Oct 27, 2022 at 01:09:57PM +, Klemens Nanni wrote:
> > > @@ -1859,6 +1857,9 @@ utvfu_audio_open(void *v, int flags)
> >
On Thu, Oct 27, 2022 at 01:08:57PM +, Klemens Nanni wrote:
> @@ -1040,6 +1041,9 @@ ad1848_open(void *addr, int flags)
>
> DPRINTF(("ad1848_open: sc=%p\n", sc));
>
> + if ((flags & (FWRITE | FREAD)) && sc->mode != 2)
> + return ENXIO;
> +
> sc->sc_pintr =
On Thu, Oct 27, 2022 at 01:27:43PM +, Klemens Nanni wrote:
> Make drivers which do *not* adverise AUDIO_PROP_FULLDPLEX return ENXIO
> in their open() if full-duplex mode was requested.
>
> This way, sys/dev/audio.c:audio_open() will fail immediately rather than
> later through the
On Thu, Oct 27, 2022 at 01:09:57PM +, Klemens Nanni wrote:
> @@ -1859,6 +1857,9 @@ utvfu_audio_open(void *v, int flags)
> if (usbd_is_dying(sc->sc_udev))
> return (EIO);
>
> + if ((flags & (FWRITE | FREAD)))
> + return (ENXIO);
> +
> if ((flags &
On Tue, Oct 25, 2022 at 10:25:30PM +, Klemens Nanni wrote:
> The property bits of audio(9) are obsolete and ought to be removed
> completely.
>
> sys/dev/audio.c:audio_open() currently uses get_props() to bail out if
> read *and* write was requested on a driver non-duplex driver.
>
> Drivers
On Wed, Oct 19, 2022 at 07:31:59PM +, Klemens Nanni wrote:
> All consumers now use C99 struct init and none of them sets `.setfd'.
>
> My X230 still plays audio just fine:
> azalia0 at pci0 dev 27 function 0 "Intel 7 Series HD Audio" rev 0x04: msi
> azalia0: codecs: Realtek ALC269,
On Wed, Oct 19, 2022 at 08:33:17AM +, Klemens Nanni wrote:
> Used only for lookups; builds on i386.
>
> OK?
>
sure!
On Tue, Oct 18, 2022 at 02:27:53PM +, Klemens Nanni wrote:
> Each only used once for a printf() call in *_attach().
> Seen while tweaking their *_hw_if struct.
>
> OK?
>
ok
On Tue, Oct 18, 2022 at 08:02:34PM +, Klemens Nanni wrote:
>
> Here's the actual complete diff that was tested as per above,
> the previous did not include a bunch of files.
>
> I can also send/commit this in smaller per driver/arch/whatever chunks
> if that's preferred.
Your call ;-)
ok
On Tue, Oct 18, 2022 at 02:17:54PM +, Klemens Nanni wrote:
> audio(9) cleanup demands removing a member from this struct, which is
> cumbersome in our current tree as drivers initialise it inconsistently,
> i.e. a simple removal of ".member_name = driver_func," is not always
> possible.
>
>
On Mon, Oct 17, 2022 at 07:45:33PM +, Klemens Nanni wrote:
> I was looking at one particular driver and needed to know what those
> flags are, turns out AUDIO_PROP_FULLDUPLEX is the only audio(9) property
> that is in use.
Even AUDIO_PROP_FULLDUPLEX (and the associated get_props() and setfd()
On Thu, Apr 28, 2022 at 06:34:00AM -0500, Scott Cheloha wrote:
> speaker(4) is a whimsical thing, but I don't think we should have a
> dedicated chiptune interpreter in the kernel.
>
> This patch unhooks the driver and the manpage from the build. The
> driver is built for alpha, amd64, and i386.
On Wed, Apr 27, 2022 at 10:48:42PM +0200, Caspar Schutijser wrote:
> Hi,
>
> On Thu, Mar 24, 2022 at 07:11:42AM +0100, Alexandre Ratchov wrote:
> > Most audio/video players do a stop/start cycle whenever the play
> > position is changed, track is changed, etc. Curre
On Thu, Mar 24, 2022 at 07:11:42AM +0100, Alexandre Ratchov wrote:
> Most audio/video players do a stop/start cycle whenever the play
> position is changed, track is changed, etc. Currently, stopping drains
> the play buffer, which by default is very large (to workaround very
> lon
Most audio/video players do a stop/start cycle whenever the play
position is changed, track is changed, etc. Currently, stopping drains
the play buffer, which by default is very large (to workaround very
long kernel non-preemptive code-paths). This makes player controls
sluggish.
This diff adds a
On Mon, Mar 21, 2022 at 12:09:54PM +, Miod Vallat wrote:
> The following diff makes {audio,midi,radio,video}_hw_if structs in the
> kernel const, in order to move them to rodata.
>
ok ratchov
On Thu, Feb 10, 2022 at 04:53:59PM +0100, Anton Lindqvist wrote:
> On Wed, Feb 09, 2022 at 09:13:58AM +0100, Alexandre Ratchov wrote:
> > On Tue, Feb 08, 2022 at 06:59:39PM +0100, Anton Lindqvist wrote:
> > > On Tue, Feb 08, 2022 at 07:32:38AM +0100, Alexandre Ratchov wrote:
>
On Tue, Feb 08, 2022 at 06:59:39PM +0100, Anton Lindqvist wrote:
> On Tue, Feb 08, 2022 at 07:32:38AM +0100, Alexandre Ratchov wrote:
> > On Mon, Feb 07, 2022 at 06:55:21PM +0100, Anton Lindqvist wrote:
> > > On Mon, Feb 07, 2022 at 11:21:43AM +0100, Alexandre Ratchov wrote:
>
On Mon, Feb 07, 2022 at 06:55:21PM +0100, Anton Lindqvist wrote:
> On Mon, Feb 07, 2022 at 11:21:43AM +0100, Alexandre Ratchov wrote:
> > On Sun, Feb 06, 2022 at 08:40:35AM +0100, Anton Lindqvist wrote:
> > >
> > > Polished diff. I'm omitting a necessar
On Mon, Feb 07, 2022 at 06:58:40PM +0100, Anton Lindqvist wrote:
> On Mon, Feb 07, 2022 at 11:43:43AM +0100, Alexandre Ratchov wrote:
> > On Sat, Feb 05, 2022 at 06:30:43PM +0100, Claudio Jeker wrote:
> > > On Sat, Feb 05, 2022 at 12:28:08PM +0100, Mark Kettenis wrote:
> >
On Sat, Feb 05, 2022 at 06:30:43PM +0100, Claudio Jeker wrote:
> On Sat, Feb 05, 2022 at 12:28:08PM +0100, Mark Kettenis wrote:
> > > Date: Sat, 5 Feb 2022 09:29:42 +0100
> > > From: Anton Lindqvist
> > >
> > > Hi,
> > > I recently got a USB headset with physical volume buttons, handled by
> > >
On Sun, Feb 06, 2022 at 08:40:35AM +0100, Anton Lindqvist wrote:
>
> Polished diff. I'm omitting a necessary refactoring commit making
> audio_attach_mi() accept a new cookie argument.
>
I'm not sure to understand the need for the wskbd_audio structure.
Couldn't we just store the cookie in
On Sat, Feb 05, 2022 at 06:30:43PM +0100, Claudio Jeker wrote:
> On Sat, Feb 05, 2022 at 12:28:08PM +0100, Mark Kettenis wrote:
> > > Date: Sat, 5 Feb 2022 09:29:42 +0100
> > > From: Anton Lindqvist
> > >
> > > Hi,
> > > I recently got a USB headset with physical volume buttons, handled by
> > >
On Sat, Feb 05, 2022 at 09:29:42AM +0100, Anton Lindqvist wrote:
> Hi,
> I recently got a USB headset with physical volume buttons, handled by
> ucc(4). However, after enabling the device in sndiod the volume buttons
> does not cause the volume to change. Turns out wskbd_set_mixervolume()
> is
On Sat, Dec 25, 2021 at 02:51:08PM +, Klemens Nanni wrote:
>
> either "devices that are" or "device that is", I'd say the latter.
>
commited with "device that is".
BTW, the example of the -F option description seems more appropriate
for the new hot plugging section.
OK?
diff --git
On Sat, Dec 25, 2021 at 01:34:19PM +, Klemens Nanni wrote:
>
> This reads OK kn, but I suspect others will object to the hotplugd(8)
> reference.
>
here's a new one, with attach/detach replaced by plug/unplug and no
ref to hotplug(8)
OK?
diff --git a/sndiod/sndiod.8 b/sndiod/sndiod.8
This diff switches internal sample representation frem 16-bit to
24-bit fixed-point. Resampling is already 24-bit only, so there's
little point in keeping the current 16-bit code.
The default device precision doesn't change, i.e. we still request the
same 16-bit mode (and convert everything to
On Fri, Dec 17, 2021 at 07:11:41PM +, Klemens Nanni wrote:
>
> So we've concluded that the hotplpugging framework needs work, fine.
>
> I'd still like to improve sndiod(8) regarding its own behaviour.
>
> How about the same diff modulo hotplug referencing/examples?
> This helps me
On Sat, Dec 18, 2021 at 10:27:34AM +, Jason McIntyre wrote:
> On Sat, Dec 18, 2021 at 10:51:28AM +0100, Richard Ulmer wrote:
> > Hi,
> > after reading about using USB audio interfaces in
> > https://www.openbsd.org/faq/faq13.html I looked up what -F and -f mean
> > in sndiod(8) but was briefly
On Thu, Dec 09, 2021 at 09:02:07PM -0700, Theo de Raadt wrote:
>
> I think drivers, or maybe this can be done in higher-level subsystems, need
> to be modified such that events get sent when a device is *actually ready*,
> and the call from config_attach() should be deleted.
>
For audio and
On Thu, Dec 09, 2021 at 02:04:06PM +0100, Solene Rapenne wrote:
>
> where does sndioctl server.device= come from?
>
> on my system I don't have the server.device property
>
There's one server.device knob for each "-s" to controls on which
device are player (or recorded from).
> > sndioctl
On Wed, Dec 08, 2021 at 10:30:08PM +, Klemens Nanni wrote:
> Following https://www.openbsd.org/faq/faq13.html#usbaudio and reading
> sndiod(8)'s
>
> -F device
> Specify an alternate device to use. If it doesn't work, the one
> given with the last -f or -F
The current sndiod latency (minimum time between when the program
plays something and when sound reaches Joe's ears) is too large and
makes OpenBSD unpleasant to use for telephony, games, and makes
controls of video players slugish.
The defaut latency (of 160ms) was set ~10 years ago to
selwakeup() needs to be protected by KERNEL_LOCK, but we're not
allowed to grab KERNEL_LOCK on interrupt context because midi runs at
IPL_AUDIO with the audio_lock held.
Furthermore, doing so is a locking order bug: syscall code-path grabs
KERNEL_LOCK first while interrupt code-path does the
On Fri, Oct 29, 2021 at 01:12:06PM +0100, Martin Pieuchot wrote:
> On 29/10/21(Fri) 13:12, Alexandre Ratchov wrote:
> > On Sat, Oct 23, 2021 at 10:40:56AM +0100, Martin Pieuchot wrote:
> > > Diff below switches both poll(2) and select(2) to the kqueue-based
&g
On Sat, Oct 23, 2021 at 10:40:56AM +0100, Martin Pieuchot wrote:
> Diff below switches both poll(2) and select(2) to the kqueue-based
> implementation.
>
> In addition it switches libevent(3) to use poll(2) by default for
> testing purposes.
>
> I don't have any open bug left with this diff and
Hi,
Current sndiod logic supports one device only: If two -f are used then
two independent instances of the whole server are created, each with
its own set of clients, options, controls, and so on. This diff shifts
sndiod towards a more flexible (and conceptually simpler) model:
- clients
On Wed, Jul 07, 2021 at 03:13:37PM +0100, Edd Barrett wrote:
> Hi,
>
> This diff is an attempt to make identifying audio devices easier by
> giving each device a human-readable description that can be read from
> userspace (and without scraping dmesg).
>
> This is implemented on a
On Wed, Jul 07, 2021 at 08:25:16AM -0600, Theo de Raadt wrote:
> > This diff is an attempt to make identifying audio devices easier by
> > giving each device a human-readable description that can be read from
> > userspace (and without scraping dmesg).
>
> But why does anyone want that?
>
>
On Thu, Apr 15, 2021 at 03:24:56PM +0200, Ivo Sbalzarini wrote:
> Thanks a lot!
>
> I also got the sound working on this machine now. As far as I
> can tell, both speakers work and Dolby Atmos works, too, thanks
> to the awesome quirk by Joshua Stein (jcs@).
>
> I’m not sure I did everything
On Sat, Feb 27, 2021 at 09:59:21PM +, Edd Barrett wrote:
>
> This is mostly a no-op for sndiod in the default configuration (except
> that play-only devices now accept recording clients). If you use
> alternative devices (-F), then it's possible for a record-only device to
> be found first,
On Fri, Jan 29, 2021 at 12:42:37PM +0100, Alexandre Ratchov wrote:
> Moving to a global server-wide controls list is necessary to expose
> controls that are not associated to a particular device (ex. a device
> selector).
>
> The current hack to use the device-side sioctl_desc
Moving to a global server-wide controls list is necessary to expose
controls that are not associated to a particular device (ex. a device
selector).
The current hack to use the device-side sioctl_desc->addr variable as
client-side key can't work anymore. So, we use a unique dynamically
allocated
On Tue, Jan 26, 2021 at 08:56:29PM +, Edd Barrett wrote:
> Hi,
>
> I've recently come across a uaudio device which doesn't work in OpenBSD:
>
> uaudio2 at uhub0 port 1 configuration 1 interface 3 "E+ Corp. DAC Audio" rev
> 1.10/0.01 addr 2
> uaudio2: class v1, full-speed, async, channels: 2
On Sun, Dec 20, 2020 at 05:58:22PM +0200, Paul Irofti wrote:
> Hi,
>
> Interesting diff.
>
> I did not have time to look at it thoroughly, but here are a few
> observations:
>
Hi,
Thanks for looking at this.
- why do you keep the symmetric filter coefficients? (this could halve your
>
Hi,
The current sndiod resampling algorithm is very basic mainly to keep
CPU usage very low, which used to make sense for the zaurus. So,
resampling produces aliasing noise, easily audible in 8kHz to 48kHz
conversions but present in other cases.
The diff below reduces the aliasing noise. It's a
On Fri, Dec 11, 2020 at 09:07:45AM +0100, Marcus Glocker wrote:
>
> After doing some deeper analyzes in to asmc_wait() I agree to that.
> Something seems to go fundamental wrong there. In every asmc_update()
> execution, I can see asmc_wait() timeout 9 times, always on the
> ASMC_ACCEPT check.
On Thu, Dec 10, 2020 at 05:27:16PM +0100, Marcus Glocker wrote:
> Hi All,
>
> I recently started to play around with uvideo(4) and uaudio(4) on my
> amd64 iMacs. There I quickly noticed regular freezes when streaming
> USB video or audio. On some of those machines it was very frequent,
> like
this wording is shorter and more precise and complete.
ok?
Index: sio_open.3
===
RCS file: /cvs/src/lib/libsndio/sio_open.3,v
retrieving revision 1.51
diff -u -p -r1.51 sio_open.3
--- sio_open.3 20 Nov 2020 12:09:45 - 1.51
On Fri, Nov 20, 2020 at 05:49:00PM +0100, Klemens Nanni wrote:
> Not every control has a group as the manual wording says, i.e.
>
> $ sndioctl
> input.level=0.486
> input.mute=0
> output.level=1.000
> output.mute=0
> app/aucat0.level=1.000
>
> Feedack? OK?
OK
On Tue, Nov 17, 2020 at 05:09:28PM +, Stuart Henderson wrote:
> On 2020/11/17 17:13, Peter J. Philipp wrote:
> > Hi,
> >
> > I have a mic on snd/1 and speakers on snd/0. I had tried a lot of different
> > settings with audacity port but couldn't get this to work, so I chose the
> > method of
On Sat, Oct 17, 2020 at 05:52:58PM +0200, Jan Stary wrote:
> Currently, mixerctl.conf(5) says
>
> Most devices have a number of digital to analogue converters
> (DACs), used for sound playback, and each DAC has a corresponding
> output mixer. The mixers are labelled “mix” or
On Fri, May 22, 2020 at 08:10:54AM +0100, Ricardo Mestre wrote:
> Hello,
>
> I tried to open the raw device but now it seems I was to sleepy to
> figure out that I couldn't access it due to sndiod(8) having the device
> opened earlier and therefore coundn't reach that code path.
>
> Here's the
On Fri, May 01, 2020 at 05:16:10PM +0200, Damien Couderc wrote:
>
> So if I'm not wrong it could be possible to set the -f option with the
> analog device and the -F option with the digital-only one.
>
> That said, it would work only if you have two audio device (e.g. HDMI from
> video card as
On Fri, May 01, 2020 at 03:01:04PM +0200, Mark Kettenis wrote:
> > Date: Fri, 1 May 2020 14:17:56 +0200
> > From: Alexandre Ratchov
> >
> > On Fri, May 01, 2020 at 01:11:16PM +0200, Damien Couderc wrote:
> > >
> > > Speaking of the hdmi-onl
On Fri, May 01, 2020 at 01:34:54PM +0200, Damien Couderc wrote:
> Hi,
>
> I noticed that audioctl and mixerctl both use /dev/audioctl0 as a default
> since the reimplementation of the new api.
>
> Shouldn't it use the /dev/audioctl link instead to permit choosing which
> device we want as the
On Fri, May 01, 2020 at 01:11:16PM +0200, Damien Couderc wrote:
>
> Speaking of the hdmi-only devices that were disabled in 2009: does the
> project still stand on this position in 2020? I made a quick search and it
> seems that more than half of the screens are audio capable now. I understand
>
On Wed, Apr 29, 2020 at 01:26:51PM +0200, Otto Moerbeek wrote:
> On Wed, Apr 29, 2020 at 01:02:29PM +0200, Otto Moerbeek wrote:
>
> > On Wed, Apr 29, 2020 at 10:28:37AM +, Oliver Marugg wrote:
> >
> > > Possible typo group _sniop shoud be _sndiod:
> >
> > Nope. _sniop is the correct name.
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
The /dev/audioctlN files, when used in O_WRONLY mode offer the same
functionality as /dev/mixerN.
Ports don't use /dev/mixerN anymore, by switching mixerctl(4) to
/dev/audioctlN too, we remove the last /dev/mixerN user.
OK?
Index: mixerctl.1
On Thu, Apr 02, 2020 at 05:21:45PM +0100, Stuart Henderson wrote:
> On 2020/04/02 17:13, Landry Breuil wrote:
> > On Wed, Apr 01, 2020 at 07:27:12PM +0200, Alexandre Ratchov wrote:
> > > ping!
> > >
> > > FWIW, the diff below affects the following
On Thu, Apr 02, 2020 at 05:13:49PM +0200, Landry Breuil wrote:
> On Wed, Apr 01, 2020 at 07:27:12PM +0200, Alexandre Ratchov wrote:
> > ping!
> >
> > FWIW, the diff below affects the following ports:
> > - emulators/gambatte
> > - gstreamer-0.10 mixe
one of above ports and want to test, just apply this diff
to src/lib/libossaudio in base, rebuild it and reinstall it. The ABI
is not changing, so no need to rebuild or update ports.
- Forwarded message from Alexandre Ratchov -
Date: Tue, 17 Mar 2020 12:27:40 +0100
From: Alexandre Ratchov
On Mon, Mar 23, 2020 at 10:51:06PM +0100, Tobias Heider wrote:
> In alloc_all_jacks() the variables 'sc_in_jacks' and 'sc_out_checks'
> are set to NULL if 'sc_in_num_jacks' and 'sc_out_num_jacks' are 0.
> Further down both are dereferenced unconditionally. I added explicit NULL
> checks where I
On Mon, Mar 16, 2020 at 10:16:34AM +0100, Patrick Wildt wrote:
> Otherwise, if we want to do that in acpivout_get_brightness(),
> I guess we can update acpivout_select_brightness() and its caller
> to remove the check for -1, since there will be no -1 anymore?
>
Sure, I missed those. Here's a
On Mon, Mar 16, 2020 at 10:16:34AM +0100, Patrick Wildt wrote:
> On Sat, Mar 14, 2020 at 04:28:26AM +0100, Alexandre Ratchov wrote:
> > On ASUS 1001PXD, _BQC returns an out of range value which makes
> > acpivout_get_brightness() return -1, in turn breaking the
> > displ
On ASUS 1001PXD, _BQC returns an out of range value which makes
acpivout_get_brightness() return -1, in turn breaking the
display.brightness control (wsconsctl displays a mangled value).
This diff ignores the out of range value and makes the brighness
control just work again.
OK?
Index:
On Tue, Feb 25, 2020 at 01:02:06PM +0100, Alexandre Ratchov wrote:
> On Thu, Feb 13, 2020 at 04:52:12AM +, Raf Czlonka wrote:
> >
> > Hi Alexandre,
> >
> > I have to say that I also find the two ranges mildly confusing,
> > i.e. 0-255 in one place, and 0-
===
RCS file: lib/libsndio/sioctl.c
diff -N lib/libsndio/sioctl.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/libsndio/sioctl.c 24 Feb 2020 06:03:30 -
@@ -0,0 +1,177 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2014-
On Thu, Feb 13, 2020 at 05:15:34AM +, Raf Czlonka wrote:
> 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
> >
> >
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
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
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
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
>
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:
>
On Sun, Feb 09, 2020 at 07:20:15PM +0100, Landry Breuil wrote:
> On Sun, Feb 09, 2020 at 01:14:47PM +0100, Alexandre Ratchov wrote:
> > Here's a new sndioctl utility similar to mixerctl(1) but using the new
> > sndio API. Example:
>
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
Certain ports use -lossaudio to get access to the volume knobs. This
diff updates -lossaudio to use the new sndio API. By default, it
exposes both sndiod output level and hardware master input/output
knobs (if present). The source selectors are not exposed any longer as
sndiod doesn't expose them.
diff -N usr.bin/sndioctl/sndioctl.1
--- /dev/null 1 Jan 1970 00:00:00 -
+++ usr.bin/sndioctl/sndioctl.1 9 Feb 2020 11:05:02 -
@@ -0,0 +1,148 @@
+.\" $OpenBSD$
+.\"
+.\" Copyright (c) 2007 Alexandre Ratchov
+.\"
+.\" Permission to use, copy, modify, and distrib
or=1
Index: lib/libsndio/sioctl.c
=======
RCS file: lib/libsndio/sioctl.c
diff -N lib/libsndio/sioctl.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/libsndio/sioctl.c 8 Feb 2020 14:49:37 -
@@ -0,0 +1,177 @@
+/* $OpenBSD$
On Sat, Feb 08, 2020 at 11:04:10PM +0100, Ingo Schwarze wrote:
> Hi Theo,
>
> you have a point, that was a lot of cheap talk and no patch.
>
> I don't aim at changing yacc(1) grammars. I think most parts of
> OpenBSD configuration systems already have sane defaults and most
> configuration
The plan is to make sndiod need to control volume knobs. This diff
adds the AUDIO_MIXER_xxx ioctls to the "audio" pledge. Another option
would be to introduce a new "audioctl" promise, but IMHO we don't seed
such fine-grained promises.
OK?
Index: kern_pledge.c
The diff bellow allows programs to get notifications about changes of
audio controls. Programs open the /dev/audioctlN device node and use
the read(4) syscall to get the index of each changed control.
There may be only one reader at a time. Supporting multiple readers
would be much more
On Thu, Jan 16, 2020 at 10:32:21PM -0600, Scott Cheloha wrote:
> Ticks to milliseconds.
>
> Pretty sure all we need to do to convert the drain timeouts is
> substitute 1000 for hz in each expression.
>
> While we're here, I noticed that at halt time for input/output we
> msleep to allow a drain
On Sat, Jan 11, 2020 at 02:33:07AM -0600, Scott Cheloha wrote:
> Both of these cards have a 100ms sleep when closed.
>
> ok?
>
sure, ok ratchov
> Index: pci/eap.c
> ===
> RCS file: /cvs/src/sys/dev/pci/eap.c,v
> retrieving
On Fri, Jan 10, 2020 at 08:23:14PM -0600, Scott Cheloha wrote:
> Whoops, missed one last time.
>
> ok?
ok
>
> Index: pci/bktr/bktr_tuner.c
> ===
> RCS file: /cvs/src/sys/dev/pci/bktr/bktr_tuner.c,v
> retrieving revision 1.8
> diff
On Wed, Dec 18, 2019 at 10:41:56AM -0600, Scott Cheloha wrote:
> On Wed, Dec 18, 2019 at 09:54:43AM +0100, Alexandre Ratchov wrote:
> > On Tue, Dec 17, 2019 at 07:09:02PM -0600, Scott Cheloha wrote:
> > > The only conversion I'm having trouble with is the tsleep().
> >
1 - 100 of 294 matches
Mail list logo
