Exploring the Fragmentation of Wayland, an xdotool adventure

[-]

zlice0@reddit

tldr : we cared about security so much we just removed the idea in its entirety and left a giant hole that was bound to get filled by something insecure instead of being a good leader and putting even the slightest security protocol idea in the base of wayland

[-]

extracc@reddit

Linux, the OS that lets you delete all your files with a single command, now thinks we need to be babied from the terribly dangerous functionality of moving a mouse

[-]

the_abortionat0r@reddit

You clearly don't understand what you are talking about so maybe treating you like the baby you act like is a rather safe bet.

[-]

AnsibleAnswers@reddit

There's a reason why you need to add --no-preserve-root to the rm command. It wasn't always like that. It's okay to design an desktop operating system in a way that confirms human intent along the way. You should be able to do stupid things in unique cases where "it ain't stupid if it works," but stupid shouldn't be the default and it should take some intentional human input to configure it that way and run it. Installing isn't enough because it is impossible to avoid all supply chain attacks and trojans. Someone can infect enough computers to form a botnet in an ecosystem with a significant number of Linux desktops. sudo isn't really of use because its a user session. That calls for a XDG Desktop Portal. At least according to Gnome, KDE, Arch, Debian, Suse, RHEL, Fedora, IBM, and Valve.

[-]

dumbestbeaver@reddit

Did you spa從寬的ghetti?

[-]

natermer@reddit

X11 fragmentation was taken care of by every X11 implementation except Xorg's becoming irrelevant.

For keyboard and mouse automation I've been using tools like houmain/keymapper which attack the problem on the input level. There are a variety of tools like this and they typically follow all the same pattern. You have a daemon that runs in user session to manage configuration that communicates with a privileged daemon to do the actual virtual keyboard/mouse stuff.

There a a few programs out there that deal with that. sezanzeb/input-remapper seems pretty sophisticated. rvaiya/keyd is another. There are probably a half a dozen more.

I like the keymapper one because it allows application-aware keyboard macros in Gnome, KDE, and Wlroots-based managers.

For scan codes keymapper just uses web browser standards to decide what codes correspond to which keys. I don't know what other tools use.

The upshot of this general approach is that the basic functioning of input macros and modifications is independent of whatever display technology you are using. It works the same (except for the application detection) in Linux console or X11 or Wayland.

As far as moving windows around in a automated fashion I don't have any answers for that.

[-]

Patient_Sink@reddit

I think that moving around windows probably will require a compositor plugin since most of the parties don't seem interested in allowing random app to control other windows sizes and positions arbitrarily. Given that both gnome and kde have extensions that allow for tiling or other windowing configurations it doesn't seem impossible to have a plugin that listens to signals from a cli tool, but I don't know.

[-]

natermer@reddit

Yes, the fact that it needs to be Wayland manager specific is one of the major things he is complaining about.

Gnome is fully scriptable through Javascript, KDE has its plugin features, and things like Hyprland have command line clients and API for interacting with things.

But they are all different and require different tools/approaches. There is no 'one and done' way to do something like make a new window from a terminal go into the upper left quadrant of the screen.

[-]

AnsibleAnswers@reddit

Then standardize on an XDG Desktop Portal instead of a Wayland protocol where compositors would be required to support it. You should be able to have a desktop where that portal just goes no where. GUI automation has inherent risks.

[-]

Patient_Sink@reddit

I don't think either of us were arguing for a protocol, but yeah.

[-]

Patient_Sink@reddit

I mean, if there's no common portal then yeah. But it doesn't have to be one tool for each compositor, you can have a common cli tool interacting through the plugins for the running compositor. I think kdeconnect or gsconnect does something similar for it's browser/file manager stuff. But that might just be semantics.

[-]

GregTheMadMonk@reddit

Prepeare for a billion screen tearing/VRR/fractional scaling comments that all refuse to address the actual issues outlined

[-]

zlice0@reddit

still the number 1 'benefit' i see when ppl compare the 2

[-]

AnsibleAnswers@reddit

Window management is also quite weird. Wayland appears to have no built-in protocol for one program (like xdotool) asking a window to do anything - be moved, resized, maximized, or closed.

Automating window resizing and movements would need to be implemented by a compositor as far as I understand the modern architecture. The whole point is to ensure that the DE + user is in charge of all windows. This is a security feature and it’s kind of disingenuous for the author to insinuate that justifications for it don’t exist. The notion that you can trust every application installed on your system is just not very practical on a modern desktop. You want to make it impossible for one application to “impersonate” another. This is how it is done. Personally, I think automating GUIs is more of a “weird” (niche) use case than secure desktop computing.

As I learned about libei and XDG Portal recently, I wrote some test code to send some keyboard events. Writing my own software, running on my own machine, GNOME still prompted me “Allow remote interaction?” with seemingly no way to permanently allow my own requests. I’m not the only one confused by GNOME and KDE making such prompts.

My guess is this feature is unfinished, and will eventually allow users to whitelist their own libei server, and perhaps even distinguish between remote connections and connections from localhost.

[-]

TyssaRolli420@reddit

Meanwhile obscure platforms like "Windows" and "Mac OS" have no problem providing developers with such functionality. But I'm sure the Wayland developers have so much pull with devs that they can get away with not doing so.

[-]

AnsibleAnswers@reddit

I said the use case is niche, not that OSes that support the use case are obscure. You’re welcome to use X11 until these niche features are added to the modern Linux desktop.

Windows does so at the expense of preventative security. Apple has window resizing and movement functionality built into the Quartz compositor, just like I said would have to be developed on Linux.

Here’s the deal: either we implement things the Wayland way or we will need invasive and resource-intensive antimalware software akin to Windows Defender. The only thing that makes X11 sessions safe enough without antivirus is lack of market share.

[-]

nightblackdragon@reddit

Meanwhile obscure platforms like "Windows" and "Mac OS" have no problem providing developers with such functionality

Certain Wayland compositors also provide that functionality.

with much better sandboxing stories too

Such as?

[-]

Patient_Sink@reddit

Yeah being able to permanently allow certain apps/etc is an issue with the portal and has its own issue ticket IIRC.

[-]

TiZ_EX1@reddit

xdotool, wmctrl, and devilspie2 are the reliable hallmarks of my window placement automation. I have been able to take the majority of my rules from XFCE to Plasma, and unlike Plasma's window rules, devilspie2 is programmatic and can react to situations such as single vs multi-monitor.

The common thread between all three of these tools is EWMH. No Wayland compositor implements it, so I am not interested in migrating to Wayland until these tools work or have equivalents. I will continue to run Plasma on Xorg until it ceases to exist and there is no distro shipping the last release with it.