emersion / grim Goto Github PK

View Code? Open in Web Editor NEW

877.0 17.0 37.0 210 KB

Grab images from a Wayland compositor

Home Page: https://wayland.emersion.fr/grim

License: MIT License

C 88.38% Meson 8.63% Shell 2.99%

wayland screenshot cli scrot

grim's Introduction

grim

⚠️ Heads up! This project has moved to SourceHut.

Grab images from a Wayland compositor. Works great with slurp and with sway.

Example usage

Screenshoot all outputs:

grim

Screenshoot a specific output:

grim -o DP-1

Screenshoot a region:

grim -g "10,20 300x400"

Select a region and screenshoot it:

grim -g "$(slurp)"

Use a custom filename:

grim $(xdg-user-dir PICTURES)/$(date +'%s_grim.png')

Screenshoot and copy to clipboard:

grim - | wl-copy

Grab a screenshot from the focused monitor under Sway, using swaymsg and jq:

grim -o $(swaymsg -t get_outputs | jq -r '.[] | select(.focused) | .name')

Grab a screenshot from the focused window under Sway, using swaymsg and jq:

grim -g "$(swaymsg -t get_tree | jq -j '.. | select(.type?) | select(.focused).rect | "\(.x),\(.y) \(.width)x\(.height)"')"

Pick a color, using ImageMagick:

grim -g "$(slurp -p)" -t ppm - | convert - -format '%[pixel:p{0,0}]' txt:-

Building from source

Install dependencies:

meson
wayland
pixman
libpng
libjpeg (optional)

Then run:

meson build
ninja -C build

To run directly, use build/grim, or if you would like to do a system installation (in /usr/local by default), run ninja -C build install.

Contributing

Either send GitHub pull requests or send patches on the mailing list.

Join the IRC channel: #emersion on Libera Chat.

License

MIT

grim's People

Contributors

Stargazers

Watchers

grim's Issues

Make jpeg support optional

Hi,

i'm preparing a debian package of grim. I fear that the license of cairo_jpg.c is not DFSG compliant. Even if so, it would be an embedded code copy, which is frowned up in Debian. But i could repackage before packaging for Debian- i would just need a switch to be able to compile without the two cairo_jpg files.

failed to create display

With the command:

grim test.png

I get the following output:

failed to create display

Using ArchLinux 64 bit, with sway version 1.0 on a Lenovo thinkpad.

Not working Gnome on Manjaro

grim screenshot.png
wl_registry@2: error 0: invalid version for global wl_output (4): have 2, wanted 3
compositor doesn't support wlr-screencopy-unstable-v1

Any ideas?

Orbital screenshooter protocol support

It's not a pretty protocol, but that's all we got for now.

Doesn't handle space in a file name

Grim prints everything, but what printed after a space.
ex: 'grim $(xdg-user-dir PICTURES)/Screenshots/$(date +'%x %T').png' will print only 12.11.2018.

Cropped screenshot

Feature request: it will be nice if we could take the screenshot by cropping it via the mouse and select only the relevant parts for SS

Output to clipboard

I was using spectacle which has a "Copy to clipboard" option. It would be cool if grim could do that.

Capture screenshot in ChromeOS

I need to capture screenshot in ChromeOS. As per your meson.build file all dependencies are installed using "crew" (off the shelf pkg manager), but the build got failed.

Can you help us resolve the issue or point in right direction? I believe Chrome/Chromium OS runs on wayland since no X11 was found.

I am using OVA provided by neverware/cloudready for VMware, coming from windows & .NET background this is so far I have got..

Add argument to choose the output image scale

Will either scale down HiDPI or scale up LoDPI.

Provide more helpful error message(s)

When working on #62, I found that the error message displayed when cairo_surface_to_xxx fails is not very helpful when very long filenames are used:

> grim <morethan255charactershere> 
failed to write output file

The various strerrror functions don't really anything more helpful:

strerror Resource temporarily unavailable
cairo_status_to_string error while writing to output stream

Perhaps we could check the returned status code and if it is CAIRO_STATUS_WRITE_ERROR and our filepath is > NAME_MAX we could suggest that may be the issue in the error message.

The code in cairo_surface_write_to_png is:

    fp = fopen (filename, "wb");
    if (fp == NULL) {
	switch (errno) {
	case ENOMEM:
	    return _cairo_error (CAIRO_STATUS_NO_MEMORY);
	default:
	    return _cairo_error (CAIRO_STATUS_WRITE_ERROR);
	}
    }

JPEG support

Optimizations when capturing a region of the layout

Don't capture outputs we don't care about
Don't allocate memory we won't use

Migrate to the screencopy protocol

Screenshot Selected Region

Hey, is there any way to screenshot a selected region (click and drag to select) like with maim? If not, would it be possible to add this functionality? Thanks!

Screenshooting individual windows

Hi,

would it be possible to screenshot a focused window?

scrot could do that scrot -ue $f.

If slurp has some hidden option that does that I am sorry for asking in advance.

Cannot capture region into clipboard

I have a setup with slurp that allows me to select a region then dump it to file. That works fine (there's a bug in slurp with multi outputs but that's a different story).

I'm having trouble however to combine slurp, grim with geometry and wl-copy (to capture to clipboard instead):

# This works fine, region is captured to file
 slurp | grim -g - $(xdg-user-dir PICTURES)/Screenshot-region-$(date +'%Y-%m-%d-%H%M%S.png')

# This captures all outputs
slurp | grim - -g | wl-copy


This upsets grim's argument parser:
slurp | grim -g - | wl-copy

