KDE "dropping" X11 for Wayland on Plasma 6 discussion and the alternatives in that case

[Kresimir]

@Zesko

Many of these features are already available in KDE Wayland.

Wrong.

@Zesko

→ For example: I press F12 in any focused or unfocused window app to open another terminal yakuake. Kwin has this feature to listen any key presses.

Please write a minimal example, in a programming language of your choice, of a program that creates a window and waits for a keypress, and it detects what key was pressed while another window is focused. You will fail.

@Zesko

For example: I use kcolorchooser to be able to detect which pixel color outside of its window app without any problem.

Can you do this with any other colour chooser? A custom one? Does xcolor work?

@Zesko

AFAIK, Kwin Wayland uses the protocol kde-fake-input (See Wayland protocol document ) , It should work with KDE Connect app on smartphone for remote access to simulate mouse input and key presses on Desktop.

Can you do this from another program, which is not run as root?

For example, open 3 instances of LibreOffice and run a Bash script in a terminal emulator that types the contents of some text file at about a character per second. Then whichever LibreOffice window you focus, into it the text is autotyped. ydotool can do something like that (poorly), but it need to constantly run a service as root, which is crap.

@Zesko

I do not understand what do you mean.I suspect you mean switching between virtual desktops. The feature is available.

No, I mean a gap between screens. For example, I have a pair of 1440p monitors, each has a width of 2560 pixels, and I want a buffer zone of 20 pixels between them, so that my total workspace resolution is 5140 × 1440 instead of 5120 × 1440:

 
 
 Screen 1     
 
 Screen 2 
                         ^ 20 pixel gap

to account for the width of the physical edge of the monitors. Alas, Wayland does not allow the mouse cursor to leave the screen.

@Zesko

For example: KDE widgets. I open Eclipse or Intellij Idea to initially display a borderless window.

That’s not a fully transparent, borderless window.

[Zesko]

@Kresimir

Please write a minimal example, in a programming language of your choice, of a program that creates a window and waits for a keypress, and it detects what key was pressed while another window is focused. You will fail.

Yes, my own program doesn’t work without root except Kwin control. I can only add my custom shortcuts of any program in the KDE setting and let Kwin compositor listen to my global keystrokes.

If you successfully write your program without root to break the restriction for fun, this shows a proof that Kwin wayland has a security vulnerability.

@Kresimir

Can you do this with any other colour chooser? A custom one? Does xcolor work?

Yes, some apps work e.g kontrast. Other X apps do not.
However, KDE has a native KDE app kcolorchooser.

@Kresimir

Can you do this from another program, which is not run as root?

For example, open 3 instances of LibreOffice and run a Bash script in a terminal emulator that types the contents of some text file at about a character per second. Then whichever LibreOffice window you focus, into it the text is autotyped. ydotool can do something like that (poorly), but it need to constantly run a service as root, which is crap.

Yes, no root is required. AFAIK, KDE prompts you to click a button of Auth “Accept” or “Reject” for encrypted communication with any app if it supports the protocol “kde-fake-input”.

You can add any programs and your bash scripts into KDE connect setting on Desktop, see the screenshot:

All remote programs are present in the KDE connect app in my smartphone. When I play to click on one of them for example firefox to invoke and run firefox on Desktop. That should work.
Rest there are many different features in the KDE connect setting that you can try.

[Kresimir]

@Zesko

Yes, my own program doesn’t work without root except Kwin control. I can only add my custom shortcuts of any program in the KDE setting and let Kwin compositor listen to my global keystrokes.

If you successfully write your program without root to break the restriction for fun, this shows a proof that Kwin wayland has a security vulnerability.

Well, that’s utterly useless for my use case. I can’t just add a few hundred shortcuts to Kwin every time I run my keylogger, for example. Also, what about conflicts? It’s a total mess.

Running random programs as root is a much greater security vulnerability.

@Zesko

→ Yeah, the pipewire API has this ability to detect all running graphic apps and mouse movements on the screen. pipewire-session-manager is used by Kwin compositor. For example OBS Studio and KDE Spectable can see them.

How would you implement Xeyes with that? One without root privilege, of course.

