On Mon, Jan 13, 2020 at 12:20:10PM +0100, Patrick Wildt wrote:
> The problem is that the last two values are 67 and 100. If you go
> 5% down, it's 95. The nearest will still be 100. The code then
> realizes that it's the same level as before, and does nlevel--.
> But nlevel-- is 99, and not 67,
On Mon, Jan 13, 2020 at 12:20:10PM +0100, Patrick Wildt wrote:
> The problem is that the last two values are 67 and 100. If you go
> 5% down, it's 95. The nearest will still be 100. The code then
> realizes that it's the same level as before, and does nlevel--.
> But nlevel-- is 99, and not 67,
On Mon, Jan 13, 2020 at 11:58:11AM +0100, Klemens Nanni wrote:
> On Sun, Oct 13, 2019 at 09:28:26PM -0500, joshua stein wrote:
> > When responding to hardware keys to increment or decrement screen
> > brightness, don't just adjust by 1 BCL level as there may be 100
> > levels. Find the next
On Sun, Oct 13, 2019 at 09:28:26PM -0500, joshua stein wrote:
> When responding to hardware keys to increment or decrement screen
> brightness, don't just adjust by 1 BCL level as there may be 100
> levels. Find the next brightness level that is at least 5% up or
> down, and use that.
> Date: Sun, 13 Oct 2019 21:28:26 -0500
> From: joshua stein
>
> When responding to hardware keys to increment or decrement screen
> brightness, don't just adjust by 1 BCL level as there may be 100
> levels. Find the next brightness level that is at least 5% up or
> down, and use that.
I
Patch works well on a T470s. Stepping is better in the larger
increments. No ill effects from the patch here.
Thanks,
Tracey
On Sun, Oct 13, 2019 at 09:28:26PM -0500, joshua stein wrote:
> When responding to hardware keys to increment or decrement screen
> brightness, don't just adjust by 1
When responding to hardware keys to increment or decrement screen
brightness, don't just adjust by 1 BCL level as there may be 100
levels. Find the next brightness level that is at least 5% up or
down, and use that.
Index: dev/acpi/acpivout.c