FS#48086 - [linux][i915][hdmi] graphics not recoverying from power save + more
Attached to Project:
Arch Linux
Opened by Javier (jevv) - Monday, 08 February 2016, 05:48 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 11 July 2016, 00:35 GMT
Opened by Javier (jevv) - Monday, 08 February 2016, 05:48 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 11 July 2016, 00:35 GMT
|
Details
Description:
After upgrading Arch from last weekend (I do it on weekends on these boxes), now the intel graphics using i915 driver is misbehaving. Before the update there was no problem. Now, when booting, if the display attached to the hdmi port is still turned off, then there's no way afterwords for the box to recognize the right resolution of the display when turned on. It just sticks with a default low resolution. This was not happening before, when actually I used to turn the display on and off at will after boot. Also, for this box, it happens that when getting into power save mode, actually the graphics turn off. But now a days, if that happens, there's no way to turn them back on. That's weird. As a work around for the later misbehavior I've totally turned off display blanking (power saving) : xset s off xset -dpms And if I miss to turn the display on before booting, I'll be forced to reboot to get an appropriate resolution. I'm not hard coding the resolution for X, neither for the terminal. I've enabled early KMS through mkinitcpio: MODULES="i915" My box is a "mintBox 2" with Intel HD Graphics 4000. Through lspci -v: 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation Device 2211 Flags: bus master, fast devsel, latency 0, IRQ 28 Memory at e0000000 (64-bit, non-prefetchable) [size=4M] Memory at c0000000 (64-bit, prefetchable) [size=512M] I/O ports at 4000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 Kernel modules: i915 No particular configurations (modprobe.d) for i915, just default. Just to reiterate that the display is hooked through the hdmi port. I noticed that both systemd (udev) and linux were upgraded on this weekend, but this seems closer to linux. My work around for the not allowing display blanking is not very good, given there's energy waste, but one can live with it. However the need to reboot if the display was not turned on before the box is really uncomfortable since one automatically tends to turn everything on at once (always the box wakes up faster). Additional info: * package version(s) ----------------------------------------------------- local/linux 4.4.1-2 (base) The Linux kernel and modules local/linux-api-headers 4.1.4-1 Kernel headers sanitized for use in userspace local/linux-firmware 20160113.40e9ae8-1 Firmware files for Linux local/libsystemd 228-4 systemd client libraries local/systemd 228-4 system and service manager |
This task depends upon
?
To provide more info, the good stock linux with no problem was:
Linux version 4.3.3-3-ARCH (builduser@tobias) (gcc version 5.3.0 (GCC) ) #1 SMP PREEMPT Wed Jan 20 08:12:23 CET 2016
And the linux with problems is:
Linux version 4.4.1-2-ARCH (builduser@foutrelis) (gcc version 5.3.0 (GCC) ) #1 SMP PREEMPT Wed Feb 3 13:12:33 UTC 2016
The sleep problem sound pretty similar, except that for me display gets totally lost, even on the terminal, so I can't restart the display manager (xdm) from the same box (well, I can't see what I'm typing).
Another difference is that on issue "47997" there's no mention of what happens to me @ boot. Which is the most annoying part for me, since rebooting to get the box recognize the display automatically doesn't sound good.
However the sleep part, as mentioned is pretty close. It might be who reported it actually restarted the display manager remotely, but even in that case, I wouldn't understand why moving from Xorg to terminal wouldn't have a similar effect...
Thanks,
Javier
1.- Resolution problem @ boot if display turns on later.
2.- Resolution problem @ power saving state.
3.- Graphics not recovering after asleep.
Well, [2] is new to this report, it happens that instead of not recovering from power state, as on [3], the graphics comes back, but as on [1], it can negotiate the resolution, and comes with a default low resolution.
Also, after moving from early KMS to late KMS (removing the mkinitcpio initrd load of the module), [3] doesn't seem to be an issue, or at least I haven't experienced it again, but [2] is still present. I left the box turned on, with the display turned off for ~ 8 hours, and the graphics waked up, only thing unable to get the right resolution from the display on the hdmi port.