https://github.com/autokey/autokey
Haven't used that one, and it is for Xorg only. Meaning, it is basically a standard application that asks Xorg to deliver it copies of all keyboard events, and when it sees the hotkey'd ones, it generates the needed additional keypress events. It won't work on the terminal console (say, serial terminals, or on SSH connections to the machine), but it should work fine in Gnome, Cinnamon, KDE, XFCE, and LXDE environments (as long as they use Xorg and not Wayland).
maybe there is something in Linux that sits beetween keyboard and mouse and the linux core to generate keyboard and mouse automated scripts
There are three things.
- Linux Input Subsystem. It is basically the interface to all Human Interface Devices: keyboards, mice, tablets, touch screens, joystics, et cetera. It provides one event interface device per device. (Some devices, like touchpads on laptops with buttons both above and below the touchpad, are actually two separate devices, with the second device being usually a generic mouse with just the buttons but no movement axes.) You can examine these events by running evtest as root.
Each event interface by default provides copies of the events to each application that has the device open. Keyboard events are also forwarded to the process that is reading from the terminal console, and mouse and touchpad events to a combined "mice" device. An event interface device can also be "grabbed", so that the events are exclusive to the process, and not forwarded by the kernel.
There is also an uinput event device, that can be used to create new event interface devices that look exactly like hardware devices, and emit events into them. It can be used to echo events from a grabbed device, inserting new events as needed, on the kernel level.
For example, you can create a daemon that monitors (not grabs) keypresses, and when it detects a specific keypress, it generates a mouse or touchpad event that moves the pointer by a specific amount in a specific direction.
Because the Linux Input Subsystem is a part of the kernel, this works with all Human Interface Devices connected to the machine.
Examples I've shown at StackOverflow include a basic skeleton of a daemon that reads keyboard events from a barcode scanner, verifying and translating them, before emitting the barcode as if it was typed on a numeric keyboard.
- Pseudoterminal interfaces. These are used by "command-line" applications, including things like shells and SSH-connections. Basically, tools like screen can interpose a pseudoterminal interface on top of an existing one, and do all sorts of translations between the two. GNU screen itself is a tool that allows you to for example connect to a remote machine, run screen there, do something, log out, later log back in and connect to the existing screen session -- the applications running in the session see the user as continuously connected, as screen hides the SSH connection loss from the applications in its session. Equally, it could do input translation and hotkey stuff. (It actually might.)
Unfortunately, the session management in systemd may make using tools like screen harder, since systemd forgoes the Unix philosophy of modular tools, and often assumes that when the user logs out, all the processed started in that session should be killed, also killing screen.
In practice, any kind of translation at this level is exceedingly rare. Possible, but probably only useful as a gag; say a fake shell.
- Desktop Environment. In Linux, there are two main servers, Xorg and Wayland, that can act as the base server. It provides basic 2D and OpenGL functionality, and an event interface. They do provide a mechanism for applications to interpose (or divert the events to themselves) for AutoKey-like functionality.
Desktop Environments are sets of applications on top of such a server, implementing toolbars, menus, window decorations, media services, and so on. The current ones already monitor for specific keypresses (for things like volume and brightness controls, menu popups, et cetera), and all have a facility for the user to add new keypresses that either copy an existing functionality, or execute a custom script or program.
In most cases, the Desktop Environment (or Xorg) -based one is most suitable for Autokey-like functionality.
Things like translating the output from a barcode scanner, or combining multiple different devices into one (say two joystics into a wheel and a joystic, to physically use two-stick-steering in driving simulatiors), should be done on the Linux Input Subsystem level.
For example, if you or your kids like playing free online two-player games, but using a single keyboard or different keys is annoying (they usually use W/A/S/D for one player, and cursor keys for the other), one could easily write a Linux Input Subsystem daemon that grabs two specific gamepads or keyboards, and translates them to keypresses on a single keyboard, with very little latency (not enough to notice on even small SBCs on kernels configured for interactive use (HZ at least 100, preferably 1000). Just fire up a browser, open a two-player game you like, use a small GUI tool to select the two keyboards/gamepads and the mappings used, and play away. The tool and the daemon are not complicated programs at all; personally, I find the UI design for even such small tool to take more time than the actual daemon code.
(It is simpler, though, to use a microcontroller with a native USB interface, like ATmega32u4 (as in Arduino Micro and Leonardo; SparkFun Pro Micro; Teensy 2.0; Makey Makey; and a ton of custom keyboards and gamepads), and have them simply enumerate as an USB HID device, and generate the proper keypresses themselves. That works on all computers, and requires no drivers; and there is even existing Arduino code to do it nicely. The only "problem" is making the physical gamepad itself; whereas one can buy cheap but okay USB ones off fleabay and elsewhere. And if you want to change the keys they generate, you again need a small UI tool; I'm not sure if suitable open source ones already exist. Years back, I made myself one, using an arcade joystick and buttons, on top of a 30cm by 60cm 18mm thick birch board.)
Home
Help
Search
Login
Register
