Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hushboard doesn't work with Wayland #13

Open
stuartlangridge opened this issue Jan 11, 2021 · 7 comments
Open

Hushboard doesn't work with Wayland #13

stuartlangridge opened this issue Jan 11, 2021 · 7 comments
Labels
help wanted Extra attention is needed

Comments

@stuartlangridge
Copy link
Owner

Not sure if it's the same error, but in my case it only seems to work on certain applications (Wayland vs Xorg). We should probably adapt the software a little to get the keystrokes from both environments.

To reproduce the issue, you can use my setup:

  • Arch Linux
  • Sway
  • Firefox
  • Alacritty

Then open an alacritty terminal (wayland) and the Firefox browser. Start to type on the terminal and then try on Firefox.
Result: keystrokes on Alacritty (Wayland) are not detected, thus the microphone is not muted. Keystrokes on Firefox (Xorg) are detected and the microphone is correctly muted.

Originally posted by @denysvitali in #6 (comment)

@stuartlangridge
Copy link
Owner Author

@denysvitali I can certainly confirm that Hushboard doesn't work in Wayland; I don't believe it can work in Wayland, and it doesn't attempt to. Am I right in thinking that you are running some sort of a mixture of Wayland and X, so that Hushboard does work when you press keys in X apps?

@denysvitali
Copy link

That's correct! Wayland input is not detected, but Xorg is. By looking at the source code, this is an expected behavior since only Xorg is handled.

I've also tried to fix the issue myself by adding a Wayland client using pywayland, but I didn't succeed: I don't think I'm able to fix the issue myself, but at least I understood the cause 👍

@stuartlangridge
Copy link
Owner Author

Wayland being architected differently, I am not sure it is possible at all for one application to see keypresses of another (and note that Hushboard doesn't need to see what the keypresses are, just that there were some). So I don't think this can be fixed, but I may be wrong on that; I'm not running Wayland myself so I can't tell. I'll leave this issue open for now rather than WONTFIXing it because if I'm wrong perhaps someone else can contribute a Wayland patch!

@stuartlangridge stuartlangridge added the help wanted Extra attention is needed label Jan 11, 2021
@bluelightzero
Copy link

Wayland is not comparable to X.org.

X is the server, but Wayland is just a protocol that servers (known as compositors under wayland) can use to talk to clients. There is no wayland process.

When using a wayland compositor, you can start up something called XWayland which runs what is basically an X Server and sends any X commands from X clients to the current wayland compositor. Keypress listeners can ask Xwayland for key presses, But if an application is a wayland client then it will skip past this.

If you want to support wayland, you should be looking at the APIs for each popular desktop environment (gnome, kde, ect) to see if they allow it. They may share a common library for handling this which is ideal. I don't know of one. They might not even be one.

Will get back to you, because I really want this on wayland.

@bluelightzero
Copy link

This might actually help make this work: https://www.codedbearder.com/posts/writing-keyboard-remapper-wayland/

Apparently a work around is to get exclusive access to a keyboard, then create a virtual keyboard that echos the input.

@nekohayo
Copy link

Maybe the only way you could achieve this is to somehow plug onto whatever mechanism GNOME Settings / GSD / libinput uses to disable touchpads while the user is typing? At least that works on Wayland, because it's a built-in core feature, but you'd have to talk to GNOME folks to figure out if there might be any way to tap into that. The only hint I have is that the feature is globally controlled by this hidden dconf key: org.gnome.desktop.peripherals.touchpad disable-while-typing true

@bluelightzero
Copy link

This was a cool concept, but AI noise suppression is much better now and just works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants