MOmodinfo·Aug 25, 2026Submission
Ydotool – Generic command-line automation tool
2 points · Open discussionReimuNotMoe
ydotool
C2018–2026
ReimuNotMoe / ydotool
ydotool
Generic command-line automation tool
20Distinct people
23Mentions
0Explicit recommenders
2.4KGitHub stars
What to know before exploring
What it is
Generic command-line automation tool
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- atx/wtype · linked in 2 of the same discussions
- flatpak/xdg-desktop-portal · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year23 dated mentions
Observed mentions: 2018-11-25 14:19:31 UTC to 2026-08-25 04:31:24 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 3 | 1 | 2 |
What Hacker News says
23 sourcesI have a personal fork of hyprvoice[0] which I use almost everywhere now (w/ the big cohere-transcribe running on a local vLLM instance). It does a similar thing, but that's not why I'm mentioning it; I think it's worth looking at because it's a clean reference for the few elegant ways you can implement text injection in modern Linux (wayland).
It supports ydotool[1], wtype[2] and "clipboard fallback with clipboard restore". The first two you can probably think of as AHK equivalents - they wire in at the input layer and inject keystrokes when injecting text. wtype is wayland-only and a bit less invasive, ydotool supports non-wayland also apparently, but I haven't tried it. Neither approach provides 'instant text' - you have to watch the text get typed out, and you don't touch your keyboard while it's happening; the clipboard implementatio
Read the rest
n is fallback for a reason as it's the least reliable. The first two work 'well enough' though, and are fairly tunable.
The other thing hyprvoice does in probably the most linux-friendly and universal way is the 'hotkey handling'. The server creates a socket in /tmp that the cli can then ping when the user triggers the start/stop/cancel, and they do this by binding whatever their DE's keyboard shortcut mapping mechanism is to trigger `hyprvoice toggle` as a background shell command. This works extremely well and is much cheaper than you'd intuitively think coming from Windows. This way you don't have to interface with DE-specific global keyboard listeners etc, but leave that to the WM (that's not to say that your installer couldn't prompt the user to configure the keyboard shortcut for them with their detected WM, you just wouldn't do it in the software itself).
I haven't actually looked at your project in too much depth yet as I have a solution for this already, so apologies if none of the above is news to you. Hope it helps though - happy to poke around and contribute something if the gap's still there.
[0]: https://github.com/leonardotrapani/hyprvoice
[1]: https://github.com/ReimuNotMoe/ydotool
[2]: https://github.com/atx/wtype
ydotool exists
https://github.com/ReimuNotMoe/ydotool
In I hate: Programming Wayland applicationsWayland is fantastic, but it requires some external tools for some non-default (seemingly 'simple') utilization. Therein lies double work, devs scratching their itch in whatever programming language they prefer, sure. The most popular one isn't always the best. And all of that is the nature of the bazaar. But the way I regard it, the bazaar can make use of curators who make a cathedral and sell that (anyone can, in theory). In other words, this is a service problem.
I used ydotool [1] in Sway years ago, worked perfectly fine. Had to setup the permissions though, IIRC via some udev rule. There are also other tools which do something similar, each being slightly different and sometimes with different features or pros/cons. For example, there was this tool for just swapping buttons (wtype), one for reading the input and echoing what was bein
Read the rest
g pressed (wev), and there is one doing that with a keyboard visual picture, too (wshowkeys). Basically, sircmpwn (author of Sway) wrote a lot of useful Wayland utils [2].
Then for running GUI apps remotely, there's Waypipe [3], and for running Android apps on Wayland there's Waydroid [4].
The beauty of all this, is that with Wayland you don't have to run QubesOS in order to have a somewhat secure desktop OS.
..but it did require some work to get all of this working. I already knew that the moment I went for Sway instead of Gnome or KDE.
Also, I believe the mobile Linux DE's each use Wayland, too. pmOS with say Phosh, Lomiri, Plasma Shell, you'd always be using Wayland. That all started with N9 MeeGo and SFOS, while the predecessor of N9 (N900) still used X.org.
[1] https://github.com/ReimuNotMoe/ydotool
[2] https://git.sr.ht/~sircmpwn
[3] https://gitlab.freedesktop.org/mstoeckl/waypipe
[4] https://waydro.id/
About AutoHotKey, you can do similar stuff as long as you are using X11 as there are various utilities for it, such as xdotool[0]. There is even an AutoHotKey-for-Linux project[1] (it also needs X11 - the author did try to port it to Wayland but gave up). For Wayland there are some alternatives like ydotool[2] (actually AFAIK since ydotool uses some daemon to inject events it works with anything, not just Wayland, but on the other hand it only provides a basic tiny subset of xdotool's commands) but the core protocol isn't particularly friendly to such automation.
[0] https://github.com/jordansissel/xdotool
[1] https://github.com/phil294/AHK_X11
[2] https://github.com/ReimuNotMoe/ydotool
In No I don't want to turn on Windows Backup with One DriveThere is an xdg-desktop-portal which an application can use to register a global shortcut.
https://github.com/flatpak/xdg-desktop-portal/blob/main/data...
Not sure which compositor support this and which ones don't. Hyprland, which I use, supports it.
There is also ydotool, which can emit key presses anywhere in Linux by registering a virtual uinput device.
https://github.com/ReimuNotMoe/ydotool
Using these two building blocks, it should not be very difficult to implement an application that implements global macro support.
In GreggloggerI've been using Ydotool[1] for this, and it works really well.
1. https://github.com/ReimuNotMoe/ydotool
In Show HN: Keydogger – Minimal keyboard macro for Linux (Wayland)Wayland provides little by design, so this is quite typical. For example:
Screensharing is handled by pipewire [0], changing keyboard layouts aren't defined [1] by wayland, and generally anything Wayland devs think would 'corrupt' their protocol.
They leave most things to the compositor to implement, which leads to significant fragmentation as every compositor implements it differently.
Long gone are the days of xset and xdotool working across nearly every distro due to a common base, now the best you'll get is running a daemon as root to directly access `/dev/uinput` [2] or implementing each compositors accessibility settings (if they have them) as a workaround.
[0] https://superuser.com/questions/1221333/screensharing-under-...
[1] https://unix.stackexchange.com/questions/292868/how-to-custo...
[2] https://github.com/ReimuNotMoe/ydotool
In Improving cursor rendering on WaylandOr https://github.com/ReimuNotMoe/ydotool for wayland.
In Somehow AutoHotKey is kinda good nowHave you tried ydotool as a replacement for xdotool? It also works on X, as it uses uinput.
https://github.com/ReimuNotMoe/ydotool
In Wayland Protocol Finally Ready for Fractional Scalingyeah. this is as far as you get: https://github.com/ReimuNotMoe/ydotool.
begs the question. how come ahk can run on windows(tm) but not wayland? my understanding is that win10/11 are pretty secure.
In Show HN: AutoHotkey for LinuxThere is some rough functionality for operations with wlroots via wlrctl https://git.sr.ht/~brocellous/wlrctl and more generically (via uinput) ydotool https://github.com/ReimuNotMoe/ydotool
In Show HN: AutoHotkey for LinuxI get your confusion, there is one screenshot API that abstract the compositor but it lies in xdg-desktop: https://github.com/flatpak/xdg-desktop-portal/blob/master/da...
The portal for xdg-desktop takes care of the implementation and is the responsibility of the compositor.
It's already used by Flameshot for example.
There is several xdottool equivalent as well:
https://github.com/atx/wtype
https://github.com/ReimuNotMoe/ydotool
This one is specific to wlroot based compositor:
https://git.sr.ht/~brocellous/wlrctl
In Less Than 10% of Firefox Users on Linux Are Running WaylandA project to keep an eye on, to replicate 'autotype' support offered by many password managers, is wlrctl¹. A popular alternative is ydotool², but brings some additional risks the operator might not be comfortable with.
¹https://git.sr.ht/%7Ebrocellous/wlrctl
²https://github.com/ReimuNotMoe/ydotool
In Wayland in 2021Showing the 15 most recent of 23 sources. Enable JavaScript to search and browse every indexed mention.