[Kde-hardware-devel] Review Request 119597: Brightness fixes, part 2: Implement brightnessStep logic.
Nikita Skovoroda
chalkerx at gmail.com
Wed Aug 6 00:59:28 UTC 2014
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119597/
-----------------------------------------------------------
(Updated Авг. 6, 2014, 12:59 д.п.)
Review request for Solid and Àlex Fiestas.
Changes
-------
Clean up whitespace.
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 (updated)
-----
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
daemon/powerdevilbrightnesslogic.h PRE-CREATION
daemon/powerdevilbrightnesslogic.cpp PRE-CREATION
daemon/powerdevilkeyboardbrightnesslogic.h PRE-CREATION
daemon/powerdevilkeyboardbrightnesslogic.cpp PRE-CREATION
daemon/powerdevilscreenbrightnesslogic.h PRE-CREATION
daemon/powerdevilscreenbrightnesslogic.cpp PRE-CREATION
daemon/CMakeLists.txt 9759ea1
daemon/actions/bundled/brightnesscontrol.h 8ae3157
daemon/actions/bundled/brightnesscontrol.cpp 8d06bc2
daemon/actions/bundled/keyboardbrightnesscontrol.h 9f12537
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/20140806/f97ec410/attachment.html>
More information about the Kde-hardware-devel
mailing list