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.
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.
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 
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.