Message-ID: <53C4D17E.60206@redhat.com>
Date:	Tue, 15 Jul 2014 09:00:14 +0200
From:	Hans de Goede <hdegoede@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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

Hi,

On 07/14/2014 06:24 PM, Linus Torvalds wrote:
> On Mon, Jul 14, 2014 at 6:14 AM, Hans de Goede <hdegoede@...hat.com> wrote:
>>
>> This *not* a regression, it is an intended behavior change [..]
> 
> That counts as a regression.
> 
> If things used to work, and they don't work, it's a regression. If
> it's intentional, that just makes it worse.

The problem is that our previous default behavior turns out to be
wrong for many users.

So as answered later in the thread Bjørn is using a custom setup with
acpid and WindowMaker. So in order to keep his exotic (and very simple
to fix) setup working we are keeping thing broken on what are probably
a 100 thousand Linux installs or more.

> 
>> Yes this may break existing configurations for some users, most likely
>> users running some custom setup, who thus should be able to fix things
>> by adding one more customization to there setup.
> 
> .. and apparently this whole paragraph is completely bogus. It *does*
> break things, and for normal people.

It breaks things on exotic setups, running a non standard desktop
environment or no desktop environment at all. Note that this is
about laptops most people will be using one of gnome / kde / unity /
xfce on a desktop, and for all of these the old default behavior is
bad.

> That's what the bug report is all about. So don't waffle about it.
> 
> Bjørn, what's your setup?
> Is this perhaps solvable some other way?

I see that further down the thread you've send a patch to fix
this by waiting sometime for userspace to react and if it does
not then do the change in the kernel as it used to be.

FWIW I don't think this is a good idea. This is inherently racy, so
we will still sometimes see the backlight taking 2 steps leading to
hard to debug problems.

It has made me think about doing something to keep both setups
like Bjørn's working, and get rid of the 2 steps problem. I think
adding an auto setting for brightness_switch_enabled and making that
the default is a good idea. But instead of using a timeout, I suggest
to make -1 / auto behave the same as 1 / on until userspace sets the
brightness. Once userspace has written to the brightness attribute
we start interpreting auto as 0 / off.

Rafael would you be willing to take a patch doing this ?

>> TL;DR: This change really is for the better and is here to stay.
> 
> Wrong. We don't break existing setups, and your attitude needs fixing.
> 
> Rafael, please get it reverted, or I will have to revert it. We have
> *long* had a rule that we don't break things "in order to improve
> things for others", and quite frankly, power management and ACPI in
> particular was exactly *why* that rule was introduced, because the
> whole "one step back, two steps forward" model does not work.
> 
> The problem needs to be solved some other way, and developers need to
> f*cking stop with the "we can break peoples setups" mentality./
> 
> Hans, seriously. You have the wrong mental model. Fix it.

Linus, normally I agree 101% with your no regressions policy. but I'm
also a big fan of the it just works philosophy. The problem here is
that when this switch got introduced a long time ago it got (in hindsight)
the wrong default. In order to make things just work it needs to get
fixed, but maybe we can come up with a solution to both have our cake
and eat it.

Regards,

Hans
--
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/

Powered by blists - more mailing lists