[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Missing CONFIG_PMAC_BACKLIGHT_LEGACY breaks backlight control

On Sat, 20 Jan 2007 15:21:20 +0100
"Bin Zhang" <yangtze31@gmail.com> wrote:

> No problem on my ibook G4 using debian pbbuttons package.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389770

Thanks. I didn't remember this bug report. I think the backlight
control itself is not the problem here. Since version 0.7.9 pbbuttonsd
uses the sysfs interface too and depends no longer on the PMU ioctl
interface (except IOC_GRAB_BACKLIGHT).

But we have another side effect here. If you press the brightness up
key, the kernel itself processes the key trigger and makes the display
brighter. After that a key event is sent out and pbbuttonsd does the
same again. You got a double brightness increase for the price of one.

That sounds not very serious but if you use the display fading feature
I would expect that the brightness change smoothly from one level to
another after I hit the brightness up key. What happens here is that
you could see the brightness jump up and then maybe the rest changes
smoothly. The reason for that is that the kernel changes the brightness
still hard in 15 steps (It doesn't know anything about fading) although
the sysfs interface supports 127 steps (on my machine) and therefore
the step size of the kernel must not be the same as of pbbuttonsd .

The key problem here is if you can't safely disable old interfaces you
have to keep them fully intact. Don't disable them partly. If debian
doesn't add CONFIG_PMAC_BACKLIGHT_LEGACY people will recognise odd
backlight behaviour on powerpc machines. I have no problem with that
because I compile my own kernel and that's it. At least I hope Frank,
pbbuttons' debian maintainer, would remove such bug reports instantly
if someone blamed pbbuttons for that.

 Best Regards

Reply to: