Re: audio usemixer breaks vs(4) Re: CVS commit: src/sys/dev

2017-11-06 Thread Tetsuya Isaki
At Tue, 07 Nov 2017 12:45:47 +0900,
Tetsuya Isaki wrote:
> 
> nat@, (cc: christos@)
> 
> With this change, vs(4) no longer works even if usemixer=0.
  ^^
Oops, it should be 'usemixer=1'.

If usemixer=1, it plays noise.
If usemixer=0, failed to open sound device.

Anyway, please revert it.
---
Tetsuya Isaki 

> Please revert it, and don't break without public discussion.
> 
> This is the 3rd time you broke vs(4).
> You broke and I repaired.
> You broke and I repaired.
> I spent a lot of time this half year.
> 
> If you can not consider about supported devices (at least
> devices which has active users), please don't touch audio.
> 
> Thanks,
> ---
> Tetsuya Isaki 
> 
> At Tue, 7 Nov 2017 01:13:19 +,
> > Module Name:src
> > Committed By:   nat
> > Date:   Tue Nov  7 01:13:19 UTC 2017
> > 
> > Modified Files:
> > src/sys/dev: audio.c audiovar.h
> > 
> > Log Message:
> > A sysctl is now available to disable the in kernel mixer.
> > sysctl -w hw.hdafg0.usemixer=0
> > 
> > There currently is a problem draining the last block with the mixer
> > disabled.  I will fix this in a follow up commit.
> > 
> > AFAIK there will be a problem wiht vs(4) on x68k with the mixer disabled
> > as the filters for mulaw, alaw and unsigned linear have been removed post
> > audio mixing changes.
> > 
> > Documentation for this sysctl variable will be made to audio.4 in a follow
> > up commit.
> > 
> > Ok christos@.
> > 
> > 
> > To generate a diff of this commit:
> > cvs rdiff -u -r1.429 -r1.430 src/sys/dev/audio.c
> > cvs rdiff -u -r1.66 -r1.67 src/sys/dev/audiovar.h
> 


audio usemixer breaks vs(4) Re: CVS commit: src/sys/dev

2017-11-06 Thread Tetsuya Isaki
nat@, (cc: christos@)

With this change, vs(4) no longer works even if usemixer=0.
Please revert it, and don't break without public discussion.

This is the 3rd time you broke vs(4).
You broke and I repaired.
You broke and I repaired.
I spent a lot of time this half year.

If you can not consider about supported devices (at least
devices which has active users), please don't touch audio.

Thanks,
---
Tetsuya Isaki 

At Tue, 7 Nov 2017 01:13:19 +,
> Module Name:  src
> Committed By: nat
> Date: Tue Nov  7 01:13:19 UTC 2017
> 
> Modified Files:
>   src/sys/dev: audio.c audiovar.h
> 
> Log Message:
> A sysctl is now available to disable the in kernel mixer.
>   sysctl -w hw.hdafg0.usemixer=0
> 
> There currently is a problem draining the last block with the mixer
> disabled.  I will fix this in a follow up commit.
> 
> AFAIK there will be a problem wiht vs(4) on x68k with the mixer disabled
> as the filters for mulaw, alaw and unsigned linear have been removed post
> audio mixing changes.
> 
> Documentation for this sysctl variable will be made to audio.4 in a follow
> up commit.
> 
> Ok christos@.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.429 -r1.430 src/sys/dev/audio.c
> cvs rdiff -u -r1.66 -r1.67 src/sys/dev/audiovar.h


Re: CVS commit: src/usr.bin/kdump

2017-11-06 Thread Christos Zoulas
In article <20171106163453.gb28...@britannica.bec.de>,
Joerg Sonnenberger   wrote:
>On Sun, Nov 05, 2017 at 12:44:29PM -0500, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sun Nov  5 17:44:29 UTC 2017
>> 
>> Modified Files:
>>  src/usr.bin/kdump: mkioctls
>> 
>> Log Message:
>> deal with the stdbool.h mess defining bool in  and 
>> and then xf86Opt.h wanting to define a struct field called bool.
>
>I'd prefer to fix the latter.

You mean change xf86Opt.h and rename 'bool' to 'xbool' or something else?
That would probably require touching a lot of other X client code, and
things will stop compiling out of the box for NetBSD. I think upstream
should fix it first :-)

christos



Re: CVS commit: src/usr.bin/kdump

2017-11-06 Thread Joerg Sonnenberger
On Sun, Nov 05, 2017 at 12:44:29PM -0500, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Sun Nov  5 17:44:29 UTC 2017
> 
> Modified Files:
>   src/usr.bin/kdump: mkioctls
> 
> Log Message:
> deal with the stdbool.h mess defining bool in  and 
> and then xf86Opt.h wanting to define a struct field called bool.

I'd prefer to fix the latter.

Joerg