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

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

Am Mon, 16 May 2022 09:05:51 +0200
schrieb Thomas Orgis <tho...@or...>: 

> Hm, the normal ASCII characters arrive as such and higher codes are
> used for things like cursor keys?

I'm still not fully awake, with KBDKEYINFO key:

- key.chScan is the scancode
- key.chChar is the character

So that's all well. Is KbdCharIn an option nowadays? What's the full
documentation? Turning echo off and having a full termios would be
nice, too, though (incidentally: Do you have the TERM environment
variable set to something meaningful?).

http://www.edm2.com/index.php/KbdCharIn says:

Parameters

CharData (PKBDKEYINFO) - output
    Pointer to character data. 
    A pointer to a KBDKEYINFO structure in which the character data is returned. 
Wait (ULONG) - input
    Wait Flag.

        0 IO_WAIT: Wait for a keystroke if one is not available. The
        keystroke returned is removed from the queue. 

        1 IO_NOWAIT: Return immediately, with or without a keystroke.
        If a keystroke is returned, remove it from the queue. 

        2 IO_PEEK: Return immediately, with or without a keystroke. Do not remove the keystroke from the queue. 

        3 IO_PEEKWAIT: Wait for a keystroke if one is not available.
        Return the keystroke but do not remove it from the queue. 

hkbd (HKBD) - input
    Reserved. Must be 0. 


Remarks

Note
    KbdCharIn returns a complete keystroke. This behaviour is unlike
    the OS/2 1.3 version, which returns only a single byte. This
    affects only double-byte character set (DBCS) characters. 

If bit 0 of fbStatus is set, the character returned is either 0 or
0xe0. The Unicode character contains the virtual key.

For valid characters, the character in the current code page is
returned, and the Unicode character contains the Unicode encoding of
the character.

On an enhanced keyboard, the secondary enter key returns the normal
character 0DH and a scan code of E0H.

Extended ASCII codes are identified by bit 1 of the status byte being
set to on, and the ASCII character code being either 00H or E0H. Both
conditions must be satisfied for the character to be an extended
keystroke. For extended ASCII codes, the scan-code byte returned is the
second code (extended code). Usually, the extended ASCII code is the
scan code of the primary key that was pressed.

A thread in the foreground session that repeatedly polls the keyboard
with KbdCharIn (with no wait), can prevent all regular priority-class
threads from executing. If polling must be used, and a minimal amount
of other processing is being performed, the thread should periodically
yield to the CPU by issuing a DosSleep call for an interval of at least
5 milliseconds. 

[END OF QUOTE]

I am not sure where Unicode comes in here. But maybe we should be able
to ignore that when only caring about ASCII.


This looks like the little test program could skip all terminal
setup/term_fd stuff and do this:

int get_key(int do_delay, char *val)
{
	KBDKEYINFO key;
	key.chChar = 0;
	key.chScan = 0;
	// optionally: sleep for a tiny bit
	if(!KbdCharIn(&key,IO_NOWAIT,0) && key.chChar)
	{
		*val = key.chChar;
		return 1;
	}
	return 0;
}


Could that work?


Alrighty then,

Thomas