-
Notifications
You must be signed in to change notification settings - Fork 116
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
Linux (Wayland): Simulating keyboard input crashes Labwc #356
Comments
Which features do you activate when using enigo (e.g |
FYI, my project is at controller-remap. It uses |
The examples directory doesn't have For
For
Once I comment out those lines, the mouse moves, clicks and drags as expected. No crash. |
With Rust, you can usually clone the repository and then run I can't see anything in these logs that would hint at what the problem is. Could you please run your program with the environment variables
|
It seems the
Immediately after the command, I can see an "a" character printed, and nothing went wrong. I could still move mouse. But whenever I click anywhere on the desktop, Labwc crashes. The log from Labwc was shown above. |
Thank you for the logs. That's weird. According to the output even |
I reran and verified that the "Hello World ..." indeed not typed. "a" is the only text typed. |
Does the keyboard "Squeekboard" work? It uses the same protocols. I am starting to suspect that labwc is doing something unusual. |
Squeekboard works fine. No crash on Labwc. It is the default OSK of Raspberry Pi. If it crashes Labwc, I think they would fix it before making the switch from Wayfire. If you need any log to debug, please let me know. |
I tried running Raspberry OS in a VM, but failed because it is only available as ARM. Does LabWC crash if you click after the letter was entered but before the program terminates? Maybe it has something to do with dropping the Wayland objects. I pushed the branch https://github.com/pentamassiv/enigo/tree/labwc for you to try it out. It only contains an additional sleep statement in the keyboard example. |
Unfortunately yes. I also added a sleep right after the Now the log for Squeekboard. I ran Squeekboard, click "p", confirm it is printed on screen, click desktop, no crash, then Ctrl-C. I can see that it is using the same
|
Thank you for the logs. Establishing the connection looks different. Maybe the error is even before trying to simulate input. Unfortunately this is just trial and error, but could you please run the keyboard example with all code that simulates any input removed? It should only create an enigo object and then terminate. If labwc crashes then as well, we can at least narrow it down to the start of the connection. I published another branch where I removed the virtual_pointer protocol and the kde_fake_input protocol just in case the problem was because of them. If labwc crashes even in the above described process, could you please do the same process I explained above with that branch to see if it helps? I think labwc should not crash even if enigo does something it doesn't expect. Maybe the labwc maintainers can help narrow down the issue and fix labwc to at least not crash. They likely know a lot more about wayland then I do as well and might be able to speed up the search for the issue. Please post a link to an issue if you decide to open one for their project as well. |
I got a raspberry pi and tried it myself. Labwc doesn't crash for me, but there's definitely a problem. I have yet to narrow it down. Modifiers don't work and every time I enter a letter, the terminal becomes unresponsive afterwards. The other windows continue to work though. Using the input_method protocol doesn't enter anything |
Wow, I hope I doesn't force you to buy something you don't need. I'll still get back to you with the tests. Since you got a Raspberry Pi yourself now, could you also give a shot to test the old Wayfire compositor? I remember enigo doesn't behave correctly for some keys there too, though the behavior is different (I remember simulating PageDown would minimize the current focused window). Of course, both could be linked to one root source. |
No crash. The log is similar to what posted above, just ended with
Still crashes. Still only "a" typed. Log:
|
Don't worry, the RPI was sitting in my drawer, eagerly waiting to get used. It just took some time to get it running. I did some more experiments here: https://github.com/pentamassiv/enigo/tree/wayland_fixes It's yet another new branch but I plan to merge these changes once the crash is fixed. So far, it's mostly refactorings to simplify the code. I also removed the Drop implementation. Now it seems to correctly destroy the objects. Apparently it is done automatically. When I now run the keyboard example without simulating anything, labwc no longer crashes. It does have a problem as soon as I enter a letter though. I guess it's progress though :) |
The issue is related to the input_method protocol. When I removed it, everything worked as expected (see this commit 7357f79). I thought that maybe the order of events was incorrect, but so far I didn't have any luck with it. Squeekboard binds to wl_seat first and gets the registry twice. Here is the output of the keyboard.rs example with the input_method protocol disabled:
|
Thank you. Please let me know if there is anything I could do to help. |
I created a draft PR to fix the many issues I found: #368 I won't have time to continue with it for the next days/weeks though. The hopefully last blocking issue is that the keycode that gets sent to the compositor via virtual_keyboard protocol likely is wrong. If you want to help, that would be the best place to look into. Other than that I am afraid there's not much you can do for now. If you do decide to look into it, the code within the keymap module needs a refactoring and it would probably be best to replace as much of the code as possible with functions provided by xkbcommon. Instead of starting with a completely new keymap, ideally we would read the keymap the compositor sends to us. That should also fix issue #302 |
I tried the PR. It now outputs more text:
From the source code, I see it is supposed to press "pop", but it seems only "p" is typed. FYI, it still crashes my Labwc, though you said it doesn't for you. Weird. Maybe I need to reinstall the OS. |
No, it also crashes for me with that PR. It didn't crash with an older commit. No need to reinstall your OS. It outputs more text because I think the input_method protocol is fixed and works. The virtual_keyboard protocol is still broken. I think it successfully initializes the keyboard for the virtual keyboard but then it crashes when trying to simulate a key. Now that I'm looking at the output, you could try to comment out this [line]https://github.com/pentamassiv/enigo/blob/847176b3f567a4fc6f944861a4c52c08e7843904/src/linux/wayland.rs#L306() and see if it fixed the issue. |
I reran the keyboard example several times, and I found that
|
Describe the bug
Recently Raspberry Pi OS switches their Wayland compositor from Wayfire to Labwc. The current version of Labwc in Debian Bookworm is 0.7.2. Now whenever a enigo
key()
is called, the compositor would crash. Before in Wayfire it would work.Also, mouse movement and button clicks do not trigger crash.
Here is the log from Labwc:
To Reproduce
enigo.key(enigo::Key::Unicode('A'), Direction::Click);
Expected behavior
No crash happens.
Environment (please complete the following information):
Linux rpi 6.6.51+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt3 (2024-10-08) aarch64 GNU/Linux
The text was updated successfully, but these errors were encountered: