linux-kernel - [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-next>] [day] [month] [year] [list]

Date:	Mon, 14 Jul 2014 14:59:44 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	Hans de Goede <hdegoede@...hat.com>
Cc:	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: [BISECTED 3.16-rc REGREGRESSION] backlight control stopped working

Yes, I actually bisected this just to get

886129a8eebebec260165741fe31421482371006 is the first bad commit
commit 886129a8eebebec260165741fe31421482371006
Author: Hans de Goede <hdegoede@...hat.com>
Date:   Tue May 6 14:46:23 2014 +0200

    ACPI / video: change acpi-video brightness_switch_enabled default to 0
    
    acpi-video is unique in that it not only generates brightness up/down
    keypresses, but also (sometimes) actively changes the brightness itself.
    
    This presents an inconsistent kernel interface to userspace, basically there
    are 2 different scenarios, depending on the laptop model:
    
     1) On some laptops a brightness up/down keypress means: show a brightness osd
     with the current brightness, iow it is a brightness has changed notification.
    
     2) Where as on (a lot of) other laptops it means a brightness up/down key was
     pressed, deal with it.
    
    Most of the desktop environments interpret any press as in scenario 2, and
    change the brightness up / down as a response to the key events, causing it
    to be changed twice, once by acpi-video and once by the DE.
    
    With the new default for video.use_native_backlight we will be moving even
    more laptops over to behaving as in scenario 2. Making the remaining laptops
    even more of a weird exception. Also note that it is hard to detect scenario
    1 properly in userspace, and AFAIK none of the DE-s deals with it.
    
    Therefor this commit changes the default of brightness_switch_enabled to 0
    making its behavior consistent with all the other backlight drivers.
    
    Signed-off-by: Hans de Goede <hdegoede@...hat.com>
    Reviewed-by: Aaron Lu <aaron.lu@...el.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>

:040000 040000 5bbac8c4f3e9fd5421daf84289004c32c3217f2a 82c99a358bda6360f845b6063182d3e707ff90f0 M      Documentation
:040000 040000 81ed56a41130bbbea980620114ff11e3bb23ee63 a9870ba1d046bde69796060304c78dfbb1d00a1f M      drivers



The fact that this seems to be an *intentional* breakage does not help a
lot.  Yes, I understand that you believe the choice of default was
incorrect for some reason.  You might even be right about that.  But
that is still not a valid reason to break existing configurations for
end users!  Please do not do that.

Note that NO USER cares about "some laptops" or "other laptops".  They
care about their own systems, which either
 a) depend on the old default and therefore breaks with your change, or
 b) have a user modified setting and therefore are unaffected by your
    change

The above commit should be reverted.  It causes breakage for end users.

If you think the default was wrong, then please go back in time and fix
it when it was introduced. Thanks.


Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/