> > 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
