Bug 1544245

Created attachment 1395008 [details]
additional logfiles

attached some logfiles of a "damned turn on my screen" event where "killall plasmashell; /usr/bin/plasmashell &" did half of the trick but that time again with wrong resolution, CTRL-ALT+BACKSPACE ended in completly wired state and screen turned off again

the backup fo logfiles was done via smartphone and sshd
frankly that situation drives me crazy

Created attachment 1395626 [details]
logfiles from today

don't get me wrong but am i the only linux user with a larger screen?

* all day long native resolution (not tried a VT switch)
* logout
* SDDM stares at me with a unusable 1920x1080
* VT switch works, also 1920x1080
* fine, power down virtual machines
* reboot

frankly that is a joke in 2018

"AIGLX: Suspending AIGLX clients for VT switch" is the last thing which happens afetr press CTRL+ALT+F2 - somtimes like today you can restart the display-manager via SSH and it restarts with 1920x1080 and so actually reboot is the only temporary solution :-(

horrible when you learned to start long-running terminal stuff in a VT so that it does not die with your X-session

[ 47406.415] (II) event1  - Power Button: device removed
[ 47406.421] (II) event6  - Video Bus: device removed
[ 47406.443] (II) event5  - Video Bus: device removed
[ 47406.463] (II) event0  - Power Button: device removed
[ 47406.472] (II) event2  - Lite-On Technology Corp. HP Basic USB Keyboard: device removed
[ 47406.480] (II) event3  - Logitech USB Optical Mouse: device removed
[ 47406.496] (II) event4  - HP WMI hotkeys: device removed
[ 47406.512] (II) AIGLX: Suspending AIGLX clients for VT switch

this seems to be some timing issue

another guy using two of that screens on windows told me after wakeup window positions over both screens are not restored and all windows are on the primary screen

change from "auto-select" input to DP and disable "DDC/CI" don't change anything as well as "ro video=2560x1140@60" in the kernel line

when the screen is powered off at boot it won't wake up by move mouse or hit keyboard and after switch the screen to standby with "sleep 1; /usr/bin/xset dpms force standby" chances are high that you won't be able to power it on again by move mouse/keyboard

Xorg.0.log in that case starts with garbage and repeatet:
[   699.065] (EE) modeset(0): failed to set mode: Invalid argument
[   699.318] (WW) modeset(0): flip queue failed: Device or resource busy
[   699.318] (WW) modeset(0): Page flip failed: Device or resource busy
[   699.318] (EE) modeset(0): present flip failed
[   699.334] (WW) modeset(0): flip queue failed: Device or resource busy
[   699.334] (WW) modeset(0): Page flip failed: Device or resource busy
[   699.334] (EE) modeset(0): present flip failed
[   700.007] (WW) modeset(0): flip queue failed: Device or resource busy
[   700.007] (WW) modeset(0): Page flip failed: Device or resource busy
[   700.007] (EE) modeset(0): present flip failed
[   700.025] (WW) modeset(0): flip queue failed: Device or resource busy
[   700.025] (WW) modeset(0): Page flip failed: Device or resource busy
[   700.025] (EE) modeset(0): present flip failed

i thought we are in 2018 :-(

Created attachment 1405332 [details]
new logs

that all sucks

* no wakeup after move mouse
* thanks to my configs CTRL+ALT+BACKSPACE back to SDDM
* wrong screen resolution
* 60 seconds later screen power off (as configured)
* no wakeup again
* SSH via smartphone -> reboot

well, seems to be a long known problem - https://bugzilla.redhat.com/show_bug.cgi?id=1179924#c114 but with the previous DP-DVI-adapter you don't reach the native resolution and hence cuaght on DisplayPort :-(

wake up the screen is some lottery at all, what hepls are KDE shortcuts, many times the ALT+PRINT dance helps wakeup while moving windows down - if that all does not help manually wake up the screen by press the input-select-button and THEN ALT+PRINT

if the session is locked - well - enter your password blidnly first so that shortcuts are working - what a mess

PRINT:
sleep 0.5; xset dpms force standby

SHIFT+PRINT: 
sleep 0.5; xset dpms force standby; sleep 0.5; qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock

ALT+PRINT: 
xrandr --output DP-1 --off; sleep 0.5; xrandr --output DP-1 --mode 2560x1440

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

this is all still a joke with F28

Seems it might be related to hardware acceleration. Please see if the walkaround in the link helps:

https://wiki.archlinux.org/index.php/Intel_graphics#X_freeze/crash_with_intel_driver

@Alick Zhao 

as you can see on top i use the modesetting driver and with a shitty small 23" screen all was fine, the problem is the native reolution of 2560x1440 from the "new" screen

it's all even that shitty that if you reboot with the screen powered off that you never ever will get any output without reboot again after power on the screen

when i don't power off the screen at all everything is fine but that's not an option on a mchine running 365/24 when the screen thakes 40 watts and the whole it without 28-35 watts

besides that you can forget KDE as well as GNOME without hardware acceleration

that's the nonsense you get when you power on the machine with WOL while said screen is connecte dbut powered off and after that you can forget the idea power on the screen and get any output later, you need to power on the screen, login to the machine with a smartphone and reboot it per SSH

don't get me wrong but that all feels like in the 1970's

[Mo Dez 10 13:33:13 2018] [drm:intel_print_wm_latency [i915]] *ERROR* Primary WM3 latency not provided
[Mo Dez 10 13:33:13 2018] [drm:intel_print_wm_latency [i915]] *ERROR* Sprite WM3 latency not provided
[Mo Dez 10 13:33:13 2018] [drm:intel_print_wm_latency [i915]] *ERROR* Cursor WM3 latency not provided

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.