Improve Solaar rules in Wayland #1020
Comments
|
See Issue #1006. Pynput complained when run under Wayland. |
|
Ah, I see. The title of that issue was not prominent enough, I guess.
uinput should work for that... on my system,
This would be trickier for sure. |
|
What is needed is someone who knows about Wayland and can help put together a solution. On my Fedora system there does not appear to be any ACLs set up for input devices. |
TBH any system with functional logind will do that (and a default Fedora absolutely counts). Try
So I googled a bit. There actually is a protocol, wlr-foreign-toplevel-management, that does what Solaar wants. Unfortunately (for me) GNOME does not implement it and likely will not. There is also said to be some GNOME-specific DBus API (edit: an example of its usage), but whatever it will be, I doubt that you would want to support an exception just for GNOME. |
|
No ACLs on /dev/uinput here. Perhaps it is only done in Wayland? |
Right. The udev rule that assigns ACLs to uinput node is not built-in as I thought, but is rather supplied by Steam on my system. That said, nothing prevents Solaar from shipping a similar rule itself (the significant part is |
|
The help of someone who knows about Wayland and can program in Python would be very helpful. There isn't too much that is needed - faking input (probably using uinput) and determining the active program are the major bits. |
|
I wrote a little program to fake input using /dev/uinput. It works for keyboard input but not for mouse buttons and I have no idea why. If someone can figure it out it would be possible to do more Solaar rule processing under Wayland. EDIT: It turns out that you need to synchronize between mouse down and up to register a click, but not for keyboard keys. The buggy behaviour is really for keyboards, not for mice. |
|
If someone can find something saying how to determine the current program in Wayland that would help in getting Solaar rules running in Wayland. |
|
If you have X11 (emulation?) running in Wayland then Solaar rules will be active. They can't see the active program or fake input, but at least they can respond to notifications and run programs. |
|
So as of yet this hasn't been implemented right? I can see Solaar intercepting my Mouse Gesture Button of Ctrl + Alt + Shift, but I can't give it any new inputs. I figure these are send over X and therefore not registered. I might check to see if it would run in a contained X client through But I guess a workaround would be to give the keyboard bindings a new function through a bindsym in Sway. |
|
The problem in Wayland is that it is difficult to emulate input. |
Rules Lastly, the config: So you are saying that I should make the Mouse Gesture button to make a script, and in that script put a keybind for |
|
It looks as if you had a running Solaar. To get debug output you need to quit out of Solaar and then run One way to debug rules is to include an action to execute a command that pops up an on-screen notification, like |
|
The KeyPress action uses XTest, which might not work in Wayland. |
That's very helpful, thanks. I do think it Solaar works as it should, just that my use-case is limiting. The keypress might be not supported, but I could circumvent it also, by rebinding the Ctrl+Alt+Tab, which is the default for the mouse gesture button to Ctrl+w. Will try the |
Then more error code info |
|
Hmm. That looks like a bit of a bug. Solaar rules haven't been tested under XWayland. |
|
It looks like you put in a Process condition in your rule. You probably wanted to use an Execute action instead. |
|
PR #1391 should fix the crash you experienced. To download and use Solar from its GitHub repository Run Solaar as bin/solaar from this directory. To run PR #1391, first clone Solaar if you have not already done so and cd to the clone directory. The first time you download the pull request, fetch it into a new branch and checkout that branch, as in: To download a new version of the pull request, fetch it and then set your pull branch |
|
Running the above commands, and setting 'firefox' as an execute command. I can verify that working, but that might have been also the case before. The Keypresses of Ctrl+w are not working yet. I was sure to close solaar before I opening the command. I will have a play around, I am not the most well-versed when it comes to linux, so thanks for the initial pointers, also how to git into new repos. |
|
It seems to hang a bit, but definitely gives different and no error like before. </details. |
|
The KeyPress action is unlikely to work in Wayland. You should execute some command that has the desired effect, if this is possible. |
pfps
changed the title
|
If someone is willing to do the testing, it should be possible to get part of Solaar rules running under Wayland. It might even be possible to get Solaar to optionally use /dev/uinput for simulating keypresses and mouse movement. If someone is willing to do some testing please respond here. |
|
I am up for some testing, I am using Sway under Wayland. I don't think it should matter which DE is being used, but I thought I should mention. |
|
Yes, I made that change to make it more obvious what the devices where for. |
|
it's even weirder: with latest PR #1530,
|
|
reboot doesn't change anything other than ACL getting lost |
|
I tried running Gnome several ways. Even when I tried Gnome under Wayland some X11 functionality remained. What I did was fix up the Solaar code a bit to document what features are set up. I also modified how the uinput device is created - there is only one device now. I am also seeing evtest not picking up simulated input. The most reliable way I found to see what exactly is going on is to use emacs and its C-h l command, which shows the last few inputs it sees. I noticed that even if there is only one uinput device that keyboard and mouse events are not seriallized correctly through to the end process. I added a very short sleep and that seems to result in correct serialization. So please try out the newest PR #1530 with Also post your ~/.config/solaar/rules.yaml file. With the newest PR #1530 I'm seeing correct behaviour under both Gnome (Wayland and forcing X11 off) and XFCE. Here are the two rules that I worked with: |
|
|
|
I think I know what's happening (no idea why tho..): this morning I told you that the middle mouse button is being registered in another window. Turns out the same is true for the key presses. I have a desktop full of windows (5 terminals, 4 browser windows, several other programs and Thunderbird). All events are being sent to Thunderbird, no matter which other window currently has the focus. If I switch to another window, keyboard focus changes, but Solaar simulated input stays in TB. This is new and appeared two 1530 revisions ago. I have rebooted in between. |
|
I expect that what is happening is that Solaar is using Xtest, even in Wayland, as the Xtest libraries and interface are available. But Xtest under Wayland probably isn't fully capable. To see if this is the problem edit lib/logitech_receiver/diversion.py to cause an error at line 80 (just before the If this doesn't help, provide output of |
|
force Xlib to fail: immediate success! Everything works like it should! Fantastic. |
|
OK. But that means that the way Solaar determines what to use for simulated input needs to be rethought, which may take a while. |
|
yes, I'm a happy camper. In fact, Solaar was the only thing keeping me from switching to Wayland on my main workstation, and now I can. Thanks a bunch! |
|
the current PR #1530 only halfway works: only the first scroll-wheel-left or -right switches the workspace, then I have to restart Solaar. The 'force Xlib to fail' version runs without this issue. |
|
Please provide output of |
|
ok here's mousewheel-right (working) + some mouse movement + mousewheel-left (not working) |
|
I noticed that sometimes the latest version works, but so far the patched one has always worked |
|
I'm not seeing anything problematic but there isn't good visibility on exactly what is being done. I've added permanent debugging output for that so please try the current version of the PR again. It should show simulated uinput debug lines for each keydown and keyup. I tested the current version of the PR on Gnome Wayland and I'm not seeing any problems there. |
|
https://daduke.org/junk/solaar -> again, first KeyPress worked, second didn't. |
|
The relevant part is: What is happening is that on the second notification Solaar thinks that a control modifier is on and doesn't bother to simulate pressing and releasing the control key. This may again a problem with Wayland in that there is no global notion of the keyboard modifiers. To verify, see if clicking on the Solaar window results in a good result. The resolution might have to be to simulate pressing and releasing modifier keys unconditionally, which can cause problems if a modifier key is actually down. |
|
what do you mean by "see if clicking on the Solaar window results in a good result"? In the test as I'm doing it right now, the Solaar window isn't even visible after the first click since I just switched workspaces.. as for "The resolution might have to be to simulate pressing and releasing modifier keys unconditionally, which can cause problems if a modifier key is actually down" - why does the 'force Xlib to fail' version work so well then? |
|
Thinking further, if the simulated input changes the window or does something else to change focus then this is likely to cause Solaar to have an incorrect notion of which modifier keys are down. |
|
uhm ok. All I can say is that it worked perfectly under X and it also works perfectly under Wayland with the frankensteined patch |
|
I think the results may depend on whether a rule is ever run when the Solaar window is active. If so, then Solaar may end up with an incorrect notion of which modifier keys are down. The reason for this is that the control-key down is performed when the Solaar window is active but the control-key up is performed when another window is active. Under X there is a global notion of which control keys are down that all programs can see. Under Wayland programs only see what has happened in the input system when they are active. (At least this is my understanding.) |
my "patched" version is this ^ one - it was a git clone done on that day, pulled 1530 and disabled Xlib |
|
It looks as if the patched Solaar doesn't refer to the modifier state. |
|
Patching the current PR to not use the modifier state can be done via changing line 212 of diversion.py to |
|
this seems to work fine too |
|
OK, I'll probably make this change to Solaar. |
|
I just added the patch to the PR. As this seems to work I'm going to merge it in. |
Information
1.0.4.r54.g0427e56solaar show:The newly introduced rule-based crown handling (#987, #988) does not appear to work in Wayland environments. As I understand, this is not a bug but a deliberately missing feature.
Describe the solution you'd like
It would be nice to have this working in Wayland environments.
Describe alternatives you've considered
I don't know, use X11 maybe.
Additional context
As I understand, input injection can happen via non-X11-dependent mechanisms, like pynput's uinput backend. What else does solaar need from the window system?
The text was updated successfully, but these errors were encountered: