| Summary: | Okular turns off/on HDMI external monitor | ||
|---|---|---|---|
| Product: | [Applications] okular | Reporter: | alien <27978> |
| Component: | general | Assignee: | Okular developers <okular-devel> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | CC: | justin.zobel, luigi.toscano, staniek |
| Priority: | NOR | ||
| Version First Reported In: | 0.24.0 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
alien
2016-06-23 15:19:57 UTC
I can confirm it for openSUSE 42.1 and updated 42.2. Therefore the issue looks like an universal trouble because my OS and hardware is different than the above.
Steps to Reproduce:
1. Open a PDF file.
Actual Results: identical as above. It happens without even running the presentation mode. No way to restore the display or detecting it again (which is primary so the issue breaks the usage) even AFTER restart. The only way is turning off, waiting 2 seconds and booting again.
It's a new behavior that started with KF5-based Okular for me. It has never been the case for kdelibs-based Okular.
Possible workaround (may be handy for actual users that want their productivity back):
- harder: associate another PDF reader such as Evince
(harder because there's no universal way to associate applications with extensions on Linux - all different for browsers, Plasma, mc...), optionally enable PDF preview directly in the browser.
- simpler but radical: uninstall Okular completely, use other PDF readers until the issue is fixed
-- More info on my software/hardware:
4.4.49-16-default #1 SMP Sun Feb 19 17:40:35 UTC 2017 (70e9954) x86_64 x86_64 x86_64 GNU/Linux
00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09)
Subsystem: ASUSTeK Computer Inc. Device [1043:1d82]
Kernel driver in use: i915
--
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Whistler LE [Radeon HD 6610M/7610M] [1002:6742] (rev ff)
Kernel driver in use: radeon
Kernel modules: radeon
PS: % okular --version Qt: 4.8.6 KDE Development Platform: 4.14.25 Okular: 0.26. (In reply to Jarosław Staniek from comment #2) > PS: > > % okular --version > > Qt: 4.8.6 > KDE Development Platform: 4.14.25 > Okular: 0.26. Is it working one or the non-working one? For what I remember, Okular simply uses QScreen to compute the DPI. Jaroslaw, can you please try to recompile after commenting the code which uses QScreen inside core/utils.cpp , Utils::realDpi? It's non-working. I am 99% convinced some code outside of Okular is the reason. That is because I also managed to run into the situation while testing some build of Kexi... (I am not using QScreen here though).
> recompile after commenting the code which uses QScreen inside core/utils.cpp , Utils::realDpi?
would try it... thanks for the hint
> It's a new behavior that started with KF5-based Okular for me [...] > Okular: 0.26. That is not the KF5-based Okular version. > That is not the KF5-based Okular version
I had two versions back then, apparently executed --version for the earlier.
Upgraded to openSUSE 42.4 KF/Plasma unstable repos and uninstalled most of kdelibs4 based apps. Hope there will be difference. I'll inform after some time.
The same issue happened today while trying to run gthumb (gwenview was uninstallable for some time).
Just a hint to @alien on how to possible recover from the disaster: I have a ~/.screenlayout/arandr.conf.sh script that contains (in my quite similar case: #!/bin/sh xrandr --newmode "1280x1024_60.00" 108.88 1280 1360 1496 1712 1024 1025 1028 1060 -HSync +Vsync xrandr --addmode HDMI1 "1280x1024_60.00" xrandr --output HDMI1 --primary --mode "1280x1024_60.00" --pos 0x0 --rotate normal --output LVDS1 --mode 1366x768 --pos 1280x0 --rotate normal The script can be anywhere in fact, you run it by hand. Also read comment #1 and #s at https://forums.opensuse.org/showthread.php/493985-SOLUTION-FOR-KSCREEN-NOT-SAVING-DUAL-MONITOR-CONFIGURATION-IN-OPENSUSE-13-1?p=2612605#post2612605 (yes, it's years-old advice and the open source radeon drivers feel worse; I disabled KScreen to avoid too much automatics; I am sorry for comments now not really related to only Okular -- Kexi causes exactly the same and it does not use QScreen API, all is used is probing geometry of QDesktopWidget at most..) Sorry Now my Okular version is Version 1.0.70, KDE Frameworks 5.26.0 Qt 5.8.0 (built against 5.6.1) The xcb windowing system (btw, this info is no longer available in --version :( ) Thanks for the report. I've just tested on okular 1.11.3 and I can't replicate this issue. Can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I'm setting status to "needsinfo" pending your response, please change back to "reported" or "resolved" when you respond, thanks. 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! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now 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 Thank you for helping us make KDE software even better for everyone! |