Wayland autotype implementation (using xdg-desktop-portal) by FuZzledd · Pull Request #10905 · keepassxreboot/keepassxc

FuZzledd · 2024-06-15T21:29:26Z

This is a work-in-progress attempt to implement auto-type on Wayland, using the RemoteDesktop portal. Caveats currently include:

Requires to have a desktop portal installed that supports the RemoteDesktop portal (xdg-desktop-portal-kde, xdg-desktop-portal-gnome, xdg-desktop-portal-luminous)
Global shortcuts aren't implemented (and trying to set one in the auto-type tab will crash), but I've added a D-Bus method which should make it fairly easy to bind a shortcut to request a global type in your DE
Window detection isn't implemented, as there's no cross-platform way to do this on Wayland currently, but could be done in the future for some platforms (i.e. wlr-foreign-toplevel-management, KWin scripts, etc.)
As a consequence of the last point, activation of foreign windows isn't possible, so typing occurring in the correct window relies on it being automatically activated when the application window is deactivated
A RemoteDesktop session is started when the plugin is loaded (on application launch), and the restore token isn't persisted, so it will ask every time. Ideally, a session would only be started when you request an auto-type, and would be closed when done, and the token persisted in the database, but this would need a couple changes to the how the autotype plugins work I think, so I've not touched that yet.

All testing so far I've done on KDE Plasma 6.1, and the core functionality seems to work great there. Testing other platforms is a bit annoying to do, so I'd appreciate people trying it and giving feedback

Screenshots

Testing strategy

Type of change

✅ New feature (change that adds functionality)

droidmonkey · 2024-06-15T22:57:34Z

Geez sure is nice when you don't have to muck with emulated key presses! I wonder if we could use this same method for X11 as well, do you know?

FuZzledd · 2024-06-15T23:04:00Z

Geez sure is nice when you don't have to muck with emulated key presses! I wonder if we could use this same method for X11 as well, do you know?

Technically it should, as long as there's a desktop portal running that works on it, so I have a feeling KDE and GNOME would, but I don't think there's a generic portal that supports RemoteDesktop for other X11 WMs.

Also, it is very nice I can just chuck keysyms at it without worrying about reversing keymaps and whatnot :)

droidmonkey · 2024-06-15T23:12:38Z

Worth a try to see if that fixes some of our awkward issues with international keyboard layout.

hifi · 2024-06-16T03:12:01Z

Very nice, I will give this a spin!

hifi · 2024-06-16T06:10:15Z

Applied a small patch to build on Debian bookworm and to fix some assumptions about a window title existing and the shortcut crash and to disable minimize behavior if the main window is inactive, didn't test X11 still works: https://gist.github.com/hifi/e32c03f7b131cfc9e2d38c1ca11764fe

I registered this command with KDE to perform globally: dbus-send --session --type=method_call --dest=org.keepassxc.KeePassXC.MainWindow /keepassxc org.keepassxc.KeePassXC.MainWindow.requestGlobalAutoType

Good work! I will stay on Wayland for now as this implements everything I need. Just needs some cleanups.

Zahrun · 2024-06-16T09:47:06Z

Thanks @TheConfuZzledDude for the PR
Thanks @droidmonkey for all the work on KeepassXC
Thanks @hifi for the patch

I was able to build this branch on my Tuxedo OS 3 (Plasma 6.0.5) after applying @hifi ’s patch.

If I perform AutoType from the KeePassXC window, that one does not get minimized. That is due to the && qApp->activeWindow()) added by @hifi . Works fine once reverted that line.

Assigned a global keyboard shortcut to dbus-send --session --type=method_call --dest=org.keepassxc.KeePassXC.MainWindow /keepassxc org.keepassxc.KeePassXC.MainWindow.requestGlobalAutoType in Plasma, that’s pretty sick, just need to press the shortcut, type the name of the entry, select it, and it will autotype.

The only issue I’m having is that when I switch keyboard layout, the autotype changes. On my default fr oss layout it types correctly. Changing to fr bepo_afnor or us intl types wrong characters. It is actually pressing the same keys on the keyboard, but now they have different characters.

hifi · 2024-06-16T11:05:17Z

