Bug 385885

Also sounds a bit like https://bugs.kde.org/show_bug.cgi?id=381528

I can reproduce this issue with Spectacle 17.12.1, same setting as the original reporter: 4k main display + FullHD and some scaling factor applied (1.4 in my case)

However, contrary to the duplicate suggestion (Bug 381528), the cursor correctly apperas and I can perform a sepection - it is just the selection area doesn't correctly show both monitors. Please see the following video: https://youtu.be/BMzENE6t1kE

So I think this bug is valid for its own and reproduceable.

Thanks for the video Clemens, that goes a long way in understanding what "The secondary monitor goes white." from the original report actually means.

I can reproduce the issue in a VM. Preliminary findings:
- Does not depend on compositing vs. non-compositing code path.
- Actual resolution of the monitors is irrelevant, you just need at least two.
- "QT_SCALE_FACTOR=1.4 spectacle -rb" is enough, no need for session scaling.
- Other methods of capturing are fine.
- For 2.1x scaling or different resolutions, the white area can sometimes appear at the bottom.
- The displacement depends on the scaling factor.
- The displacement depends on the amount of overlap of both displays in "kcmshell5 kcm_kscreen".

Thus the issue is probably somewhere in the UI of the rectangular region picker, perhaps only some scaling factor or a term in some calculation missing.

Let us know if you want to try to come up with a patch, we can get you started.

Created attachment 112369 [details]
Incorrect display of screenshot to be cropped

Same issue here.

I'd wager a guess that it's caused by using two monitors in combination with (uneven) scaling (1.5).

Screen 0: minimum 320 x 200, current 4480 x 1440, maximum 8192 x 8192
eDP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
2560x1440     60.00*+  59.99    59.99    59.96    59.95  
1920x1440     60.00  
1856x1392     60.01  
1792x1344     60.01  
2048x1152     59.99    59.98    59.90    59.91  
1920x1200     59.88    59.95  
1920x1080     60.01    59.97    59.96    59.93  
1600x1200     60.00  
1680x1050     59.95    59.88  
1400x1050     59.98  
1600x900      59.99    59.94    59.95    59.82  
1280x1024     60.02  
1400x900      59.96    59.88  
1280x960      60.00  
1440x810      60.00    59.97  
1368x768      59.88    59.85  
1280x800      59.99    59.97    59.81    59.91  
1280x720      60.00    59.99    59.86    59.74  
1024x768      60.04    60.00  
960x720       60.00  
928x696       60.05  
896x672       60.01  
1024x576      59.95    59.96    59.90    59.82
960x600       59.93    60.00
960x540       59.96    59.99    59.63    59.82
800x600       60.00    60.32    56.25
840x525       60.01    59.88
864x486       59.92    59.57
700x525       59.98
800x450       59.95    59.82
640x512       60.02
700x450       59.96    59.88
640x480       60.00    59.94
720x405       59.51    58.99
684x384       59.88    59.85
640x400       59.88    59.98
640x360       59.86    59.83    59.84    59.32
512x384       60.00
512x288       60.00    59.92
480x270       59.63    59.82
400x300       60.32    56.34
432x243       59.92    59.57
320x240       60.05
360x202       59.51    59.13
320x180       59.84    59.32
DP-1 connected 1920x1200+2560+0 (normal left inverted right x axis y axis) 518mm x 324mm
1920x1200     59.95*+
1920x1080     60.00
1600x1200     60.00
1680x1050     59.95
1280x1024     60.02
1280x960      60.00
1024x768      60.00
800x600       60.32
640x480       59.94
720x400       70.08

Two different resolutions to boot.

Trying to select a region to take a screenshot of results in the screen I've attached a photo of. The program seems to take a screenshot that you then select the part you want to crop, however the screenshot taken is not aligned with the actual monitors, so I'm unable to select about half of the screen to the left.

Same here. 2 Screens 3840x2160, side by side, scaled 1.5. When promting for selection the image of the captured screens is moved to the left by half a screen, the remaining half on the other end is filled with white. It's impossible to do a rectangular selection on the left half of the left screen.

KDE 5.12.6

*** Bug 397815 has been marked as a duplicate of this bug. ***

There is a bug in a flameshot app, it is the same that this. 

https://github.com/lupoDharkael/flameshot/issues/227

Maybe is the bug in Qt?

*** Bug 400903 has been marked as a duplicate of this bug. ***

*** Bug 402557 has been marked as a duplicate of this bug. ***

We just rewrote the Rectangular Region mode, so maybe this is fixed! Need to test.

Great! Any way we can help?

If you have a HiDPI multimonitor setup, compile Spectacle from source and give the new rectangular Region mode a whirl!

Here's the documentation: https://community.kde.org/Get_Involved/development

Created attachment 117141 [details]
Screencast

It is wrong for me. I attached a video

Darn. Thanks for testing!

To those who are affected and really need working screenshot tool with rectangular selection I can recommend shutter - it is not KDE based but at least it works. Perhaps Nate can also investigate shutter code to see how come shutter works and not Spectacle.

I'm affected by this, too.

I can only replicate this on the spectacle version version that ships with my distro (18.12.2), it seems to be working fine in the latest git version (19.03.70, commit bda92cd), could someone who was affected by this pull the latest source and try this again?

That would be nice, yes.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

I've tried reproducing it in various combinations of monitors, and it seems that bug is not there anymore for me. Thank you!

Created attachment 118960 [details]
Bug

It is wrong for me. I attached a video (v. 19.07.70)

It is wrong for me. I attached a video (v. 19.07.70)

Okay, thanks to your video I can now reproduce this issue. 
On my system it seems to occur when DPI scaling is enabled (using QT_SCALE_FACTOR=1.4 to test) 
and my left monitor is set to a lower resolution than my right monitor, which is similar to the configuration shown in your video. 
The whole overlayed rectangle selection interface seems to be shifted left or right, depending on which monitor is selected as the primary one.
Note that this does NOT happen when my right monitor is set to a lower resolution than the left one or both are set to the same resolution. 
I don't know what configurations could cause issues if you have >2 monitors as I don't have the hardware to test that.

I'm gonna peruse the code a bit, maybe I can figure out why this is happening...

Yes, exactly! see my comment #c5 :)

Nice, great investigation!

*** Bug 410096 has been marked as a duplicate of this bug. ***

The rectangular Region mode is a full screen window/widget painted with full screenshot, and users draw a rectangle on it. You can still select all area in the window. Actually everything works fine, just the window was placed in a wrong position. Sometimes it is left offset, sometimes it is top offset.

So I guess it is a KWin related. Maybe KWin developers can help with it.

Created attachment 121692 [details]
Similar issue with Qt Creator window

When I was about to use Qt Creator to test something, I get this wired window: all content are moved left. I can also reproduce it with Kate and some other Qt app. No matter how I resize the window it doesn't help. Look similar to this bug. If it happens to different software, no matter window position or widget position, then it is more likely a Qt issue.

I opened a bug ticket at Qt website. Subscribe if you are interested!
https://bugreports.qt.io/browse/QTBUG-77149

Thanks so much!

I fixed a similar dual screen hidpi rendering issue with Kate/KonsolePart https://bugs.kde.org/show_bug.cgi?id=411965

However, I am still not sure what is the cause. Kai Uwe Broulik said it may be caused by winId() function call. And I do find a usage in Spectacle. I am trying to remove it and see if it fix the issue.

Find this line in QuickEditor.cpp:

setGeometry(0, 0, static_cast<int>(mPixmap.width() * dprI), static_cast<int>(mPixmap.height() * dprI));

I have a 1920x1080 and 2560x1440 setup with x1.5 scale side by side. If I change the width to 2560 or less, it works:

setGeometry(0, 0, 2560, static_cast<int>(mPixmap.height() * dprI));

Anything bigger causes rendering issue:

setGeometry(0, 0, 2561, static_cast<int>(mPixmap.height() * dprI));

If I log the geometry x position, it is set to 0 but in each paintEvent, it is changed to -640:

qDebug() << geometry().left();

I made a patch and it works very well on my set up. But I need more test with different monitor configuration. Try out if you know how to compile it https://phabricator.kde.org/D24034

I've just uninstall xf86-video-intel and I use driver of the kernel.
Now, Spectacle works right.

Created attachment 123859 [details]
Spectacle without xf86-video-intel

My system doesn't have xf86-video-intel. But still have the issue.

Here is a bug of Kdenlive that caused by intel gpu driver. https://invent.kde.org/kde/kdenlive/issues/277

This sounds interesting. So all people that can reproduce this issue, what GPU you are using (vendor, model, driver)? This may help us to narrow down the issue.

I'm using GTX980M under Arch Linux with Nvidia proprietary driver.

Here's something I noticed about this bug while playing around with xprop. I ran this command:

    $ sleep 5; xprop -id $(xdotool search --pid `pidof spectacle`)

and ran spectacle --region in the 5 second grace period before the command ran. Here is a section of the output:

------------------------------------[ begin output ]-----------------------------------------------
_NET_WM_NAME(UTF8_STRING) = "Spectacle"
WM_CLASS(STRING) = "spectacle", "spectacle"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_W
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                user specified location: -864, 0
                user specified size: 11583 by 2159
                program specified resize increment: 1 by 1
                program specified base size: -1 by -1
                window gravity: Static
------------------------------------[  end output ]-----------------------------------------------


That's funny. "User specified location" is negative by the exact amount of pixels the preview gets offset by (and user specified size is one pixel less than my desktop resolution — 11584 x 2160).

I assume this is the spectacle's "select rectangular region" window on which one draws rectangular selection. The "easy" solution/workaround for this bug could be to set spectacle's rectangular select window location to 0,0 and disallow other offsets (especially the negative ones, as they'd put spectacle off screen).



# TRYING WORKAROUNDS — UNSUCCESSFUL

I'm just leaving this here in order to save two minutes of anyone who thinks about trying to work around this bug with kwin window rules. Specifying kwin window rules didn't work. I tried the following:

In 'window matching' tab:
 * 'spectacle' for window class (substring match)
 * 'Spectacle' (exact match) for window title (WM_CLASS and _NET_WM_NAME))
 * all window types selected

In 'size&position' tab:
 * [*] Position       Force     0,0

Nothing happened. Spectacle kept being offset.



# TRYING WORKAROUND — SUCCESSFUL

0. Create and open new file. 
1. Paste this in (indent optional, it's present for visibility reasons)

    #!/bin/bash
    (sleep 2; xdotool windowmove $(xdotool search --pid `pidof spectacle` | tail -n 1) 0 0) & spectacle --region

2. Save the file. Make it executable.
3. Go to custom keyboard shortcuts. Create new shortcut. You can use the same keyboard shortcut as you already do (the old shortcut is useless anyway) or use a new one.
3. In the 'Action' tab, select this file as command/url
4. That's it, really

Some side notes:
 * You absolutely DO need to put that command in a file. The command from step 1 didn't work if used as command directly. I had to put it in a file. 
 * If this still doesn't work for you, try adding the file to your $PATH on startup
 * Just as a curiosity — according to my experience playing around in the terminal, it seems important that the xdotool bit goes first and spectacle last. If I tried to run it the other way around, that is:
    
    spectacle --region & sleep 5; <xdotool stuff>

Nothing would happen in this case.

Side side note: I don't know enough about C/C++ to whip up a proper patch for this or else I would.

Wayland is not affected.

A possibly relevant merge request was started @ https://invent.kde.org/graphics/spectacle/-/merge_requests/18

Git commit ccf8d5220dc5ac2a5722247386d6cde82494dbb3 by Vlad Zahorodnii.
Committed on 06/09/2020 at 09:22.
Pushed by vladz into branch 'release/20.08'.

Properly position QuickEditor when HiDPI support is on

Currently, the position for the quick editor is specified in the native
pixels. But, when the HiDPI support is turned on, QWidget::setGeometry()
expects the specified geometry to be in the device-independent pixels.
FIXED-IN: 20.08.2

M  +40   -4    src/QuickEditor/QuickEditor.cpp

https://invent.kde.org/graphics/spectacle/commit/ccf8d5220dc5ac2a5722247386d6cde82494dbb3

I hate to bring this up again but It's an issue again.

I'm on Manjaro, KDE Plasma 5.27.10, Qt 5.15.12,  X11. Spectacle is version 23.08.4

Trying to use the rectangle selection tool creates an offset and basically tears the screen in halves.

Created attachment 165094 [details]
Offset issue in 23.08.4

Not sure if it's this bug, #400921, something new or something I didn't find in the BTS but on my dual-monitor setup with HiDPI the screen gets turned black when using the spectacle selection. Disabling the second monitor in kscreen makes the bug disappear so it's similar to this bug but black screen as opposed to some corruption makes it similar to #400921. And it worked on earlier software versions but it's hard to say when it broke as I upgraded from a couple years old configuration before noticing this. The configuration details are below.

Software: today's Debian Unstable, Spectacle 23.04.2, Plasma 5.27.10, X 7.7, Qt 5.15.10, nVidia drivers 535.86.10.
Setup: a desktop nVidia card with a 2160p monitor on DP-4 and a 1080p monitor connected on HDMI-0, with a "{viewportin=3840x2160, ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}" xorg.conf incantation scaling the 1080p one to match the 2160p one. And the global scaling in kscreen is set to 200%.
What happens: when I start the selection mode in spectacle, the 1080p monitor gets the usual gray overlay but the 2160p one gets fully black, with the spectacle UI correctly drawn on top of that. But if I disable the 1080p one in kscreen and start spectacle again it works correctly.

It's almost certainly a different bug (even if the result looks the same), since Spectacle has been rewritten since the original one was opened.