From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= Subject: Re: [BISECTED 3.16-rc REGREGRESSION] backlight control stopped working Date: Mon, 14 Jul 2014 22:45:07 +0200 Message-ID: <877g3fsm98.fsf@nemi.mork.no> References: <87pph8kse7.fsf@nemi.mork.no> <53C3D7C3.7090505@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from canardo.mork.no ([148.122.252.1]:53485 "EHLO canardo.mork.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755638AbaGNUpa convert rfc822-to-8bit (ORCPT ); Mon, 14 Jul 2014 16:45:30 -0400 In-Reply-To: (Linus Torvalds's message of "Mon, 14 Jul 2014 09:59:51 -0700") Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Linus Torvalds Cc: Hans de Goede , Linux Kernel Mailing List , Linux ACPI , "Rafael J. Wysocki" Linus Torvalds writes: > On Mon, Jul 14, 2014 at 9:24 AM, Linus Torvalds > wrote: >> >> Bj=C3=B8rn, what's your setup? Is this perhaps solvable some other w= ay? Just to answer that: I don't use any particular desktop environment. I have acpid running to take care of the most basic power management stuff. My X session is simply WindowMaker (sic) running directly from lightdm. No session management or fancy policy daemons. So I don't hav= e any daemon which would react on the brightness key codes. Now, it's not that I would mind adding a daemon to handle stuff like brightness control. I reported this as a bug because I was a bit surprised by the existing behaviour breaking like that, and I thought that other users might be as surprised as me. Some maybe even without the ability to track down the change and the setting that would restore the old behaviour. > 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 t= o > 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 cance= l > the kernel-induced pending change. That sounds like a good solution to me FWIW. Bj=C3=B8rn -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html