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.
Related
I need to check the toggled state of caps lock and block it.
I have tried using a low-level keyboard hook SetWindowsHookEx with WH_KEYBOARD_LL and checking for WPARAM==WM_KEYDOWN || WPARAM==WM_SYSKEYDOWN messages, and LPARAM.vkCode==VK_CAPITAL || LPARAM.scanCode==0x3A, but this results in me intercepting/blocking caps lock when it's held down/pressed, not when it's actually toggled.
It's important that I intercept the toggled event exclusively because I don't wish to rely on a single press of caps lock toggling its state, and I don't want to disrupt other events in case of caps lock being used as a modifier.
I'm currently using GetKeyState(VK_CAPITAL)&1 to check for caps lock state in my window callback, and forcing it back off with SendInput , but I would rather intercept/block it if any possible.
I have tried Raw Input as well, and it generates a pair of RI_KEY_BREAK And RI_KEY_MAKE messages when caps lock gets toggled, but (unless I'm mistaken), there is no way to block keys based on WM_INPUT messages, and trying to synchronize a hook and Raw Input seems to be difficult because the hook always gets them first.
Using GetKeyState or GetAsyncKeyState from a hook also seems not to work, as they seem to get the event after the hook.
Use GetAsyncKeyState to detect when/if the caps key is hit, and its current state (up or down).
Then call keybd_event (or SendInput) to programmatically set the caps key back to the state that you want it to be.
The following code snippet (along with other setup code) is included in this link, and will toggle CAPS lock on or off when executed:
RUN keybd_event ({&VK_CAPITAL}, 0, {&KEYEVENTF_KEYUP}, 0, OUTPUT intResult).
RUN keybd_event ({&VK_CAPITAL}, 0, {&KEYEVENTF_EXTENDEDKEY}, 0, OUTPUT intResult).
RUN keybd_event ({&VK_SHIFT}, 0, {&KEYEVENTF_KEYUP}, 0, OUTPUT intResult).
RUN keybd_event ({&VK_SHIFT}, 0, {&KEYEVENTF_EXTENDEDKEY}, 0, OUTPUT intResult).
The recommended way to deploy this implementation (GetAsyncKeyState / keybd_event combination) within your application is to encapsulate it into a worker thread set in a forever loop with sleep() set to allow sampling of the state approximately every 100ms.
(Note, I believe GetAsyncKeyState() over GetKeyState() is an improvement for what you want to do here as GetKeyState() gets the key status returned from the thread's message queue. The status does not reflect the
interrupt-level state associated with the hardware. GetAsyncKeyState()
specifies whether the key was pressed since the last call to
GetAsyncKeyState(), and whether the key is currently up or down.) With a reasonable and appropriate sample cycle using GetAsyncKeyState().
The concept above is comprised of functions that run in user-mode, therefore almost certainly limited to implementations of reaction algorithms (detect toggle, then execute another toggle.) as opposed to a true prevention algorithm. (ie, one that either re-maps a key to a no-op at run-time, or trap the request at a low level.)
Most true prevention algorithms would likely make use of Kernel mode driver calls, which are accessible and implementable via the WinAPI and for which concepts are introduce (among other places) by burrowing down through the content here RAWKEYBOARD into areas such as Keyboard and Mouse HID drivers.
A key-mapping approach
The method described below meets the primary need, i.e. to disable the the Caps Lock key from toggling the keyboard into CAPS mode. However, it does not maintain the ability of key to be used as a modifier once it has been re-mapped. (One of the criteria you list.)
The uncap project worked (almost out-of-the-box) for me to disable the Caps Lock key.
Before trying it, I recommend going through the README.md to get the details. In short, it uses a key map approach that allows keys to be mapped to different locations. I found it essentially does what it claims in terms of disabling Caps Lock, and it is capable of doing much more. This could be good or bad. Having the source code available allows you to create a pared down version that simply disables the Caps Key, or do other modifications as needed.
While exploring it, I found a couple of issues that I describe below under problems.
Note that the default behavior is to map Caps Lock key to VK_ESCAPE upon startup. I commented out the following line in the parseArguments(...) function to disable that feature so I could experiment with other mappings...
/*my.keymap[VK_CAPITAL] = VK_ESCAPE;*/
I used uncap.c as the only source file and the following on a Windows 10 machine:
gcc.exe -Wall -g -std=c89 -I"C:\Program Files (x86)\CodeBlocks\MinGW\mingw32\lib" -c C:\play_cb\uncap\uncap.c -o obj\Debug\uncap.o
Problems
It builds with a few warnings related to wrong number of arguments, or format specifiers in sprintf, but once addressing those issues, the code worked as described in this section of documentation.
Although the feature list claims "Disable key mappings easily by stopping Uncap.". did not work. Once the PC was re-booted, normal key mappings are restored.
If the keyboard is set to CAPS ON when uncap is executed, it remains in CAPS mode and the Caps Lock key is not able to undo it :)
I found this link useful when experimenting with mappings: Virtual key codes
You could set a low-level hook with SetWindowsHookEx. Refer to the thread: Best way to intercept pressing of Caps Lock
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.
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 :)
I have a steering wheel game controller.Now I am trying to write a driver for playing a race game such as NFS-17.I knew the game is using Xinput.I will write the driver in C.
My questions:
1) How to send message to the game when I turned the steering wheel.
2) Is it using SendMessage().
3) If use SendMessage(), how to get the game window's handle and which wParam and lParam should I send.
XInput is for xbox360 controllers. For the steering wheel X axis you can use the two Triggers of the gamepad. XInput is a getter/setter nothing more :P It gets you the state of the connected controller and reports if there is something connected or not at your request only, it doesn't monitor or save anything anywhere nor does it send messages to apps that have input focus. Sending messages is your job with an app that you could build.
Now, down to what you actually need. You could write a simple C++ app that would scan the state of the controller, but wait...you don't have a xbox360 controller :P So first test how your app would respond to your steering wheel with its oem driver. If you can't read it as connected on any usb port (check on MSDN the GetInputState()) then try using a windows generic driver (let it install whatever suits it, it might even perceive your steering wheel as a xbox360 they are very similar to a point, difference being the number of axis and buttons with more expensive wheels).
Then when you achieved actually reading the state of your controller (steering wheel), use GetHDC( windowhandle), where windowhandle is retrieved via (I don't remember for sure)FindWindow(name/title of the window). Use alt-tab to check with mouseover whatever title is used for the game's window.
When you are in possession of the window handle and the device context you can send messages to its call back WndProc function corespondent via the window handle and even display texts/draw images/shapes via the device context. The messages should be the according virtualkey codes (VK_UP for UP arrow for instance...look it up) that would be pushed on the keyboard if there wasn't a wheel available. The trick is to simulate a PWM for every degree of the wheel rotation. Just send a high frequency messages of alternating push/release of the VK_LEFT key code for a high degree of wheel turn to the left and for steering lock just send one KEY_DOWN message until the steering lock is removed and then a KEY_UP message followed by the corresponding frequency of alternations again. For low degrees of wheel make larger pauses between the key press/release messages.
A bonus of making a driver is that you can adjust the sensitivity, button correlations, dead zones for your own liking.
On the other hand there are simulators like this already and then again you could build your own steering wheel with 6+1 transmision using just a usb comunication API(read/write data from/to USB port, nothing fancy :) ) from windows, a microcontroller (PIC,atmega, nxp, etc whatever cheaper and with hardware USB at the ready or plus a usb controller), variable resistors for the X,Y, etc axis and some parts for the driving system. Good luck and post on youtube :P!
P.S. Hell it is way too late now, but hey...I felt I needed to write some mambo-jambo I have never done, but which would work... if I wasn't that lazy. :)
Update: xInput may work if compatible (probably high end wheels and joys), but directx knows of steering wheels too, all of them. For me it was the only solution. Microsoft says both XInput and directX should be used as XINput offers audio and more stuff for compatible products.
The algorythm is sound, though open to many implementations. I implemented it successfully for GTA SA, since dedicated tools didn't support my version. Now I have Acc and Brake from the pedals, finally:) I used a timer to achieve a certain frequency (of own choice, empiric stuff), and modulated the pulse width from near 0s to full period (light touch of the pedal and continuously applied pedal to the metal). On every pulse I sent two messages: W/S keys down at the start of the pulse and W/S keys up when the calculated pulse width has reached its end value. The formula for Pulse Width is percentage of total width, the same percentage or modified by a sensitivity setting for instance the pedal had traveled from its max travel distance (DirectInput reports a integer number in[-1000,1000] I think. [-fullbrake,fullacceleration]).
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.)