Re: [PATCH] Cygwin: dsp: Implement SNDCTL_DSP_SETFRAGMENT ioctl().

2023-01-31 Thread Corinna Vinschen
On Jan 31 20:20, Takashi Yano wrote:
> On Tue, 31 Jan 2023 10:28:40 +0100
> Corinna Vinschen wrote:
> > On Jan 30 22:09, Takashi Yano wrote:
> > > Previously, SNDCTL_DSP_SETFRAGMENT was just a fake. In this patch,
> > > it has been implemented to allow latency control in some apps.
> > > 
> > > Reviewed-by: Corinna Vinschen 
> > > Signed-off-by: Takashi Yano 
> > > ---
> > >  winsup/cygwin/fhandler/dsp.cc   | 78 -
> > >  winsup/cygwin/local_includes/fhandler.h |  3 +
> > >  2 files changed, 42 insertions(+), 39 deletions(-)
> > 
> > LGTM.  Given how much I *don't* use the audio stuff in Cygwin,
> > would you just like to take over maintainership for this code?
> 
> BTW, should this pach be applied only for master branch?
> What do you think?

It's new functionality, so, yeah, main branch only.


Thanks,
Corinna


Re: [PATCH] Cygwin: dsp: Implement SNDCTL_DSP_SETFRAGMENT ioctl().

2023-01-31 Thread Corinna Vinschen
On Jan 31 20:18, Takashi Yano wrote:
> On Tue, 31 Jan 2023 10:28:40 +0100
> Corinna Vinschen wrote:
> > LGTM.  Given how much I *don't* use the audio stuff in Cygwin,
> > would you just like to take over maintainership for this code?
> 
> Thanks. I could take care of it if you don't mind?

Not at all!


Thanks,
Corinna


Re: [PATCH] Cygwin: dsp: Implement SNDCTL_DSP_SETFRAGMENT ioctl().

2023-01-31 Thread Takashi Yano
On Tue, 31 Jan 2023 10:28:40 +0100
Corinna Vinschen wrote:
> On Jan 30 22:09, Takashi Yano wrote:
> > Previously, SNDCTL_DSP_SETFRAGMENT was just a fake. In this patch,
> > it has been implemented to allow latency control in some apps.
> > 
> > Reviewed-by: Corinna Vinschen 
> > Signed-off-by: Takashi Yano 
> > ---
> >  winsup/cygwin/fhandler/dsp.cc   | 78 -
> >  winsup/cygwin/local_includes/fhandler.h |  3 +
> >  2 files changed, 42 insertions(+), 39 deletions(-)
> 
> LGTM.  Given how much I *don't* use the audio stuff in Cygwin,
> would you just like to take over maintainership for this code?

BTW, should this pach be applied only for master branch?
What do you think?

-- 
Takashi Yano 


Re: [PATCH] Cygwin: dsp: Implement SNDCTL_DSP_SETFRAGMENT ioctl().

2023-01-31 Thread Takashi Yano
On Tue, 31 Jan 2023 10:28:40 +0100
Corinna Vinschen wrote:
> LGTM.  Given how much I *don't* use the audio stuff in Cygwin,
> would you just like to take over maintainership for this code?

Thanks. I could take care of it if you don't mind?

-- 
Takashi Yano 


Re: [PATCH] Cygwin: dsp: Implement SNDCTL_DSP_SETFRAGMENT ioctl().

2023-01-31 Thread Corinna Vinschen
On Jan 30 22:09, Takashi Yano wrote:
> Previously, SNDCTL_DSP_SETFRAGMENT was just a fake. In this patch,
> it has been implemented to allow latency control in some apps.
> 
> Reviewed-by: Corinna Vinschen 
> Signed-off-by: Takashi Yano 
> ---
>  winsup/cygwin/fhandler/dsp.cc   | 78 -
>  winsup/cygwin/local_includes/fhandler.h |  3 +
>  2 files changed, 42 insertions(+), 39 deletions(-)

LGTM.  Given how much I *don't* use the audio stuff in Cygwin,
would you just like to take over maintainership for this code?


Thanks,
Corinna


Re: winsup/cygwin/sys/termios.h bit rates extension

2023-01-31 Thread Corinna Vinschen
On Jan 29 22:57, Brian Inglis wrote:
> FreeBSD, NetBSD, and Linux all bumped their serial bit rates to support
> 500k(+500k)4000k, extending the rates to 3500k and 4000k, dropping 128k and
> 256k, renumbering the extended baud rate indices under Linux, effectively
> changing the ABI for any previously compiled serial application.
> 
> See:
> https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/include/sys/termios.h;hb=HEAD#l189
> 
> Patch would be like:
> diff a/winsup/cygwin/include/sys/termios.h 
> b/winsup/cygwin/include/sys/termios.h
> --- a/winsup/cygwin/include/sys/termios.h
> +++ b/winsup/cygwin/include/sys/termios.h
> @@ -190,19 +190,19
>  #define CBAUDEX  0x0100f
>  #define B57600 0x01001
>  #define B115200  0x01002
> -#define B128000  0x01003
> -#define B230400  0x01004
> +#define B230400  0x01003
> -#define B256000  0x01005
> -#define B460800  0x01006
> +#define B460800  0x01004
> -#define B50  0x01007
> +#define B50  0x01005
> -#define B576000  0x01008
> +#define B576000  0x01006
> -#define B921600  0x01009
> +#define B921600  0x01007
> -#define B100 0x0100a
> +#define B100 0x01008
> -#define B1152000 0x0100b
> +#define B1152000 0x01009
> -#define B150 0x0100c
> +#define B150 0x0100a
> -#define B200 0x0100d
> +#define B200 0x0100b
> -#define B250 0x0100e
> +#define B250 0x0100c
> -#define B300 0x0100f
> +#define B300 0x0100d
> +#define B350 0x0100e
> +#define B400 0x0100f
> 
>  #define CRTSXOFF 0x04000
>  #define CRTSCTS  0x08000
> 
> Is this acceptable, not really any issue for Cygwin, or an issue, and some
> compatibility code would be required to do an internal upgrade, and return
> an error for unsupported speeds, or should we add another bit to extend
> CBAUD/CBAUDEX to 0x0101f, and use higher indices 0x01010/0x01011?

We'd need a compat layer, depending on the version of Cygwin
the executable has been created under (see include/sys/cygwin.h).

Just extending CBAUD/CBAUDEX. isn't an option because all bits
in cflags are taken, afaics.

However, afaics our CBAUDEX is defined incorrectly.  The BSDs define it
as LINUX_CBAUDEX, because it's apparently not a BSD idea.  And per
Linux, it should only contain the mask bit which defines extended
speeds, so

  #define CBAUD0x0100f
  #define CBAUDEX  0x01000

would be the right (i. e., Linux-compatible).


Corinna