[Kde-hardware-devel] Review Request 119597: Brightness fixes, part 2: Implement brightnessStep logic.

[Nikita Skovoroda]

> On Авг. 3, 2014, 11:05 п.п., Àlex Fiestas wrote:
> > daemon/powerdevilbackendinterface.cpp, lines 277-339
> > <https://git.reviewboard.kde.org/r/119597/diff/1/?file=295242#file295242line277>
> >
> >     Split into different methods and put documentation on top of each other when necessary.
> >     
> >     Also, maybe some test for them?
> 
> Nikita Skovoroda wrote:
>     Moving that logic to a separate class triggered some changes in other places, so the diff became a bit bigger.
>     Is that fine or should I split it in two commits?

Ah, actually I managed to still keep the changes minimal for now.

Will upload the new diff soon.


- Nikita


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119597/#review63725
-----------------------------------------------------------


On Авг. 5, 2014, 1:42 п.п., Nikita Skovoroda wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119597/
> -----------------------------------------------------------
> 
> (Updated Авг. 5, 2014, 1:42 п.п.)
> 
> 
> Review request for Solid and Àlex Fiestas.
> 
> 
> Repository: powerdevil
> 
> 
> Description
> -------
> 
> This is a continuation of https://git.reviewboard.kde.org/r/119559/.
> 
> Now that all layers are aware of the actual integer brightness value and the maximum brightness value, rework «brightness up/down» actions.
> See background explanation in previous RR.
> 
> ____
> 
> Implement brightnessStep logic.
> 
> Introduce brightnessStep, brightnessStepMax, brightnessStepChanged, setBrightnessStep D-Bus endpoints in org.kde.Solid.PowerManagement.Actions.BrightnessControl.
> Introduce correspoding D-Bus endpoints in org.kde.Solid.PowerManagement.Actions.KeyboardBrightnessControl.
> 
> Use step-based logic for increase/decrease brightness actions.
> 
> This makes the increase/decrease brightness actions behave as if the brightness steps are pre-calculated.
> 
> 
> Also, brightness percentage is now rounded everywhere (it was just cast to int without rounding before), now that the inner logic does not depend on the percentage anymore.
> Before this patch I was not sure if this would make things look worse or not.
> ____
> 
> An illustraton:
> Before: http://oserv.org/tests/kde/powerdevil/brightness_before.php
> After: http://oserv.org/tests/kde/powerdevil/brightness_after.php, this script shares the same code for calculating steps count.
> 
> 
> Diffs
> -----
> 
>   daemon/actions/bundled/brightnesscontrol.h 8ae3157 
>   daemon/actions/bundled/brightnesscontrol.cpp 8d06bc2 
>   daemon/actions/bundled/keyboardbrightnesscontrol.h 9f12537 
>   daemon/actions/bundled/keyboardbrightnesscontrol.cpp 075a984 
>   daemon/actions/bundled/org.kde.Solid.PowerManagement.Actions.BrightnessControl.xml abe33c6 
>   daemon/actions/bundled/org.kde.Solid.PowerManagement.Actions.KeyboardBrightnessControl.xml ea4a504 
>   daemon/backends/hal/powerdevilhalbackend.h a261a65 
>   daemon/backends/hal/powerdevilhalbackend.cpp b9ab9aa 
>   daemon/backends/upower/powerdevilupowerbackend.h 2b51f30 
>   daemon/backends/upower/powerdevilupowerbackend.cpp 92a6cdd 
>   daemon/powerdevilbackendinterface.h d79ba46 
>   daemon/powerdevilbackendinterface.cpp de15302 
> 
> Diff: https://git.reviewboard.kde.org/r/119597/diff/
> 
> 
> Testing
> -------
> 
> Works for me, shortcuts now follow persistent brightness steps.
> 
> Works on acpi_video0 with 10 steps, asus::kbd_backlight with 3 steps, and intel_backlight notebook with 4000+ steps.
> 
> The BackendInterface::calculateStepsCount() logic was separately tested for all possible max_brightness values.
> 
> Only upower backend was tested.
> 
> HAL backend uses variable m_cachedKeyboardBrightness before it is initialized, and I am not the one who wrote it that way.
> 
> 
> Thanks,
> 
> Nikita Skovoroda
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20140805/947d119c/attachment-0001.html>