~ slurp | grim -g -    
Usage: grim [options...] <output-file>

  -h              Show help message and quit.
  -s <factor>     Set the output image scale factor. Defaults to the
                  greatest output scale factor.
  -g <geometry>   Set the region to capture.
  -t png|jpeg     Set the output filetype. Defaults to png.
  -q <quality>    Set the JPEG filetype quality 0-100. Defaults to 80.
  -o <output>     Set the output name to capture.
  -c              Include cursors in the screenshot.

Use xdg-output to get outputs names

Waiting for wayland-protocols 1.14 to be available.

Add support for long options

I find myself calling grim --help a lot, and get this:

invalid option -- '-'

I think adding long options support should be done because a lot of other software propose short and long options, for example sway. With long options, we can even deduce what the option does without reading the facing text description, allowing faster discoverability of options.

Since the main.c is already using getopt, this should be fine to implement.

Also, IIRC getopt can generate an usage message from the list of (long option, short option, description). I think this should be done instead of having a static usage message. I have a program example that I could use to try to implement this if required.

Screenshots duplicated/transformed wrong.

I've found yet another (probably edge case) issue with screenshots on my new set up.

My set up is admittedly very strange.

I have:
1 4k display at the top
4 1080p displays beneath it in 2x2 (This is actually a 4k dispay that supports pbp as 4 separate inputs.)
1 1080p display on the right of those in portrait (headless doing vnc to a wayvnc session)
1 1080p display beneath that in regular orientation (headless doing vnc to a wayvnc session)

And screenshots are completely messed up.

The screenshot shows the 4k as a 1080p transformed 90 degrees and it actually screenshots the headless output (just sideways)
The 2x2 displays are all mirrors of the same headless output as the 4k, and all transformed incorrectly to boot.
Also, the 5 screens that are all mirrors of each other are showing artifacts on the side of windows that are not currently visible.

The only display that is correct is the headless-2 display in the bottom right.

I've attached the screenshot, my swaymsg -t get_outputs, and a photo taken with my cell phone of what they actually look like (you can ignore the laptop on the left; it's not part of this configuration/setup.)

(Yes, I know, that's a lot of screens.)

Output DP-1 'Goldstar Company Ltd LG Ultra HD 0x00005750'
  Current mode: 1920x1080 @ 60.000000 Hz
  Position: 1920,2160
  Scale factor: 1.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 2
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    640x480 @ 59.939999 Hz
    640x480 @ 59.939999 Hz
    640x480 @ 60.000000 Hz
    720x480 @ 59.939999 Hz
    720x480 @ 60.000000 Hz
    800x600 @ 60.317001 Hz
    1024x768 @ 60.004002 Hz
    1280x720 @ 59.939999 Hz
    1280x720 @ 60.000000 Hz
    1280x720 @ 60.000000 Hz
    1280x800 @ 59.910000 Hz
    1440x900 @ 60.000000 Hz
    1280x1024 @ 60.020000 Hz
    1600x900 @ 60.000000 Hz
    1680x1050 @ 60.000000 Hz
    1920x1080 @ 59.939999 Hz
    1920x1080 @ 60.000000 Hz
    1920x1080 @ 60.000000 Hz

Output DP-2 'Goldstar Company Ltd LG Ultra HD 0x00005750'
  Current mode: 1920x1080 @ 60.000000 Hz
  Position: 0,3240
  Scale factor: 1.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 3
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    640x480 @ 59.939999 Hz
    640x480 @ 59.939999 Hz
    640x480 @ 60.000000 Hz
    720x480 @ 59.939999 Hz
    720x480 @ 60.000000 Hz
    800x600 @ 60.317001 Hz
    1024x768 @ 60.004002 Hz
    1280x720 @ 59.939999 Hz
    1280x720 @ 60.000000 Hz
    1280x720 @ 60.000000 Hz
    1280x800 @ 59.910000 Hz
    1440x900 @ 60.000000 Hz
    1280x1024 @ 60.020000 Hz
    1600x900 @ 60.000000 Hz
    1680x1050 @ 60.000000 Hz
    1920x1080 @ 59.939999 Hz
    1920x1080 @ 60.000000 Hz
    1920x1080 @ 60.000000 Hz

Output HDMI-A-1 'Goldstar Company Ltd LG Ultra HD 0x00005750' (focused)
  Current mode: 1920x1080 @ 60.000000 Hz
  Position: 1920,3240
  Scale factor: 1.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 4
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    640x480 @ 59.939999 Hz
    640x480 @ 59.939999 Hz
    640x480 @ 60.000000 Hz
    720x480 @ 59.939999 Hz
    720x480 @ 60.000000 Hz
    800x600 @ 60.317001 Hz
    1024x768 @ 60.004002 Hz
    1280x720 @ 59.939999 Hz
    1280x720 @ 60.000000 Hz
    1280x720 @ 60.000000 Hz
    1280x800 @ 59.910000 Hz
    1440x900 @ 60.000000 Hz
    1280x1024 @ 60.020000 Hz
    1600x900 @ 60.000000 Hz
    1680x1050 @ 60.000000 Hz
    1920x1080 @ 59.939999 Hz
    1920x1080 @ 60.000000 Hz
    1920x1080 @ 60.000000 Hz

Output DVI-D-1 'Goldstar Company Ltd LG Ultra HD 0x00005750'
  Current mode: 1920x1080 @ 60.000000 Hz
  Position: 0,2160
  Scale factor: 1.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 1
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    640x480 @ 59.939999 Hz
    640x480 @ 59.939999 Hz
    640x480 @ 60.000000 Hz
    720x480 @ 59.939999 Hz
    720x480 @ 60.000000 Hz
    800x600 @ 60.317001 Hz
    1024x768 @ 60.004002 Hz
    1280x720 @ 59.939999 Hz
    1280x720 @ 60.000000 Hz
    1280x720 @ 60.000000 Hz
    1280x800 @ 59.910000 Hz
    1440x900 @ 60.000000 Hz
    1280x1024 @ 60.020000 Hz
    1600x900 @ 60.000000 Hz
    1680x1050 @ 60.000000 Hz
    1920x1080 @ 59.939999 Hz
    1920x1080 @ 60.000000 Hz
    1920x1080 @ 60.000000 Hz

Output HEADLESS-1 'headless headless '
  Current mode: 1920x1080 @ 60.000000 Hz
  Position: 3840,1000
  Scale factor: 1.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: 270
  Workspace: 5
  Max render time: off
  Adaptive sync: disabled

Output HEADLESS-2 'headless headless '
  Current mode: 1920x1080 @ 60.000000 Hz
  Position: 3840,2920
  Scale factor: 1.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 6
  Max render time: off
  Adaptive sync: disabled

Output HDMI-A-2 'ViewSonic Corporation VX4380 SERIES 0x00000101'
  Current mode: 3840x2160 @ 60.000000 Hz
  Position: 0,0
  Scale factor: 1.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 7
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    720x400 @ 70.082001 Hz
    640x480 @ 59.939999 Hz
    640x480 @ 59.939999 Hz
    640x480 @ 60.000000 Hz
    640x480 @ 66.667000 Hz
    640x480 @ 72.808998 Hz
    640x480 @ 75.000000 Hz
    720x480 @ 59.939999 Hz
    720x480 @ 60.000000 Hz
    720x576 @ 50.000000 Hz
    800x600 @ 56.250000 Hz
    800x600 @ 60.317001 Hz
    800x600 @ 72.188004 Hz
    800x600 @ 75.000000 Hz
    832x624 @ 74.551003 Hz
    1440x480 @ 59.939999 Hz
    1440x480 @ 59.939999 Hz
    1440x480 @ 60.000000 Hz
    1440x480 @ 60.000000 Hz
    1024x768 @ 60.004002 Hz
    1024x768 @ 70.069000 Hz
    1024x768 @ 75.028999 Hz
    1280x720 @ 50.000000 Hz
    1280x720 @ 59.939999 Hz
    1280x720 @ 60.000000 Hz
    1152x864 @ 75.000000 Hz
    1280x800 @ 59.997002 Hz
    1440x900 @ 59.901001 Hz
    1280x1024 @ 60.020000 Hz
    1280x1024 @ 75.025002 Hz
    1600x900 @ 60.000000 Hz
    1400x1050 @ 59.948002 Hz
    1680x1050 @ 59.882999 Hz
    1600x1200 @ 60.000000 Hz
    1920x1080 @ 50.000000 Hz
    1920x1080 @ 59.939999 Hz
    1920x1080 @ 60.000000 Hz
    1920x1080 @ 60.000000 Hz
    1920x1200 @ 59.997002 Hz
    2560x1440 @ 59.951000 Hz
    3840x1080 @ 59.967999 Hz
    1920x2160 @ 59.999001 Hz
    3840x2160 @ 23.976000 Hz
    3840x2160 @ 24.000000 Hz
    3840x2160 @ 29.981001 Hz
    3840x2160 @ 50.000000 Hz
    3840x2160 @ 59.939999 Hz
    3840x2160 @ 60.000000 Hz
    4096x2160 @ 50.000000 Hz
    4096x2160 @ 59.939999 Hz
    4096x2160 @ 60.000000 Hz
    3840x2160 @ 59.997002 Hz

Allow recording screencats in combination with ffmepg

Hi,

reading the last post here from dac-override, I would imagine that it could/should be possible to pipe the output of grim into ffmpeg and produce screencasts... potentially through slurp also for a specific region!

But I am not sure what the swaygrab -c did ...

Maybe -c stood for continuous grabbing ??

Could you add such a "endless-loop" grabbing ... not sure how the handover to ffmpeg works yet...

But I think this would be amazing :))

Add video capture support

I think video capture would be a great addition.
Or is this out of scope for this project?

fails to build on 32 bit

The build on 32 bit archlinux fails due to some type cast from size_t * to long unsigned int *:

