No backlight control when resuming from suspend-to-ram

I'm having difficulty resuming my Precision 5510 after suspending. I have currently replaced the default Ubuntu installation with Gentoo on my laptop. I'm currently using the Intel GPU for primary graphics output and the Nvidia through bumblebee as needed.

I'm able to put the laptop to sleep either with a lid trigger or by calling pm-suspend (I'm using openRC instead of systemd so I'm still using pm-utils to suspend.) The machine goes to sleep reliably and will wake up but with odd behavior of the backlight upon resuming. Adjusting the backlight with the hotkeys, a slider widget or by directly echoing values into /sys/class/backlight/intel_backlight/brightness will not adjust the backlight. The hotkeys will still trigger the OSD to react as if brightness is being lowered. However, once I hit the bottom of the brightness scale or echo "0" into the sysfs node, the backlight will turn off and can be turned on again.

Unfortunately, there's a second side effect that I've seen from this odd suspend behavior. Once I have suspended and resumed the computer, I won't be able to use the hotkeys to adjust brightness after rebooting the computer. Echoing into sysfs or using GUI widget slider will adjust the backlight but the hotkeys will not react or trigger events in X (including when I test with xev). However, the backlight and keys still work because I am able to adjust the backlight during POST and the bootloader, it is only after the kernel initializes that I lose control. I am yet to be able to isolate how it is that I regain hotkey usage again, but after some combination of suspends, resumes and reboots, I'm usually able to get things working again, but it's a frustrating procedure since I can't reproduce it reliably.

Does anyone have any thoughts on what might be going on here or how I might be able to properly re-initialize the backlight? This seems to be the only problem that I am still having and it is quite vexing. This doesn't seem to happen with systemd based suspend and resume, but I'm yet to test it exhaustively. Has anyone else encountered a similar issue?

I'm on the most recent BIOS and am booting using legacy boot instead of EFI should that be relevant. I've also tried the different quirks available to pm-utils to no avail and have also tried passing "acpi_osi=Linux/!Windows 2012 and acpi_backlight=vendor/native/video in all combinations but to no avail. vbetool stops functioning after I resume from suspend and will respond to any attempted usage with "Real mode call failed".

Responses(16)

A

alhashash1

2 Posts

0

October 16th, 2016 00:00

There was an extra line I added for debugging. Here is the final script:

#!/bin/sh
# From patchwork.freedesktop.org/.../
# and en.community.dell.com/.../19985320
# Suspend Resume fails to restore PWM_GRANUALITY
# Based on script by Tony.Jewell@Cregganna.Com

INTEL_REG_READ=/usr/bin/intel_reg_read
INTEL_REG_WRITE=/usr/bin/intel_reg_write

ADDR="0x000c2000"
SAVE_FILE=/var/lib/systemd/save_intel_reg_pwm_granuality

[ -x "$INTEL_REG_READ" ] || exit 1
[ -x "$INTEL_REG_WRITE" ] || exit 1

case "$1" in
        pre)
		"$INTEL_REG_READ" "$ADDR" \
			| (read addr colon value && echo "$value") \
			>"$SAVE_FILE"
		echo "$0: Saving Intel Register PWM_GRANUALITY \"$value\""
	sync
	;;
	post)
		value=`cat "$SAVE_FILE" 2>/dev/null`
		if [ -n "$value" ]
		then
			echo "$0: Restoring Intel Register PWM_GRANUALITY \"$value\""
			"$INTEL_REG_WRITE" "$ADDR" "$value"
			rm "$SAVE_FILE"
		fi
	;;
esac

1
2

View All

No Events found!

Linux General

No backlight control when resuming from suspend-to-ram