Created attachment 732575 [details, diff] allow xdotool to work on xwayland again This is primarily an upstream problem which they're already aware of and intend to deal with, but I believe a gentoo tracker will be useful as well, both because I believe the previous version should remain available in gentoo until it's fixed, and to provide a patch for /etc/portage/patches if people need it before either upstream or gentoo fixes the problem. xdotool-3.20210804.2 errors out when it detects wayland, while the old 3.2016.0805.1 version works fine on X apps using xwayland. (Not on wayland-native apps but that's a given.) The original issue triggering the code change (and thus the bug) is here: https://github.com/jordansissel/xdotool/issues/341 The corresponding PR is here: https://github.com/jordansissel/xdotool/pull/342 The specific commit (of five in the PR) is 9b1cc6bdd, found here: https://github.com/jordansissel/xdotool/pull/342/commits/9b1cc6bdddff3070acd8202a7f5bad08ecd2a730 The new issue reporting that the above broke xdotool on xwayland is here: https://github.com/jordansissel/xdotool/issues/346 Jordan acknowledges the problem and says he'll probably revert the error to a warning here (a comment on the above issue): https://github.com/jordansissel/xdotool/issues/346#issuecomment-893070520 Later (the last comment as I write this) another user suggests the solution that I would have suggested, a command-line option like --enable-xwayland that would allow users to use xdotool on xwayland, with the current error remaining if the option isn't given. Meanwhile, the relevant code in above commit 9b1cc6bdd is the following added as lines 119-124 of xdo.c: // This library and xdotool do not work correctly on Wayland/XWayland. // Try to detect XWayland and warn the user about problems. if (appears_to_be_wayland(xdpy)) { fprintf(stderr, "The X server at %s appears to be XWayland. Unfortunately, XWayland does not correctly support the features used by libxdo and xdotool.\n", display); return NULL; } If xwayland is detected it prints the message to stderr and returns null, which ultimately terminates xdotool. Simply commenting the return NULL; line will still print the error message but will allow xdotool to continue, and that's what the attached patch does. Until upstream commits a fix, gentoo can apply it, or users can apply it by dropping the patch in /etc/portage/patches/x11-misc/xdotool, which is how I'm applying it ATM. Just commenting a line so arguably uncopyrightable, but FWIW... Signed-off-by: John Duncan <1i5t5.duncan@cox.net>
Upstream is planning to downgrade this to a warning so I see no reason not to include this change already!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4de47de2cf0b57f01df6d3bc2af091fa9b715826 commit 4de47de2cf0b57f01df6d3bc2af091fa9b715826 Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2021-08-17 13:04:12 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2021-08-17 13:09:17 +0000 x11-misc/xdotool: allow using 3.20210804.2 with XWayland This will likely no longer be needed come next release - with users generally reporting having been able to use xdotool on XWayland, upstream has decided to change the behaviour of the newly added check to "warn but allow". See https://github.com/jordansissel/xdotool/issues/346 for details. Suggested-by: Duncan <1i5t5.duncan@cox.net> Closes: https://bugs.gentoo.org/807989 Signed-off-by: Marek Szuba <marecki@gentoo.org> .../files/xdotool-3.20210804.2-allow_xwayland.patch | 14 ++++++++++++++ x11-misc/xdotool/xdotool-3.20210804.2.ebuild | 1 + 2 files changed, 15 insertions(+)
