linux-kernel - Re: i915/kms/backlight-combo mode problem

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]

Date:	Sun, 15 May 2011 12:08:48 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Melchior FRANZ <melchior.franz@...il.com>
Cc:	linux-kernel@...r.kernel.org, Michael Chang <mchang@...ell.com>,
	Joey Lee <jlee@...ell.com>, chris@...is-wilson.co.uk,
	dri-devel@...ts.freedesktop.org
Subject: Re: i915/kms/backlight-combo mode problem

At Tue, 10 May 2011 13:08:23 +0200,
Melchior FRANZ wrote:
> 
> * Michael Chang -- Tuesday 10 May 2011:
> > Could you please try this patch and get the log ? We wonder why
> > is_backlight_combination_mode () returns false.
> 
> This information was already buried in the bugzilla thread:
> 
>   https://bugzilla.kernel.org/show_bug.cgi?id=31522
>   "It turned out that on this machine INTEL_INFO(dev)->gen equals 4,
>   and is_backlight_combination_mode() returns 0x40000000."
> 
> 
> But to say it again in your words:   :-)
> 
>   [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824  (0x40000000)
> 
> 6x during boot-up, and several times later when changing the backlight
> brightness.
> 
> 
> This was with 8b061610dac3a3b89770c85ad63b481a47b0c38e. And now
> I have a little shocker for you (and me): because this was a
> vanilla kernel (apart from these debug messages), the screen went
> black again, like I knew it. But pressing the "brightness down"
> key turns the backlight on! I can't believe that I haven't tested
> that. I guess I've only tried "brightness up" and "display toggle".
> Those don't turn backlight on. Or maybe somethine else relevant
> meanwhile changed in the i915 drivers. (I've regularly been
> updating to HEAD.)  
> 
> So, the problem was just the initial state all the time?

Looks so, indeed.  Now, the question is what's the real cause.

IIRC, you reported that the backlight gets normal when you revert my
commit in 2.6.38.x.  So, this was regarded as a regression at first.
But, one question remains: whether the backlight level control worked
with the reverted kernel?
Judging from the attempts so far, it looks like that only LBPC can
adjust the level on your machine.  If it's true, 2.6.38.0 shouldn't be
able to adjust the level.  If you can still change the level without
LBPC, the former analysis was incorrect.

Also, with the latest 2.6.38.x, you found that the backlight gets back
when you adjust the level down.  Another question now is what happens
if you again turn it up to the max level.  Is the backlight still on?

If the backlight is kept on even with the max level, it implies that
the problem is only the initial value; once when set correctly, it'll
work fine after that.  OTOH, if the backlight gets off again at max,
it means that the max value (LBPC 0xfe) is a sort of out-of-range.
Then LBPC calculation in the driver has to be modified.

thanks,

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