linux-kernel - Re: [BISECTED 3.16-rc REGREGRESSION] backlight control stopped working

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFzHo4BEO8W0yza7g0YMgg-b=hPbk20-vpR3s==ydpmAOg@mail.gmail.com>
Date:	Mon, 14 Jul 2014 09:59:51 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Hans de Goede <hdegoede@...hat.com>
Cc:	Bjørn Mork <bjorn@...k.no>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux ACPI <linux-acpi@...r.kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [BISECTED 3.16-rc REGREGRESSION] backlight control stopped working

On Mon, Jul 14, 2014 at 9:24 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Bjørn, what's your setup? Is this perhaps solvable some other way?

For example, I wonder if we could fix the "dual brightness change"
problem automatically by making a new option for
'brightness_switch_enabled'.

Currently, there are two cases:

 - enabled: do the actual brightness change _and_ send the input
report keycode for a brightness change

 - disabled: just send the keycode, excpecting the desktop software to
handle it.

and maybe we could have a new case (and make *that* the default):

 - delayed: send the keycode, and set up a delayed timer (say, one
tenth of a second) to do the actual brightness change. And if a
brightness change from user mode comes in during that delay, we cancel
the kernel-induced pending change.

Something like the very hacky attached patch that is COMPLETELY UNTESTED.

My point being that I think we can get this right *without* some
stupid "user has to specify the behavior of their desktop application
and ACPI implementation" crap. Especially since it's entirely possible
that there are different behaviors for the same machine (ie the user
session may act differently from the login screen, which will act
differently from the text virtual terminal).

I really don't expect my patch to work as-is, it is really meant more
as an illustration of an approach that might work. There may well be
many other complications (ie how does this interact with the whole
"use_native_backlight" thing and user space possibly accessing *other*
backlight controls). But I have the feeling that this should be
solvable without breaking old setups or causing problems on newer
ones.

                Linus

View attachment "patch.diff" of type "text/plain" (3393 bytes)