[comp.unix.questions] keyscan wanted

medfys@wn2.sci.kun.nl (Victor Langeveld/Tjeerd Dijkstra) (06/01/89)

I am searching for a (small?) routine that informs me about a
possible pressed key. This routine should *not* wait for input,
but return immediately, wether succesfull or not.
Suggestions?

Victor Langeveld,                            |    lack      |
Med.Phys. Dept.                              |     of       |
University of Nijmegen.                      | inspiration  |

bill@twwells.uucp (T. William Wells) (06/02/89)

In article <475@wn2.sci.kun.nl> medfys@wn2.sci.kun.nl (Victor Langeveld/Tjeerd Dijkstra) writes:
: I am searching for a (small?) routine that informs me about a
: possible pressed key. This routine should *not* wait for input,
: but return immediately, wether succesfull or not.
: Suggestions?

Yes. Tell us what hardware and OS you are talking about.

For example, this should be doable on my system, a '386 running
Microport's Unix, by telling the driver to return scan codes and
doing nonblocking reads. It's all in the relevant sections of the
manual, under keyboard(7), open(2), and fcntl(2), and maybe a few
other places I can't think of off hand.

But on your system, who knows? We certainly don't, since we don't
know the system.

---
Bill                            { uunet | novavax } !twwells!bill

medfys@wn2.sci.kun.nl (Victor Langeveld/Tjeerd Dijkstra) (06/05/89)

In article <1006@twwells.uucp>, bill@twwells.uucp (T. William Wells)
writes:
> In article <475@wn2.sci.kun.nl> medfys@wn2.sci.kun.nl (Victor Langeveld/Tjeerd Dijkstra) writes:
> : I am searching for a (small?) routine that informs me about a
> : possible pressed key. This routine should *not* wait for input,
> : but return immediately, wether succesfull or not.
> : Suggestions?
> 
> Yes. Tell us what hardware and OS you are talking about.
> 
> For example, this should be doable on my system, a '386 running
> Microport's Unix, by telling the driver to return scan codes and
> doing nonblocking reads. It's all in the relevant sections of the
> manual, under keyboard(7), open(2), and fcntl(2), and maybe a few
> other places I can't think of off hand.
> 
> But on your system, who knows? We certainly don't, since we don't
> know the system.
> 
> ---
> Bill                            { uunet | novavax } !twwells!bill

There is no need to know what hardware this should be working on.
Mr Charles Thayer (Thanks again, Charles!) gave me a perfect solution:

int key_pressed()
{
	int mask=1;
	struct timeval wait;

	wait.tv_sec=0;
	wait.tv_usec=0;
	return (select(1,&mask,0,0,&wait));
}

This can be used as e.g. if(!key_pressed) { do stuff} else { key
handling}. Works fine! (As is should (?) on any unix machine)


Victor Langeveld,                          |              |
Med.Phys. Dept.                            |  *empty*     |
University of Nijmegen.                    |              |
The Netherlands                            |              |

kucharsk@uts.amdahl.com (William Kucharski) (06/06/89)

In article <607@wn2.sci.kun.nl> medfys@wn2.sci.kun.nl (Victor Langeveld/Tjeerd Dijkstra) writes:
 >There is no need to know what hardware this should be working on.
 >Mr Charles Thayer (Thanks again, Charles!) gave me a perfect solution:
 >
 >int key_pressed()
 >{
 >	int mask=1;
 >	struct timeval wait;
 >
 >	wait.tv_sec=0;
 >	wait.tv_usec=0;
 >	return (select(1,&mask,0,0,&wait));
 >}
 >
 >This can be used as e.g. if(!key_pressed) { do stuff} else { key
 >handling}. Works fine! (As is should (?) on any unix machine)

As long as the machine in question has select(2), which automatically assumes
a UNIX with some BSD extensions - SYSV hacks will have to use poll(2) instead.
-- 
					William Kucharski

ARPA: kucharsk@uts.amdahl.com
UUCP: ...!{ames,decwrl,sun,uunet}!amdahl!kucharsk

Disclaimer:  The opinions expressed above are my own, and may not agree with
	     those of any other sentient being, not to mention those of my 
	     employer.  So there.

bill@twwells.uucp (T. William Wells) (06/06/89)

In article <607@wn2.sci.kun.nl> medfys@wn2.sci.kun.nl (Victor Langeveld/Tjeerd Dijkstra) writes:
: In article <1006@twwells.uucp>, bill@twwells.uucp (T. William Wells)
: writes:
: > In article <475@wn2.sci.kun.nl> medfys@wn2.sci.kun.nl (Victor Langeveld/Tjeerd Dijkstra) writes:
: > : I am searching for a (small?) routine that informs me about a
: > : possible pressed key. This routine should *not* wait for input,
: > : but return immediately, wether succesfull or not.
: > : Suggestions?
: >
: > Yes. Tell us what hardware and OS you are talking about.
: >
: > For example, this should be doable on my system, a '386 running
: > Microport's Unix, by telling the driver to return scan codes and
: > doing nonblocking reads. It's all in the relevant sections of the
: > manual, under keyboard(7), open(2), and fcntl(2), and maybe a few
: > other places I can't think of off hand.
: >
: > But on your system, who knows? We certainly don't, since we don't
: > know the system.
: >
: > ---
: > Bill                            { uunet | novavax } !twwells!bill
:
: There is no need to know what hardware this should be working on.
: Mr Charles Thayer (Thanks again, Charles!) gave me a perfect solution:
:
: int key_pressed()
: {
:       int mask=1;
:       struct timeval wait;
:
:       wait.tv_sec=0;
:       wait.tv_usec=0;
:       return (select(1,&mask,0,0,&wait));
: }
:
: This can be used as e.g. if(!key_pressed) { do stuff} else { key
: handling}. Works fine! (As is should (?) on any unix machine)

Leaving aside the possible interpretational problem (the solution I
suggested *really* permits checking for key pressed, and key
released, too), you're talking BSD. Your code won't work on my sysV
3.0 and on many others.

---
Bill                            { uunet | novavax } !twwells!bill

guy@auspex.auspex.com (Guy Harris) (06/07/89)

>Works fine! (As is should (?) on any unix machine)

On any UNIX machine that has "select"; not all of them do.  (Yes, Mr.
Wells was right; you *do* need to know what flavor of the OS - not
necessarily what hardware - you're running.  You just happened to luck
out, in that Mr. Thayer and you were presumably running versions of UNIX
similar enough that his solution worked on your machine.)

guy@auspex.auspex.com (Guy Harris) (06/07/89)

>As long as the machine in question has select(2), which automatically assumes
>a UNIX with some BSD extensions - SYSV hacks will have to use poll(2) instead.

Unless, of course:

	1) their System V doesn't have "poll" (releases before S5R3
	   didn't have it, unless there was some version that snuck it
	   in as an undocumented feature, say);

	2) their System V doesn't have the device that you're trying to
	   "poll" as a streams device, and doesn't support "poll" on
	   non-streams devices (I've not seen any release from AT&T that
	   1) has *all* its ttys as streams devices or 2) supports
	   "poll" on non-streams devices, although S5R4 may do both).

eric@tccc0.UUCP (Eric Smith) (06/07/89)

>int key_pressed()
>{
>	int mask=1;
>	struct timeval wait;
>
>	wait.tv_sec=0;
>	wait.tv_usec=0;
>	return (select(1,&mask,0,0,&wait));
>}

For that to work reliably, you must make sure the stdin buffer is empty
before calling key_pressed, because the select call doesn't check for
characters already in the stdin buffer.  In some applications using raw
mode this could be very hard to debug unless you had some hints (such as
this one) because an undetected character in the stdin buffer might only
happen very rarely and randomly.  To check for characters in the stdin
buffer, you can look at stdin->_cnt, which tells how many characters,
so it should be 0 to proceed with the key_pressed call.

allbery@ncoast.ORG (Brandon S. Allbery) (06/10/89)

As quoted from <607@wn2.sci.kun.nl> by medfys@wn2.sci.kun.nl (Victor Langeveld/Tjeerd Dijkstra):
+---------------
| In article <1006@twwells.uucp>, bill@twwells.uucp (T. William Wells)
| writes:
| > In article <475@wn2.sci.kun.nl> medfys@wn2.sci.kun.nl (Victor Langeveld/Tjeerd Dijkstra) writes:
| > : I am searching for a (small?) routine that informs me about a
| > : possible pressed key. This routine should *not* wait for input,
| > : but return immediately, wether succesfull or not.
| > 
| > Yes. Tell us what hardware and OS you are talking about.
| > 
| > For example, this should be doable on my system, a '386 running
| > Microport's Unix, by telling the driver to return scan codes and (...)
| > But on your system, who knows? We certainly don't, since we don't
| > know the system.
| 
| There is no need to know what hardware this should be working on.
| Mr Charles Thayer (Thanks again, Charles!) gave me a perfect solution:
| 
| 	return (select(1,&mask,0,0,&wait));
+---------------

BZZZZZZ!  You lose.  Select() is a BSD system call; Microport is System V,
and for all you know Victor is running V7.  (Anti-System-V flames to
/dev/null.)

++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery@hal.cwru.edu
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser