On Sat, 20 Jan 2007 13:51:21 +0100 Bastian Blank <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
