Bug 394529

Input remapping would need to be implemented in KWin for Wayland.

There has been a GSoC project last year writing a GTK based ui for configuring gaming mice in libinput. Don't know if it got merged into GNOME or what's the current state is:

https://www.hjdskes.nl/blog/gsoc-part-15/

Might be worth a look for inspiration at least.

Conceptionally this is wrong in KWin. Kglobalaccel should learn about mouse shortcuts instead.

You mean KHotkeys? KGlobalAccel doesn't emit fake input events to applications, as far as I know.

(In reply to Christoph Feck from comment #4)
> You mean KHotkeys? KGlobalAccel doesn't emit fake input events to
> applications, as far as I know.

On Wayland we will never emit fake input events. The only possible things are global shortcuts going over dbus and that's exactly what kglobalaccel does.

That does not help applications expecting a mouse click. If I understand you correctly, KDE cannot offer central customization; it has to be handled by each application individually.

So, to what should I reassign this? Or should I open a new bug to change the KGlobalAccel API, or systems settings can already make use of the API for mice as well?

Changing KGlobalAccel won't help, it cannot generate mouse clicks, it only sends D-Bus messages to applications when you press the global shortcuts. Those D-Bus messages are then translated to QAction triggers. As I said, it won't help for applications that need QMouseEvent.

If libinput doesn't allow plugins to generate fake input events (or remapping input events), then either the Qt toolkit would need to be expanded (very unlikely to happen, because Qt developers stay away from any type of configuration), or the applications need to handle it.

Understood, there's no maintainer for libinput configs ( http://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-lot-of-config.html ) and button remapping is still a big showstopper for default wayland on KDE.

However, seems that there's already a deamon available https://github.com/philipl/evdevremapkeys

Any plans to utilize sth. like this to offer some customization options in the settings?

(In reply to sac from comment #9)
> Understood, there's no maintainer for libinput configs (
> http://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-lot-of-config.
> html ) and button remapping is still a big showstopper for default wayland
> on KDE.
> 
> However, seems that there's already a deamon available
> https://github.com/philipl/evdevremapkeys
> 
> Any plans to utilize sth. like this to offer some customization options in
> the settings?

You can use this, but we won't add anything which utilizes this or encourages to use it. This is a huge security risk and thus is unsuited for a secure Wayland session. One of the biggest security issues of X is the possibility to generate fake input events.

OK, we need a proper solution. 

Apart from security, evdevremapkeys & xbindkeys don't work for productive use (GTK apps like Thunderbird remap input events, one has to click several times to trigger an action after another window had focus; totally messed up).

Libinput pointed back to DE & Toolkit ( https://gitlab.freedesktop.org/libinput/libinput/issues/44 ).

This affects basically every user and we expect from them to reprogram Kernels if they want to remap sth. properly :( Does noone have good connections to QT, which I guess is our last option here?

I think this is overall a wish which is just too complex. Peter's answer in the libinput request is really good. You need to change all toolkits and all compositors to support this. But changing the toolkits won't be sufficient. Even the toolkit doesn't have enough information. For a browser it is obvious where a close tab action should go to. But what to do if you have Kate in split screen with multiple tabs and maybe a Konsole window with tabs. Then you have three tab bars, where should the action go? No toolkit will be able to answer such a question. The toolkit developers will notice such issues and thus not add a general solution.

And then we are back to interact with each application. As I said in my first reply: global shortcut triggering is pretty much the only possibility I can think of.

>As I said in my first reply: global shortcut triggering is pretty much the only possibility I can think of.

Got you now & renamed the bug. That solution would be perfect. @Christoph Feck GS wouldn't have to genereate mouse clicks in that case. It would just have to learn to accept those as input / trigger. In addition, the option to assign a shortcut to several actions would be great.

(Maybe libinput can later cover at least the mousewheel as doubleclick case, that would help in 90% of the cases).

Why are you reopening this ticket? How would a global shortcut help an application that expects mouse events to open a context menu or execute a double-click action? Global shortcuts already work, and you would have to change the application to either handle those shortcut events, or you would have to change the Qt toolkit to transform those into mouse events.

This will not be fixed in KWin, according to its developers.

>Why are you reopening this ticket? How would a global shortcut help an application that expects mouse events
>This will not be fixed in KWin, according to its developers.

I think you're not getting the idea here. Forget about mouse events (no mouse events in this bug report). The suggestion of the developers was to adjust global shortcuts.

Currently Global Shortcuts shows the following tooltip:
"Click on the button, then enter the shortcut like you would in the program. 
Example for CTRL+A: hold the CTRL key and press A."

Instead the tooltip should say:
"Click on the button, then enter the shortcut like you would in the program on your keyboard or mouse. 
Example for CTRL+A: hold the CTRL key and press A.
Example for righ mouse button: press the right mouse button.
"

In addition, the option to assign a shortcut to several actions would be great.

(yes, I know, just changing a tooltip is only 5% of the work, but maybe this explains it better. BTW: there are keyboards with a button for a mouse context menu. So even a mouse context menu can be triggered, if there's an action for this KEYBOARD BUTTON. Again: no mouse events here, but I'm able to customize my mouse and am even able to call batch sripts or programs [that might trigger mouse events, ugh forget that])

Let's set it back to wontfix as that is the correct state from KWin perspective. Moving this feature request to kglobalaccel doesn't make sense as there is too much unrelated discussion in it.

For people coming here through google, the proper bug seems to be this: https://bugs.kde.org/show_bug.cgi?id=171295