Cool. I've been recommending "-vga vmware" with QEMU/NVMM because
it works quite well (even without acceleration on the NetBSD side)
and offers the widest choice in resolutions. Does this affect
QEMU/NVMM when used with that option?
On Wed, Jun 21, 2023 at 01:50:47PM -0400, Theodore Preduta wrote:
> 2. They can be used to test the epoll code with ATF.
In my opinion we should expose such system calls in a way that they
can be used by ATF but won't be detected by configure scripts.
Unfortunately file formats are standardized but the
the way the audio APIs are implemented varies. :/
> It's now no longer broken to handle 24bit WAV files.
This is true, but audioplay is hardly the only
consumer of the API and could easily be made to communicate
with the kernel using 32-bit
I believe this should not be enabled, and that applications
should be trained to write 32-bit linear samples instead.
The reason being that it's very confusing how exactly
24-bit samples should be encoded, and different applications
and implementations have different ideas.
In OSSv4, S24 means
This is neat, thanks for the work. Do we need a kernel
compiled with any specific options to make the DTrace
probes active?
On Tue, Nov 15, 2022 at 07:26:01AM -0500, Christoff Humphries wrote:
> Hello all,
>
> What are some areas within the kernel that need some attention?
>
> I’m looking for a project within the kernel to work on, and I
> wanted to reach out to see what may be neglected or could use a
> programmer
I'd like to know more about these drivers so I can write man pages
for them, so any input is welcome.
sys/dev/usb/udsir.c
Committed in 2013 by kiyohara@, log message was
"Add KingSun/DonShine IRDA dongle."
However, the copyright is 2001 dsainty@, perhaps copypasted
On Wed, Mar 09, 2022 at 08:39:06PM -0500, Mouse wrote:
> Perhaps I just need a better approach
I know you've previously expressed a lack of interest in such
things when we've talked previously, but I've found the built-in
sanitizers in modern GCC useful for approximating the functionality
of
On Sat, Mar 12, 2022 at 08:54:39AM +0100, Martin Husemann wrote:
> After reading your proposal it seems to me you may have misunderstood
> something about the project itself (and that is likely because it's
> description is very vague).
Aye, I've updated the wiki page a little bit to clarify
The unix(4) man page incorrectly states:
"A UNIX-domain socket supports two socket-level options for use with
setsockopt(2) and getsockopt(2): [...]"
In reality, the protocol level when using these socket options
must be 0, which is a magic number not really documented anywhere
except the test
On Thu, Jul 01, 2021 at 08:59:04AM -0400, Mouse wrote:
> > The primary gain control might not be the one currently responsible
> > for output volume depending on the various DACs available.
>
> Possibly - but audioctl's play.gain field _does_ work to control the
> output volume. I had thought
Hi mouse,
There have been several changes to the audio interface over the
years. In particular, I would describe the pause, port, gain, and
balance fields as "legacy compatibility". These provide a simplified
interface to the mixer(4) interface which may not provide a perfect
match (or do what
hi tech-kern,
The uscanner driver only exists for compatibility with userspace Linux
software that uses an interface that was already deprecated by Linux
in 2004. All scanner software these days uses ugen.
I think we should remove this driver in case someone mistakenly
enables it thinking it
On Sat, Jun 19, 2021 at 07:59:06AM +, RVP wrote:
> On Sat, 19 Jun 2021, nia wrote:
>
> > There seems to be a limit somewhere that causes open() to return ENOMEM
> > when 1000+ files are opened with O_EXLOCK, this is independent of any
> > "open file" limits.
per https://github.com/ziglang/zig/issues/9162,
There seems to be a limit somewhere that causes open() to return ENOMEM
when 1000+ files are opened with O_EXLOCK, this is independent of any
"open file" limits.
I eyeballed the vfs syscalls code but couldn't figure out where
ENOMEM is coming from.
If there are no objections, I will commit this patch:
Index: sys/dev/audio/audio.c
===
RCS file: /cvsroot/src/sys/dev/audio/audio.c,v
retrieving revision 1.91
diff -u -r1.91 audio.c
--- sys/dev/audio/audio.c 14 Feb 2021
In audio_hw_probe in sys/dev/audio/audio.c, the default preferred
format will be scored based on the number of hardware channels.
This makes sense for hardware that supports monaural and stereo
formats, so stereo will be preferred.
However, for hardware that supports surround, it can result
in
On Mon, Apr 05, 2021 at 01:22:49PM -0700, Greg A. Woods wrote:
> I don't see how. I don't see any evidence for that happening.
>
> So, show me how entropy is being collected in my system:
>
> 16:18 [1.793] # uptime
> 4:19PM up 22 days, 16:04, 2 users, load averages: 0.00, 0.00, 0.00
> 16:19
On Mon, Apr 05, 2021 at 12:51:44AM +0200, Joerg Sonnenberger wrote:
> On Sun, Apr 04, 2021 at 02:16:41PM -0700, Paul Goyette wrote:
> > Perhaps sysinst(8) should ask
> >
> > Do you need a hyper-secure system?
> >
> > If yes, then leave things as they are today. But if you answer no,
> > we
I have updated the rndctl(8) documentation so it reflects the current
model in the kernel and is no longer misleading.
It could still use some extra work (e.g. -l could print number of
samples collected).
On Sat, Apr 03, 2021 at 10:03:21PM +0200, Steffen Nurpmeso wrote:
> Btw i track
>
>
>
> xHCI resume support
>
> xhci is everywhere, and for many machines, it's the only remaining step
> for a flawless suspend/resume experiences.
> xhci_{suspend,resume} are unimplemented, and devices do not work after
> resume.
>
> (Contact nia in http://gnats.netb
On Thu, Nov 12, 2020 at 11:46:02PM +, David Holland wrote:
> On Thu, Nov 12, 2020 at 12:49:13PM +0000, nia wrote:
> > > Many years ago, I made it so that mixer operations
> > > would fall though and complete successfully (can't find the commit now).
> > >
On Thu, Nov 12, 2020 at 11:02:34AM +, Stephen Borrill wrote:
> On Tue, 10 Nov 2020, nia wrote:
> > On Tue, Nov 10, 2020 at 06:36:06PM +0100, Martin Husemann wrote:
> > > - Improve linux audio support
> >
> > Does anyone know what's needed yet?
>
> What
On Tue, Nov 10, 2020 at 06:36:06PM +0100, Martin Husemann wrote:
> - Improve linux audio support
Does anyone know what's needed yet?
On Sat, Oct 10, 2020 at 01:29:43PM -0400, Greg Troxel wrote:
>
> chris...@astron.com (Christos Zoulas) writes:
>
> > Aside for the TIOCGSID bug which I am about to fix (it is in tty_43.c
> > and is used in libc tcgetsid(), all the compat tty ioctls are defined
> > in
On Sat, Oct 10, 2020 at 01:33:42PM +, nia wrote:
> syzkaller found a bug in tty_43.c which i noticed could lock up my
> system after i wrote a reproducer for it.
>
> i was curious why 43bsd compat is enabled by default on amd64 then
> noticed it gets loaded by tt
syzkaller found a bug in tty_43.c which i noticed could lock up my
system after i wrote a reproducer for it.
i was curious why 43bsd compat is enabled by default on amd64 then
noticed it gets loaded by tty if it detects an unrecognized ioctl
On Thu, Sep 24, 2020 at 06:37:43AM +, nia wrote:
> On Tue, Sep 22, 2020 at 02:32:23PM +0200, Manuel Bouyer wrote:
> > OK, so the printf should never happen when the system has been properly
> > configured. In this case I have no objection.
>
> No, it will happen frequen
On Tue, Sep 22, 2020 at 02:32:23PM +0200, Manuel Bouyer wrote:
> OK, so the printf should never happen when the system has been properly
> configured. In this case I have no objection.
No, it will happen frequently in VMs and on non-recent-x86 hardware.
I'm writing system monitoring code for NetBSD.
Right now, to get the current CPU frequency, I have to iterate through
~six machine dependent sysctl variables and check their presence,
even though they return exactly the same format.
This patch addresses some low hanging fruit by changing the
Hi Jason,
> We still need to protect the unique identity and reputation of
> WireGuard (our "brand"). This ensures that when people see the
> WireGuard name or logo, they know it is something we, the
> WireGuard developers, have worked on."
Personally, I would be in favour of entirely rebranding
It feels like we could avoid the controversy of whether it should be
enabled by default by making it an option in sysinst.
Of course, it would also be nice to have the option of more filesystems
in sysinst (ZFS, LFS in 10 assuming the remaining deadlocks mainly effect
removable media - taylor?),
On Tue, Jun 23, 2020 at 01:26:21PM +0200, Reinoud Zandijk wrote:
> Is there any hope for adding this? Does the default ATI/AMD Radeon driver
> support this and is this thus just a missing detection in drmkms?
No, the radeon driver does not support this. The amdgpu driver does,
but that isn't
On Thu, Jun 18, 2020 at 08:21:36PM -0400, Greg Troxel wrote:
> So it remains to make userland AES use also constant time, as a separate
> step?
For userland AES, we are mostly using OpenSSL.
There was a bug recently in the in-src copy of OpenSSL that prevented it
from detecting the CPU type
I'm really excited about this patch in general, especially getting
an alternative to AES for cgd that has similar security properties
but isn't terrible in software.
Just one comment that nobody has brought up yet..
On Wed, Jun 17, 2020 at 11:36:11PM +, Taylor R Campbell wrote:
> * Other
35 matches
Mail list logo
