Bug 385885 - Multi-monitor HiDPI screens with scaling: Rectangular Region mode causes graphical corruption on one of the screens
Summary: Multi-monitor HiDPI screens with scaling: Rectangular Region mode causes grap...
Alias: None
Product: Spectacle
Classification: Applications
Component: General (show other bugs)
Version: unspecified
Platform: Neon Linux
: HI normal
Target Milestone: ---
Assignee: Boudhayan Gupta
URL: https://bugreports.qt.io/browse/QTBUG...
Keywords: usability
: 397815 400903 402557 410096 (view as bug list)
Depends on:
Reported: 2017-10-18 00:56 UTC by Wyatt Childers
Modified: 2020-09-06 09:30 UTC (History)
19 users (show)

See Also:
Latest Commit:
Version Fixed In: 20.08.2

Incorrect display of screenshot to be cropped (3.27 MB, image/jpeg)
2018-05-02 06:48 UTC, Dennis Irrgang
Screencast (2.43 MB, video/x-matroska)
2018-12-28 09:26 UTC, Rober
Bug (1.64 MB, video/x-matroska)
2019-03-21 13:11 UTC, Rober
Similar issue with Qt Creator window (42.63 KB, image/png)
2019-07-23 11:19 UTC, Guo Yunhe
Spectacle without xf86-video-intel (1.37 MB, video/x-matroska)
2019-11-12 11:17 UTC, Rober

Note You need to log in before you can comment on or make changes to this bug.
Description Wyatt Childers 2017-10-18 00:56:03 UTC
This may be a duplicate of: https://bugs.kde.org/show_bug.cgi?id=357022.

However, it seemed different enough, I figured it warranted a report.

Reproduction Steps:
1. Set DPI Scaling to 2x on a multi monitor system
2. Relogin
3. Take a screen shot using Rectangular Region mode
Actual result:
The secondary monitor goes white.

Expected result:
The rectangular region tool works the same with and without scaling.

Reproduced on KDE 5.11.1 using both native 4k and HD resolution hardware.
Comment 1 Nate Graham 2017-10-18 17:01:59 UTC
Also sounds a bit like https://bugs.kde.org/show_bug.cgi?id=381528
Comment 2 Clemens Eisserer 2018-03-16 12:16:27 UTC
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.
Comment 3 null 2018-03-17 07:27:43 UTC
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.
Comment 4 Dennis Irrgang 2018-05-02 06:48:38 UTC
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.
Comment 5 Michael Reiher 2018-08-24 12:17:37 UTC
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
Comment 6 Nate Graham 2018-08-24 17:26:28 UTC
*** Bug 397815 has been marked as a duplicate of this bug. ***
Comment 7 Rober 2018-11-13 15:25:35 UTC
There is a bug in a flameshot app, it is the same that this. 


Maybe is the bug in Qt?
Comment 8 Nate Graham 2018-11-14 22:27:31 UTC
*** Bug 400903 has been marked as a duplicate of this bug. ***
Comment 9 Nate Graham 2018-12-26 23:32:32 UTC
*** Bug 402557 has been marked as a duplicate of this bug. ***
Comment 10 Nate Graham 2018-12-26 23:34:16 UTC
We just rewrote the Rectangular Region mode, so maybe this is fixed! Need to test.
Comment 11 bj.cardon 2018-12-27 05:22:56 UTC
Great! Any way we can help?
Comment 12 Nate Graham 2018-12-28 03:16:56 UTC
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
Comment 13 Rober 2018-12-28 09:26:20 UTC
Created attachment 117141 [details]
Comment 14 Rober 2018-12-28 09:27:45 UTC
It is wrong for me. I attached a video
Comment 15 Nate Graham 2018-12-28 15:18:28 UTC
Darn. Thanks for testing!
Comment 16 Karol Bryd 2019-01-30 09:14:29 UTC
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.
Comment 17 Mike Krutov 2019-02-20 10:50:04 UTC
I'm affected by this, too.
Comment 18 Nils Rother 2019-03-06 19:35:43 UTC
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?
Comment 19 Nate Graham 2019-03-06 19:44:13 UTC
That would be nice, yes.
Comment 20 Bug Janitor Service 2019-03-21 04:33:08 UTC
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:

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!
Comment 21 Mike Krutov 2019-03-21 09:00:21 UTC
I've tried reproducing it in various combinations of monitors, and it seems that bug is not there anymore for me. Thank you!
Comment 22 Rober 2019-03-21 13:11:35 UTC
Created attachment 118960 [details]

It is wrong for me. I attached a video (v. 19.07.70)
Comment 23 Rober 2019-03-21 13:14:50 UTC
It is wrong for me. I attached a video (v. 19.07.70)
Comment 24 Nils Rother 2019-03-21 14:44:38 UTC
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...
Comment 25 Michael Reiher 2019-03-21 15:28:37 UTC
Yes, exactly! see my comment #c5 :)
Comment 26 Nate Graham 2019-03-25 00:06:01 UTC
Nice, great investigation!
Comment 27 Nate Graham 2019-07-22 17:34:24 UTC
*** Bug 410096 has been marked as a duplicate of this bug. ***
Comment 28 Guo Yunhe 2019-07-23 11:10:31 UTC
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.
Comment 29 Guo Yunhe 2019-07-23 11:19:54 UTC
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.
Comment 30 Guo Yunhe 2019-07-23 11:36:27 UTC
I opened a bug ticket at Qt website. Subscribe if you are interested!
Comment 31 Nate Graham 2019-07-23 14:42:31 UTC
Thanks so much!
Comment 32 Guo Yunhe 2019-09-16 17:31:33 UTC
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.
Comment 33 Guo Yunhe 2019-09-17 13:22:45 UTC
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));
Comment 34 Guo Yunhe 2019-09-17 14:18:05 UTC
If I log the geometry x position, it is set to 0 but in each paintEvent, it is changed to -640:

qDebug() << geometry().left();
Comment 35 Guo Yunhe 2019-09-17 20:13:33 UTC
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
Comment 36 Rober 2019-11-12 11:13:25 UTC
I've just uninstall xf86-video-intel and I use driver of the kernel.
Now, Spectacle works right.
Comment 37 Rober 2019-11-12 11:17:38 UTC
Created attachment 123859 [details]
Spectacle without xf86-video-intel
Comment 38 Guo Yunhe 2019-11-12 11:27:28 UTC
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.
Comment 39 Frederick Zhang 2019-11-13 05:59:23 UTC
I'm using GTX980M under Arch Linux with Nvidia proprietary driver.
Comment 40 tamius.han 2020-01-08 22:24:30 UTC
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"
                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).


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.


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

    (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.
Comment 41 Méven Car 2020-04-30 09:10:38 UTC
Wayland is not affected.
Comment 42 Bug Janitor Service 2020-09-04 12:23:54 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/spectacle/-/merge_requests/18
Comment 43 Vlad Zahorodnii 2020-09-06 09:30:29 UTC
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