FS#50364 - [linux] After update to kernel 4.7.0-1 plasma won't login
Attached to Project:
Arch Linux
Opened by Mike Cloaked (mcloaked) - Thursday, 11 August 2016, 21:05 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 04 July 2018, 15:03 GMT
Opened by Mike Cloaked (mcloaked) - Thursday, 11 August 2016, 21:05 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 04 July 2018, 15:03 GMT
|
Details
Description:
After update to kernel 4.7.0-1 this evening with the usual pacman -Syu my desktop ( Intel Ivybridge DQ77KB ) boots up fine and presents the sddm greeter screen as normal - but when logging in the usual splash screen appears on the monitor with the progress bar moving across, but at around 90% through this process, the plasma login seems hangs for many seconds - eventually the splash screen disappears and I end up with just the desktop background image - but no taskbar, and the mouse is not active. At that point the mouse is active again and I can select the usual options with right click including the logout option. Rebooting makes no difference, and logging out and back in also makes no difference. Additional info: * package version(s) kernel 4.7.0-1 produces this bug, but downgrading to 4.6.4-1-ARCH allows the plasma desktop login to proceed as normal to give a desktop that includes the taskbar. * config and/or log files etc. Steps to reproduce: Upgrade kernel to 4.7.0-1 and reboot, then try to login at the sddm screen. |
This task depends upon
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
Subsystem: Intel Corporation Device 2036
Flags: bus master, fast devsel, latency 0, IRQ 31
Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
I/O ports at f000 [size=64]
[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: i915
Kernel modules: i915
There are two xorg config files:
$ cat /etc/X11/xorg.conf.d/90-libinput.conf
# Match on all types of devices but tablet devices and joysticks
Section "InputClass"
Identifier "libinput pointer catchall"
MatchIsPointer "on"
MatchDevicePath "/dev/input/event*"
Driver "libinput"
EndSection
Section "InputClass"
Identifier "libinput keyboard catchall"
MatchIsKeyboard "on"
MatchDevicePath "/dev/input/event*"
Driver "libinput"
EndSection
Section "InputClass"
Identifier "libinput touchpad catchall"
MatchIsTouchpad "on"
MatchDevicePath "/dev/input/event*"
Driver "libinput"
Option "Tapping" "on"
Option "DisableWhileTyping" "on"
Option "ScrollMethod" "edge"
EndSection
Section "InputClass"
Identifier "libinput touchscreen catchall"
MatchIsTouchscreen "on"
MatchDevicePath "/dev/input/event*"
Driver "libinput"
EndSection
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
# Driver "modesetting"
# Option "AccelMethod" "uxa"
# Option "DRI" "False"
Option "TearFree" "true"
Option "DRI" "3"
EndSection
$ cat /etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
# Option "AccelMethod" "uxa"
EndSection
Xorg.0.log-4.7-modesetting.log (39.5 KiB)
Xorg.0.log-4.7-intel.log (16.6 KiB)
Xorg.0.log-4.6-intel.log (16.6 KiB)
https://git-scm.com/docs/git-bisect
a git bisect allows to find the commit which triggers the bug,
the process is simple but it can be slow if your PC is not fast for the compilation, you can use ccache in order to speed up the process :
https://wiki.archlinux.org/index.php/ccache
So in order to resolve this issue I logged on with kernel 4.6.4-1 running with the erroneously assigned panel still displayed on the primary real monitor. Then unlocking the plasma widgets, and removing the panel using the panel controls, I then created a new default panel, configured it, and locked the widgets again. Logging out and back in displayed the newly created panel correctly on the primary monitor.
Then adjusting the xorg config to include the following lines allowed logging out and back in with no phantom screen detected:
Section "Monitor"
Identifier "HDMI2"
Option "Enable" "true"
EndSection
Section "Monitor"
Identifier "eDP1"
Option "ignore" "true"
EndSection
Then upgrading the kernel to 4.7.4-1 and rebooting, allows the login from the sddm screen to proceed normally and completes without any problem including having the panel displayed on the only screen detected by kwin.
The xrandr output before and after these changes shows that prior to the steps detailed above there was a phantom eDP1 screen, but afterwards there is only a single HDMI2 screen - and now all is well.
I also found that Martin Graeslin has commented on the multi-screen issue in the past at
https://blog.martin-graesslin.com/blog/2015/10/some-thoughts-on-the-quality-of-plasma-5/ and there is another post also mentioning this issue at: https://vizzzion.org/blog/2016/05/multiscreen-in-plasma-5-7-and-beyond/
So although the problem is resolved in my case, it looks like there are still possible remnants of problems for systems where more than one monitor has been connected and during multi-screen operation some screen configs have been changed which can become an issue when the additional monitors are later removed. Therefore please close this bug as my issue is resolved.