I'm currently writing up my own ASCII Game Engine in bare metal on the Raspberry Pi 3.
I'd like to create a keyboard interface that will work like my planned NES controller over GPIO. This way I can swap what input I'm using or have multiplayer support.
My question is, is it possible (maybe using VT100 or the like) to query from putty a string of the keys being pressed at any given time? My plan is to pull the state of any button being pressed (ie no interrupts).
How can I ask for or constantly receive the keys being pressed? I'm assuming putty wont send me the keys pressed in this scenario: A + B + Left Arrow.
Thanks :)
Related
For an automated test application I have to simulate large amount of unicode keyboard input into an old X11 application (of which I don't have any source access).
My program takes the input from an UCS-2 LE encoded input stream via stdin and the basic operation is as follows:
Save current keyboard layout and lock modifiers (XDisplayKeycodes, XGetKeyboardMapping, XkbGetState)
Unlock active modifiers (XkbLockModifiers)
Disable all X11 slave keyboard devices via Xinput2 extension
Read input into a key press queue until n unique symbols are encountered, where n is the number of possible keycodes as returned by XDisplayKeycodes.
Map these n unique X11 KeySyms via XChangeKeyboardMapping on the n available KeyCodes
Type the correct KeyCodes for all enqueued KeySyms via XTestFakeKeyEvent
Clear the queue and continue at 4.) until no input is available
Reactivate keyboards and restore initial modifiers and mappings
Basically this system works better and much more performant than any virtual X11 key input tool I've seen so far.
However, there is an issue I can currently only fix using ugly delays:
As any other X11 application, the target application receives a MappingNotify (request==Keyboard) event from the X server after my application succeeded in changing the keyboard mapping table.
The usual response of a X11 client is to call XRefreshKeyboardMapping to update Xlib's knowledge of the new keyboard layout.
Now if the the client has some lag processing its X11 event queue, the XRefreshKeyboardMapping call might return a too recent mapping that is already some generations too far in the future.
E.g. my input generator has already done the fourth XChangeKeyboardMapping when the target application just arrived at handling the second MappingNotify event in its XEvent queue handler.
Actually it should get the second generation of the map, which isn't available at the X server anymore at that time.
Unfortunately there is no map id or version of any kind in the keyboard MappingNotify event so that XRefreshKeyboardMapping could refer to a specific map ... and the X server does not seem to keep a history either.
The result is that the X11 application's KeyCode to KeySym conversion operates with an invalid layout and generates wrong KeySyms.
So basically I have to wait until all clients (or at least the one with the input focus) have requested and received my last XChangeKeyboardMapping map before I am allowed to do the next XChangeKeyboardMapping.
I can fix 99.9% of the errors using a delay before XChangeKeyboardMapping and that delay is calculated by some ugly witchcraft (amount of key strokes etc.) and is way to high if 100% accuracy has to be achieved.
So my question is if there is any way to programmatically be notified or to check if a X11 client has completed XRefreshKeyboardMapping or if its map is in sync with the server map?
If not, is there a way to get another X11 client's current mapping via xlib (to check if the map is current)?
Thanks for any hints!
I've done something similar on Windows in the past. I had the luxury of being able to use the SendInput function which accepts a KEYBDINPUT structure with KEYEVENTF_UNICODE flag. Unfortunately X11 does not support direct keystroke synthesizing of Unicode characters.
Since I cannot comment yet I'm forced to give a suggestion as answer:
Have you considered using the clipboard instead in order to transfer your "unicode input" into this X11 application's input field ?
You also might consider using direct Unicode input if that application uses a toolkit that supports this:
E.g. programs based on GTK+ (that includes all GNOME applications) support Unicode input.
Hold Ctrl + Shift and type u followed by the Unicode hex digits and release Ctrl and Shift again.
I guess it should be easy to synthesize these sequences using the Xtest extension.
Backstory:
I want to write a C program to automate clicks in a program running in OSx (in a desktop setting).
I first tried Using Quartz Event Services to simulate input events. But then I had this problem: Simulating mouse clicks on Mac OS X does not work for some applications, and the answers didn't help in my case.
CGEventRef click1_down = CGEventCreateMouseEvent(NULL, kCGEventLeftMouseDown, CGPointMake(posx, posy), kCGMouseButtonLeft);
CGEventSetIntegerValueField(click1_down, kCGMouseEventClickState, 0);
// This down click works about 5% of the time.
CGEventPost(kCGHIDEventTap, click1_down);
usleep(30000);
CGEventRef click1_up = CGEventCreateMouseEvent(NULL, kCGEventLeftMouseUp, CGPointMake(posx, posy), kCGMouseButtonLeft);
CGEventSetIntegerValueField(click1_up, kCGMouseEventClickState, 1);
CGEventPost(kCGHIDEventTap, click1_up);
// I've tried every combination of CGEventSetIntegerValueField, usleep and CFRelease, nothing seems to help
// The only thing helping is repeating the line: "CGEventPost(kCGHIDEventTap, click1_down);" 100s of times,
// then the down click works about 80% of the time, still not acceptable
I'm now turning to solution #3 suggested here: How can Mac OS X games receive low-level keyboard input events?
(this might also help How can I simulate the touch events by IOHIDEvent?)
I tried with Karabiner by sending a mouse click on key press:
<item>
<name>Right Mousebutton</name>
<identifier>rightMouseButton</identifier>
<autogen>__KeyToKey__ KeyCode::H, PointingButton::LEFT</autogen>
</item>
And this sends the click 100% of the time, but I want to send the click with by writing C code (to have greater control). Tough I'm not sure, Karabiner seems to use IOKit to send events, so I think this should work in my case, if I'm able to send mouse events with IOKit.
So my question is basically: how do I write a C program to simulate a mouse left click with IOKit ? The documentation is very sparse and I didn't manage to do it.
I tried getting inspiration from some projects:
https://github.com/tekezo/Karabiner
https://github.com/NoobsArePeople2/manymouse
Linux - is there a way to find the instantaneous keyboard state? e.g. is the Enter key currently pressed v. has the Enter key been pressed. I'm trying to process a power-off interrupt on the iMX6 processor - get the interrupt (in user space...), wait 500 or 1000 mS, and check if the key is still pressed. input.c does not seem to have a like-named method.
Thanks.
It might take a bit of effort on your part, but you can query key states and listen for key press-release events by using the evdev kernel interface.
For an example of how to do this look at evtest.
Or look at my python re-write: https://github.com/naedanger/pyevtest
I've used both of these tools on an iMX28 platform to listen for key-presses from a simple matrix keypad.
I'm currently working on an IR key handler for a box running on linux kernel 2.6.15. I'm fetching IR key events from tts/1. The issue I'm facing is that for a single key press on the remote results in 2-3 key press events.
What I'mm doing is that I'm reading from the file descriptor of tts/1 using read(). What I have seen is that for a single key press I got the same key code twice(sometime thrice). I think that this is not a hardware issue. I' using standard UART code.
Anybody has any idea ?
You could do like most devices and just add a minimum delay between repeated keystrokes. I did that for a custom key input device on windows and it worked really well. It's the same as your keyboard. When you hold down a key, it pauses after the first reaction. Later repeats are faster but still have built in minimum delays.
(not sure if I'm phrasing it right but it worked great for me. I was writing a program to generate keystrokes as a reaction to repeating input signals.)
I'm trying to make a small game using (free)GLUT. I know that it's old and there are better alternatives, but currently I prefer to stick with it and use it as much as possible. I program with C.
I'm currently trying to make GLUT detect properly all the keys I press.
I use glutKeyboardFunc, glutKeyboardUpFunc, glutSpecialFunc and glutSpecialUpFunc to detect pressed keys and I store their state in a short array I created (I currently have only 5 usable keys, so I just created a specific array for them).
However, while everything works fine for 2 keys or less, the game doesn't detect properly 3 keys or more. While for some keys it detect the combination properly (that actually happens for only 1 specific combination), for others the functions simply don't detect the third key that I press.
I checked my code a few times, and there is nothing special about the combination that does work.
I also made glutKeyboardFunc and glutSpecialFunc directly print every key-press that they receive, and it seems they simply stop working after I press more then 2 keys.
Is it a known issue with GLUT or something? I googled a lot and didn't find anyone with a similar issue.
I am not very into GLUT but as I know, but you should make sure, that your keyboard supports more than 2 input keys at once. This feature is called n-key rollover. This page says, that 2-key rollover may be a common value for some keyboards, but you dont need to trust this source.
I'll clarify a point: The glutKeyBoardFunc is a callback i.e., it is invoked for every key pressed and re-executed over and over again and all the if-else (or switch-case) statements for various key combinations are executed. What it means is this - if you were to press 'A', '->' (right arrow) and 'D' all at once, depending on which key-press event was received first the callback will be executed accordingly. Sometimes with a delay and sometimes the on screen animation may stop momentarily.
GLUT is purely for educational/learning purposes but not good for full blown applications since that's not what it was designed for. You land up using OS specific libs or other languages (e.g., Qt) to embed OpenGL "window" within them and execute the keyboard events etc., The event handling in those (and/or OS specific frameworks) is radically different (and better) than GLUT.
You may want to keep your simultaneous key presses to a minimum. You may augment it with the mouse to get rid of the jerky response/processing...