Bug 1544245 - 2560x1440 after poweroff screen VT (CTRL+ALT+F2) 1920x1080 or freeze
Summary: 2560x1440 after poweroff screen VT (CTRL+ALT+F2) 1920x1080 or freeze
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-11 16:24 UTC by Harald Reindl
Modified: 2019-05-28 23:26 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-28 23:26:35 UTC


Attachments (Terms of Use)
additional logfiles (72.55 KB, application/octet-stream)
2018-02-12 16:21 UTC, Harald Reindl
no flags Details
logfiles from today (14.55 KB, application/octet-stream)
2018-02-13 18:26 UTC, Harald Reindl
no flags Details
new logs (19.39 KB, application/octet-stream)
2018-03-07 13:11 UTC, Harald Reindl
no flags Details

Description Harald Reindl 2018-02-11 16:24:52 UTC
i have a new AOC 31.5" screen with 2560x1440 connectd via display port to a i7-3770 which works fine after boot and as long as i don't try to switch to a VT also continues to work as expected

but wehn the screen is longer powered of and you try to switch back to VT2 (CTRL+ALT+F2) you have either the wrong resolution leading that you can't read the bottom of the VT besides unreadable font

more sadly in most cases doing so Xorg freezes completly up to freeze most of the machine (webserver still reachable but even ssh login for clean reboot hangs) 

that switch to a VT afetr you had powered of the screen mostly ends in a freeze or that moving the mouse to turn the screen on sometimes work at all while CTRL+ALT+BACKSPACE bombs you back to SDDM login but with 1920x1080 and even disconnect the screen don't switch back to native resoluton until supsend running virtual machines and comletly reboot makes it very annoying
_______________________

somewhere here the freezes seem to happen

[ 29380.180] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 29432.514] (II) AIGLX: Resuming AIGLX clients after VT switch
_______________________

/etc/X11/xorg.conf.d/02-intel.conf:

Section "Device"
 Identifier "Videocard0"
 Driver     "modesetting"
 Option     "AccelMethod" "glamor"
EndSection
_______________________

here is 2560x1440 completly missing

[    45.896] (II) modeset(0): Supported established timings:
[    45.896] (II) modeset(0): 720x400@70Hz
[    45.896] (II) modeset(0): 640x480@60Hz
[    45.896] (II) modeset(0): 640x480@67Hz
[    45.896] (II) modeset(0): 640x480@72Hz
[    45.896] (II) modeset(0): 640x480@75Hz
[    45.896] (II) modeset(0): 800x600@56Hz
[    45.896] (II) modeset(0): 800x600@60Hz
[    45.896] (II) modeset(0): 800x600@72Hz
[    45.896] (II) modeset(0): 800x600@75Hz
[    45.896] (II) modeset(0): 832x624@75Hz
[    45.896] (II) modeset(0): 1024x768@60Hz
[    45.896] (II) modeset(0): 1024x768@70Hz
[    45.896] (II) modeset(0): 1024x768@75Hz
[    45.896] (II) modeset(0): 1280x1024@75Hz
[    45.896] (II) modeset(0): Manufacturer's mask: 0
_______________________

some lines later in Xorg.0.log it looks fine:

[    45.896] (II) modeset(0): Printing probed modes for output DP-1
[    45.896] (II) modeset(0): Modeline "2560x1440"x60.0  241.50  2560 2608 2640 2720  1440 1443 1448 1481 +hsync +vsync (88.8 kHz eP)
[    45.896] (II) modeset(0): Modeline "2560x1440"x75.0  296.00  2560 2568 2600 2666  1440 1443 1448 1481 +hsync -vsync (111.0 kHz e)
[    45.896] (II) modeset(0): Modeline "1920x1080"x60.0  148.50  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
[    45.896] (II) modeset(0): Modeline "1920x1080"x50.0  148.50  1920 2448 2492 2640  1080 1084 1089 1125 +hsync +vsync (56.2 kHz e)
[    45.896] (II) modeset(0): Modeline "1920x1080"x59.9  148.35  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.4 kHz e)
[    45.896] (II) modeset(0): Modeline "1920x1080i"x60.0   74.25  1920 2008 2052 2200  1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz e)
[    45.896] (II) modeset(0): Modeline "1920x1080i"x50.0   74.25  1920 2448 2492 2640  1080 1084 1094 1125 interlace +hsync +vsync (28.1 kHz e)
[    45.896] (II) modeset(0): Modeline "1920x1080i"x59.9   74.18  1920 2008 2052 2200  1080 1084 1094 1125 interlace +hsync +vsync (33.7 kHz e)

_______________________

and here (after power on screen) xorg.0.log.old 2560x1440 is missing

[ 28980.668] (II) modeset(0): Printing probed modes for output DP-1
[ 28980.668] (II) modeset(0): Modeline "1920x1080"x60.0  148.50  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
[ 28980.668] (II) modeset(0): Modeline "1920x1080"x50.0  148.50  1920 2448 2492 2640  1080 1084 1089 1125 +hsync +vsync (56.2 kHz e)
[ 28980.668] (II) modeset(0): Modeline "1920x1080"x59.9  148.35  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.4 kHz e)
[ 28980.668] (II) modeset(0): Modeline "1920x1080i"x60.0   74.25  1920 2008 2052 2200  1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz e)
[ 28980.668] (II) modeset(0): Modeline "1920x1080i"x50.0   74.25  1920 2448 2492 2640  1080 1084 1094 1125 interlace +hsync +vsync (28.1 kHz e)
[ 28980.668] (II) modeset(0): Modeline "1920x1080i"x59.9   74.18  1920 2008 2052 2200  1080 1084 1094 1125 interlace +hsync +vsync (33.7 kHz e)
[ 28980.668] (II) modeset(0): Modeline "1280x1440"x59.9  156.00  1280 1376 1512 1744  1440 1443 1453 1493 -hsync +vsync (89.4 kHz e)
[ 28980.668] (II) modeset(0): Modeline "1680x1050"x60.0  146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz e)
[ 28980.668] (II) modeset(0): Modeline "1280x1024"x75.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)

Comment 1 Harald Reindl 2018-02-12 16:21:06 UTC
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

Comment 2 Harald Reindl 2018-02-13 18:26:09 UTC
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

Comment 3 Harald Reindl 2018-02-14 11:01:47 UTC
"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

Comment 4 Harald Reindl 2018-02-28 19:17:10 UTC
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

Comment 5 Harald Reindl 2018-02-28 20:11:55 UTC
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 :-(

Comment 6 Harald Reindl 2018-03-07 13:11:13 UTC
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

Comment 7 Harald Reindl 2018-03-19 15:00:17 UTC
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

Comment 8 Ben Cotton 2018-11-27 16:34:21 UTC
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.

Comment 9 Harald Reindl 2018-11-27 17:11:46 UTC
this is all still a joke with F28

Comment 10 Alick Zhao 2018-12-07 16:48:55 UTC
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

Comment 11 Harald Reindl 2018-12-08 20:49:28 UTC
@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

Comment 12 Harald Reindl 2018-12-10 12:54:12 UTC
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

Comment 13 Ben Cotton 2019-05-02 20:09:12 UTC
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.

Comment 14 Ben Cotton 2019-05-28 23:26:35 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.