Bug: clipboard option freezes everything when used with slurp #109
Comments
|
I think I misunderstood your issue. Apologies. |
|
Can reproduce. Sway does not actually freeze but you have to full-screen apps before you can interact with them. Likely a bad interaction between freeze-feat's use of callbacks+layer-shell and wl-clipboard-rs's thread use or our own daemonization functionality. Will look into it. |
|
My preliminary theory is that freeze-feat destroys the overlay shell surface as a side effect of the program terminating rather than removing it manually on completion of selection, so when wayshot persists instead of terminating immediately to keep the image on the clipboard, the layer shell does too. Could this be plausible @AndreasBackx ? |
|
yeah that seems to have been it. Have a patch solving this. |
|
@CheerfulPianissimo your assertion seems very likely. It made me look into why we're doing it this way in the first place and I looked into the unsafe code for the clipboard stuff. @Shinyzenith, I don't fully understand why we need to fork here. Could you explain why we cnanot piggyback on the wl-clipboard implementation? It it because you did not want this to block and it's blocking for a long time? Also, from my understanding of daemonisation (I'm using it quite extensively at work as a "hack" to make sure terminals exit quickly and can do some work afterwards), this is not daemonisation. We are forking, but we are not "daemonising" the process. That requires a second fork and a setsid call. Unless the Rust stuff does it differently somewhat, the current behaviour simply has 2 processes but should not exit earlier than without this forking code. Though please correct me if I'm wrong. |
|
The rationale for doing the fork is explained here: #89 (comment)
Yes, it blocks till the user copies something else to the clipboard. We could just block stdout and not exit till this happens but that would be surprising behavior imo and would not be in line with the other clipboard tools in the ecosystem like wl-copy.
Presently wayshot forks and exits while the forked child process sets wl-clipboard's foreground option to true and calls copy. Only one process remains as the parent process' My goal here was to basically disconnect wayshot from the terminal it's running in along with the stdout/stdin/stderr. I searched around a bit and this seemed to be the idiomatic unix way to do this. Do you have any suggestions to improve this @AndreasBackx ? |
|
Checked out running after merging #110, have this error after Protocol error 1 on object wl_display@1: invalid method 1 (since 1 < 3), object zwlr_layer_shell_v1@12
Error: dispatch error: Backend error: Protocol error 1 on object wl_display@1: invalid method 1 (since 1 < 3), object zwlr_layer_shell_v1@12
Caused by:
0: Backend error: Protocol error 1 on object wl_display@1: invalid method 1 (since 1 < 3), object zwlr_layer_shell_v1@12
1: Protocol error 1 on object wl_display@1: invalid method 1 (since 1 < 3), object zwlr_layer_shell_v1@12
Location:
wayshot/src/wayshot.rs:71:9 |
|
Can reproduce this but not consistently (about 1 in 6 times?). Happens without the |
|
Some logs: Logs
Could be a case of use after destroy? |
Yeah, happens every time for me. Running |
|
Which compositor are you using @Gigas002 ? |
|
I'm using hyprland |
|
I'm using sway. Alright, I have a patch that solves this. The existing code destroys the layer_shell object instead of the layer_surface objects, destroying only layer_surface objects seems to solve the issue but destroying both in that order doesn't. It isn't clear to me why this is the case but I'll create a PR for you to test. |
Built from
freeze-feat-andreasbranch. Just runningwayshot --clipboardworks fine, but when trying to runwayshot --clipboard -s "slurp"compositor freezes, until wayshot is killed from ttyThe text was updated successfully, but these errors were encountered: