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

Nikita Skovoroda chalkerx at gmail.com
Sat Aug 9 22:04:59 UTC 2014


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

(Updated Авг. 9, 2014, 10:04 п.п.)


Review request for Solid and Àlex Fiestas.


Changes
-------

Signal fixes:
1) Use const & for passing a structure.
2) Use Qt5-styled connect() calls for nicer syntax and compile-time checks.


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/CMakeLists.txt 9759ea1 
  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 
  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 

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/20140809/9cd39aaf/attachment.html>


More information about the Kde-hardware-devel mailing list