Could you write (in a programming language of your choice) a program that displays a window, and prints to the standard output the global coordinates of that window, as well as the global coordinates of the mouse pointer. That would be quite enough for me to make my own version of Xeyes, which would be a huge step towards Wayland actually being usable.

@Zesko

However, KDE has a native KDE app kcolorchooser.

I don’t care, I don’t want to be vendor-locked in a walled garden of approved colour pickers. I want to be able to write my own tools, so I need to be able to write my own program that can see any pixel that my eyes can see.

@Zesko

Yes, no root is required. AFAIK, KDE prompts you to click a button of Auth “Accept” or “Reject” for encrypted communication with any app if it supports the protocol “kde-fake-input”.

I’ve used KDE Connect before, I know what it is. But why are you bringing it up? It has nothing to do with my use case.

Can you give me a minimal example in a programming language of your choice? Like a program that types text into any window that is focused (to make it simple, lets have it type H, E, L, L, O, H, E, L, L, O, … one character per second, in an infinite loop), in such a way that the target window has no idea that it’s not the user typing that text on a keyboard, but a bot. No root, of course (including no daemon running in the background with root privileges).

[keybreak]

@Kresimir

Running random programs as root is a much greater security vulnerability.

Yeah…It would be one thing to ask for permission or something, but root is a bit much

[Zesko]

@Kresimir

@Zesko

→ Yeah, the pipewire API has this ability to detect all running graphic apps and mouse movements on the screen. pipewire-session-manager is used by Kwin compositor. For example OBS Studio and KDE Spectable can see them.

How would you implement Xeyes with that? One without root privilege, of course.

I’m not a professional C programmer and I understand the basics of how it works.
I already mentioned above:

@Zesko

Theoretically, if “xeyes” uses pipewire API, that should work independently of Xorg or Wayland. I would rename it to “peyes”.
But pipewire API would provide read-only information about any graphic apps and mouse on the screen.

• See the official doc of pipewire about the data structure spa_meta_cursor in C program:
  https://docs.pipewire.org/structspa__meta__cursor.html
• And a sample source code how to get info about the cursor:
  https://docs.pipewire.org/video-play-pull_8c-example.html#_a11

---

@Kresimir

5. Ability to simulate keypresses, mouse movement and clicking from a user process, without needing privilege escalation.

@Kresimir

I’ve used KDE Connect before, I know what it is. But why are you bringing it up? It has nothing to do with my use case.

Because that was XY problem.

[Kresimir]

@Zesko

Because that was XY problem.

How?

Ability to simulate keypresses, mouse movement and clicking from a user process, without needing privilege escalation.

Well, that’s exactly what I need. Ability to make a program that simulates keypresses and mouse actions. KDE Connect doesn’t do that.

@Zesko

I’m not a professional C programmer

Doesn’t have to be C, pretty much any programming language will do. And I do not intend to pay you for it, so whether you’re a professional or not makes no difference to me.

[Schlaefer]

@keybreak

Yeah…It would be one thing to ask for permission or something, but root is a bit much

That’s why you don’t need root. You don’t enter your admin password if you want to pick a color our share your screen on plasma wayland.

[keybreak]

I’m sure you have enough reading skills to catch that they were talking about standalone programs for color pickers, not ones bound to KDE’s session.

[Schlaefer]

@keybreak

I’m sure you have enough reading skills to catch that they were talking about standalone programs for color pickers, not ones bound to KDE’s session.

What does “standalone” mean? It was just a synonym for “we support X only”. Yes we are not talking about X, we are probably aware of that fact.

[peciwov]

@Kresimir

I can’t just add a few hundred shortcuts to Kwin every time I run my keylogger, for example.

To be fair, you have to realize that what you are trying to achieve (in this specific example at least) is what 99.9% of people want to avoid, and pretty much exactly the reason Wayland has made the decisions it has made…

And if you still want to run your keylogger for X or Y reason, running it with root (if that is possible) would make sense, as you should be trusting in the first place. (if it’s a keylogger, it already knows your password)

[Kresimir]

Keylogger is just an example, don’t take things so literally. And no, I don’t want to run it as a root, because it might be part of a GUI program that uses some widget toolkit with millions of lines of code.

[keybreak]

Ok…i guess reading is not your thing after all.

@Schlaefer

What does “standalone” mean?

Standalone program means your own program (not written by KDE and not bound to it’s session running). It can be X11, it can be Wayland.

Go ahead, write simple program for Wayland that doesn’t require root to gather pixel color data…

[Kresimir]

Read the posts above, I explain in painful detail what exactly I need. Don’t sidetrack a productive discussion with questions that have been answered.

@keybreak

Go ahead, write simple program for Wayland that doesn’t require root to gather pixel color data…

Yes, please.

A very nice demo program would be one that detects a certain image on the screen (in whatever window it is present) and slowly moves the mouse pointer to it.

Like a “Where is Waldo” application: every time Waldo (a specific bitmap) shows up in any window (like browser, or Krita, or GwenView, or as a thumbnail in Dolphin, etc…), the application finds him and points to him with the mouse pointer.

[peciwov]

@Kresimir

Keylogger is just an example, don’t take things so literally. And no, I don’t want to run it as a root, because it might be part of a GUI program that uses some widget toolkit with millions of lines of code.

I understand, but then maybe it wasn’t a great example in the first place.

And again, a keylogger that works without root, already has your root password. (An argument could be made that you can be cautious and not type it while the keylogger is running, but I’m just saying that by design, you would be exposed).

Other than that, I’ve already stated earlier in the thread that I respect that your needs are not met by Wayland, I’m not trying to say your needs are pointless.
Just that particular example I felt was a bit unreasonable.

[Kresimir]

@peciwov

And again, a keylogger that works without root, already has your root password.

No, it doesn’t, especially I haven’t typed it while the program is running. We are not talking about malicious keyloggers, just a general type of an application.

And in the end, it doesn’t matter whether it is malicious or not, as long as it is under my control, I’m fine with it.

And even if it did have my password, I still don’t need to run millions of lines of code from some GUI widget kit. Not because of security (although that is also a big concern), but because it will break my system and permissions in my home directory.

[peciwov]

@Kresimir

No, it doesn’t, especially I haven’t typed it while the program is running

I already adressed that argument.

@peciwov

(An argument could be made that you can be cautious and not type it while the keylogger is running, but I’m just saying that by design, you would be exposed).

---

@Kresimir

And in the end, it doesn’t matter whether it is malicious or not, as long as it is under my control, I’m fine with it.

You might disagree and that’s totally fine, but all I’m saying is that if you trust that it is not malicious (eg your own code) there is nothing wrong about running it as root.

[Kresimir]

@peciwov

all I’m saying is that if you trust that it is not malicious (eg your own code) there is nothing wrong about running it as root.

But that is wrong. Lack of trust is not the primary reason we don’t generally run GUI programs as root.

For example, I trust that Kate is not a malicious program. I generally have no problem typing my root password in a text buffer inside Kate (though, why would I ever do that is unclear, but for the sake of the argument). I would never run Kate as root, though.

Same thing with my own “keylogger”, obviously, I trust it because I wrote it. It won’t steal my passwords and send them to some evildoer. Still, I don’t want to run it as root.

[ntp]

Why the condescending tone, though?

[thereillywriter]

I do not have particular accessibility needs and Wayland works just fine for me. However, Wayland has been noted to break Orca, on screen keyboards and other basic accessibility tech. There is an observed pattern of patches implementing temporary fixes, followed by updates overriding those patches.

I do not interpret anything @Kresimir says as telling other people not to use Wayland, but rather frustration at having his workflow disrupted. He simply does not want X to be phased out until Wayland is able to deliver to meet his use case - which is a reasonable position to take. I also think he is right to be sceptical that Wayland will ever be able to meet his use case based on its past performance.

[peciwov]

I see the point you are making and it makes sense, I can’t argue with that. I agree.

At the same time though, don’t you see why “most” would prefer a keylogger functionality to be as close to impossible (realistically, as inconvenient) as possible to get working?
Again, I’m only discussing this specific example, nothing more.