Ubuntu – Display on HDMI doesn’t wake up

16.04displayhdmimonitorxubuntu

I just got myself a beautiful 27" WQHD display. It is connected to HDMI (no VideoPort) and works great showing 2560×1440 @ 60 Hz.

There is a problem however. When it goes to sleep/I turn the monitor off and then I wake it up/turn it on it doesn't come back. It stays blank eventually displaying "no signal".

The weird thing is when I switch to a different TTY, e.g. Ctrl+Alt+F2 it wakes up, but then going back to Ctrl+Alt+F7 immediately puts it back to sleep and shows "no signal" message. Currently I have to run service lightdm restart in a different TTY in order to wake the monitor up, which is better than reboot but far from ideal. The fact that it can be woken up by switching to a different TTY or restarting X tells me that it is a software related problem.

I am looking for any reasonable solution e.g.

  1. configuration tweak which will force it wake up on keypress
  2. a command that I could give a hot key combination which will wake up
    the monitor
  3. a driver install/update
  4. anything else that works

As I am running out of ideas I would appreciate any advice, thoughts, guesses. Thanxalot!

P.S. I run xubuntu 16.04 and use IntelĀ® HD Graphics 4600

Best Answer

I found a way to wake up the monitor. It is not ideal but much better than restarting X server or rebooting. I created a simple shell script which forces graphics mode to be reset.

#!/bin/bash
xrandr --output HDMI2 --primary --mode 2560x1440

or a simpler one

#!/bin/bash
xrandr --output HDMI2 --auto

Then I assigned a hot key combination to invoke my script. This way the monitor wakes up but only on specific key press vs any key or mouse event.

I will wait for a better answer before accepting my own answer. I am still hopeful that somebody knows a way to fix the actual problem.

UPDATE 2018-01-12 I upgraded kernel from the default LTS version to the latest (https://wiki.ubuntu.com/Kernel/LTSEnablementStack) and the monitor now behaves as it is supposed to. Thanks to @Ellis Whitehead for pointing out it could be a problem in the kernel implementation.

Related Question