Kernel Bug Tracker – Bug 19592
brightness is changed by double steps
Last modified: 2013-03-28 08:21:29 UTC
Hallo, regulation of brightness after X loading is twice
see this bug
Intel driver not work properly, ati open source driver works well
comment #63 in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/257827?comments=all suggests that one step is done by kernel and another is done by userspace.
If this is true, why we don't have such bug report before? This problem should happen on all the laptops.
it seems that X STARTs to handle KEY_BRIGHTNESSUP/KEY_BRIGHTNESSDOWN input event recently, right?
No, not at all laptops
Probably, I can be fixed by workaround in gnome-power-manager
Try setting /sys/module/video/parameters/brightness_switch_enabled to N.
I have tried it, but it disables brightness regulation in TTY (where no X running)
Yes, you'll need some userspace package running in tty sessions as well (which may involve you writing one)
hmm, so reg. of brightness in TTY is bug or feature?
and brightness switch should be disabled by default
so, how will it be fixed?
Why some intel machines don't have this problem?
(In reply to comment #7)
> and brightness switch should be disabled by default
well, /sys/module/video/parameters/brightness_switch_enabled is introduced because we want X to disable the kernel backlight regulation, when X knows it CAN handle the backlight switching.
the default value is N, because we don't want to lost the backlight control in console mode.
So IMO, the future work is to help x play well with this switch.
Matthew, what do you think?
Hmm, is it already inplemented in X?
*** Bug 25482 has been marked as a duplicate of this bug. ***
Hello, coming in from bug 25482 - the problem in my case is likely unrelated to X, as it occurs in ubuntu's recovery mode as well - without X running.
What INFO is needed, as per this bug's status?
It's great that kernel bugzilla is back.
can you please verify if the problem still exists in the latest upstream
Tried with this kernel
There some investigation
But, I think, it works like this, when you press key, kernel changes brightness and also report that key was pressed, so gnome-power-manager also changes brightness (2 steps then, because 1 by kernel + 1 by GPM).
We need to get kernel detecting that GPM is running or so, or just support computers and remove function from GPM.
Or just simply patch GPM to watch, if kernel already changed brightness, if so, then GPM will just report it was changed and do not change again
Testing now with Kubuntu precise + mainline from ppa :
Still the same behaviour:
- down by steps of 2, up not at all
- echo N > ...switch_enabled fixes everything
- regular or recovery mode (single user, no X) boot, X or vty makes no difference
same for me, I have tried my crappy patch to GPM, but they refused it and said it is kernel problem. I have seen speech from kernel dev, so I am encouraged to get it fixed.
so, we are clear what the problem is.
for one hotkey press,
1) kernel changes the backlight
2) kernel send notification to userspace
2) userspace changes the backlight based on the kernel notification
And kernel has a module parameter to disable step 1) and do step2) only, and this parameter is designed to be used by X to disable step 1) when X starts.
but this is not the proper solution that X guys want?
I just proposed your idea to the gnome bugzilla page, let's see what do they think.
The video module parameter brightness_switch_enabled can be used to enable/disable this feature; to avoid the level changing twice, please set it to 0. I would very much like to set the value default to 0, but then perhaps other people would request this set to 1. Let's leave it as it is now.