lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 03 Apr 2014 04:12:58 +0100
From:	James Hogan <>
To:	Jani Nikula <>,
	Imre Deak <>,
	Kamal Mostafa <>,
	Daniel Vetter <>,,,
Subject: drm/i915: XPS13 backlight regression in v3.14


I've noticed that v3.14 breaks the backlight on Dell XPS13. Reverting the 
following commit fixes the issue for me (i.e. the GUI brightness controls work 

bc0bb9fd1c78 drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE

It appears that in v3.14 (with the above patch):
* intel_backlight/brightness=4882 (max & default) causes 
acpi_video0/brightness to have no effect.
* intel_backlight/brightness=0 causes acpi_video0/brightness to behave 
corrrectly (the firmware (I assume) fades the brightness gradually when 
acpi_video0/brightness is set)
* intel_backlight/brightness=something else in between often causes 
acpi_video0 and intel_backlight to apparently "fight" over the backlight, 
resulting in brightness flickering up and down every second or so.

Reverting the above patch on v3.14:
* intel_backlight/brightness has no effect
* acpi_video0/brightness works normally

It doesn't seem quite as simple as them trying to use the same hardware since 
when intel_backlight/brightness=4882, acpi_video0/brightness has no effect at 
all, so I don't really get what's going on.

Can anybody shed some light or suggest a proper fix for this recurring issue?

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists