External Montior Not Detected

[tpeacock19]

My understanding is that the default command wayshot should take a full screenshot of the active monitor. When I have my external monitor selected it still defaults to my laptop's screen.

❯ uname -a
Linux baalsecundus 5.16.11-zen1-1-zen #1 ZEN SMP PREEMPT Thu, 24 Feb 2022 02:18:22 +0000 x86_64 GNU/Linux
❯ paru -Qs "river-git|wlroots-15|wayshot-git"
local/river-git 0.1.0.r49.ge67a942-1
    A dynamic tiling wayland compositor.
local/wayshot-git 1.1.5.64.g02c5041-1
    A screenshot tool for wlroots compositors.
local/wlroots-15 0.15.0.r.-1
    Modular Wayland compositor library (git version)

[tpeacock19]

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.

[Shinyzenith]

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.

[Shinyzenith]

Thank you for the bug report ❤️.

[Shinyzenith]

I can replicate this issue.

[Shinyzenith]

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.

[tpeacock19]

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

[Shinyzenith]

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.

[uncomfyhalomacro]

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.

[Shinyzenith]

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

And this is the cause of the geometry bug.

[tpeacock19]

@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]

@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!

[Shinyzenith]

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.

[uncomfyhalomacro]

@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

[Shinyzenith]

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

[heavyrain266]

@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.

[Shinyzenith]

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

[Shinyzenith]

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.

[mstoeckl]

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.

[Shinyzenith]

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