[nvidia] Screenshot feature seems to be broken

[Poly-cryptic]

The screenshot feature seems to broken for me and instead of a screenshot, a gray background pops up. These errors are probably related.

[LOG] [gl] GL_INVALID_OPERATION error generated. and are incompatible [LOG] [gl] GL_INVALID_OPERATION error generated. and are incompatible [LOG] [gl] GL_INVALID_OPERATION error generated. and are incompatible

Here is my config:

background { monitor = path = screenshot }

I have attached a full verbose log.

log.txt

[vaxerski]

nvidia?

[Poly-cryptic]

Yeah, NVidia, I don't know how I forgot that crucial detail.

[vaxerski]

https://github.com/ValveSoftware/gamescope/issues/708#issuecomment-1436051840

I am unsure how to check if a modifier is marked as such, I've asked on IRC. Will try to figure something out.

[vaxerski]

patch4.txt hey hey try this

[Poly-cryptic]

It doesn't seem to change anything whatsoever.

log-patch1.txt

[vaxerski]

:(

[vaxerski]

patch69.txt try this :D

[Poly-cryptic]

Nothing changed again sadly...

log-patch2.txt

[vaxerski]

patch69.txt wont fix anything but add a few logs

[Poly-cryptic]

log-patch3.txt

[vaxerski]

are you on 10bit?

[Poly-cryptic]

To be honest, I don't know. How should I go about checking that?

[vaxerski]

if you didnt explicitly set 10 bit you aren't running it. you can enable it by adding ,bitdepth,10 to your monitor configs in hyprland.

Maybe worth trying, I remember issues in xdph around screensharing on nvidia without 10 bit

[Poly-cryptic]

Yeah I don't have that enabled and enabling it didn't change anything.

[vaxerski]

:(

All issues I see regarding this error is that it happens because nvidia doesn't support importing buffers with linear modifiers, but we filter those unsupported mods and gbm chooses a non-linear one :(

I dont know honestly

[vaxerski]

I've committed the patch regardless as it's the correct thing to do anyways. Maybe I'll look into this more tomorrow, I've asked on IRC but it's kinda late and simon zeni doesnt know wtf is up and neither do I

[Poly-cryptic]

Yeah, thank you for the quick support. This is why I choose Hyprland.

[NoisyFlake]

Same issue, using nvidia-dkms 535 driver.

[nosduco]

Also seeing this using nvidia-dkms 550 driver

[hamishneu]

same issue using nvidia 550 driver, heres my hacky solution:

first set the path to a temp location

background {
path = /tmp/screenshot.png
}

then, every time you run hyprlock, take a screenshot of the monitor and save it to this location

grim -o DP-1 /tmp/screenshot.png && hyprlock

et voilà

[cxOrz]

why not use a more compatible way to implement this feature, to capture the screenshot, then save to some temp directory, and use the screenshot.

Then it could work on any graphic card.

[vaxerski]

because it's slow and wasteful. We can get the screenshot to a cpu buffer, it's just slow.

[cxOrz]

I've tried hyprpicker just now, seems it can grab a "screenshot", then pick color directly on the screen. Works on my nvidia card. Is it possible to refer to this implementation? :smile:

[vaxerski]

hyprpicker is not gpu-accelerated, so it grabs a cpu buffer, exactly what I said, it's slow.

[samos667]

same issue using nvidia 550 driver, heres my hacky solution:

first set the path to a temp location

background {
path = /tmp/screenshot.png
}

then, every time you run hyprlock, take a screenshot of the monitor and save it to this location

grim -o DP-1 /tmp/screenshot.png && hyprlock

et voilà

You can use "-l 0" as option of grim command to not compress screenshot and make command execution 4-5x more fast:

This makes a big difference when using multi-screen and/or high-resolution displays.

btw f*ck nv*dia everyday

[samos667]

For multiscreen, you can also use the screenshot commands in parallel. This will speed things up a bit too:

#!/usr/bin/env bash

grim -o HDMI-A-1 -l 0 /tmp/hyprlock_screenshot1.png & # run this command in background
grim -o DP-1 -l 0 /tmp/hyprlock_screenshot2.png & # idem
wait && # wait background commands to finish
hyprlock # so hyprlock will only start when screenshot(s) are done

Edit: For my case, I don't need to wait finally

#!/usr/bin/env bash

grim -o HDMI-A-1 -l 0 /tmp/hyprlock_screenshot1.png & # run this command in background
grim -o DP-1 -l 0 /tmp/hyprlock_screenshot2.png & # idem
# wait && # wait background commands to finish. But if hyprlock spawn time (at least until the background image pick step) > the time to take the screeshot(s), you don't have to wait at all :')
hyprlock # so hyprlock will only start when screenshot(s) are done

[samos667]

It's a silly (and certainly naive) question, but in the future, with the open kernel module https://github.com/NVIDIA/open-gpu-kernel-modules is there a chance that NVIDIA hardware will get better support in the Linux ecosystem ? Or have the red team won once and for all ?

[Arroquw]

Why not put us nvidia users up with a slow (but working) way until nvidia finally decides to do something about this?

[vaxerski]

because nobody can be arsed to code it, it seems

[TotalTaxAmount]

Any update on this?