search

houmain / keymapper

A cross-platform context-aware key remapper.
GNU General Public License v3.0
260 stars 22 forks source link

Wayland support #24

Closed mfinelli closed 2 years ago

mfinelli commented 2 years ago

I love this project and it works perfectly for me under xorg. But I'm wondering if you're planning to support wayland? (I recently upgraded and now GNOME uses wayland by default)

I thought that there might be some problems because of some of the new security features of wayland, but this project https://github.com/sezanzeb/input-remapper/ claims to work with wayland (thought it's written in python, not fast C++) although I haven't tried it yet

If you're interested in adding wayland support I'm happy to help by providing debug time or logs or anything else that would be useful but unfortunately programming in C++ is not in my skillset

houmain commented 2 years ago

I did some research and think that this is what is needed for detecting the focused window (the rest is display server agnostic): https://github.com/jlindgren90/wlroots/blob/master/examples/foreign-toplevel.c . I compiled the example (foreign-toplevel.zip) and tested it with sway and it worked. I could not get gnome/mutter running yet...

mfinelli commented 2 years ago

I'm running gnome/mutter, can you give the the compilation steps to compile and I'll try it out too? (I'm assuming the point is that if it works then you can implement the same thing into keymapper)

houmain commented 2 years ago

I tried it out in gnome now but unfortunately it did not work. I saw that the keyd project achieves this by injecting a gnome-shell user extension. Maybe I can solve this similarly.

houmain commented 2 years ago

Good news, I found a nice solution. Currently one has to follow these steps:

I hope I did not forget anything.

mfinelli commented 2 years ago

@houmain I tested this out locally and it's working great for me! nice work and thanks for looking into this and for the quick turnaround!

FYI, once you publish a new tag with these changes, I'm going to update the keymapper package on the AUR to start publishing a split package gnome-shell-extension-keymapper so that someone can just install the extension with pacman instead of needing to copy the files into their local gnome shell extensions. (I've tested this locally and it works, I just need to wait until there is a tagged version to use).

Also, FYI, I changed the UUID in the prepare function of the extension to be more unique keymapper@houmain instead of just kaymapper. I don't know if you want to adopt such a change upstream, but most other gnome shell extensions seem to do something similar.

Cheers

houmain commented 2 years ago

Thank you for testing it and your suggestion - I made the extension uuid more unique. I think it is okay, to install the gnome-shell-extension unconditionally with the keymapper package. I committed the .desktop and systemd .service files too in the extra directory. Now everything can be installed using cmake --install. I updated your PKGBUILD to try it out. Maybe the package could also automatically enable the extension when gnome-extensions is available. Cheers!

mfinelli commented 2 years ago

Ok, I will not make a split package (although, personally on non-gnome machines I think it's cleaner to not install it if not necessary). In any case I think the ExecStart in the service file that you added either needs to respect the $DESTDIR or needs to at least be hardcoded with the full path /usr/bin/keymapperd.

houmain commented 2 years ago

Yes, it would be cleaner but I think it's easier to setup/document this way (especially for non-Arch-users).

Good catch, I deliberately removed the /usr/bin from the ExecStart to circumvent that problem (in my test it worked well). Do you think, that this is a security issue? I am afraid I can not generate the correct path in the cmake installation script. I could only hardcode it as you said or maybe the PKGBUILD could insert the correct path. What do you think? Thanks!

mfinelli commented 2 years ago

I updated the PKGBUILD, but there are a couple of issues (I could fix them in the PKGBUILD, but better to fix them upstream :))

The metadata.json is not valid (looks like you have some extra/missing trailing commas -- interestingly even after fixing them if I pipe the metadata to jq it complains as invalid, I'm not sure what that's about)

The gnome shell extension needs to be in usr/share/gnome-shell/extensions/keymapper@houmain not usr/share/gnome-shell/keymapper.

Cheers

houmain commented 2 years ago

Sorry, I should have tested it. Now it should work.

Cheers