Bug 276482

Well, imagine cat /sys/class/backlight/acpi_video0/max_brightness would be 1000 (i.e. very fine stepping possible), would you still agree that hitting the key should step by amount of 1? In other words, there should be a sensible reduction or limitation in number of steps when using the key shortcuts. Reassigning to Solid maintainers to decide.

Ok but 8 steps is too low. It misses usable settings which now I have to change by hand via /sys/ filesystem. 16 looks more resonable but still...


When changing brightness a bar popups with graphical representation of what brightness is. This bar has 21 rectangles representing steps, so there should be exactly that number of steps max (or less if hardware doesn't allow for that).

People tell me that apple hw has more brightness levels than 16 (needs to be verified) and if that's true then maybe bigger (like 32 max) number is reasonable as default.

Also people tell me that in gnome this is customizable - you tell how many steps there are going to be, so if you want you can have 1000 steps (even if this will be mapped to real 16 levels).

gnome limits to 20 steps:
http://git.gnome.org/browse/gnome-power-manager/tree/src/gpm-brightness.c#n190

I am not in the position to decide, but given the fact that OSD and GNOME code agreed on 20 steps, it would make sense to raise to that number in KDE code, too.

cat /sys/class/backlight/acpi_video0/max_brightness 
15

But I have only got 6 steps (0, 3, 6, 9, 13 and 15) on my Thinkpad Edge 13 (AMD). I would wish to have at least more steps in the lower region (1 and 2).

I can but agree with the previous comment. Lowest level is too dark and the next level up is too bright.

*** Bug 280813 has been marked as a duplicate of this bug. ***

Hi,
i have a similar issue with my Thinkpad Edge (intel model).
It has 15 brightness steps which i can control perfectly (with fn+F7/F8) right until i login into KDE. As soon as the brightness OSD appears every fn+F* stroke makes the brightness change by several levels, and not one by one as it should be doing. 

In KDE4.6 it changed by two brightness levels each time, so out of 15 possibilities i could only use 8. In KDE4.7 i can only use 6 brightness levels.
By the way, the brightness OSD contains 21 bars, much more than the 15 levels supported by the laptop... shouldn't this be adjusted to the hardware capabilities of each device?

When using the command showkey on the console the idea that i get is that KDE is ajusting the key strokes to whatever it considers appropriate. I can see that most of the time each fn+F7 or F8 key press counts as two strokes. But sometimes, when close to the limit of the OSD bar is shows up properly as a single keystroke.

Also, if i move to another "console"(?) using ctrl+alt+F1 i can use the whole 15 brightness steps. Back to KDE (crtl+alt+F7) and i'm stuck with 6 levels again.
Of note, other OSDs such as sound volume works fine.

Here is another bug report which i think deals with the same problem:
https://bugs.kde.org/show_bug.cgi?id=273437

Can the status be changed to confirmed?

regards,
Carlos

> Also, if i move to another "console"(?) using ctrl+alt+F1 i can use the whole
> 15 brightness steps. Back to KDE (crtl+alt+F7) and i'm stuck with 6 levels
> again.
I just tried this and can confirm it (KDE 4.7.1, Thinkpad Edge 13 (AMD)).

I have reverse issue. I have 16 levels of brightness control, but in kde I can control only 10 levels and it`s better !:
I dim from 15 to 0 and in kde it`s going with 15...14...and so on...6...5 and blank screen.
Last 5 steps are used. When I light up it`s starts from 5 (more bright).

Is there way to this behaviour?

Asus A6RP, Funtoo on KDE 4.7.4

New info about original issue from this bug report.

On my thinkpad t400 brightness change is handled by bios/hardware without any need for software to work.

In PowerDevilUPowerBackend::brightnessKeyPressed() [1] this is handled - basically method just stores currently read value brightness (which is actually a new value since bios changed it on it's own) and stores it in m_cachedBrightness.

The whole problem comes from the fact that PowerDevilUPowerBackend::brightnessKeyPressed() is called TWICE for single brightness up/down key press. No idea why.

Since it's called twice then first call will make brightnessKeyPressed() just store new value under m_cachedBrightness but the second call will make brightnessKeyPressed() cause to increase/decrease brightness value (by 10).

So my single press -> bios changes brightness (by 6 here) -> brightnessKeyPressed() called, it notices value change, stores new value -> brightnessKeyPressed() is called again; code thinks it's real change request (different code path than on first brightnessKeyPressed()) -> kde changes brightness by 10.

In the end single key press causes increase/decrease by 16 instead of just 10. This causes many levels to be skipped.

1. kde-workspace-4.8.2/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp

Created attachment 70519 [details]
workaround I'm using

This workaround ignores second brightnessKeyPressed() call if it was done in less than 0.1s than previous brightnessKeyPressed() call.

Also update OSD display when going via "else" codepath there sine I want OSD to show brightness change even if it's handled by BIOS itself.

One explanation: kde internally maps brightness value to 0-100 always and when talking about steps in last two comments I was talking about steps in that mapped range (and not what is in /sys/ fs).

So
100 (max value) / 16 (bios+kde own change step) -> 6 steps total.
100/10 -> 10 steps total.

Since my bios does steps by ~6 then with patch applied I'm eliminating kde own +-10 and thus I have 100/6->16 levels which matches sysfs max_brightness value!

Thanks Arkadiusz for your workaround, but how can i use it...
Should i patch some file using the "patch" command?
regards,
Carlos

Created attachment 75601 [details]
patch for kde 4.9.4

Update workaround for 4.9.4.

Note that this bugreport is about two issues:
1) too small limit of levels
2) two brightness events emited on some thinkpads while only one physically happened

Workaround deals with both these. Tested on Lenovo Thinkpad T400.

I agree this is a workaround but it may be the only way... I'm affected by this on XPS1330.

Dario what should we do? is this patch good to go?

https://bugs.launchpad.net/ubuntu/+source/hal/+bug/207473

*** Bug 303131 has been marked as a duplicate of this bug. ***

*** Bug 309325 has been marked as a duplicate of this bug. ***

*** Bug 304501 has been marked as a duplicate of this bug. ***

*** Bug 314048 has been marked as a duplicate of this bug. ***

In response to Comment #12:
I have the same problem on my EeePC with Intel GMA3150. On the console and in other Desktops (I tried XFCE and Awesome WM) I can switch brightness just fine. But in KDE, it is more like gambling:
- brightness is always changed twice for one trigger of the key combination
- each trigger induces considerable CPU load
- if pressed too long or too often in succession, CPU load stays on for a very long time during which KDE becomes very unresponsive.
- sometimes it seems that the brightness change is triggered again and again, for instance if there is already some load on the system. I.e.: I press brightness up more than once during the system is busy (compiling, browsing, etc.). Now brightness goes up in a jerky way and the progress bar appears at some point. Now I press brightness down, and it goes down, but then immediately up again. Or it goes fully up, then fully down, and fully up again.

I, too, have two interfaces:
/sys/class/backlight/acpi_video0/
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/

The ACPI range goes from 0 to 10 (0 being dark, but switched on). Each Fn-keypress in/decreases it by 1 (in XFCE by 2). I can echo a value into the Intel brightness file from 0 to 125. 0 to to 4 switches off the backlight, 16 is the lowest value achievable through the Fn+F* keys, and 125 is the maximum (everything above yields "echo: write error: Invalid argument").

It looks like some race between hard- and software. I also found out the culprit: in my case, it is the eeepc-wmi module. If I unload it, I still have both interfaces of course, but this whole race situation is gone, even with the asus-wmi module still loaded (which is a dependency of eeepc-wmi).
BUT: without eeepc-wmi, there is no more progress OSD and the power applet's brightness slider doesn't update anymore (though it can still be used). XFCE, on the other hand, still shows the correct OSD.

I hope I could shed some additional light on this.

Can you send this patch to the KDE reviewboard?

Well, I have 892 steps via /sys.
But these KDE's 10% steps does not catch the sweetspots. For example I really seldom use anything above 40%.  So currently 7 out of 10 steps are really useless (including lowest zero/screen off).

I'd wish to have this user customizable rather than hardcoded in the source. Ideally if it were limited I would probably prefer something like this:
0% 5% 10% 15% 20% 35% 45% 60% 80% 100% 

But it's only me, I'm not sure how the bundled OS did, but it's smoother and probably allowing less than 1% accuracy where you set the brightness by feel, not by a value! Which should be the whole point serve the user rather than the math with exact values. The end user doesn't care if it's 31,33% or 30% brightness as long as it looks good for the current moment.

1. Please add option "Brightness control device" in "System Settings" ->"Display and Monitor" where I can choose from combo menu what device controls backlight of LVDS device.
This combo would use names from: /sys/class/backlight/ directory listing,
Real life example: laptop HP ProBook 455 G1 with two Radeons inside.
Inside: /sys/class/backlight/
acpi_video0 (connected to primary Radeon inside APU, brightness steps 0-20)
acpi_video1 (connected to secondary Radeon mobile GPU - no brightness control because it is mux-less - connects to display via primary Radeon in APU no backlight control possible)
radeon_bl0 (connected to Radeon inside APU, brightness steps 0-255)
Stupid KDE chooses acpi_video1 because some egoistic moron hardcoded this in backlighthelper.cpp file inside kde-workspace sources. Because it is good for his laptop and of course nobody else lives on this planet and use KDE.

2. Allow to configure steps. Now +-10 step is hardcoded in powerdevilupowerbackend.cpp because nobody else uses KDE than 1 developer who wrote this code. If you strongly believe that there is more than 1 person using KDE add option to configure step size.
Now sadistic powerdevilupowerbackend.cpp developer decided to burn my eyes out from head not allowing to have brightness lower than 12 where I need 1.

Only way to set mild brightness for this laptop is to open konsole and do:
echo 1 > /sys/class/backlight/radeon_bl0/brightness

http://www.kde.org/code-of-conduct/

I do some debugging for these code and can CONFIRM that the really problem is that PowerDevilUPowerBackend::brightnessKeyPressed will be called twice after Fn+Brightness is pressed.

This is really inconvenient for people does not have much brightness level:  for me, I original have 7 level of brightness.  As PowerDevilUPowerBackend::brightnessKeyPressed is called twice, I can only use 3 brightness level. Really annoying!

Since this bug is has target millstone 4.11, I hope developers can at least merge the workaround in.  People have suffered this bug for more than 3 years.

OK.  It seems that the bug is not in powerdevilupowerbackend.cpp:

One Workaround without patch:
Open your KDE Global Keyboard Shortcuts, Switch to KDE Daemon,  Change the shortcuts for {Increase, Decrease} Screen Brightness to other shortcuts, for example Meta+F7 and Meta+F8.

Now I can use Meta+F7 and Meta+F8 to enjoy full level brightness switch, since my hardware only support 7.

Maybe we should reassign this bug to kdelibs team?

I update the patch for kde 4.11.5. 
See https://git.reviewboard.kde.org/r/115420/.

This only workaround double PowerDevilUPowerBackend::brightnessKeyPressed problem. 

It doesn't fix
1.  give more brightness steps:  20 brightness steps will not work on my laptop, becuase I have only 7 levels of brightness and 7/20 < 0.5, which will be round to zero.  So I still keep 10 steps.

2. custom the number of steps (as requested by Zbigniew Luszpinski)

3. custom "LVDS device"  (as requested by Zbigniew Luszpinski)

To fix these problems I think some large changes in the code base are needed.  It's too risky for me to implement them because it will cost a longer time and it is possible that finally the maintainer doesn't accept such patches.

Custom number of steps will be very useful for the intel haswell gfx cards since they offer finegrained control over brightness. On my Intel 4600, the 'max_brightness' is around 4400, so 10% doesn't cut it.

(In reply to Jimmie Tauriainen from comment #25)
> Well, I have 892 steps via /sys.
> But these KDE's 10% steps does not catch the sweetspots. For example I
> really seldom use anything above 40%.  So currently 7 out of 10 steps are
> really useless (including lowest zero/screen off).
> 
> I'd wish to have this user customizable rather than hardcoded in the source.
> Ideally if it were limited I would probably prefer something like this:
> 0% 5% 10% 15% 20% 35% 45% 60% 80% 100% 
> 
> But it's only me, I'm not sure how the bundled OS did, but it's smoother and
> probably allowing less than 1% accuracy where you set the brightness by
> feel, not by a value! Which should be the whole point serve the user rather
> than the math with exact values. The end user doesn't care if it's 31,33% or
> 30% brightness as long as it looks good for the current moment.


This would seem to be the sensible option.  Either a user interface displaying a bezier curve of some kind which allows adjusting the mapping to better fit the individual hardware's brightness response to a series of fixed steps (taking a cue from the control panel for Wacom graphics tablets' pressure sensitivity would be a good start), or allowing manually specifying the steps, as you suggest.

For my 2013 Sony Vaio Pro 13, the max_brightness is 93 (go figure), and 10% steps are useless at *both* ends of that scale - for using the machine in darkness or near darkness far too coarse, but near the maximum brightness, the apparent difference between 80%, 90% and 100% is almost unnoticable, so I'd be looking for something along the lines of (values/93) (0) 1 2 5 10 15 20 30 40 50 70 93 to get useful apparent brightness levels.

Currently (Dell XPS) I'm increasing number of steps using this patch:

http://git.pld-linux.org/gitweb.cgi?p=packages/kde4-kdebase-workspace.git;a=blob_plain;f=kde4-kdebase-workspace-brightness-step.patch;hb=HEAD

--- kde-workspace-4.11.10/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp~	2014-06-08 12:55:49.000000000 +0200
+++ kde-workspace-4.11.10/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp	2014-08-05 20:09:46.321671397 +0200
@@ -321,7 +321,7 @@
 
     float currentBrightness = brightness(controlType);
 
-    int step = 10;
+    int step = 2;
     if (controlType == Keyboard) {
         // In case the keyboard backlight has only 5 or less possible values,
         // 10% are not enough to hit the next value. Lets use 30% because

I think this is actually a kernel bug, which was fixed in linux 3.17. In the meantime you can set video.brightness_switch_enabled=0 in the kernel parameters to work around it.

The step calculation in PowerDevil 5 is a bit more complicated and will actually ensure it's always 10% no matter how many or few actual values your hardware accepts.
Battery monitor, starting in Plasma 5.2, will now use the full range of brightness available on your hardware for the sliders. As for the Fn keys, I was planning on changing it from 10% to 5% steps to be consistent with KMix.

This bug is reported on libsolid which is the kdelibs4 version of the solid library.  It is now in maintenance mode.  If you think it should still be fixed in the KDE Frameworks 5 version of solid please move it to or report a bug on frameworks-solid or Powerdevil.

For me, 20 steps is way to much! I would prefer to have 10 or so, like it was before.
Also, as a site note, the speaker volume has 15 steps, not 10 or 20 as stated in comment 36.

I use Kubuntu 15.10 with KDE Frameworks 5.15.0 on a Thinkpad T440s.

Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I am closing this bug. Please try again with the latest version and submit a new bug to frameworks-solid if your issue persists. Thank you!