Re: [mpg123-devel] Please test new network code in/out of mpg123 (now with HTTPS support)!

[Thomas O. <tho...@or...>]

Am Sun, 15 May 2022 10:55:45 -0700
schrieb Dave Yeo <dav...@gm...>: 

> ctermid() in the headers is commented out with a @todo so unsupported.
> Libc should map /dev/tty to CON: (likewise /dev/nul maps to NUL:)

OK, so we're accessing /dev/tty already, which should work, just not
with tcgetattr()/tcsetattr(). What about select()? Do we need to
attempt non-blocking reads instead? Your quote about read_kbd() also
says:

> Please use the general terminal interface instead.

I don't want to deal with fancy scancodes, I just want (ASCII)
characters;-)

So what did this one do?

> Seems bad versioning and actually version 0.59m+,
> H:\tmp\mpg123_020>mpg123.exe  
> High Performance MPEG 1.0/2.0 Audio Player for Layer 1, 2 and 3.
> Version 0.59m+ (1997/10/07). Written and copyrights by Michael Hipp.
> Uses code from various people. See 'README' for more!
> THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK!
> Modified and ported to OS/2 by Samuel Audet <gu...@ca...> (C) 1998 v0.20
> https://www.os2site.com/sw/mmedia/mp3/player/mpg123_020.zip

Where is the source code for that? Can you ask Samuel Audet about that?
What was changed from our 0.59m? Can you get the original 0.59m to
work? It seems work from Samuel went into mpg123 versions up to 0.59r.

And actually … our 0.59m doesn't feature terminal control yet! That was
just a special hack by Samuel? In 0.59r, it is already what we had up
to now, using STDIN, not /dev/tty:

    fd_set r;
    struct timeval t;
    char val;
    t.tv_sec=0;
    t.tv_usec=(do_delay) ? 1000 : 0;
    FD_ZERO(&r);
    FD_SET(0,&r);
    n = select(1,&r,NULL,NULL,&t);
    if(n > 0 && FD_ISSET(0,&r)) && read(0,&val,1) == 1)
    {
      handle the key in val ...
    }

Is that supposed to work or not? You can do this in a little test
program, even:

-----------8<--------------

#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <sys/select.h>
#include <unistd.h>
#include <termios.h>

int term_fd = -1;

int get_key(int do_delay, char *val)
{
	fd_set r;
	struct timeval t;
	t.tv_sec=0;
	t.tv_usec=(do_delay) ? 1000 : 0;
	FD_ZERO(&r);
	FD_SET(term_fd,&r);
	int n = select(term_fd+1,&r,NULL,NULL,&t);
	if(n > 0 && FD_ISSET(term_fd,&r) && read(term_fd,val,1) == 1)
		return 1;
	return 0;
}


int main(int argc, char **argv)
{
	if(argc >= 2)
		term_fd = open("/dev/tty", O_RDONLY);
	else
		term_fd = STDIN_FILENO;
	if(term_fd < 0)
	{
		perror("failure opening terminal input");
		return 1;
	}
	fprintf(stderr, "terminal fd: %d\n", term_fd);

	struct termios old_tio;
	int termsetup = 0;
	if(!tcgetattr(term_fd, &old_tio))
	{
		fprintf(stderr, "proper terminal setup\n");
		struct termios tio = old_tio;
		tio.c_lflag &= ~(ICANON|ECHO); 
		tio.c_cc[VMIN] = 1;
		tio.c_cc[VTIME] = 0;
		tcsetattr(term_fd,TCSANOW,&tio);
		termsetup = 1;
	}

	char val = 0;
	while(val != 'q')
	{
		if(get_key(1, &val))
			fprintf(stderr, "got key: %c\n", val);
	}

	if(termsetup)
		tcsetattr(term_fd,TCSAFLUSH,&old_tio);
	if(term_fd > 0)
		close(term_fd);
	return 0;
}

------------>8--------------

This is a complete program that works nicely here for accepting keys
both on stdin and on /dev/tty:

$ gcc -pedantic -o keytest  keytest.c
$ ./keytest
terminal fd: 0
proper terminal setup
got key: d
got key: u
got key: d
got key: f
got key: k
got key: 1
got key: q
$ ./keytest /dev/tty
terminal fd: 3
proper terminal setup
got key: f
got key: j
got key: d
got key: i
got key: q

Without the proper terminal setup, I have to press enter to get keys
read. I'd expect at least that to work. Can you circle this little test
program around OS/2 folks and hand us a variant that works over there
to get single keypresses? This is the essence of what mpg123 does and
probably ever did — outside Samuel Audet's special hack of 0.59m+.

I hope that the changes to the above program are minimal to get things
going (again?). Ideally with /dev/tty. If only stdin works, we have to
disable terminal control for streams from stdin again.

> I'd just stick to __OS2__ as it is obvious.

Alrighty then,

Thomas