Re: Bug#407671: Missing CONFIG_PMAC_BACKLIGHT_LEGACY breaks backlight control
On Sat, 20 Jan 2007 13:51:21 +0100
Bastian Blank <waldi@debian.org> wrote:
> severity 407671 wishlist
> thanks
>
> On Sat, Jan 20, 2007 at 01:18:26PM +0100, Matthias Grimm wrote:
> > This option disables some PMU ioctls that won't be needed anymore due
> > to the sysfs backlight interface. Unfortunately the current setting also
> > disables IOC_GRAB_BACKLIGHT, that _is_ needed by any user space daemon that
> > likes to control the LCD backlight.
>
> Why? IOC_GRAB_BACKLIGHT is used to add some lock to it.
No, it doesn't. IOC_GRAB_BACKLIGHT disables kernel code that handles
the brightness up/down keys directly. It has nothing to do with setting
the backlight level via the PMU ioctl interface.
The kernel does the backlight tuning automatically if the backlight
up/down keys are triggered by its own and no user space can influence
this. In fact if I press brightness up the LCD backlight becomes
brighter a certain step even if my user space daemon doesn't want this.
The only thing that prevents the daemon to go crazy is that it reads
the brightness change from the kernel back and adapt itself to it but
we have to say goodby to a fine grained backlight control. Especially
fading is a grief and key trigger will be processed twice: First from
the kernel and second from the daemon.
The kernel developers didn't remove the ancient backlight code and
installed IOC_GRAB_BACKLIGHT instead. With this ioctl a user space
daemon can switch off the kernel backlight keys code and get full
control over it. Unfortunately CONFIG_PMAC_BACKLIGHT_LEGACY will also
disable this ioctl and a user space daemon can't disable the kernel
backlight keys code anymore.
> > This bug is at least grave because it will break system daemons like
> > pbbbuttons, hal and any other that controls the backlight on powerpc.
>
> No, it is wishlist. The userspace tools have to be fixed to cope with
> that.
Don't agree. The user space daemon have no chance to cope with this
because the kernel take over a task that is usually and better done by
user space programs. The only way for user space daemons to handle this
is _not_ to handle this. Let the kernel do the brightness keys and the
daemon do the volume keys. As side effect the volume keys will cause a
popup to appear showing the current level and brightness keys won't.
That's real usability, don't you think? ;-)
> The code is unchanged in 2.6.20-rc5, so the behaviour is not yet
> questionable. If it is broken, bug upstream first.
Very good hint ;-) I did this already at the beginning of 2002 and they
implemented IOC_GRAB_BACKLIGHT as reaction, I did it again in 2006
as I discovered the messed up kernel configuration with no reaction yet
and I will do it again but this way is very rough for a complete kernel
outsider as I am.
This is no doubt a kernel bug but debian has the chance to fix it very
easily for its users. Otherwise they would be forced to built their own
kernel (as I already did). On the other hand it is only a small
configuration change that leads to a few bytes bigger kernel image and
with no other side effects. It would be a grief if etch comes without
this.
Best Regards
Matthias
Reply to: