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.
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.