Synergy + Warp causes Xorg to crash about warpd HOT 30 CLOSED

Please list the commit you have built from (and the output of warp -v in all future issues). I suspect the issue has something to do with teamviewer, can you try reproducing it both with and without teamviewer? Also confirm that it is still an issue in the latest commit, there have been a few bugfixes. The problem likely has something to do with the two programs competing for the xinput devices. If this is the case it is unlikely anything can be done to make warp cooperate with teamviewer but it should be possible to make it fail gracefully.

from warpd.

Try pulling the latest commit and running

WARP_DEBUG_FILE=~/warp.dbg warpd

And include the contents ~/warp.dbg and /var/log/Xorg.0.log if you manage to reproduce the issue.

from warpd.

Alright! Didn't happen again since I last updated. If it happens I will send you the logs.

from warpd.

Happened on ubuntu with i3 and picom as compositor! I wasn't expecting this to happen so i didn't run it correctly to log the crash :P.... Didn't happen with plasma again so far.

The screen just went black after the hints showed up. Next time it happens now I will be ready.

from warpd.

Happened on ubuntu!
Xorg.0.log

warp.log

from warpd.

Thanks, the logs help a lot. Did you kill X manually after this happened or did it crash? In the first case you said it crashed in the second you mention that the screen 'went blank'. Is this the same problem you were experiencing before? Does it correlate with you plugging in or removing any input devices?

from warpd.

Happened on plasma finally!

syslog_coredump.log
Xorg.0.log
warp.log

Thanks, the logs help a lot. Did you kill X manually after this happened or did it crash? In the first case you said it crashed in the second you mention that the screen 'went blank'. Is this the same problem you were experiencing before? Does it correlate with you plugging in or removing any input devices?

I didn't kill Xorg manually, it just restarts when this happens on both my machines, so is not correlated with any external device at all. Notice also that both machines are different (Ubuntu + i3 and arch = plasma) and is the same problem happening. The screen goes black and Xorg restarts.

The only application that I have in both machines is synergy. Maybe that's the issue?

from warpd.

from warpd.

I'm using a session manager on both machines. I don't see any relation with anything I do on synergy that is triggering that at all. Synergy is always on on my both machines but it works with it on or not. In the i3 machine there is nothing plugged besides synergy client. On the plasma one there are many things plugged but I'm not ever changing anything.

I think there isn't much left on my: ~/.local/share/xorg/Xorg.0.log
Xorg.1.log
Xorg.1.log.old.log

from warpd.

Did you copy the Xorg files immediately after the crash? (they get overwritten each time you restart xorg). I don't see any evidence of termination. I can't seem to reproduce the problem or find the root cause in the logs. I suspect something input related on your system is causing the issue (it is unlikely that it is truly random). See if you can figure out what is triggering it and consistently reproduce the issue.

from warpd.

I've added some additional debug statements, please make sure you are running the latest version in the event that it happens again.

from warpd.

Alright, I just updated on both machines. I couldn't find any pattern on this yet.

from warpd.

I've updated some of the input logic for unrelated reasons. You should make sure you are running on the latest version. Have you encountered the issue again? Continuous X logs will help /var/log/Xorg.0.log and /var/log/Xorg.0.log.old are the files you probably want to upload.

from warpd.

Weirdly the issue didn't happen again so far again in neither of my machines! Well I will pull the latest version but I suspect this is gone somehow.

from warpd.

And is not working on ubuntu but working on arch. Really likely to be synergy's fault.

Just to make it clear arch is my main machine and synergy's server is on it, and ubuntu is on a old laptop which I use as a hacky secondary monitor with synergy client, in another words ubuntu is controlled by arch using synergy.

file:///home/matheus/tmp/warp.log

Whenever I hit an activation key synergy complains with:

Jun 20 19:09:41 Vostro Synergy 1.10.2: [2020-06-20T19:09:41] INFO: found key in group 0
Jun 20 19:09:44 Vostro Synergy 1.10.2: [2020-06-20T19:09:44] INFO: found key in group 0
Jun 20 19:09:45 Vostro Synergy 1.10.2: [2020-06-20T19:09:45] INFO: found key in group 0
Jun 20 19:09:45 Vostro Synergy 1.10.2: [2020-06-20T19:09:45] INFO: found key in group 0
Jun 20 19:09:46 Vostro Synergy 1.10.2: [2020-06-20T19:09:46] INFO: found key in group 0

Synergy also displays that for things like ctrl+shift+V, and many alt shortcuts so no idea if that matters.

I tried changing the shortcut, restarting, compiling older commits that were working, and now nothing makes it work again lol...

from warpd.

Okay on the last commit after pluging the physical keyboard and unplugging it works normal again even from synergy but on the latest this doesn't fix it.

from warpd.

