Date: Thu, 08 May 2008 08:06:52 +0200 From: rmgls@free.fr To: Jeremy Chadwick <koitsu@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: general i/o question Message-ID: <20080508060655.9C4BC3227F6@smtp7-g19.free.fr>
next in thread | raw e-mail | index | archive | help
On Wed, 7 May 2008 14:40:57 Jeremy Chadwick <koitsu@freebsd.org> wrote:
> On Wed, May 07, 2008 at 05:39:00PM +0200, rmgls@free.fr wrote:
> > i need to test (NOWAIT), the presence of keypressed/depressed on a terminal
> > and then read the scan code, like for a piano pc keyboard.
> >
> > my questions are as follows:
> >
> > 1. is it a general C function which may scan a terminal without waiting?
> >
> > 2. how to get the scancodes?
>
> It depends on if you're wanting the actual hard-wired keyboard (on the
> console), or if you're taking input from a tty/pty. You won't get a
> true scancode from a tty/pty, but you will get a character (0x00 to
> 0xFF).
Hi Jeremy,
after all, i don't need the scancode, i can work with characters,
this avoid the nls translation, which is already done!
> Regarding I/O without waiting: there is not a general libc function for
> this. Garrett mentioned getc(), which blocks (waits).
Attilio Rao pointed me tje termios struct, and looking to the doc
i found the O_NONBLOCK open(2) flag... which means: NOWAIT
i was not aware of it! and in this case getc() works fine as expected.
> You might want to consider seeing if the kqueue/kevent stuff on the BSDs
> will work with pty/tty input. You can use that to set up an event in
> the kernel which tells the kernel "run function XYZ when I/O is seen on
> this fh/fd". It's like select() in that respect, but is faster.
Thanks for this point i will investigate now.
BUT
don't you think it would be a desirable behaviour addition to the read()
libc function???
> > of course i can poll tje (0x64) keyboard port on a i386 architecture,
> > but this is not a general method, and it is suited for a distant terminal
> > for instance.
>
> I agree. This method is also very old, and I'd be surprised if it would
> work with USB keyboards. I would assume it would also interfere with
> any existing keyboard I/O handler the OS has, but I'm not sure.
Yes, i agree it would be a bad idea, kqueue/kevent is better.
i will see that.
Best regards
raoul
rmgls@free.fr
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080508060655.9C4BC3227F6>