[Bug]: Incorrect Screenshot/Video Region Selection Behaviour in Multi-Screen Set-Ups

[Chiitoo]

Contact Details (e.g. Tox ID or email)

No response

qTox Version

v1.18.2-16-gc6a756608

Commit Hash

c6a7566

Toxcore Version

0.2.20

Qt Version

6.8.1

Steps to reproduce

1. Set up a desktop environment with multiple displays.
2. Start qTox.
3. Use the 'Send a screenshot' tool in a chat.

Observed Behavior

Example configuration:

[ 2560x1440+0+0 ] [ 2560x1440+2560+0 ] [ 1920x1080+5120+0 ]

Here, running the screenshot grabber will darken and let the user select an area in the size of 1920x1080 in the left-most display, with the actual screen content being from the primary display in the middle.

Disabling the right-most display will have a similar effect, only the size of the capture area is then correct (likely only because the primary display is using the same resolution).

Using the Select region for a video source behaves in the same way, and this seems to happen already at the initial Qt 6 refactoring.

Expected Behavior

The whole screen area is available for the screenshot/video grab.

Reproducibility

Always

Operating System

Linux

Operating System version/distro/name/etc.

Gentoo Linux

Relevant log output

[iphydf]

This should be fixed in #457, if it's convenient for you to test that, I'd be happy to get feedback on it.

[Chiitoo]

This should be fixed in #457, if it's convenient for you to test that, I'd be happy to get feedback on it.

Will do, though at this time it seems to be in need of a rebase.

[iphydf]

I've rebased it.

[iphydf]

Is this a regression from 1.17? I see the screenshot grabber (including in the old version) is using QGuiApplication::primaryScreen() for things. I can't easily fix this bug because I don't have an X11 system. Contributions welcome :).

[Chiitoo]

Yes, I do believe it starts with the very first Qt 6 build, while it still works with my custom Qt 5 build.

[Chiitoo]

Er, I mean not in 1.17 yet.

That said, my latest Qt 5 builds are from "git master", not from the last release, but in any case, I suppose something there has changed in Qt 6 (could even be a Qt bug, hmmm).

[Chiitoo]

A bit confusing there are some QApplication uses instead [1]

::primaryScreen()`

...what the Helck is with this ctrl+enter == submit comment... urgh... as I was saying:

Some are QApplication instead of QGuiApplication [1], not that changing it makes any difference.

1. https://github.com/TokTok/qTox/blob/master/src/widget/tool/screenshotgrabber.cpp#L36

[Chiitoo]

Actually, it seems the selection area is only 1706x960, not 1920x1080 as I initially thought.

Also, if I change

QScreen* screen = QGuiApplication::primaryScreen();

to something like

QScreen* screen = QGuiApplication::screenAt(QCursor::pos());

at

https://github.com/TokTok/qTox/blob/master/src/widget/tool/screenshotgrabber.cpp#L208

and then initiate the screenshot on the left-most display, the content seems more correct, and I can even select all of the displays for the screenshot, though the selection area is still only that 1706x960 visibly.

Also, if the window is in the middle, or the right-most display when starting it, the screenshot area always starts from 0x0, that is, the left-most display, and one or more displays from the left is "dropped out".

If I start the screenshot in the right-most display, and then start "painting" from top left corner of the left-most display and go as far to the lower right in the right-most display, the actual screenshot will only have content from the right-most display, and everything to the right after that is just black.

Furthermore, the sizes look OK when I look at them via debug messages, like rec: QRect(0,0 7040x1440) and screen: QScreen(0x560cea1ec840, name="DisplayPort-1").

Iif I manually set the area at

https://github.com/TokTok/qTox/blob/master/src/widget/tool/screenshotgrabber.cpp#L74

to something like QPoint(0,0), QSize(5960, 1440), reducing the horizontal size by the size of the 1080p display, then the selection area actually fills the two larger displays as normal... except again, the middle display content is on the left-most display, while the middle display shows the content of the right-most display (anything going beyond the 1080p resolution being filled with black).

When the setGeometry extends to the third display even by 1 pixel, the selection area is again that 1706x960 in the left-most display.

I hope at least some of this makes at least some sense. I think I feel more confused while trying to put it all into words myself...

I need a nap!

[Chiitoo]

Guessing now that part of the weirdness is from removing use of desktop(), which is no more in Qt 6, at

https://github.com/TokTok/qTox/blob/master/src/widget/tool/screenshotgrabber.cpp#L213

and while grabWindow(0) does grab the whole screen, it's relative to the screen it happens on.

While I have managed to get the grab start from 0,0 of the left-most display, the overlay for selecting an area is still acting weird when the grab area extends to the third display, perhaps due to the different resolution, I'm not sure about that yet.

Here are some possibly relevant Qt bugs:

• https://bugreports.qt.io/browse/QTBUG-94748
• https://bugreports.qt.io/browse/QTBUG-112991
• https://bugreports.qt.io/browse/QTBUG-119538
• https://bugreports.qt.io/browse/QTBUG-129280

There is a simple screenshot application ( https://github.com/lxqt/screengrab ) that has a very similar feature, and it works okay still for me after the Qt 6 migration, so at least it should be possible to restore here too.

[Chiitoo]

I have a funny workaround where I give the overlay window scrollbars and frames so that I can move it around, and its content around.

Feel like it's a bug in QGraphicsView or/and QGraphicsScene.

[iphydf]

Since screengrab works, maybe we can adopt their code into qTox?

[Chiitoo]

Yeah, that is what I was kind of trying to do, but need to probably change things quite a bit... and would be nice to find out if it really is a Qt bug in any case.

I'll try to come up with a minimal example to re-produce it and file a Qt bug for it.