And is not working on ubuntu but working on arch. Really likely to be synergy's fault.

From what you have written I assume X isn't crashing anymore.

file:///home/matheus/tmp/warp.log

I think you forgot to upload the log (The X logs would also help if you still have them
(probably /var/log/Xorg.0.log.old)

I tried changing the shortcut, restarting, compiling older commits that were
working, and now nothing makes it work again lol...

Have there been any configuration changes on your end?

Okay on the last commit after pluging the physical keyboard and unplugging it
works normal again even from synergy but on the latest this doesn't fix it.

I'm not sure what you mean by this. Are you saying hotplugging causes X to crash?

from warpd.

warp.log
Ah this doesn't have nothing important I think anyway. X didn't crash again (so far), in both machines. Not sure if it is fixed but seems like.

The only problem is after the latest commit is that is not working over synergy. Which it was. If I hotplug it works. I haven't changed the configs, but I am still not sure if this is your fault or mine yet :P. Anyway that would be another subject but did you do something on this last one that would conflict with synergy's input or so?

I will still test for more days on my main machine and I will just close this issue if it doesn't happen again. But I really suspect synergy is fighting with warp for control somehow :P.

from warpd.

I just exerimented with synergy and poked around the source. It looks like the two programs are fundamentally incompatible by design. Did this ever work? If you run warp on each machine and then try and activate something like hint mode it should only work on the server (and it will only work properly if the server screen is focused). Discrete mode might appear to work but that is only because it concerns itself with relative movements. Did you ever have all modes successfully running on synergy?

from warpd.

Yes this worked on the client machine already! Yes when I run the keybinding for hints mode even if I'm focused on the client it triggers it on the host machine, but with a different shortcut it was working on the client machine as well just fine all the 3 modes.

I reverted to the commit 95f56f139fe5f863e138533a36e3362d9ef9800b when it was surely working all the tree modes with synergy but it didn't just work again either, but i was able to get them working after a system restart and many synergy resets and all the 3 modes just works again now.

On ea94b9020ec69dbcee152a97254156c4e1f96813 and beyond it doesn't work over synergy anymore.

Still not any Xorg crash so far though.

from warpd.

Yes this worked on the client machine already! Yes when I run the keybinding for hints mode even if I'm focused on the client it triggers it on the host machine, but with a different shortcut it was working on the client machine as well just fine all the 3 modes.

What you describe is expected behaviour for 95f56f1. Unfortunately any compatibility was a bug, not a feature (see #3). The reason you had to map a separate hot key for each client is because synergy uses a higher level input mechanism than warpd. If the two mechanisms were compatible the same key would work seamlessly between screens. This approach was deliberately taken in order to facilitate use with a larger number of programs (mainly to support popup menus which grab the keyboard). A side effect of the design is that some keyboard oritented programs (mainly games and some accessibility tools) will be incompatible.

ea94b90 introduced a patch to the input system for stability which had the side effect of nuking any residual support for programs which simulate key events (including synergy). This was never intended to work in the first place.

There are some potential work arounds but they all involve trade offs and altering core functionality. You should still be able to use warpd, but only on the server (when it is focused). Anything else is unsupported.

from warpd.

I understand why I would need to set a separate shortcut for working on the synergy client. Would be nice to have it working on this computer since I only use it through synergy but I understand if that this can be out of the scope of this project and was not even intended to work, but it works nice with ea94b90 which is impressive :P.

If it has a high trade off to make this work then better not. Or maybe we could have a synergy compatible mode or something? If that is doable.

from warpd.

If it has a high trade off to make this work then better not. Or maybe we could
have a synergy compatible mode or something? If that is doable.

I might consider introducing an option to use standard X grabs in place of xinput ones assuming the user understands that it breaks popup menus but it would require some additional modifications to the input logic which I am too lazy to do at the moment.

from warpd.

No worries! At your speed! This project is already amazing and useful :P. That mode would do it.

The Xorg crash didn't ever happen again so this issue could be closed.

from warpd.

Just to point it out, the issue with Xorg crashing never happened anymore and it's been a week, so I guess was some rare race condition or something we might never now anyway. I suppose I should leave this open as being the feature request for the "External Virtual Input Sofwares Friendly Run Mode" ?

from warpd.

Based on the logs you sent me and my own experiments I suspect synergy was causing the crash. The input patch probably indirectly solved the issue. If it happens again feel free to open another issue. I am closing this for now. I have created another issue for the associated feature request.

from warpd.

Not sure if the issue is related to synergy. It is back to me again sadly... warpd wasn't working then i killed and restarted it and when I triggered hints mode Xorg crashed making me lose some work :P

from warpd.

One recent change I did was remaping caps lock to esc..... Didn't happen again so far.

from warpd.

from warpd.

from warpd.