KMilo: brightness OSD shows old value #68

Basic information

TDE version: R14.1.1
Distribution: Arch Linux
Hardware: amd64 (Acer TravelMate laptop)

Description

When using Fn keys to control brightness, the OSD that appears shows the old brightness value.

Steps to reproduce

Ensure KMilo service is running.
Consecutively press the Fn combination that corresponds to the "decrease brightness" hotkey (Fn+F3 for me). Each time the brightness should decrease by 10%.
Notice that the last value that appears on the OSD before the screen goes totally dark is 20%.
Press the Fn combination that corresponds to the "increase brightness" hotkey (Fn+F4 for me) once.
Notice how the OSD displays a value of 0%.
Consecutively press the hotkey of step 3 until the OSD shows 90%.
Press the hotkey once.
Notice how the brightness did not change but the OSD now shows 100%.

Background

TDE/tdeutils#55 introduced improved brightness OSD feedback to KMilo. The core of that PR was to display the correct value on machines with fewer brightness steps capability and not blindly assume that logical value == actual value.

The PR introduced a DCOP call to get the actual brightness value after the brightness was modified.

Possible explanation

This issue is likely related to that change, which was part of the R14.1.1 update, because in R14.1.0 and earlier I did not encounter this issue.

It is probable that in some cases something delays the brightness change in TDEPowersave, resulting in the DCOP call returning the old brightness value.

Notes

This is probably the same issue that Roman has encountered (but the proposed patch is an unacceptable hack).

Hi Philippe, thanks for reporting this. I can't reproduce it so I will need your help for testing. I can think of three possible explanations:

the hardware is slow to update even if all the calls are sync, so physically the brightness value is changed after the call to get the new brightness
there are two video cards and for some reasons the value is updated on one card and read from another. This is a stretch and I don't think it is actually the case but I don't want to rule out any possibility
a bug in the changes I made. Although I checked the code several times and tested on various computers, you never know, bugs can always get into the code.

For sure the old way of using the logical value was not accurate either. I will look into this.

This is probably the same issue that Roman has encountered (but the proposed patch is an unacceptable hack).

Sounds like the same issue to me too.

I am able to replicate this on my own real computer with Q4OS live, so I will be able to troubleshoot it.

It's a combination of 1. and 3.
The call in kmilo is non blocking (send instead of call) and the hardware takes some time to update (60ms on this computer). Will prepare a fix.

Solved by PR #69.