Summary: | file area becomes inaccessible for the mouse after opening a file on hidpi screen when using a multi monitor setting | ||
---|---|---|---|
Product: | [Applications] dolphin | Reporter: | moert09 |
Component: | view-engine: general | Assignee: | Dolphin Bug Assignee <dolphin-bugs-null> |
Status: | REOPENED --- | ||
Severity: | grave | CC: | brian, danielkza2, d_p_leone, elvis.angelaccio, faure, grumpfl, hsanson, kde, kdebugtracker, mads, mailad34, martijnvdc, miabraha, nate, pauloedgarcastro, romuluspb, rrockers, seanvk, simonandric5, wim.delvaux, yannick.leteigner, yuxin.ma1989 |
Priority: | NOR | ||
Version: | 16.12.2 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | https://commits.kde.org/kio/e10f44d87270ca6f8e509a99f6df17c8a31fbfa8 | Version Fixed In: | 5.35 |
Sentry Crash Report: |
Description
moert09
2016-05-26 13:28:24 UTC
the actual dolphin version is 16.04.1 Exactly the same behaviour here. The only QT_* variables defined are: $ set | grep QT_ QT_DEVICE_PIXEL_RATIO=2 QT_IM_MODULE=xim The issue doesn't happen if I unset QT_DEVICE_PIXEL_RATIO. Dolphin Version 15.12.3 Using: KDE Frameworks 5.23.0 Qt 5.6.1 (built against 5.6.0) The xcb windowing system I'm getting the same thing with current KDE Neon. (Plasma 5.6.1, Frameworks 5.24.0, Dolphin 16.04.2) On my center monitor, mouse clicks register correctly on the right half of the Dolphin window but not on the left half. Took a closer look at this bug since I'd quite like it fixed. In KItemListController.cpp around line 529, the function: bool KItemListController::mousePressEvent(QGraphicsSceneMouseEvent* event, const QTransform& transform) does not seem to be receiving any mouse events when clicking on the left half of the view after the bug is triggered. Debug output is generated from clicks in this part of the screen before opening a file, but after opening a file the debug output is gone. Also a usable workaround for me on Neon: export QT_SCREEN_SCALE_FACTORS= && dolphin %u I have the same problem but the cause is different. I simply have to hover the cursor around a bit and it will randomly stop receiving mouse events. When this happens, SOME of the files/folders that are listed will still be able to receive the events. It seems to be completely random. I'm getting hit by the same bug. System: - Debian Stretch (testing) - KDE Plasma 5.8.2 - dual screen setup (one hidpi, one regular 1920x1200) Same symptom as described by everybody else: an area within the dolphin window becomes unresponsive to mouse clicks. I can still use the cursor keys to change the currently selected file and open a file by hitting return. But the window is unresponsive to mouse clicks. *** This bug has been confirmed by popular vote. *** I can confirm when I run dolphin with QT_SCREEN_SCALE_FACTORS="2;2" but when I run it with QT_SCREEN_SCALE_FACTORS="2;1" it resizes and re-scales fine when I move it to the other screen. Very weird. This bug is so absurd. The bug does not happen if I don't pass a window to the "new KRun" call in DolphinViewContainer. It passes "this", ie. the DolphinViewContainer widget, which has status bar, KUrlNavigator as well as the DolphinView (one of the affected QGraphicsViews). I traced it down in KRun to KStartupInfo. If I remove the KStartupInfo::sendChange(id, data); call in KRun the bug does not happen. CC'ing David F (as KRun guru) and Martin G (as KWindowSystem guru) - I have no idea how this happens. The docs for KStartupInfo say it's the "top level widget", so perhaps it should be DolphinMainWindow (indeed, if for testing f I pass KMainWindow::memberList().first()) and not the view container? I don't see how this could end up keeping mouse events (stuff like "window became (in)active" arrive fine) from the graphics views?! It even affects the places sidebar which is *not* in the affects DolphinViewContainer but has its own afaics. My theory: due to the scaling Qt did not create a native window. But once KStartupInfo is used the wid is needed, thus a window gets created and that is stealing the events. Yup, Qt creates native windows. We do winId() on the DolphinViewContainer which will apparently causes Qt to create a native window chain up until the first window it encounters. When I set WA_DontCreateNativeAncestors I suddenly get a mirror of the DolphinViewController positioned at 0,0 in the Dolphin window. I can't reproduce with a minimal test case, though. Seems embedded widgets are (also) broken in this setup, e.g. System Settings QML stuff or KMail WebEngineView... *** Bug 378402 has been marked as a duplicate of this bug. *** *** Bug 378155 has been marked as a duplicate of this bug. *** Same issue: OpenSUSE Tumbleweed dolphin 16.12.3 Laptop: 4K display Attached Display: 4K display Using hidpi scaling factor of 2 in KDE Only able to open a single file using Dolphin on the Attached Display. Further attempts to open another file on the Attached Display is blocked. Only work around, use context menu each time I open a file OR close Dolphin, relaunch Dolphin and open file. However, on the laptop display when attached or not attached to the external 4K display I can freely open files, multiple. This is super annoying. Sean I have met this issue since several months ago. Currently the bug is still reproducible on my desktop. Spec: Kubuntu 17.04 with Plasma 5.9.4 and Dolphin 16.12.3-0ubuntu2 Two Dell 4K Monitors Set QT_SCREEN_SCALE_FACTORS=2 On primary screen the dolphin performs fine, however when opening a file on secondary screen the file area becomes freezed. If you can, please try this patch: https://phabricator.kde.org/D6046 Git commit e10f44d87270ca6f8e509a99f6df17c8a31fbfa8 by David Faure, on behalf of Kai Uwe Broulik. Committed on 03/06/2017 at 09:54. Pushed by dfaure into branch 'master'. Workaround for QTBUG-59017 CHANGELOG: Addressed an issue where certain elements in applications (e.g. Dolphin's file view) would become inaccessible in high-dpi multi-screen setup FIXED-IN: 5.35 Differential Revision: https://phabricator.kde.org/D6063 M +11 -3 src/widgets/krun.cpp https://commits.kde.org/kio/e10f44d87270ca6f8e509a99f6df17c8a31fbfa8 If I'm reading the release notes (https://www.kde.org/announcements/kde-frameworks-5.35.0.php) correctly, the fix in #18 is in KDE Frameworks 5.35.0, which is now in Neon User Edition. However, I'm still having trouble with Dolphin. In fact, it's now worse - the dolphin window is unresponsive on the second monitor even without having opened a file via double click. Is that always or only after launching an app? I'm not sure I understand the question. For clarity, here's my setup: I'm using a laptop with an internal 4K display and an external 4K monitor, both of which have a scaling factor of 2. The external display is set as primary. When I run dolphin, the default window with my home directory appears on the external display. I can't select any items in the file view or sidebar, though the address bar and toolbar remain responsive. If I drag the window so that it is entirely on the internal display, I can select and open files and directories as usual. However, when I drag the window back to the external display, I can no longer select or open items again. I have ever met Brian's issue when I applied the patch to KDE frameworks<5.35.0 to the packages from Kubuntu-ci. The file area becomes non-clickable when I drag the Dolphin window into the secondary 4k monitor, even before launching any app. Today I upgraded from the Kubuntu-ci repository where the framework 5.35.0 has already landed, and all the bugs were gone. Thanks very much for the developers' effort. (In reply to Brian Mastenbrook from comment #21) > I'm not sure I understand the question. For clarity, here's my setup: I'm > using a laptop with an internal 4K display and an external 4K monitor, both > of which have a scaling factor of 2. The external display is set as primary. > When I run dolphin, the default window with my home directory appears on the > external display. I can't select any items in the file view or sidebar, > though the address bar and toolbar remain responsive. If I drag the window > so that it is entirely on the internal display, I can select and open files > and directories as usual. However, when I drag the window back to the > external display, I can no longer select or open items again. Do you still have this issue? (In reply to Mads from comment #23) > Do you still have this issue? Yes, I do. I'm running Neon User Edition and just did an apt update / dist-upgrade, and logged out and in again. Should I file a new bug? Is the system running with Qt 5.9.1? (In reply to Mads from comment #25) > Is the system running with Qt 5.9.1? No; as far as I can tell that hasn't rolled out to Neon User Edition yet. If I understand this correctly, then the patch mentioned here is just a workaround for an underlying qt issue that has been fixed in qt 5.9.1... So you might want to wait until it rolls out or get it installed in a way or another Hm I did some testing myself now, and I don't get this bug either. On one computer I have Qt 5.7.1 with KDE frameworks 5.35.0 and dolphin 17.04.2 (everything on Gentoo), and I don't see this bug (with 2x 4k monitors). On another computer we first tested with Qt 5.7.1 and then afterwards with Qt 5.9.1, kde-frameworks 5.35.0 and dolphin 17.04.2 (also everything on Gentoo and with 2x 4k monitors), the bug happens everytime, we've yet to manage to click on a icon in dolphin on the external (primary) monitor yet... The differences between the computers is that one is an XPS15 9550, the other is a XPS15 9560, and the 9560 one has a pretty recently built Gentoo system on it. Is there a component that needs rebuilding against new Qt other than kio and dolphin that we haven't rebuilt? Sorry for spamming the bug report, but I did some more testing - there was a difference between the computers, because one screen ran with QT_SCREEN_SCALE_FACTORS 1 on the non-primary monitor and 2 on the external/primary, and the other (the one showing the bug) ran with QT_SCREEN_SCALE_FACTORS 2 on both monitors. When I changed to 2 on both monitors, I see the bug on both systems. So the bug is still there with Qt 5.7.1/5.9.1 and kde frameworks 5.35.0 (again, if anything needs rebuilding after upgrading from Qt 5.7.1 to 5.9.1 outside of kio and dolphin, then please do tell..) we use the modesetting driver for X if it's relevant. I just tried with Qt 5.9.1 and now the file area is completely inaccessible on second monitor, not just after launching a file. Meh. *** Bug 383248 has been marked as a duplicate of this bug. *** kscreen sets the QT_SCREEN_SCALE_FACTORS to "QT_SCREEN_SCALE_FACTORS=eDP-1-1=2;DP-1-1=2;HDMI-1-1=2;DP-1-2=2;HDMI-1-2=2;" on my computer when I have chosen 2 as scaling value. eDP-1 is connected, and DP-1-2 is connected. xrandr also reports that I have the connections DP-1, HDMI-1, DP-2, HDMI-2, DP-1-1, but all of them are disconnected. So, that QT_SCREEN_SCALE_FACTORS mentions some ports that might have existed some time, but for the time being is not there (e.g. HDMI-1-1 and HDMI-1-2). Might this be the actual issue? Because if I run dolphin with QT_SCREEN_SCALE_FACTORS="2;2", things seems to just work... (Qt 5.9.1, kde frameworks 5.37.0, plasma 5.10.5) To clarify: dolphin does not appear to have this unclickable file area issue anymore if using: - kde-frameworks 5.37 - dolphin 17.08.0 - plasma 5.10.0 - Qt 5.9.1 - modesetting ddx - QT_SCREEN_SCALE_FACTORS="2;2" There might still be an issue at play, but that might belong to another bugreport (scaling variable set for non-existing outputs (or vice versa) leads to high cpu usage on plasmashell process and erroneous scaling on outputs that are actually connected) and also not if you use context menues to start programs. It only happens to me if I click directly no a file and then only for certain programs. E.g. dragon player seems to work, vlc does not @Mads So the issue still persists with KDE Frameworks 5.37 in your normal setup (ie. when you don't set it to 2;2 manually)? Oh, I managed to not be clear on that, sorry! No, I can't reproduce the no-clickable issue at all anymore. So for me, this bug is resolved. *** Bug 385102 has been marked as a duplicate of this bug. *** Unfortunately I'm still getting this bug on: Operating System: Fedora 30 KDE Plasma Version: 5.15.5 KDE Frameworks Version: 5.59.0 Qt Version: 5.12.4 Kernel Version: 5.2.17-200.fc30.x86_64 OS Type: 64-bit Processors: 8 × Intel® Core™ i7-8650U CPU @ 1.90GHz Memory: 15.4 GiB of RAM With QT_SCREEN_SCALE_FACORS: QT_SCREEN_SCALE_FACTORS="eDP-1=1.5;DP-1=1.5;HDMI-1=1.5;DP-2=1.5;HDMI-2=1.5;" |