Bug#407671: Missing CONFIG_PMAC_BACKLIGHT_LEGACY breaks backlight control
> > severity 407671 wishlist
> > thanks
> >
> 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? ;-)
I have to agree with Matthias here. The same bug happens for pmud which I
haven't converted to sysfs yet. The kernel should not introduce changes
that break backwards compatibility, ever. Doubly so for the stable release
kernel.
> 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.
Fully agree. Thanks to Matthias for explaining the severity nicely. Now
can we have the bug severity reset, please? Can we have the reason for
disabling this option explained?
Michael
Reply to: