On a Dell e6510, i5, full HD, running the kernel from drm-intel-next: connecting an external display configures the external display automatically but switches off the backlight of the panel and I suspect than the panel itself is also off. The external display works fine, but I cannot do anything to recover the internal one: changing brigthness does not help, switching to VT1 and back does not work.
Add drm.debug=0xe to your grub boot parameters and attach the dmesg after connecting the display, the output of xrandr --verbose and Xorg.log
Created attachment 43217 [details] Output of the dmesg command
Created attachment 43218 [details] Contents of /var/log/dmesg
Created attachment 43219 [details] output of xrandr --verbose
Created attachment 43220 [details] Contents of the log file of the X server
And have you tried drm-intel-next for the eDP fixes therein?
(In reply to comment #6) > And have you tried drm-intel-next for the eDP fixes therein? drm-intel-next is what I have tried.
(In reply to comment #7) > (In reply to comment #6) > > And have you tried drm-intel-next for the eDP fixes therein? > > drm-intel-next is what I have tried. To be more precise, up to commit 139467433e50926d22338e9dc754feaaf94b9db0. Upon connection of an external monitor to the VGA output, the VGA port is automatically activated and the external monitor (which has less resolution than the panel) shows the leftmost uppermost part of the panel. The panel is switched off. Fn-F8 (to cycle between configurations) switches the external monitor off but does not turn the internal panel on. At this point the laptop becomes non responsive: ctrl-alt-del (which should bring up a window to turn off the computer) does not seem to do anything; and I cannot switch to vt1.
Created attachment 43267 [details] Output of the dmesg command The previous dmesg output was messed up by network messages and I had to filter them out. This made dmesg output not to have all the information since boot.
Created attachment 43268 [details] Contents of /var/log/dmesg Contents of /var/log/dmesg corresponding to the now current dmesg.
Created attachment 43270 [details] output of xrandr --verbose
Created attachment 43271 [details] Contents of the log file of the X server
Created attachment 43272 [details] Kernel boot options
If you revert dcbe6f2b3d136995915e2f9ecc7d4f3b28f47b6c and 633f2ea26665d37bb3c8ae30799aa14988622653 (in that order) does the problem go away? I'm pretty sure I'm reproducing it here, and it looks like a PCH refclk problem.
(In reply to comment #14) > If you revert dcbe6f2b3d136995915e2f9ecc7d4f3b28f47b6c and > 633f2ea26665d37bb3c8ae30799aa14988622653 (in that order) does the problem go > away? I'm pretty sure I'm reproducing it here, and it looks like a PCH refclk > problem. Seems to work - thanks a lot. Should I send any other trace to track what is happening now?
(In reply to comment #15) > (In reply to comment #14) > > If you revert dcbe6f2b3d136995915e2f9ecc7d4f3b28f47b6c and > > 633f2ea26665d37bb3c8ae30799aa14988622653 (in that order) does the problem go > > away? I'm pretty sure I'm reproducing it here, and it looks like a PCH refclk > > problem. > > Seems to work - thanks a lot. Should I send any other trace to track what is > happening now? One note: pressing Fn-F8 (which in other kernel versions rotate between activating external - cloning - deactivating external) still switches off both screens and locks the machine. I mean hard locking: it is not that the keyboard does not respond, but also that a "sleep 10; sudo reboot" I left in a shell did not have any effect.
Yeah, if the hang still happens when you try the display switch button, please file a new bug. If you can, set up netconsole and see if your machine spits anything out before it dies; too bad it's a hard hang though, that makes things a lot harder.
(In reply to comment #17) > Yeah, if the hang still happens when you try the display switch button, please > file a new bug. If you can, set up netconsole and see if your machine spits > anything out before it dies; too bad it's a hard hang though, that makes things > a lot harder. I am not sure about filing a new bug. Linus' tree rc6 (commit 4a508dd259f5995b8d31c576b894263f5947d654) plus the patch you pointed at elsewhere (https://bugs.freedesktop.org/attachment.cgi?id=43401) work beatifully - they boot, they suspend and resume, VGA output works, and cycling through display configurations with Fn+F8 works so far. I haven't tested Linus' tree alone and I haven't re-tested the drm-intel-next branch, but I will today or tomorrow.
(In reply to comment #18) > (In reply to comment #17) > > Yeah, if the hang still happens when you try the display switch button, please > > file a new bug. If you can, set up netconsole and see if your machine spits > > anything out before it dies; too bad it's a hard hang though, that makes things > > a lot harder. > > I am not sure about filing a new bug. Linus' tree rc6 (commit > 4a508dd259f5995b8d31c576b894263f5947d654) plus the patch you pointed at > elsewhere (https://bugs.freedesktop.org/attachment.cgi?id=43401) work > beatifully - they boot, they suspend and resume, VGA output works, and cycling > through display configurations with Fn+F8 works so far. I haven't tested > Linus' tree alone and I haven't re-tested the drm-intel-next branch, but I will > today or tomorrow. The drm-intel-next branch has the problem described above (external display behaving incorrectly and locking up when circulating among configurations). However, Linus' linux-2.6 repository works very well, so I am not sure I should file a bug against drm-intel-next?
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.