External Montior Not Detected about wayshot HOT 19 CLOSED

@uncomfyhalomacro Yes, I'm aware that sway uses swaymsg and river will not allow for clients to access that information (see https://github.com/riverwm/river/issues/542). I've been trying to decipher wlr-screencopy-unstable-v1 but I don't have enough experience.

For now I've just settled on passing a geometry that will capture the primary view in River, based on the currently active monitor.

@Shinyzenith @angelofallars @EdenQwQ maybe adding a utility that acts like swaymsg in river will probably help solve that issue. or we can wait i guess for wlroots to have that feature added. or if brave enough, learn C, and have fun adding that in wlroots. 🤔 but im no expert in C so 😢

EDIT: I mentioned the latter because of this https://github.com/riverwm/river/issues/542#issuecomment-1044170411. In my opinion, it does make sense because that will defeat the purpose of using Wayland. So waiting for wlroots to add that patch or add that patch yourself is the most sensible thing to do

Only actual way is PR which extends screenshoting protocol.

from wayshot.

Hi I have developed a fix for this @tpeacock19 The current implementation is a little messy so after some cleanup it should be in master branch

from wayshot.

This also results in any commands with geometry or slurp not to work on my external monitor, it just shows a black screen. Whereas with grim -g it selects the region correctly.

from wayshot.

should take a full screenshot of the active monitor.

Hi! I had attempted this approach earlier and failed miserably, I'll check in with smithay devs and see if it's possible to detect this with smithay, hence for now it defaults to the first detected monitor.

I will make sure this gets addressed.

from wayshot.

Thank you for the bug report ❤️.

from wayshot.

I can replicate this issue.

from wayshot.

It might take a day or two to get this patched as I'm not feeling too good for the past few days but I will make sure this gets rectified.

from wayshot.

understood and no problem, I appreciate your work! I'm hoping screenshots of active windows will be possible in the future.

from wayshot.

understood and no problem, I appreciate your work! I'm hoping screenshots of active windows will be possible in the future.

Thank you! And yes screenshot of specific windows is already possible with gnome, I hope wlroots implements the same asap.

from wayshot.

understood and no problem, I appreciate your work! I'm hoping screenshots of active windows will be possible in the future.

for now, wlroots does not have a way to do that currently. though there is a script that works with sway so well using swaymsg. as for other compositors such as river, well it will inherit the problem that wlroots havent implemented yet. to clarify, sway does have a "hack" for it but it is not from wlroots.

from wayshot.

So the active monitor thing will take some refactoring which I'm working on.

And this is the cause of the geometry bug.

from wayshot.

@uncomfyhalomacro Yes, I'm aware that sway uses swaymsg and river will not allow for clients to access that information (see https://github.com/riverwm/river/issues/542). I've been trying to decipher wlr-screencopy-unstable-v1 but I don't have enough experience.

For now I've just settled on passing a geometry that will capture the primary view in River, based on the currently active monitor.

from wayshot.

@uncomfyhalomacro Yes, I'm aware that sway uses swaymsg and river will not allow for clients to access that information (see riverwm/river#542). I've been trying to decipher wlr-screencopy-unstable-v1 but I don't have enough experience.

For now I've just settled on passing a geometry that will capture the primary view in River, based on the currently active monitor.

https://drewdevault.com/2017/01/06/Actually-you-CAN-do-it.html
I'm a complete beginner and I worked on wayshot after learning from cmeissl ( smithay dev ). I'm sure you can do it too with a bit of determination!

from wayshot.

So the active monitor thing will take some refactoring which I'm working on.

And this is the cause of the geometry bug.

I have found a fix for this issue, it's a bit tedious and will take a bit so I apologize.

from wayshot.

@uncomfyhalomacro Yes, I'm aware that sway uses swaymsg and river will not allow for clients to access that information (see https://github.com/riverwm/river/issues/542). I've been trying to decipher wlr-screencopy-unstable-v1 but I don't have enough experience.

For now I've just settled on passing a geometry that will capture the primary view in River, based on the currently active monitor.

@Shinyzenith @angelofallars @EdenQwQ maybe adding a utility that acts like swaymsg in river will probably help solve that issue. or we can wait i guess for wlroots to have that feature added. or if brave enough, learn C, and have fun adding that in wlroots. 🤔 but im no expert in C so 😢

EDIT: I mentioned the latter because of this https://github.com/riverwm/river/issues/542#issuecomment-1044170411. In my opinion, it does make sense because that will defeat the purpose of using Wayland. So waiting for wlroots to add that patch or add that patch yourself is the most sensible thing to do

from wayshot.

I don't think I have enough experience to extend the protocol just yet...

from wayshot.

Status update:

This is a bigger mess than I expected.

TODO:

• Guess monitor layout
• Capture each output with intersecting box
• Get offset of each monitor
• Apply offset to each output shots
• Blit the image manually into the output image.

About the fix I developed, it didn't work...it did capture both screens properly but after that it broke while trying to overlay the images due to missing offset.

from wayshot.

Guess monitor layout
Capture each output with intersecting box
Get offset of each monitor
Apply offset to each output shots
Blit the image manually into the output image.

I made a branch which does the above plan, using the xdg-output position values to find output offsets. It's very rough code, and it currently normalizes output scales to 1x, but it can take screenshots of slurp regions that include multiple monitors.. See https://github.com/mstoeckl/wayshot/tree/multi-output . I can work on upstreaming this, if you'd like, although doing so would probably be less risky if Wayshot were to update to wayland-rs 0.30.0 first.

from wayshot.

Guess monitor layout
Capture each output with intersecting box
Get offset of each monitor
Apply offset to each output shots
Blit the image manually into the output image.

I made a branch which does the above plan, using the xdg-output position values to find output offsets. It's very rough code, and it currently normalizes output scales to 1x, but it can take screenshots of slurp regions that include multiple monitors.. See https://github.com/mstoeckl/wayshot/tree/multi-output . I can work on upstreaming this, if you'd like, although doing so would probably be less risky if Wayshot were to update to wayland-rs 0.30.0 first.

Thanks for the super cool patch! My machine is currently borked so I'm unable to boot and update wayshot to Wayland-rs 0.30. I tried to look at the changes and they're pretty drastic from what I felt, I need some time to wrap my head around it. Would you mind opening a PR? I'd love to work on upstreaming this patch

from wayshot.