grimblast: add environment var 'GRIMBLAST_HIDE_CURSOR' to avoid high CPU loads on some machines

[DHDcc]

Description of changes

fixes #134

The grim cursor is not visible by default, but if your machine has high CPU loads you can add env = GRIMBLAST_HIDE_CURSOR, 0 to your Hyprland config file (the grim cursor will be visible).

Things done

• For new programs

  • Add the program to the README table, with yourself as the maintainer
  • Add a README for the program itself
  • Add Makefile (and Nix derivation optionally, otherwise @fufexan will do it)
  • If the program is a script, add it to the CI checks matrix

• For changes

  • Add changes to the CHANGELOG
  • Reflect your changes in the man pages (if they exist)

[DHDcc]

@Atemo-C @Gigas002 can you two try this?

[Atemo-C]

The screenshot cursor is back.

[DHDcc]

The screenshot cursor is back.

@Atemo-C, you need to add env = GRIMBLAST_HIDE_CURSOR, 1 in your hyprland config file or export GRIMBLAST_HIDE_CURSOR=1 in your uwsm env file.

[Atemo-C]

Did you add "env GRIMBLAST_HIDE_CURSOR, 1" in your hyprland config file or your uwsm env file?

Oh my hyprgod, I am actually blind… No, I did not. Adding it fixes it, and it works now. However, I now cannot take an area screenshot of my second monitor, with the following error:

grimblast: line 171: kill: (148500) - No such process

And the following notification:

This only happens when taking a screenshot that is only or includes part of my second monitor. Taking screenshots on my main one works fine, and the cursor does not appear when it should not.

[DHDcc]

Did you add "env GRIMBLAST_HIDE_CURSOR, 1" in your hyprland config file or your uwsm env file?

Oh my hyprgod, I am actually blind… No, I did not. Adding it fixes it, and it works now. However, I now cannot take an area screenshot of my second monitor, with the following error:

grimblast: line 171: kill: (148500) - No such process

And the following notification:

This only happens when taking a screenshot that is only or includes part of my second monitor. Taking screenshots on my main one works fine, and the cursor does not appear when it should not.

yeah, I have the same issue on my main monitor but I don't think it's caused by this patch (I can still take screenshots) :

+ killHyprpicker
+ '[' '!' 173171 -eq -1 ']'
+ kill 173171
./grimblast: line 171: kill: (173171) - No such process
+ rm -f /run/user/1000/grimblast.lock

[Atemo-C]

yeah, I have the same issue but I don't think it's caused by this patch (I can still take screenshots) :

+ killHyprpicker
+ '[' '!' 173171 -eq -1 ']'
+ kill 173171
./grimblast: line 171: kill: (173171) - No such process
+ rm -f /run/user/1000/grimblast.lock

Strange… When using Grimblast from the unstable pkgs in NixOS, or the previously patched version with the fake display workaround that was too CPU intensive, it worked just fine on my second monitor. I will have to do some more testing.

Edit: Actually, the problem does go back to the previous patches with the fake display workaround, I must have missed it in testing earlier.

[Atemo-C]

51f3cf5

This is when the issue started appearing, and it is still here, though, again, only on my second monitor.

[DHDcc]

51f3cf5

This is when the issue started appearing, and it is still here, though, again, only on my second monitor.

It started before 51f3cf5:

edit: the bad commit actually stated at f4bea56

[Atemo-C]

edit: the bad commit actually stated at f4bea56

Oh wow, goes bad quite a bit further than I thought.

[Gigas002]

The env variable works for me, but as @Atemo-C noted the cursor is visible when it's set

[DHDcc]

Is it better if the cursor is not visible by default @Atemo-C @Gigas002 ?

[Atemo-C]

Is it better if the cursor is not visible by default @Atemo-C @Gigas002 ?

I see no reason for the cursor to be visible by default unless --cursor is used.

[Atemo-C]

With the latest changes, the error still appears when taking screenshots of my second monitor; However, the screenshot is actually taken and saved/copied properly, so the error saying it cannot invoke grim seems erroneous.

Example here of a screenshot spanning both my monitors.

[DHDcc]

With the latest changes, the error still appears when taking screenshots of my second monitor; However, the screenshot is actually taken and saved/copied properly, so the error saying it cannot invoke grim seems erroneous.

Example here of a screenshot spanning both my monitors.

The bad commit wasn't me so I can't fix this issue for now. You can create a new issue for that.

[DHDcc]

@fufexan

[Atemo-C]

The bad commit wasn't me so I can't fix this issue for now. You can create a new issue for that.

I created it here, includes a possible fix, too. With all of this put together, every single function now works as expected, nothing to say.

[fufexan]

Looks good, but we should also add an entry in the manual and in the help section, informing users that if they get double cursors when screenshotting area, they should set the env var.

[DHDcc]

if they get double cursors when screenshotting

I changed the logic so that by default, the cursor is not visible and if you have high CPU loads, you can add env = GRIMBLAST_HIDE_CURSOR, 0.

[DHDcc]

It should be good now.