-
Notifications
You must be signed in to change notification settings - Fork 12
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
Comments
@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? |
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 👍 |
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! |
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. |
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. |
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: |
This was a cool concept, but AI noise suppression is much better now and just works. |
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:
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)
The text was updated successfully, but these errors were encountered: