> 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 > >
_______________________________________________ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel