![]() My plan for v2 is for the script to take xmodmap -pke as input and dynamically generate the appropriate codes. If a system’s keymap differs, the codes array near the top of xkeyscan.py will need to be adjusted accordingly. In its current iteration, the xmodmap legend is statically set. xkeyscan is tailing and parsing xkey.log in the bottom-left terminal.Keystrokes being captured were performed in the top-left terminal.Capturing is done in the right terminal (using tee to verify output).The switch is necessary for real-time parsing when tailing a log file, otherwise the data doesn’t get parsed until python’s buffer is flushed (for example with a CTL-C or CTL-D.) This disables python’s default buffer, allowing for data to be parsed as it’s streamed in. ![]() Note the usage of python’s -u switch on the last command. Or parse in real-time: $ tail -f -n +1 xkey.log | python -u xkeyscan.py Or read from stdin: $ cat xkey.log | python xkeyscan.py Xkeyscan can parse the file directly: $ python xkeyscan.py xkey.log For the following examples, data is stored to a file called xkey.log using the following syntax: $ script -c "xinput test " /dev/null > xkey.log The script can be used a handful of ways depending upon how you’d prefer to feed data into it. I’ve built in some logic to account for modifier keys, such as Shift or Alt, so the parser will correctly determine things like case-sensitivity and special characters. Type -h or -help for a full listing of options. Tail -f -n +1 xkey.log | python -u xkeyscan.py (tail log file) Python xkeyscan.py xkey.log (post-process log file)Ĭat xkey.log | python xkeyscan.py (accept logs from stdin) If tailing a log file, use python's -u switch to avoid buffering. $ python xkeyscan.py -hĪ simple script for converting xinput output to legible keystokes.Ĭan process a log file directly when passed as an argument, or canĬonvert keystrokes in near real-time if tailing a log file. What I ended up creating was a fairly simple Python script called “xkeyscan” which can be found here on GitHub. The next logical step is to leverage this keymap to automate the keycode-to-keysym conversion process. ![]() More details about xmodmap and modifiers can be found here. The Shift modifier will return the keysym in the second column, and so on. Notice how the keymap has multiple keysym columns for each keycode - this is due to modifiers (Shift, Alt, etc.) No modifier will return the keysym in the first column. Keycode 25 = w W w W U2211 doublelowquotemark Keycode 23 = Tab ISO_Left_Tab Tab ISO_Left_Tab Keycode 22 = BackSpace BackSpace BackSpace BackSpace ![]() Keycode 21 = equal plus equal plus notequal plusminus Keycode 20 = minus underscore minus underscore endash emdash Keycode 19 = 0 parenright 0 parenright masculine singlelowquotemark Keycode 18 = 9 parenleft 9 parenleft ordfeminine periodcentered Keycode 17 = 8 asterisk 8 asterisk enfilledcircbullet degree Keycode 16 = 7 ampersand 7 ampersand paragraph doubledagger Keycode 15 = 6 asciicircum 6 asciicircum section UFB02 Keycode 14 = 5 percent 5 percent infinity UFB01 Keycode 13 = 4 dollar 4 dollar cent U203A Keycode 12 = 3 numbersign 3 numbersign sterling U2039 Keycode 11 = 2 at 2 at trademark EuroSign Keycode 10 = 1 exclam 1 exclam exclamdown U2044 This is obtainable via xmodmap -pke: $ xmodmap -pke | head -n20 How can these keycodes be translated to something more legible? Well, first we need the system’s device mapping of keycodes-to-keysyms, called a keymap. This is the output from typing “nano”: $ script -c "xinput test 12" /dev/null Instead of the characters typed by the user, the result is a series of keycodes. Now, the output produced by xinput test isn’t quite the final output we’re looking for. ![]() On my lab machine, this would be id 12: ⎡ Virtual core pointer id=2 XID is the “id” number associated with the desired keyboard input device.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |