i’ve been experiencing this issue all the way since the very beginning of when plasma 6 first came out and it is extremely frustrating. i opened up a couple threads on other websites like reddit and there’s a ton of people in the same situation i’m in and we’re all looking for an answer. this is a wayland exclusive issue and for certain actions you do for example try to use teamviewer remote desktop from your phone to your linux computer each and every single time you try to connect it will pop up a very annoying box saying remote control requested each and every time! it defeats the purpose of unattended access because someone needs to press that button on the server side every time making it impossible to access a remote server. there’s a handful of other devices that trigger this box as well including playstation controllers and steam when you try to press the playstation button as well as an analog or a cord button command which would pop it up even on top of your games and it won’t go away and the controller will stop working until you press okay and the worst part is it also does not remember that you clicked the ass for an about 5 to 10 minutes or so it will ask you again if you click the button. this is crippling the experience is there any way we can get around this? i’ve tried multiple things such as adding myself to various groups in linux such as the control group and whatnot and nothing seems to work.
TL;DR: This popup is like finding a cockroach in your food.
I created an account here just to be able to expand on this with my own use cases:
-
I use an Apple trackpad to remote control my browser as well as things like VLC. Since an authorization lasts only a couple of minutes, pretty much every time I want to perform an action, I need to go through the unnecessary hassle of OK’ing this useless-at-best popup.
-
I play games using Steam on my machine. Except, with this popup, that has been made all but impossible. The popup literally breaks the gaming experience as my wireless gamepad just stops working after a little while.
Conclusion: I don’t know whose idea this popup was, but it wasn’t a good one. It adds a lot of negatives, but in the positive column is… What exactly? And please don’t say security because that is an illogical line of reasoning at best, and an irrational one at worst: too much security undermines itself because users get tired of the tedium and try to find ways around it, if necessary by removing security altogether.
Before adding a major annoyance like this, that needs to be given some thought. And I have trouble seeing here how that could have possibly been the case with this popup.
Making all this worse is that there is no affordance to just perma-OK the things I need to work, or otherwise just tell this popup to shut the hell up.
There are settings for almost everything else, why is this taking literally more than a year to get done, for a patch that should be 30 minutes at most for a KDE dev?
@ngraham you’re pretty much the only one I know by name that could do something about this. Would you please take a look at this? Fixing this is higher value than a lot of other things I can think of. If necessary I’m willing to pay some reasonable amount for it, let’s say US $100?
from what i gather at the moment, wayland’s security protocol is blame. BUT i also use kde connect to make my phone act as a mouse and keyboard and guess what? I is NOT effected by the issue! once you say yes ONCE you NEVER have to click it again. so it IS possible to save the permissions somehow. its even persistent beyond reboots
as soon as i open kde connect mouse it just says at the top
"remote control session has started
An application requested access to:
- Input devices "
all we need is a way for ANY app to have unattended permissions.
I agree with all of it.
The problem is, it’s been an issue for about a year and a half now, it’s easy to find posts from June 2023 strewn around the web talking about this very same issue.
And if it is indeed a Wayland protocol issue, then I find myself souring on Wayland more and more, even as it has become more functional over the last couple of months:
At its very core the whole thing moves like a tectonic plate while that’s needed is a development velocity more akin to a cheetah, or Facebook (except without the “and break stuff” part). If the protocols are at fault, then the obvious solution is to dispense with the security theater and just fix them already, after which the various Wayland compositors can actually do something with them. I’ve seen huge committees (as in design-by-comittee, think the likes of IEEE, the Wifi consortium etc) move faster than this.
This protocol still not being fixed then points to a more fundamental issue with the manner in which Wayland protocols are developed, and I don’t know how and whether that can be fixed. It also doesn’t bode well for the future, as the most likely thing to happen is stagnation (except for Valve, they seem to be able to get things done when it comes to Wayland protocol development, as seen not too long ago with nvidia and explicit sync).
It should also be noted that for Bluetooth input devices in particular, this popup doesn’t actually provide any security at all: the real security there comes from the necessity to pair devices, which means OK-ing that pairing on each of the 2 devices. What could a popup possibly have to add on top of that, other than irritation?
Lastly, while I’d love to back to Xorg for now, bit rot has set in and that has made it pretty much unusable for the same use cases that worked just a year ago. So sadly that’s not even an option anymore.
im too spoiled to go back to xorg, i traded my 3090ti for a radeon 7900xtx just to get the best wayland experience. And on top of that fedora is no longer including xorg these days so that means you have to set it up yourself if you want it. the last time i tried to restore xorg i got a lot of little funny issues that remained even after i removed it again. for what its worth even gnome is having a similar issue. but my point is that if kde connect can work flawless they can implement that to other apps.
We’re aware that this can be painful, and it’s being worked on. See Draft: implement a secondary permission system (!326) · Merge requests · Plasma / KDE Portal for XDG Desktop · GitLab
I too am completely sick of every 15 minutes being kicked out of a game to answer a dialog that should never have been implemented.
Been using KDE for 10 years and have seen many poor design choices and lived through them because there was a workaround. This is unacceptable!
There seems to be a solution but the examples are unclear, I dont use any flatpack’s, dont like them dont use them. Is this a solution for just flatpacks?
I just want to be able to play a game in peace and with every update this keeps getting worse!
I also wonder about that Flatpak solution. I don’t really use Flatpak too often. Is this fix exclusive to Flatpak, or is it just going to be pushed through all of the packages once it’s done?
My opinion is that this shouldn’t involve flatpak at all. For example, I use NixOS, and there, if I’m being very generous, flatpaks are completely superfluous.
It’s also true that everything else is set up and works already, so “just use a flatpak” ain’t gonna cut it anyway.
No, what is needed is a clean, KDE-only solution, no flatpak involved at all.
Hi - the second half of the merge request linked above describes using the flatpak CLI - but if I’m reading all that correctly, that’s simply because that’s where the permission-set command and back-end database are already built to provide the XDG permission store that’s being used.
A lot of the xdg-desktop-portal technology is built under the Flatpak project as a requirement for fulfilling how Flatpaks are designed to function, but it’s not necessarily bound to only work for them.
A lot of the xdg-desktop-portal technology is built under the Flatpak project as a requirement for fulfilling how Flatpaks are designed to function, but it’s not necessarily bound to only work for them.
Yes, exactly!
Portals aren’t really tied to Flatpak, it is just that the Flatpak effort has created the necessary momentum to provide these kinds of cross-desktop APIs.
Things like these have been done before. Some succeeded and some faltered.
For example launching a user’s preferred PDF viewer for a given PDF file.
GNOME, KDE and others have had APIs for that from their very early times one but they were usually desktop specific.
Almost 20 years ago a couple of developers (including myself) started working on a first attempt of a “unified API” in the form of wrapper scripts called xdg-utils.
Any third party application, e.g. Firefox, could simply call xdg-open with the PDF file and it would delegate to the desktop specific command line tool which would then use the desktop specific API to actually launch the PDF viewer.
This was a lot of work and was always meant to be a stepping stone towards actual API.
An earlier attempt to do just that, called “DAPI” (Desktop API) , unfortunately faltered for various reasons.
Fortunately the concept (D-Bus API with desktop specific implementations) has now been picked up by the Portals effort sees a lot of momentum on all fronts: API specification side, desktop/service implementation side and application side.
To get back to our example: additional to xdg-open any application can now also just call a (D-Bus) function.
Unlike xdg-open, this will work regardless of whether the application is sandboxed or not. From my point of view this is more like a bonus 
OK, good to hear that at least something is being done about it. But what does that mean for the problem in general? Is there a concretely usable GUI-level solution in the works that Is divorced from the flatpak tooling? Or hasn’t that been decided yet?
Not a developer myself, but I would generally assume that the features of, and methods of accessing, the back-end capability (what that merge request is for) need to be in-place before folks could start really building graphical interfaces for it.
Despite it being accessed via the flatpak CLI tool, I wouldn’t necessarily say it’s “flatpak tooling” though, if that implies all the other container/ostree-related parts - it’s just implementing XDG specs. The part of Does Wayland really break everything? – Adventures in Linux and KDE about portals and the “platform” feels at least conceptually relevant here.