My bad about minimizing not working as I didn't test it properly. The intention was to not minimize the main window on global auto-type if the main window isn't the active window (aka entry auto-type).

Also it's a bit funny keyboard layouts are still an issue as they are a nightmare on X11.

FuZzledd · 2024-06-17T21:13:20Z

Thanks @TheConfuZzledDude for the PR Thanks @droidmonkey for all the work on KeepassXC Thanks @hifi for the patch

I was able to build this branch on my Tuxedo OS 3 (Plasma 6.0.5) after applying @hifi ’s patch.

If I perform AutoType from the KeePassXC window, that one does not get minimized. That is due to the && qApp->activeWindow()) added by @hifi . Works fine once reverted that line.

Assigned a global keyboard shortcut to dbus-send --session --type=method_call --dest=org.keepassxc.KeePassXC.MainWindow /keepassxc org.keepassxc.KeePassXC.MainWindow.requestGlobalAutoType in Plasma, that’s pretty sick, just need to press the shortcut, type the name of the entry, select it, and it will autotype.

The only issue I’m having is that when I switch keyboard layout, the autotype changes. On my default fr oss layout it types correctly. Changing to fr bepo_afnor or us intl types wrong characters. It is actually pressing the same keys on the keyboard, but now they have different characters.

You know I really would hope that the desktop portal would be able to query the keymap correctly, but I guess not. I think that using libei would allow getting the actual current keymap (from reading through the KWin code, it seems like it would there at least). I have a branch locally where I started implementing it with EI, but it's sooooo much more of a hassle, and KDE doesn't actually support it until 6.1 is released (they say they implement v2 of the protocol but they don't :P), and I ran into issues where the keymap FD they were providing was perpetually invalid after the first time.

So I'd rather stick with this and maybe drop a question to the portal maintainers about whether they should be querying the current keymap when we request a keysym (or if we should do the exact same reverse mapping just with 200% extra effort)

droidmonkey · 2024-06-17T21:43:44Z

We should absolutely be pushing this onto the portal maintainers to handle. Direct query of the keymap or have them align the key maps accordingly between apps. I say keep current implementation and caveat that it only applies to keymaps that are largely US layout based.

FuZzledd · 2024-06-17T22:21:37Z

@Zahrun If you'd like a workaround for now, you can set up keyboard shortcuts in the KDE settings to switch layout to a default pc105 keyboard layout, and one to switch to the previous layout. Then, set the default auto-type sequence for your group to press the respective shortcuts

hifi · 2024-06-18T04:23:11Z

I've been using this for a couple of days now and it's been working very well in practice with the known caveats.

@TheConfuZzledDude Regarding keymap, does it make a difference if you start the remote desktop portal at the time of starting Auto-Type? If it helps then we could make it do the initial authorization for remote desktop on startup but immediately close the portal so that it can reopen it on demand to use the current keymap.

Zahrun · 2024-06-18T05:45:27Z

@droidmonkey I also think that the layout management issue should be raised on the desktop portal side.

@TheConfuZzledDude thank you for the workaround suggestion. I have a lot of custom auto-type sequences, so I prefer to switch layout, then do the auto-type, and then switch back manually. I'm actually currently using a script to do that with KPUInput in KeePass2 in mono. I'll adjust it to work with your implementation in KeePassXC. I hope one day the autotype will work with any layout configuration.

@hifi In my experience, it does not matter in which layout I am when starting the portal. It seems to be always using fr oss, which is the layout I have in SDDM and in the ttys. It's not even the first layout in the layout setting list inside Plasma.

EDIT: I am able to reproduce the keyboard layout issue with KDE Connect when typing from my Android device to the Plasma desktop, through xdg-desktop-portal, the keyboard layout issue is also happening.

Zahrun · 2024-06-23T05:43:08Z

I created an issue on the KDE side for xdg-desktop-portal-kde at https://bugs.kde.org/show_bug.cgi?id=489021

FuZzledd · 2024-06-25T22:40:42Z

I created an issue on the KDE side for xdg-desktop-portal-kde at https://bugs.kde.org/show_bug.cgi?id=489021

Thanks! I was thinking of doing that myself, but I think I might post it on https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues because it seems more active for the desktop portal

Regardless, I'm going to try and clean this up a bit in the next week

Zahrun · 2024-06-26T09:36:07Z

I opened the issue on bugs.kde.org due to the following guideline.

Please note that all bug reports and feature requests should be filed on [bugs.kde.org](https://bugs.kde.org/) and should never be raised here.
For support with KDE software, it is recommended to post on [KDE Discuss](https://discuss.kde.org/) instead.

Issues on KDE Invent are used for tracking ongoing work and are for the use of contributors and developers only.

Users are asked to consult with a developer or other contributor prior to opening issues here, and where in doubt recommended to open them on bugs.kde.org instead.

Apart from that, I have a suggestion for the feature. Currently, when we open KeePassXC, it directly asks for Remote Control permission. New users might get confused by that. I think it would be good to display a message "We will ask for permission, this is for autotype feature". Or even give the option yes/no. Or probably best, ask for permission only if the user asks for an autotype to be done. And then keep the token.

hifi · 2024-06-26T11:32:19Z

Apart from that, I have a suggestion for the feature. Currently, when we open KeePassXC, it directly asks for Remote Control permission. New users might get confused by that. I think it would be good to display a message "We will ask for permission, this is for autotype feature". Or even give the option yes/no. Or probably best, ask for permission only if the user asks for an autotype to be done. And then keep the token.

It could just request the remote desktop portal when being triggered and then keep it open after that until next restart. There's no need to open the portal at all if the user never uses auto-type. That's very likely for a lot of people who mostly only use the browser integration.

michaelk83 · 2024-06-26T15:24:09Z

@TheConfuZzledDude I think your input is needed at https://bugs.kde.org/show_bug.cgi?id=489021 :

Can you show where the bug is in our portal implementation? And maybe also update the title to describe the problem more fully?

michaelk83 · 2024-06-26T21:29:46Z

Btw, does the desktop portal specification specify how it should deal with different keyboard mappings? If not, then this should be brought up with them as well. Otherwise, you'll have to chase each DE to get them to do what is needed.

FuZzledd · 2024-06-27T21:22:25Z

@TheConfuZzledDude I think your input is needed at https://bugs.kde.org/show_bug.cgi?id=489021 :

Can you show where the bug is in our portal implementation? And maybe also update the title to describe the problem more fully?

Just commented, found where the issue was, depending on how fast I get through the rest of this, I may go fix it myself if it's not by the time I'm done

Btw, does the desktop portal specification specify how it should deal with different keyboard mappings? If not, then this should be brought up with them as well. Otherwise, you'll have to chase each DE to get them to do what is needed.

Not really, the remote desktop documentation is kinda sparse apart from what's implied from the method name. I did some research, and it seems like the protocol was defined for/based on Mutter's remote desktop portal, so I think that's probably the "canonical" behaviour

Apart from that, I have a suggestion for the feature. Currently, when we open KeePassXC, it directly asks for Remote Control permission. New users might get confused by that. I think it would be good to display a message "We will ask for permission, this is for autotype feature". Or even give the option yes/no. Or probably best, ask for permission only if the user asks for an autotype to be done. And then keep the token.

It could just request the remote desktop portal when being triggered and then keep it open after that until next restart. There's no need to open the portal at all if the user never uses auto-type. That's very likely for a lot of people who mostly only use the browser integration.

That is the plan, but there's a few issues to work around, and might require changing the autotype plugin behaviour in general. When you start a remote desktop session you get a restore token that can be used to restore the session without prompt in the future, and this could be retained between launches as well. The question for that then is whether you should only be prompted the first time ever, and if so, where should the restore token be stored? I guess it should be kept secure since another program could steal it and silently start controlling your inputs or something, but that means probably storing it in the database which seems kinda meh.
Also, starting the session only when the user requests an autotype has some issues too, since the way it works, as soon as they close the dialog it'll start typing, regardless of what window is now active, or how much time has passed. So I guess database unlock/auto-type being enabled would be more appropriate, but I'll need to add those to the plugin interface

droidmonkey · 2024-06-27T21:40:26Z

I like the idea of one-time ask (after first database unlock maybe) and store the token in the database. A new database requires a new token. This would emulate the behavior of the browser plugin.

The downside would be if you used your database on multiple Linux wayland boxes. So you may need to add the computer name to the token storage key.

badsmoke · 2024-09-18T06:43:02Z

is there any progress here? can i help with testing?

Zahrun · 2025-01-12T16:01:24Z

Nicolas Felas from KDE is proposing a solution for the support of multiple layout in the portal at https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/342 which would send the keysym instead of the key code.

Apollo3zehn · 2025-02-20T21:01:55Z

I am on KDE Plasma 6.3.1 (EndeavourOS) and tested this pull request as it became quite annoying on Wayland to manually search for passwords and I just wanted say that it works great!

I did not apply any patches. Minor issues that remain are:

This window pops up once after boot because I am autostarting KeePassXC:
Creating a global shortcut for the above mentioned dbus command was a hassle because KDE seems to be buggy right now in that regard. The option to run a command or launch a script (marked in red) does not work. I had to manually create a .desktop file and create an "Application" shortcut (the green one) to make it work.

As expected the current window title is not extracted and so I have to search to find the right entry in the popup but that is still a huge improvement compared to the status quo.

So thanks for the great work so far and hopefully the missing pieces will be provided on Wayland side soon.

minortex · 2025-05-12T13:21:19Z

I am on KDE Plasma 6.3.1 (EndeavourOS) and tested this pull request as it became quite annoying on Wayland to manually search for passwords and I just wanted say that it works great!
I did not apply any patches. Minor issues that remain are:

1. This window pops up once after boot because I am autostarting KeePassXC:
   ![grafik](https://private-user-images.githubusercontent.com/20972129/415363505-6366587f-96d0-4b4b-8d48-0f64b2bf7b4a.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDcwNTQyMTQsIm5iZiI6MTc0NzA1MzkxNCwicGF0aCI6Ii8yMDk3MjEyOS80MTUzNjM1MDUtNjM2NjU4N2YtOTZkMC00YjRiLThkNDgtMGY2NGIyYmY3YjRhLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA1MTIlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwNTEyVDEyNDUxNFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTE5MmYwZjExMzNkZjk4MTg5NWY1Yzk5MDg2MmUyZDI3OTYxNzZjZTcxZDEzOWNmMzZhYmJhOGVjZTc0ZDhkZDQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.6caS4eqb80QdtYkO7WEF1PSx7bA5FK7n5jlA4PTqDeY)

2. Creating a global shortcut for the above mentioned `dbus` command was a hassle because KDE seems to be buggy right now in that regard. The option to run a command or launch a script (marked in red) does not work. I had to manually create a .desktop file and create an "Application" shortcut (the green one) to make it work.

3. As expected the current window title is not extracted and so I have to search to find the right entry in the popup but that is still a huge improvement compared to the status quo.

So thanks for the great work so far and hopefully the missing pieces will be provided on Wayland side soon.

I also test this PR and use it daily, it works well.

The command and script shortcut work for me, like the picture above.

Same I'm troubled because the "request to control" window pops up every time I start up, and I found no "trust always" button for it.

This PR has been so long and does well for wayland users, so why hasn't it been merged yet?

LazyStability · 2025-05-13T11:35:47Z

I have tried this pr, using dbus-send --session --type=method_call --dest=org.keepassxc.KeePassXC.MainWindow /keepassxc org.keepassxc.KeePassXC.MainWindow.requestGlobalAutoType on three platforms:

KDE works flawlessly
Hyprland, the window to search an entry appears, but it does not type, because the xdg-desktop portal does not implement the RemoteDesktop fully so that's to be expected. There seems to be some work there so I might come back to this
Gnome does not work, it does not even open the window to search for the entry like it did on hyprland. I have unfortunately no idea on how to debug the issue.

rsudev · 2025-05-15T12:21:19Z

I had this in the try also for quite a while already (needed a few adjustments to get it to build on my machine, see https://github.com/rsudev/keepassxc/tree/autotype-wayland-tryout, also rebased on latest develop) and it works well for me (with manual searching).
I think it would be a good first step to be released. Not having this in my prior attempts to use wayland on a day-to-day basis was a deal-breaker in the past.

michaelk83 · 2025-09-18T10:40:43Z

Nicolas Felas from KDE is proposing a solution for the support of multiple layout in the portal at https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/342 which would send the keysym instead of the key code.

The portal and KWin fixes just landed. Should be out with Plasma 6.5.

droidmonkey · 2025-09-20T12:58:47Z

Excellent, will pick this one back up

blitzdose · 2025-11-17T14:10:55Z

My issue #12693 got closed as duplicate of this. I don't think the idea is quite the same but I would still like to bring my idea into this discussion. Instead of diving into the autotype nightmare on wayland, it would be awesome if we could use the same little dialog that pops up to just copy the password/username instead of having it autotype. On X11 the shortcut for that was Ctrl+Shift+1 and +2 but the normal shortcuts (Ctrl+C for password and Ctrl+B for username) would be way better to use. Also, the dialog should close when copied the username or password.

I would test this PR but unfortunately I got the same issue as @LazyStability under Debian Testing + GNOME. Just nothing happens when sending the d-bus message. If I can somehow provide logs for this issue just tell me.

droidmonkey · 2025-11-17T15:09:30Z

That is exactly what this PR does

blitzdose · 2025-11-18T20:02:38Z

+    if (!m_inGlobalAutoTypeDialog.tryLock()) {
+        return;
+    }


This seems to be the error why the dbus message is not working in GNOME. I'm not that familiar with Qt but it seems like the code is trying to get a lock already in the if-statement before this one. Just removing these lines fixes the code for Gnome. However, I don't know if just removing it has other side effects

Confirmed, it still does not work in GNOME 49.

After removing " || !m_inGlobalAutoTypeDialog.tryLock()" from the first if statement it is working in Gnome 43. I'm able to invoke autotype with e.g.

dbus-send --session --dest=org.keepassxc.KeePassXC.MainWindow --type=method_call /keepassxc org.keepassxc.KeePassXC.MainWindow.requestGlobalAutoType string:"Google Account"

After removing " || !m_inGlobalAutoTypeDialog.tryLock()" from the first if statement it is working in Gnome 43. I'm able to invoke autotype with e.g.

dbus-send --session --dest=org.keepassxc.KeePassXC.MainWindow --type=method_call /keepassxc org.keepassxc.KeePassXC.MainWindow.requestGlobalAutoType string:"Google Account"

I removed this statement, but on cachyos + gnome 49 it won't trigger autotyping. On cachyos + KDE it behaves properly. I installed xdg-desktop-portal.

EDIT:
I commented out whole two first IF statements from performGlobalAutotype and it started working. Probably the second IF was returning immediately. Note: I'm not C++ dev at all, but I'm happy that I could get it working.

Zahrun · 2025-11-28T04:42:54Z

Nicolas Felas from KDE is proposing a solution for the support of multiple layout in the portal at https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/342 which would send the keysym instead of the key code.

The portal and KWin fixes just landed. Should be out with Plasma 6.5.

I upgraded to Plasma 6.5.2 and can confirm the autotype from this PR (commit bfb6e95) now works in any and every 3 keyboard layouts that I use 🥳

azagon63 · 2026-01-19T19:26:04Z

Confirmed working on Plasma 6.5.4 on Manjaro. I had to implement some of the fixes from comments on this PR (thanks @hifi and @blitzdose !), and include a build fix present in develop (#12634).

I also wanted to restore the window title matching behavior since using a search term is pretty limited. As mentioned, window title detection varies by DE, so I've hacked in a change for plasma using kdotool and put up my full set of changes on a fork: https://github.com/azagon63/keepassxc (diff, I'm not a C++ dev so its not pretty).

Thanks for the collaboration here, I'm glad to finally be able to daily drive wayland. Hope we can get more permanent changes into a full release 🎉

kaese · 2026-01-31T16:47:04Z

Confirmed working on Gnome 43 with current keepassxc develop, this PR and the fix mentioned in #10905 (comment) . Running dbus-send --session --dest=org.keepassxc.KeePassXC.MainWindow --type=method_call /keepassxc org.keepassxc.KeePassXC.MainWindow.requestGlobalAutoType invokes the auto type window to select the desired keepass entry for auto type.

kaese · 2026-02-09T05:39:40Z

One more thing I noticed after applying this PR: Since Wayland cannot read the window title, the autotype window displays a list of all possible AutoType entries, even expired ones. The Config::AutoTypeHideExpiredEntry setting is ignored.

This is because the else path is called in

keepassxc/src/autotype/AutoType.cpp

Line 442 in 5bd42c4

if (!m_windowTitleForGlobal.isEmpty()) {

which does not remove expired entries.

rsudev · 2026-02-21T13:49:13Z

Just these days, likely due to an update of my openSuse tumbleweed installation, the feature stopped to work, kind of.
It still autotypes, but special characters in passwords (in my case those requiring special modifiers on a german keyboard) do no longer lead to the desired input...

From my research, the current way of sending keysyms might be 'deprecated', but I failed to find real docs/examples on how to implement the 'typing' part 'correctly'.

stochmalm · 2026-02-25T14:41:37Z

Confirmed working on Plasma 6.5.4 on Manjaro. I had to implement some of the fixes from comments on this PR (thanks @hifi and @blitzdose !), and include a build fix present in develop (#12634).

I also wanted to restore the window title matching behavior since using a search term is pretty limited. As mentioned, window title detection varies by DE, so I've hacked in a change for plasma using kdotool and put up my full set of changes on a fork: https://github.com/azagon63/keepassxc (diff, I'm not a C++ dev so its not pretty).

Thanks for the collaboration here, I'm glad to finally be able to daily drive wayland. Hope we can get more permanent changes into a full release 🎉

I confirm this fork is working on my machine properly. I tried fresh install of Cachy OS + KDE Plasma. Thanks! Now I can start using wayland instead of X11 :).

EDIT:
I'm asked every time for special privileges, even if I mark 'remember' checkbox. It's probably a development build issue, but I can't solve that:

rsudev · 2026-03-05T06:34:15Z

Just these days, likely due to an update of my openSuse tumbleweed installation, the feature stopped to work, kind of. It still autotypes, but special characters in passwords (in my case those requiring special modifiers on a german keyboard) do no longer lead to the desired input...

From my research, the current way of sending keysyms might be 'deprecated', but I failed to find real docs/examples on how to implement the 'typing' part 'correctly'.

After more research I found indications of ibus-related problems. After removing ibus from my system, autotype works again as expected!

rsudev · 2026-03-05T06:36:53Z

EDIT: I'm asked every time for special privileges, even if I mark 'remember' checkbox. It's probably a developer build issue, but I can't solve that:

The 'remember' feature is not yet implemented.

Waqar144 · 2026-04-21T05:43:19Z

+    m_handlers.insert(requestHandle,
+                      [this](uint _response, QVariantMap _result) { handleCreateSession(_response, _result); });
+
+    m_remote_desktop.call("CreateSession",


This call can fail, its result should be checked/logged/notified to the user. E.g., error that I saw yesterday in my local build: Portal operation not allowed: Unable to open /proc/232113/root

Waqar144 · 2026-04-21T05:45:27Z

+    for (auto modifier : modifiers) {
+        m_remote_desktop.call(
+            "NotifyKeyboardKeysym", QVariant::fromValue(m_session_handle), QVariantMap(), int(modifier), uint(1));
+    }
+
+    m_remote_desktop.call(
+        "NotifyKeyboardKeysym", QVariant::fromValue(m_session_handle), QVariantMap(), int(keysym), uint(1));
+
+    m_remote_desktop.call(
+        "NotifyKeyboardKeysym", QVariant::fromValue(m_session_handle), QVariantMap(), int(keysym), uint(0));
+
+    for (auto modifier : modifiers) {
+        m_remote_desktop.call(
+            "NotifyKeyboardKeysym", QVariant::fromValue(m_session_handle), QVariantMap(), int(modifier), uint(0));
+    }


Any/All of the m_remote_desktop.call(...) can fail and should be handled

hifi · 2026-05-19T09:05:58Z

The work has moved to #13359, thank you @TheConfuZzledDude for the initial push to make this a reality.

FuZzledd mentioned this pull request Jun 15, 2024

Support Auto-Type on Wayland #2281

Open

droidmonkey added high priority 🚨 feature: Auto-Type platform: Linux - Wayland labels Jun 15, 2024

droidmonkey added this to the v2.8.0 milestone Jun 15, 2024

droidmonkey requested review from droidmonkey, hifi and phoerious June 15, 2024 22:53

github-advanced-security AI found potential problems Jun 15, 2024

View reviewed changes

Comment thread src/autotype/wayland/AutoTypeWayland.cpp Fixed

Comment thread src/autotype/wayland/AutoTypeWayland.cpp Fixed

michaelk83 mentioned this pull request Feb 19, 2025

Create Support Auto-Type on Wayland #11772

Closed

ljubitje mentioned this pull request Jul 20, 2025

keepassxc: Auto-Type feature not available NixOS/nixpkgs#94715

Open

FuZzledd and others added 2 commits September 20, 2025 09:13

Wayland autotype implementation (using xdg-desktop-portal)

23a42b8

fixes

79fe263

droidmonkey force-pushed the autotype-wayland-xdg-portal branch from fc1bd20 to 79fe263 Compare September 20, 2025 13:15

michaelk83 mentioned this pull request Nov 17, 2025

Alternative to autotype under Wayland ("Manual" autotype) #12693

Closed

1 task

blitzdose reviewed Nov 18, 2025

View reviewed changes

phoerious mentioned this pull request Apr 7, 2026

Auto-type is not available #13112

Closed

1 task

Waqar144 reviewed Apr 21, 2026

View reviewed changes

hifi mentioned this pull request May 19, 2026

Wayland Auto-Type with XDG Desktop Portals #13359

Open

droidmonkey closed this May 19, 2026

Uh oh!

Conversation

FuZzledd commented Jun 15, 2024

Screenshots

Testing strategy

Type of change

Uh oh!

droidmonkey commented Jun 15, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

FuZzledd commented Jun 15, 2024

Uh oh!

droidmonkey commented Jun 15, 2024

Uh oh!

hifi commented Jun 16, 2024

Uh oh!

hifi commented Jun 16, 2024

Uh oh!

Zahrun commented Jun 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hifi commented Jun 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FuZzledd commented Jun 17, 2024

Uh oh!

droidmonkey commented Jun 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FuZzledd commented Jun 17, 2024

Uh oh!

hifi commented Jun 18, 2024

Uh oh!

Zahrun commented Jun 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Zahrun commented Jun 23, 2024

Uh oh!

FuZzledd commented Jun 25, 2024

Uh oh!

Zahrun commented Jun 26, 2024

Uh oh!

hifi commented Jun 26, 2024

Uh oh!

michaelk83 commented Jun 26, 2024

Uh oh!

michaelk83 commented Jun 26, 2024

Uh oh!

FuZzledd commented Jun 27, 2024

Uh oh!

droidmonkey commented Jun 27, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

badsmoke commented Sep 18, 2024

Uh oh!

Zahrun commented Jan 12, 2025

Uh oh!

Apollo3zehn commented Feb 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

minortex commented May 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

LazyStability commented May 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rsudev commented May 15, 2025

Uh oh!

michaelk83 commented Sep 18, 2025

Uh oh!

droidmonkey commented Sep 20, 2025

Uh oh!

blitzdose commented Nov 17, 2025

Uh oh!

droidmonkey commented Nov 17, 2025

Uh oh!

blitzdose Nov 18, 2025

Choose a reason for hiding this comment

droidmonkey commented Jun 15, 2024 •

edited

Loading

Zahrun commented Jun 16, 2024 •

edited

Loading

hifi commented Jun 16, 2024 •

edited

Loading

droidmonkey commented Jun 17, 2024 •

edited

Loading

Zahrun commented Jun 18, 2024 •

edited

Loading

droidmonkey commented Jun 27, 2024 •

edited

Loading

Apollo3zehn commented Feb 20, 2025 •

edited

Loading

minortex commented May 12, 2025 •

edited

Loading

LazyStability commented May 13, 2025 •

edited

Loading

stochmalm Mar 6, 2026 •

edited

Loading

Zahrun commented Nov 28, 2025 •

edited

Loading

azagon63 commented Jan 19, 2026 •

edited

Loading

kaese commented Jan 31, 2026 •

edited

Loading

stochmalm commented Feb 25, 2026 •

edited

Loading

Waqar144 Apr 21, 2026 •

edited

Loading