On Sat, 07 Jan 2017 08:18:51 +0100 solitone <solit...@mail.com> wrote:
> On Friday, January 6, 2017 9:52:13 PM CET David Wright wrote: > > in your terminal, you'll probably find that > > $ echo $DISPLAY > > will give you :0 (locally) or localhost:10.0 (if you ssh into > > another computer). So your terminal's xset command will be > > happy without -display as it's got $DISPLAY instead. > > [...] > > I'm assuming that a systemd command that suddenly pops up from > > nowhere will not have a suitable value for $DISPLAY. > > OK, I see. > > I've ssh'd into the computer with the screen issue, and done some > additional tests. I can switch off and on the monitor from ssh with > the following commands ($DISPLAY is not set in shh): > > $ xset -display :0 dpms force off > $ xset -display :0 dpms force on > > So, I turn the monitor off, hibernate, and resume, and I get the > usual black screen. The system is up and running, as I can ssh into > it. From ssh I give: > > $ xset -display :0 dpms force on > > but nothing happen. Even if I try: > > $ xset -display :0 dpms force off > $ xset -display :0 dpms force on > > nothing happens either. > > So the behaviour I have from ssh is similar to what I get from a > systemd script. The system is apparently up and running, but I can't > turn the monitor on, neither from systemd, nor from ssh. Funny thing! > Is the screen truly off? If you look at it from unusual angles, can you see any faint sign of the correct display? I gave up trying suspend and hibernate on any Linux, as none of them seem to work correctly. One effect I did see sometimes was that the screen backlight was off, but the display was being operated correctly and I could see, from some angles, the right screen material. I couldn't find any way to turn on the backlight in this situation. -- Joe
