Actually, this article is very dated, and relied on replacing the
IOHid driver with a subclass of the driver using vtable overwrites by
a KEXT. Since the vtable format and offsets have changed several
times since the article was written (once in the g++ 2.95 -> 3.x g++
transition, and then with the 1->0 option base conversion in the 3.x -
> 4.x transition), this method is really discouraged.
The diagram is also simplistic for a "UNIX command-line type program":
is (more or less) accurate, adjusting names for dating, and ignoring
input method drivers; but the complicated part is the application
being Terminal:
UserSpace___________Back to the
kernel_____________________________Back to user space
[Terminal] -|->[pty master] -> [line discipline] -> [pty slave] -|-
>[command line program]
The UNIX idea of cooked/raw is implemented in the line discipline
module in the kernel. If you turn it off (go to "raw mode"), it turns
off the TERMIOS processing - character echo, output of CR on NL, input
interpretation of a CR (return key) as a NL, and so on. What's called
"cannonical processing". But at this point, it's already dealing with
a (UTF-8 / ISO 8859-1 / ISO 646/ etc.) byte stream, without key up/
down events.
Cooking of key up/down events happens in Terminal itself; the events
are "raw" in the sense of key up/down, not in the POSIX sense of not
having TERMIOS based canonical processing of a "cooked" byte stream.
By the time they get to the master side of the pty, your ability to
see them as raw up/down events is gone. Even if you could tell
Terminal to send only raw events (you can't), there's no way to bridge
such events over the pty to your application, or such a request from
your application to Terminal.
So effectively, you must run as an application, either as a client of
Window Server (like Terminal does), or as a client of the IOHIDSystem
(as Window Server does). And either way, the Input Method overrides
are going to get the events before you do, so it won't be truly raw,
even then.
This is why Eric was pointed at becoming an event client of Window
Server, given the question he asked.
-- Terry
On Jul 30, 2008, at 9:44 AM, nawcom wrote:
There's really no way to simply write up an all-unix utility that
can communicate with the keyboard, since it all depends on how the
keyboard is connected, how keyboard events are recognized, etc, but
you can design one based on each OS. since you are on an apple
mailing list, heres what works with darwin:
Using any other unix OS would require either modifying the module or
part of the kernel that controls keyboard events so you can get the
raw data coming from it, or writing up an assembly app for
temporarily switching the the keyboard into a "monitor" mode so you
can take in what is being pressed.
Most OOPs that I know can recognize keyboard events somehow, so it
really depends on what the OS is using. So is it possible? yes, via
the keyboards driver or changing how the OS communicates with the
keyboard - if you write it in assembly so it communicates correctly
in each OS. Is it possible in general terms to write an app that
reads the keyboard and also doesn't depend on an external framework
(like xev in X11, keyboard classes in carbon, etc) for catching it?
probably not. Hope this helps.
nawcom
Eric Gorr wrote:
Is there a unix tool that will return the current state of the
keyboard?
I would like to be able to determine if that option key is
currently being pressed by the user.
thank you.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