+ exec meson setup --prefix /usr --libdir /usr/lib --libexecdir /usr/lib --bindir /usr/bin --sbindir /usr/bin --includedir /usr/include --datadir /usr/share --mandir /usr/share/man --infodir /usr/share/info --localedir /usr/share/locale --sysconfdir /etc --localstatedir /var --sharedstatedir /var/lib --buildtype release --auto-features enabled --wrap-mode nofallback -D b_lto=true build grim
The Meson build system
Version: 0.48.2
Source dir: /build/grim/src/grim
Build dir: /build/grim/src/build
Build type: native build
Project name: grim
Project version: 0.0.0
Appending CFLAGS from environment: '-march=i686 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt'
Appending LDFLAGS from environment: '-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
Appending CPPFLAGS from environment: '-D_FORTIFY_SOURCE=2'
Native C compiler: cc (gcc 8.2.1 "cc (GCC) 8.2.1 20180831")
Build machine cpu family: x86
Build machine cpu: i686
Found pkg-config: /usr/bin/pkg-config (1.5.4)
Dependency cairo found: YES 1.16.0
Dependency wayland-client found: YES 1.16.0
Dependency wayland-protocols found: YES 1.16
Dependency libjpeg found: YES 2.0.0
Library m found: YES
Program wayland-scanner found: YES (/usr/bin/wayland-scanner)
Program scdoc found: NO
Build targets in project: 2
Option werror is: True [default: true]
Found ninja-1.8.2 at /usr/bin/ninja
ninja: Entering directory `build'
[1/16] Generating 'protocol/protocol@@client_protos@sta/wlr-screencopy-unstable-v1-protocol.c'.
[2/16] Generating 'protocol/protocol@@client_protos@sta/xdg-output-unstable-v1-protocol.c'.
[3/16] Generating 'protocol/protocol@@client_protos@sta/xdg-output-unstable-v1-client-protocol.h'.
[4/16] Generating 'protocol/protocol@@client_protos@sta/wlr-screencopy-unstable-v1-client-protocol.h'.
[5/16] Generating 'grim@exe/wlr-screencopy-unstable-v1-client-protocol.h'.
[6/16] Generating 'grim@exe/xdg-output-unstable-v1-client-protocol.h'.
[7/16] Compiling C object 'protocol/protocol@@client_protos@sta/meson-generated_wlr-screencopy-unstable-v1-protocol.c.o'.
[8/16] Compiling C object 'protocol/protocol@@client_protos@sta/meson-generated_xdg-output-unstable-v1-protocol.c.o'.
[9/16] Linking static target protocol/libclient_protos.a.
[10/16] Compiling C object 'grim@exe/box.c.o'.
[11/16] Compiling C object 'grim@exe/cairo_jpg.c.o'.
FAILED: grim@exe/cairo_jpg.c.o 
cc -Igrim@exe -I. -I../grim -I../grim/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/libffi-3.2.1/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/uuid -flto -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c11 -O3 -Wno-unused-parameter -march=i686 -mtune=generic -O2 -fstack-protector-strong -fno-plt -D_FORTIFY_SOURCE=2  -MD -MQ 'grim@exe/cairo_jpg.c.o' -MF 'grim@exe/cairo_jpg.c.o.d' -o 'grim@exe/cairo_jpg.c.o' -c ../grim/cairo_jpg.c
../grim/cairo_jpg.c: In function ‘cairo_surface_write_to_jpeg_mem’:
../grim/cairo_jpg.c:50:30: error: passing argument 3 of ‘jpeg_mem_dest’ from incompatible pointer type [-Werror=incompatible-pointer-types]
  jpeg_mem_dest(&cinfo, data, len);
                              ^~~
In file included from ../grim/cairo_jpg.c:13:
/usr/include/jpeglib.h:922:43: note: expected ‘long unsigned int *’ but argument is of type ‘size_t *’ {aka ‘unsigned int *’}
                            unsigned long *outsize);
                            ~~~~~~~~~~~~~~~^~~~~~~
../grim/cairo_jpg.c: In function ‘cj_write’:
../grim/cairo_jpg.c:83:42: error: comparison of integer expressions of different signedness: ‘ssize_t’ {aka ‘int’} and ‘unsigned int’ [-Werror=sign-compare]
  if (write((long) closure, data, length) < length) {
                                          ^
cc1: all warnings being treated as errors
[12/16] Compiling C object 'grim@exe/buffer.c.o'.
[13/16] Compiling C object 'grim@exe/main.c.o'.
ninja: build stopped: subcommand failed.

regards,
deep-42-thought

Allow output to clipboard instead of a file

Sometimes when doing quick screenshots the objective is just to paste them in a browser or software application that can handle images from the clipboard.

I do not know if the clipboard management is very different between Xorg and Wayland, but this could accelerate screenshot -> open file in browser -> upload -> delete screenshot workflow.

Doesn't support tilde for home

This is a minor and unimportant issue, but it'd be cool to see this working.

Was trying to migrate from this which I used to use:

maim -s "~/Pictures/screenshot/$(date +%F-%T).png"

And I found out appearently grim doesn't like ~:

[pau@pau-thinkpad ~]$ grim "$HOME/Pictures/screenshot/new.png"
[pau@pau-thinkpad ~]$ grim "~/Pictures/screenshot/new.png"
failed to write output file

(using 1.1)

Scaling is broken on multi-monitor setups

Probably broken during the screencopy migration.

grim ignores XKB_DEFAULT_OPTIONS

I got XKB_DEFAULT_OPTIONS='compose:ralt,caps:swapescape' in my envitronment (using sway).

When I invoke grim and try to cancel it with the Caps key nothing happens.
When I press the actual Esc key it gets cancelled, but caps lock gets triggered as well.

Transforms inverted

This issue I've only seen in grim, so apologies if the issue is in wlroots/sway/something else, but I thought I'd report it here.

My set up is as follows:
4 outputs in 2x2 @ 1920x1080
1 output to the right of them in portrait mode @ 1920x1080.

$ swaymsg -t get_outputs
Output DP-1 'xxx'
  Current mode: 1920x1080 @ 60.000000 Hz
  Position: 1920,1080
  Scale factor: 1.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 4
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    640x480 @ 59.939999 Hz
    640x480 @ 59.939999 Hz
    640x480 @ 60.000000 Hz
    720x480 @ 59.939999 Hz
    720x480 @ 60.000000 Hz
    800x600 @ 60.317001 Hz
    1024x768 @ 60.004002 Hz
    1280x720 @ 59.939999 Hz
    1280x720 @ 60.000000 Hz
    1280x720 @ 60.000000 Hz
    1280x800 @ 59.910000 Hz
    1440x900 @ 60.000000 Hz
    1280x1024 @ 60.020000 Hz
    1600x900 @ 60.000000 Hz
    1680x1050 @ 60.000000 Hz
    1920x1080 @ 59.939999 Hz
    1920x1080 @ 60.000000 Hz
    1920x1080 @ 60.000000 Hz

Output DP-2 'xxx'
  Current mode: 1920x1080 @ 60.000000 Hz
  Position: 0,1080
  Scale factor: 1.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 3
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    640x480 @ 59.939999 Hz
    640x480 @ 59.939999 Hz
    640x480 @ 60.000000 Hz
    720x480 @ 59.939999 Hz
    720x480 @ 60.000000 Hz
    800x600 @ 60.317001 Hz
    1024x768 @ 60.004002 Hz
    1280x720 @ 59.939999 Hz
    1280x720 @ 60.000000 Hz
    1280x720 @ 60.000000 Hz
    1280x800 @ 59.910000 Hz
    1440x900 @ 60.000000 Hz
    1280x1024 @ 60.020000 Hz
    1600x900 @ 60.000000 Hz
    1680x1050 @ 60.000000 Hz
    1920x1080 @ 59.939999 Hz
    1920x1080 @ 60.000000 Hz
    1920x1080 @ 60.000000 Hz

Output HDMI-A-1 'xxx'
  Current mode: 1920x1080 @ 60.000000 Hz
  Position: 0,0
  Scale factor: 1.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 1
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    640x480 @ 59.939999 Hz
    640x480 @ 59.939999 Hz
    640x480 @ 60.000000 Hz
    720x480 @ 59.939999 Hz
    720x480 @ 60.000000 Hz
    800x600 @ 60.317001 Hz
    1024x768 @ 60.004002 Hz
    1280x720 @ 59.939999 Hz
    1280x720 @ 60.000000 Hz
    1280x720 @ 60.000000 Hz
    1280x800 @ 59.910000 Hz
    1440x900 @ 60.000000 Hz
    1280x1024 @ 60.020000 Hz
    1600x900 @ 60.000000 Hz
    1680x1050 @ 60.000000 Hz
    1920x1080 @ 59.939999 Hz
    1920x1080 @ 60.000000 Hz
    1920x1080 @ 60.000000 Hz

Output HDMI-A-2 'xxx' (focused)
  Current mode: 1920x1080 @ 60.000000 Hz
  Position: 1920,0
  Scale factor: 1.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 9
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    640x480 @ 59.939999 Hz
    640x480 @ 59.939999 Hz
    640x480 @ 60.000000 Hz
    720x480 @ 59.939999 Hz
    720x480 @ 60.000000 Hz
    800x600 @ 60.317001 Hz
    1024x768 @ 60.004002 Hz
    1280x720 @ 59.939999 Hz
    1280x720 @ 60.000000 Hz
    1280x720 @ 60.000000 Hz
    1280x800 @ 59.910000 Hz
    1440x900 @ 60.000000 Hz
    1280x1024 @ 60.020000 Hz
    1600x900 @ 60.000000 Hz
    1680x1050 @ 60.000000 Hz
    1920x1080 @ 59.939999 Hz
    1920x1080 @ 60.000000 Hz
    1920x1080 @ 60.000000 Hz

Output DVI-D-1 'xxx'
  Current mode: 1920x1080 @ 60.000000 Hz
  Position: 3840,0
  Scale factor: 1.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: 270
  Workspace: 5
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    720x400 @ 70.082001 Hz
    640x480 @ 59.939999 Hz
    640x480 @ 59.939999 Hz
    640x480 @ 60.000000 Hz
    640x480 @ 66.667000 Hz
    640x480 @ 72.808998 Hz
    640x480 @ 75.000000 Hz
    720x480 @ 59.939999 Hz
    720x480 @ 59.939999 Hz
    720x480 @ 60.000000 Hz
    720x480 @ 60.000000 Hz
    720x576 @ 50.000000 Hz
    720x576 @ 50.000000 Hz
    800x600 @ 56.250000 Hz
    800x600 @ 60.317001 Hz
    800x600 @ 72.188004 Hz
    800x600 @ 75.000000 Hz
    832x624 @ 74.551003 Hz
    1024x768 @ 60.004002 Hz
    1024x768 @ 70.069000 Hz
    1024x768 @ 75.028999 Hz
    1440x576 @ 50.000000 Hz
    1440x576 @ 50.000000 Hz
    1280x720 @ 50.000000 Hz
    1280x720 @ 50.000000 Hz
    1280x720 @ 59.939999 Hz
    1280x720 @ 60.000000 Hz
    1280x720 @ 60.000000 Hz
    1152x864 @ 75.000000 Hz
    1280x800 @ 60.000000 Hz
    1280x960 @ 60.000000 Hz
    1440x900 @ 59.901001 Hz
    1280x1024 @ 60.020000 Hz
    1280x1024 @ 75.025002 Hz
    1600x900 @ 60.000000 Hz
    1400x1050 @ 59.948002 Hz
    1680x1050 @ 59.882999 Hz
    1600x1200 @ 60.000000 Hz
    1920x1080 @ 50.000000 Hz
    1920x1080 @ 50.000000 Hz
    1920x1080 @ 59.939999 Hz
    1920x1080 @ 60.000000 Hz
    1920x1080 @ 60.000000 Hz

Doing a screenshot of the whole screen gets the 4 monitors in 2x2 correct, but the one on the right has its coordinates backwards, and everything is upside down and backwards in the screenshot.

Similarly, if I do a grim -g "3840,0 700x700" corner.png which should give me a 700x700 pixel image of the top left corner of the 5th monitor, I get a completely unrelated portion of that screen.

A full screen screenshot is attached as wat.png. A screenshot with the -g parameter is wat2.png. It should be the face of the character in the background, but instead it's part of his coat further down.

Feature request: option to flash/blink the screen a colour when a screenshot is taken

The visual feedback would be settling.

Investigate if it's possible to embed scale in image metadata

Option to put image in clipboard

It would be cool if there was an option to put the image into the clipboard instead of saving it to a file.

-c is the option used by other tools, such as gnome-screenshot, so grim should probably use the same.

Capturing cursor without -c

I am using sway version 1.0-alpha.6-264-g56c388b5 (Oct 15 2018, branch 'master') and used a keyboard shortcut to perform the command below. In the lower left corner you can see that the cursor is present even though the -c option is not set.

Transparent screenshots for one output

My left output refuses to get screenshotted by grim:

As you can see the right output works fine :)

stderr of grim with `WAYLAND_DEBUG=client`

[531637.416]  -> [email protected]_registry(new id wl_registry@2)
[531637.831] [email protected](1, "wl_shm", 1)
[531637.890]  -> [email protected](1, "wl_shm", 1, new id [unknown]@3)
[531637.937] [email protected](2, "wl_drm", 2)
[531637.965] [email protected](3, "zwp_linux_dmabuf_v1", 3)
[531637.993] [email protected](4, "wl_compositor", 4)
[531638.020] [email protected](5, "wl_subcompositor", 1)
[531638.046] [email protected](6, "wl_data_device_manager", 3)
[531638.073] [email protected](7, "zwlr_gamma_control_manager_v1", 1)
[531638.100] [email protected](8, "gtk_primary_selection_device_manager", 1)
[531638.127] [email protected](9, "zxdg_output_manager_v1", 3)
[531638.156]  -> [email protected](9, "zxdg_output_manager_v1", 2, new id [unknown]@4)
[531638.198] [email protected](10, "org_kde_kwin_idle", 1)
[531638.226] [email protected](11, "zwp_idle_inhibit_manager_v1", 1)
[531638.253] [email protected](12, "zwlr_layer_shell_v1", 2)
[531638.279] [email protected](13, "xdg_wm_base", 2)
[531638.307] [email protected](14, "zwp_tablet_manager_v2", 1)
[531638.334] [email protected](15, "org_kde_kwin_server_decoration_manager", 1)
[531638.361] [email protected](16, "zxdg_decoration_manager_v1", 1)
[531638.388] [email protected](17, "zwp_relative_pointer_manager_v1", 1)
[531638.414] [email protected](18, "zwp_pointer_constraints_v1", 1)
[531638.441] [email protected](19, "wp_presentation", 1)
[531638.468] [email protected](20, "zwlr_output_manager_v1", 1)
[531638.495] [email protected](21, "zwlr_output_power_manager_v1", 1)
[531638.522] [email protected](22, "zwp_input_method_manager_v2", 1)
[531638.549] [email protected](23, "zwp_text_input_manager_v3", 1)
[531638.576] [email protected](24, "zwlr_foreign_toplevel_manager_v1", 2)
[531638.603] [email protected](25, "zwlr_export_dmabuf_manager_v1", 1)
[531638.630] [email protected](26, "zwlr_screencopy_manager_v1", 3)
[531638.657]  -> [email protected](26, "zwlr_screencopy_manager_v1", 1, new id [unknown]@5)
[531638.705] [email protected](27, "zwlr_data_control_manager_v1", 2)
[531638.725] [email protected](28, "zwp_primary_selection_device_manager_v1", 1)
[531638.746] [email protected](29, "wp_viewporter", 1)
[531638.766] [email protected](30, "zwp_virtual_keyboard_manager_v1", 1)
[531638.786] [email protected](31, "zwlr_virtual_pointer_manager_v1", 2)
[531638.806] [email protected](32, "zwlr_input_inhibit_manager_v1", 1)
[531638.826] [email protected](33, "zwp_keyboard_shortcuts_inhibit_manager_v1", 1)
[531638.846] [email protected](34, "wl_seat", 7)
[531638.867] [email protected](35, "zwp_pointer_gestures_v1", 1)
[531638.887] [email protected](36, "wl_output", 3)
[531638.908]  -> [email protected](36, "wl_output", 3, new id [unknown]@6)
[531638.936] [email protected](37, "wl_output", 3)
[531638.956]  -> [email protected](37, "wl_output", 3, new id [unknown]@7)
[531638.986]  -> [email protected](new id wl_callback@8)
[531639.149] [email protected]_id(8)
[531639.174] [email protected](0, 0, 480, 270, 0, "Samsung Electric Company", "S22B300", 0)
[531639.222] [email protected](1, 1920, 1080, 60000)
[531639.249] [email protected](1)
[531639.259] [email protected]()
[531639.267] [email protected](0, 0, 520, 300, 0, "Unknown", "Q24", 0)
[531639.313] [email protected](1, 1600, 1200, 60000)
[531639.339] [email protected](1)
[531639.349] [email protected]()
[531639.356] [email protected](10760)
[531639.368]  -> [email protected]_xdg_output(new id zxdg_output_v1@8, wl_output@7)
[531639.388]  -> [email protected]_xdg_output(new id zxdg_output_v1@9, wl_output@6)
[531639.524] [email protected]("VGA-1")
[531639.547] [email protected]("Unknown Q24 709050660001 (VGA-1)")
[531639.559] [email protected]_position(0, 0)
[531639.575] [email protected]_size(1600, 1200)
[531639.590] [email protected]()
[531639.598] [email protected]()
[531639.605] [email protected]("DVI-I-1")
[531639.615] [email protected]("Samsung Electric Company S22B300 H4XC602789 (DVI-I-1)")
[531639.633] [email protected]_position(1600, 50)
[531639.649] [email protected]_size(1920, 1080)
[531639.664] [email protected]()
[531639.671] [email protected]()
[531639.680]  -> [email protected](new id wl_callback@10)
[531639.798] [email protected]_id(10)
[531639.821] [email protected](10760)
[531639.835]  -> [email protected]_output(new id zwlr_screencopy_frame_v1@10, 0, wl_output@7)
[531639.861]  -> [email protected]_output(new id zwlr_screencopy_frame_v1@11, 0, wl_output@6)
[531640.066] [email protected](0, 1600, 1200, 6400)
[531640.158]  -> [email protected]_pool(new id wl_shm_pool@12, fd 5, 7680000)
[531640.185]  -> [email protected]_buffer(new id wl_buffer@13, 0, 1600, 1200, 6400, 0)
[531640.223]  -> [email protected]()
[531640.232]  -> [email protected](wl_buffer@13)
[531640.243] [email protected](0, 1920, 1080, 7680)
[531640.283]  -> [email protected]_pool(new id wl_shm_pool@14, fd 6, 8294400)
[531640.307]  -> [email protected]_buffer(new id wl_buffer@15, 0, 1920, 1080, 7680, 0)
[531640.344]  -> [email protected]()
[531640.352]  -> [email protected](wl_buffer@15)
[531661.715] [email protected]_id(12)
[531661.739] [email protected]_id(14)
[531661.754] [email protected](1)
[531661.759] [email protected](0, 5547, 292587586)
[531674.420] [email protected](1)
[531674.443] [email protected](0, 5547, 311122860)
[531892.771]  -> [email protected]()
[531892.945]  -> [email protected]()
[531892.951]  -> [email protected]()
[531892.955]  -> [email protected]()
[531892.958]  -> [email protected]()
[531893.151]  -> [email protected]()
[531893.155]  -> [email protected]()
[531893.158]  -> [email protected]()
[531893.162]  -> [email protected]()
[531893.165]  -> [email protected]()

output of `swaymsg -pt get_outputs`

Output DVI-I-1 'Samsung Electric Company S22B300 H4XC602789' (focused)
  Current mode: 1920x1080 @ 60.000000 Hz
  Position: 1600,50
  Scale factor: 1.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 2
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    720x400 @ 70.082001 Hz
    640x480 @ 59.939999 Hz
    640x480 @ 66.667000 Hz
    640x480 @ 72.808998 Hz
    640x480 @ 75.000000 Hz
    800x600 @ 56.250000 Hz
    800x600 @ 60.317001 Hz
    800x600 @ 72.188004 Hz
    800x600 @ 75.000000 Hz
    832x624 @ 74.551003 Hz
    1024x768 @ 60.004002 Hz
    1024x768 @ 70.069000 Hz
    1024x768 @ 75.028999 Hz
    1280x720 @ 60.000000 Hz
    1152x864 @ 75.000000 Hz
    1280x800 @ 59.810001 Hz
    1440x900 @ 59.887001 Hz
    1280x1024 @ 60.020000 Hz
    1280x1024 @ 75.025002 Hz
    1600x900 @ 60.000000 Hz
    1680x1050 @ 59.953999 Hz
    1920x1080 @ 60.000000 Hz

Output VGA-1 'Unknown Q24 709050660001'
  Current mode: 1600x1200 @ 60.000000 Hz
  Position: 0,0
  Scale factor: 1.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 1
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    720x400 @ 70.082001 Hz
    640x480 @ 59.939999 Hz
    640x480 @ 66.667000 Hz
    640x480 @ 72.808998 Hz
    640x480 @ 75.000000 Hz
    800x600 @ 56.250000 Hz
    800x600 @ 60.317001 Hz
    800x600 @ 72.188004 Hz
    800x600 @ 75.000000 Hz
    832x624 @ 74.551003 Hz
    1024x768 @ 60.004002 Hz
    1024x768 @ 70.069000 Hz
    1024x768 @ 75.028999 Hz
    1152x864 @ 75.000000 Hz
    1280x960 @ 60.000000 Hz
    1440x900 @ 59.887001 Hz
    1440x900 @ 74.984001 Hz
    1280x1024 @ 60.020000 Hz
    1280x1024 @ 75.025002 Hz
    1400x1050 @ 59.978001 Hz
    1680x1050 @ 59.953999 Hz
    1600x1200 @ 60.000000 Hz

Version 1.3.1-1 on manjaro.

Can’t take a screenshot of a non-active tty

Launch Sway in tty2 (WAYLAND_DISPLAY=wayland-0)
Launch another Sway instance in tty3 (WAYLAND_DISPLAY=wayland-1)
From the second Sway instance, launch WAYLAND_DISPLAY=wayland-0 grim test.png

grim then hangs until switching back to tty2 instead of immediately taking a screenshot of the first sway instance.

grim + slurp > "screenshot region is empty"

Hello, i'm using the latest grim installed from pacman (grim-1.2.0-2).
If calling grim (either with slurp getting the coords or when setting them manually) with the -g option, this is the output:

macellatore# grim -g "10,20 300x400" screenshot.png                                                                                                                                           
screenshot region is empty

It broke all of a sudden, last month it was working fine.

Add support for time delayed screenshot

It would be nice if grim can do something like grim -d n to capture with a delay of n seconds

Support format WL_SHM_FORMAT_XBGR8888

My issue #22 has been resolved on the wlroots side, but now grim complains about an unsupported format:
[lucas@btptx4] ~ $ grim test.png
unsupported format 875709016
wlroots apparently provides WL_SHM_FORMAT_XBGR8888, whereas grim expects WL_SHM_FORMAT_XRGB8888.

Please support the format provided by wlroots.

Add argument to crop a rectangle

On the long run, we'll probably want to use layer-shell to select a region (do it in a separate client).

b5ad4f9db599cc58732b94cdd7e4fcdbe895af6a broke png support

The switch statement falls through when built with JPEG support.

This results in all files being JPEG, despite their file suffix:

[cole@xeep:~]$ /nix/store/y5y1rwaqgvjam9pbz2n02my68vd6w2s7-grim-d2508c424465b9000ddfc5681256f53d2adb50be/bin/grim  ~/test.png

[cole@xeep:~]$ file ~/test.png
/home/cole/test.png: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 3840x2158, components 3

grim fails to take screenshot in sway-1.0

I recently updated to sway-1.0 (running current master) on top of X (because of stupid reasons out of my control). When I try to take a screenshot with grim, I get the message "failed to copy output X11-1". Is there something I can do about this? Or is my setup just broken?

Transparent screenshots

Hi,

Grim just grabs fully-transparent images in latest wlroots + sway (Git master).
I also just built grim from source (using the grim-git AUR package for Arch).

Am I missing something?

Fish shell and grim slurp

Hello. I tried to take a screenshot by doing the following:

Select a region and screenshoot it:
grim -g "$(slurp)" screenshot.png

And I get:

❯ grim -g "$(slurp)" screenshot.png
fish: $(...) is not supported. In fish, please use '(slurp)'.
grim -g "$(slurp)" screenshot.png
         ^
❯ grim -g '(slurp)' screenshot.png
invalid geometry

My setup: sway 1.0, fish 3.0.2, slurp 1.1.0-1, grim 1.1.0-2.
Is there a problem with fish compatibility?

Focus stolen long enough from VS Code to hide tooltips

I'm trying to take a screenshot of a VS Code completion list with slurp/grim in sway. To get around the list disappearing when the window isn't focused, I'm just sleeping before using grim/slurp to take the screnshot while having the window focused.

When grim runs, the completion list disappears just as the screenshot gets taken, which means that I can't actually screenshot the thing I'm intending to. This feels like some focus detection thing, where the window is losing focus (and stops the tooltips).

Sorry if this isn't a lot of information to go on; it's hard to show when the issue is with screen capture itself...

Using grim 1.2.0 with slurp 1.2.0, Arch packaged.

Consider generating the output filename if none is specified

`grim -c` causes cursor to shrink

It looks like Sway is improperly rendering my cursor on a blank workspace, with scale=2 on the output. In an attempt to report it, I was attempting to take a screenshot with grim, but found that the cursor is not captured by default. When I do choose to capture the cursor, the behavior is different, and the cursor is shrunk before the screenshot. When the cursor is moved, it snaps back to regular size.

This video demonstrates what I mean: https://photos.app.goo.gl/B5aNvxnMSrZxLWZs7 (Sorry, the stabilization algorithm does some funny things with the terminal output.

I have a feeling this is maybe a result of how cursors work, but wanted to file this to check. Thanks.

Better handle multiple overlapping outputs

Not sure what's the best thing to do here. Here are some ideas:

Don't render an output if another output overlaps completely
Always draw the output with a scale greater than the screenshot scale last (more specifically, greater or equal but the closest)

Ability to output to file and stdout simultaneously.

It would be nice if there were a parameter to output to a file and stdout simulatenously. An example use case is:

grim -g "$(slurp)" ~/Pictures/$(date +'%H%M%S-%Y-%m-%d.png') | wl-copy

Of course, you could also do something like the following:

grim -g "$(slurp)" ~/Pictures/$(date +'%H%M%S-%Y-%m-%d.png') && wl-copy < ~/Pictures/$(date +'%H%M%S-%Y-%m-%d.png')

but that's pretty long and unwieldy, especially when in a Sway config file.

I am happy to implement this if you are open to the idea.

Use the xdg-output protocol to get output layout

Grim is slow

I started using grim on sway, though I have noticed that taking screenshots can take quite a while. I was experimenting with screenshotting each of my 3 displays, doing some image editing on it, and setting it as a lock screen. Though taking a screenshot of each of the 3 outputs takes around 1.6s each:

$ time grim $file_location_left -o DP-4; \
time grim $file_location_center -o DP-1; \
time grim $file_location_right -o DP-5
grim $file_location_left -o DP-4  1.62s user 0.02s system 97% cpu 1.679 total
grim $file_location_center -o DP-1  1.62s user 0.01s system 97% cpu 1.670 total
grim $file_location_right -o DP-5  1.62s user 0.03s system 97% cpu 1.681 total

I wanted to do some profiling, though I don't have any experience with meson. I cannot seem to figure out how to add gprof so I could profile the code and figure out what is taking so long.

List valid outputs

grim is not very helpful when you want to screenshot a single monitor but have no idea what the outputs are called. It should be possible to print a list of valid outputs.

Fails to build on 32bit platforms

Found on FreeBSD i386 and armv7:

../cairo_jpg.c:85:42: error: comparison of integers of different signs: 'ssize_t' (aka 'int') and 'unsigned int' [-Werror,-Wsign-compare]
        if (write((long) closure, data, length) < length) {
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~