transparent-clipping and screenshot tools

[seqizz]

If you enable transparent-clipping, screenshot tools are making whole screen transparent. You can test it via either flameshot or maim. I was expecting that excluding focus + setting transparency to 100 specifically for it to work, but sadly it didn't.

Platform

Linux amd64 (NixOS 21.05)

GPU, drivers, and screen setup

Nothing special:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Mesa Intel(R) Xe Graphics (TGL GT2) (0x9a49)
    Version: 21.0.1
    Accelerated: yes
    Video memory: 3072MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) Xe Graphics (TGL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 21.0.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 21.0.1
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.0.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Environment

Awesomewm latest

picom version

v8.2

Diagnostics

``` > picom --experimental-backends --diagnostics **Version:** v8.2 ### Extensions: * Shape: Yes * XRandR: Yes * Present: Present ### Misc: * Use Overlay: No (Another compositor is already running) * Config file used: /home/gurkan/.config/picom.conf ### Drivers (inaccurate): modesetting ```

Configuration:

Configuration file

``` wintypes: { tooltip = { fade = true; shadow = true; opacity = 0.95; focus = true; full-shadow = false; }; utility = { opacity = 0.9; }; menu = { opacity = 0.9; }; popup_menu = { opacity = 0.9; shadow = false; } dropdown_menu = { opacity = 0.9; shadow = false; } }; blur-background = true; blur-background-fixed = true; blur: { method = "gaussian"; size = 10; deviation = 5.0; }; blur-background-exclude = [ "window_type = 'dock'", "window_type = 'desktop'", "class_g = 'slop'", "_GTK_FRAME_EXTENTS@:c" ]; no-fading-openclose = true; use-ewmh-active-win = true; detect-client-opacity = true; backend = "glx"; # slock focus-exclude = [ "! name ~= '' " ]; shadow = true; shadow-radius = 5; shadow-offset-x = -5; shadow-offset-y = -5; shadow-opacity = 0.5; shadow-exclude = [ "class_g = 'TelegramDesktop' && argb", "_NET_WM_WINDOW_TYPE:a = '_NET_WM_WINDOW_TYPE_NOTIFICATION'", "class_g = 'Daily' && argb", "class_g = 'Mail' && argb", "bounding_shaped", "_GTK_FRAME_EXTENTS@:c", "class_g = 'Firefox' && !window_type *= 'menu'", "bounding_shaped && !rounded_corners" ]; ```

Steps of reproduction

1. start picom with picom --experimental-backends --transparent-clipping
2. run either maim or flameshot gui

Expected behavior

A way to ignore screenshot "overlay" so we can see what we want to select on screenshot tool

Current Behavior

Overlay makes everything transparent

[stefanradziuk]

Ran into the same issue when using slop with transparent-clipping enabled. Would be useful to have a way of disabling transparent-clipping per window class.

[BuddhiLW]

I have this script which is working. I use my graphics card to run picom, but not necesserly you have to do that.

Anyways, my solution at the moment is to kill picom; take the shot; run picom again. I believe this is sensible and in accord to UNIX philosophy. This way you are composing scripts and programs, instead of trying to make picom do everything.

#!/bin/sh

# This is bound to Shift+PrintScreen by default, requires maim. It lets you
# choose the kind of screenshot to take, including copying the image or even
# highlighting an area to copy. scrotcucks on suicidewatch right now.

kill $(pidof picom)
case "$(printf "a selected area\\ncurrent window\\nfull screen\\na selected area
(copy)\\ncurrent window (copy)\\nfull screen (copy)" | dmenu -l 6 -i -p
"Screenshot which area?")" in
  "a selected area") maim -s pic-selected-"$(date '+%y%m%d-%H%M-%S').png" ;;
  "current window") maim -i "$(xdotool getactivewindow)" pic-window-"$(date '+
%y%m%d-%H%M-%S').png" ;;
  "full screen") maim pic-full-"$(date '+%y%m%d-%H%M-%S').png" ;;
  "a selected area (copy)") maim -s | xclip -selection clipboard -t image/png ;;
  "current window (copy)") maim -i "$(xdotool getactivewindow)" | xclip -
selection clipboard -t image/png ;;
  "full screen (copy)") maim | xclip -selection clipboard -t image/png ;;
esac
prime-run $(picom --experimental-backends)

Hope it helps.

Proof of work:

[BuddhiLW]

If this satisfies you, please awnser. So, we can close the issue (picom has a lot of them open right now, and most of them landing in composability-problems, instead of picom-working-problem).

[stefanradziuk]

@BuddhiLW

I have this script which is working. I use my graphics card to run picom, but not necesserly you have to do that.

Anyways, my solution at the moment is to kill picom; take the shot; run picom again. I believe this is sensible and in accord to UNIX philosophy. This way you are composing scripts and programs, instead of trying to make picom do everything.

I haven't run your script but looking at it it seems like the screenshots won't show the effects of picom which is a significant caveat. The goal here is not to make picom do everything and excluding selected windows from transparent-clipping is similar in design to other exclusion lists picom already has (shadow-exclude, blur-background-exclude etc). The desired effect can be achieved with just a few lines of code as seen in #738

[seqizz]

I'm closing this since it seems like it's fixed now. At least it doesn't break anymore on my system neither with flameshot nor maim anymore (using latest master build).

[SolsticeSpectrum]

It is still an issue with peek, tool for recording gifs. Any solutions?

[yshui]

@DarkReaper231 there is a pull request: #738

[SolsticeSpectrum]

@DarkReaper231 there is a pull request: #738

Would you mind merging? Having self built packages in arch can be quite tricky when you for example release new bug fixes.

[SolsticeSpectrum]

Works like a charm with latest commit

[yshui]

@DarkReaper231 thanks for confirming!