Bug#434305: pbbuttons scripts trigger hdparm -p, clears PIO mode
The script was changed in version 0.8.1a. Thanks for reporting this problem Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426439: pbbuttonsd: Coexist with Gnome's power and volume daemons
Hi Martin, I'm sorry but I had to reject your patch. The phenomenon you reported is not a bug of pbbuttonsd. It is a design error of gnome power manager. Please file a bug there to change gnome-power-manager to a clean client-server architecture. In this case gpm could use pbbuttonsd's functionality as a power manager front-end instead of competing with it. I would accept patches in that direction. Your patch disables some of pbbuttons core functions. Due to your changes most of the other power management functions may fail too because essential information from the system is blocked. I can't recommend using your patch but pbbuttons is GPL, so please feel free to patch pbbuttonsd on your own risk. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426441: pbbuttonsd: Fix CD-ROM ejection on some models
Hi Martin, I applied you CDROM patch. The next release will contain it. Thanks for your work. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428494: pbbuttonsd: several bashisms (test ==)
Hi Colin, Thanks for your report. I applied your patch to the upstream source. The next release will contain it. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407671: kernel 2.6.18: Confusion about Macintosh backlight configuration
On Mon, 22 Jan 2007 14:33:35 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Which solution you prefer is up to you but I would be glad if at least solution #1 could be realised. For now, at least, what prevents you from having all enabled and have pbbuttonsd still call PMU_IOC_GRAB_BACKLIGHT ? Nothing. Pbbuttonsd does so by now but this wouldn't help if someone set CONFIG_PMAC_BACKLIGHT_LEGACY to off. I check this out with debian, hoping you will find a smart solution for this in the future. I think the debian people getting aware of this backwards compatibility problem now and there is hope they will fix it for etch. Thanks for your comment. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407671: Missing CONFIG_PMAC_BACKLIGHT_LEGACY breaks backlight control
Subject: linux-image-2.6-powerpc: Missing CONFIG_PMAC_BACKLIGHT_LEGACY breaks backlight control Package: linux-image-2.6-powerpc Version: 2.6.18+5 Severity: grave *** Please type your report below this line *** In the current debian kernel 2.6.18 the option CONFIG_PMAC_BACKLIGHT_LEGACY is not set. 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. The kernel contains still code to read the backlight up/down keys and sets the backlight by its own. This ancient code fragment uses only 15 backlight steps (sysfs will support 127 or more) and will interfere with any user space program that likes to control the LCD backlight on its own. With the ioctl IOC_GRAB_BACKLIGHT the kernel code can be disabled so that it won't interfere anymore with user space actions on the backlight. This bug is at least grave because it will break system daemons like pbbbuttons, hal and any other that controls the backlight on powerpc. Please set the kernel option CONFIG_PMAC_BACKLIGHT_LEGACY in the official debian kernel. Best Regards Matthias -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages linux-image-2.6.18 depends on: ii coreutils 5.97-5 The GNU core utilities ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy linux-image-2.6.18 recommends no packages. -- debconf information: linux-image-2.6.18/prerm/would-invalidate-boot-loader-2.6.18: true linux-image-2.6.18/preinst/lilo-has-ramdisk: linux-image-2.6.18/postinst/bootloader-test-error-2.6.18: linux-image-2.6.18/preinst/failed-to-move-modules-2.6.18: linux-image-2.6.18/preinst/abort-overwrite-2.6.18: * linux-image-2.6.18/preinst/overwriting-modules-2.6.18: false * linux-image-2.6.18/preinst/already-running-this-2.6.18: linux-image-2.6.18/preinst/bootloader-initrd-2.6.18: true linux-image-2.6.18/postinst/old-system-map-link-2.6.18: true linux-image-2.6.18/preinst/initrd-2.6.18: linux-image-2.6.18/postinst/old-initrd-link-2.6.18: true shared/kernel-image/really-run-bootloader: true linux-image-2.6.18/postinst/depmod-error-initrd-2.6.18: false linux-image-2.6.18/postinst/bootloader-error-2.6.18: linux-image-2.6.18/postinst/create-kimage-link-2.6.18: true linux-image-2.6.18/prerm/removing-running-kernel-2.6.18: true linux-image-2.6.18/preinst/elilo-initrd-2.6.18: true linux-image-2.6.18/postinst/kimage-is-a-directory: linux-image-2.6.18/postinst/depmod-error-2.6.18: false linux-image-2.6.18/postinst/old-dir-initrd-link-2.6.18: true linux-image-2.6.18/preinst/lilo-initrd-2.6.18: true linux-image-2.6.18/preinst/abort-install-2.6.18: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407671: Missing CONFIG_PMAC_BACKLIGHT_LEGACY breaks backlight control
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]
Bug#407671: kernel 2.6.18: Confusion about Macintosh backlight configuration
Hi, I know your guys are very busy and sometimes a email got lost. Normally I would let it run but this time debian is going to integrate a kernel from my point of view with a grave bug and they rejected any change because they can't see any changes in the upstream project. (see debian bug #407671) I added the new SysFS backlight interface to PBButtons and struggled over a bit of the kernel 2.6.18 (stable) configuration. Beside other we have two options in Device Driver - Macintosh Drivers: CONFIG_PMAC_BACKLIGHT enables 1. the generic backlight code used for the SysFS interface *and* 2. the direct backlight manipulating routines for older PowerBooks. This means the kernel itself react to the brightness keys and change backlight level accordingly. This feature interferes with user space daemons like pbbuttonsd. CONFIG_PMAC_BACKLIGHT enables 1. PMU_IOC_GET_BACKLIGHT 2. PMU_IOC_SET_BACKLIGHT 3. PMU_IOC_GRAB_BACKLIGHT The help text of CONFIG_PMAC_BACKLIGHT suggests that this option is only needed if I have an old PowerBook and I could say No here if I use a user space daemon. But if someone say No to this option he won't get any backlight control at all (neither SysFS nor PMU). To give a user space daemon full control over the backlight device, it has to disable function #2 of CONFIG_PMAC_BACKLIGHT. Otherwise it would rival with the kernel for any backlight setting. This all leads to one single valid configuration: CONFIG_PMAC_BACKLIGHT= YES CONFIG_PMAC_BACKLIGHT_LEGACY = YES But If we have no choice anyway, we don't need configuration options. Therefore here comes my suggestion: 1a. CONFIG_PMAC_BACKLIGHT Use this option for the generic backlight code only or compile it always in and get rid of this option. 1b. CONFIG_PMAC_BACKLIGHT_KERNELCTRL Use this option for the old Powerbooks or users that don't want to use a user space daemon. It should contain all the code that reads the brightness keys and set the backlight level in kernel space. Furthermore it should contain PMU_IOC_GRAB_BACKLIGHT to disable this behaviour during run time. 1c. CONFIG_PMAC_BACKLIGHT_LEGACY Should contain only interface parts that would be redundant with the new SysFS interface like PMU_IOC_GET_BACKLIGHT and PMU_IOC_SET_BACKLIGHT. This will allow modern systems to be compiled only with CONFIG_PMAC_BACKLIGHT and a user space daemon does the rest. I hope my point could be seen. I would really appreciate if the configuration could be cleaned up. Other solutions could be: 2. If the sysfs backlight driver is opened switch kernel backlight keys handling off by calling PMU_IOC_GRAB_BACKLIGHT for machines that support the sysfs backlight interface. 3. Remove the kernel backlight keys control code from the kernel. Which solution you prefer is up to you but I would be glad if at least solution #1 could be realised. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#313549: powerprefs: disable powermanagement at shutdown
Hi, since verion 0.7.1 pbbuttonsd checks for the current runlevel and won't suspend the machine if a shutdown procedure is in progress. I think this bug could be closed then. Benoît, would you confirm this? Best Regards Matthias
Bug#397581: Please allow for configuration of the step size in mixer and backlight settings
Hi, I just checked the brightness issue. The 10% step you observed irritates me a bit. How did you measure this? The brightness step in the display module is calculated dynamically to have always 15 steps independently of the underlying hardware. With the PMU driver on my Pismo the maximum brightness is 15. Pbbuttonsd calculated a step width of 1, which leads to 15 brightness steps. With the SysFS driver (max brightness = 127) pbbuttonsd calculated a step width of 8 which leads also to 15 brightness steps. Do we need any action on the sound issue? I think Franks explanation makes the function clear, don't you think? Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386682: imagemagick: montage causes assertion `images-signature == 0xabacadabUL' failed
Package: imagemagick Version: 7:6.2.4.5.dfsg1-0.9 Severity: normal Compiling own programs using montage functionality of ImageMagick caused an error message: MontageImages: Assertion `images-signature == 0xabacadabUL' failed. This error seems to be known upstream, becasue my programs work without changes with the latest version 6.2.9 of ImageMagick. Please update to a more recent version. Best Regards Matthias Grimm -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.11 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages imagemagick depends on: ii libbz2-1.0 1.0.3-3 high-quality block-sorting file co ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libfreetype6 2.2.1-2 FreeType 2 font engine, shared lib ii libice6 1:1.0.0-3 X11 Inter-Client Exchange library ii libjasper-1.701-11.701.0-2 The JasPer JPEG-2000 runtime libra ii libjpeg626b-13 The Independent JPEG Group's JPEG ii liblcms1 1.15-1 Color management library ii libmagick9 7:6.2.4.5.dfsg1-0.9 Image manipulation library ii libpng12-0 1.2.8rel-5.2PNG library - runtime ii libsm6 1:1.0.0-4 X11 Session Management library ii libtiff4 3.8.2-6 Tag Image File Format (TIFF) libra ii libx11-6 2:1.0.0-8 X11 client-side library ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar ii libxml2 2.6.26.dfsg-3 GNOME XML library ii zlib1g 1:1.2.3-13 compression library - runtime imagemagick recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386683: automake1.4: aclocal link to /etc/alternatives/aclocal missing
Package: automake1.4
Version: 1:1.4-p6-11
Severity: grave
Justification: renders package unusable
Hi,
The reportbug tool grabs automake1.4 but I think this is related to all
versions of automake. I have automake1.4 and automake1.9 installed on my
system.
Following link is missing:
/usr/bin/aclocal - /etc/alternatives/aclocal
The script update-alternatives update the links in /etc/alternatives but
doesn't check if the links to /etc/alternatives exist.
Best Regards
Matthias Grimm
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.11
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages automake1.4 depends on:
ii autoconf 2.60-1 automatic configure script builder
ii autotools-dev 20060702.1 Update infrastructure for config.{
automake1.4 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377447: appletouch trackpad is ignored (internal USB, 5 mo 14 iBook)
Hi Brendon, You filed a bug report to debian and I would like to ask you some further questions. Do you use the XOrg with the synaptics trackpad driver? This driver has a known problem. It opens the event device for the trackpad exclusively and block it for any other application. In this case pbbuttonsd can't open the event device for the trackpad and therefore won't get events from it. There is a patch for the synaptics driver out to solve this, but I don't have it at hand. Please file a bugreport to Xorg and the package xserver-xorg-input-synaptics too. Maybe they will fix the problem one day and use a cooperative way to read trackpad events. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368954: pbbuttonsd: shutdown on charge == 0
Hi, I'm not sure that I have understood your wish right. The emergency behaviour of pbbuttonsd is already configurable and if you like to put your machine to sleep at battery emergency level instead of shutting the machine down, you might do so. Furthermore with enabled IBAM pbbuttonsd is able to calculate the time left on battery very accurate after a certain time of learning, so that such gaps you described loose their freight. If there is still something left to improve pbbuttond please let me know. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372760: agreed on this bug (was: pbbuttonsd: polls battery_? to ofter --
On Fri, 16 Jun 2006 17:53:12 +0200 Filippo Giunchedi [EMAIL PROTECTED] wrote: performance killer) Reply-To: X-Operating-System: Debian GNU/Linux 2.6.16.20 X-Editor: VIM - Vi IMproved 7.0 Organization: NoName Inc. tags 372760 + confirmed thanks Hi, I can reproduce and agree with this bug, on my system the CS count goes from ~700/s down to ~200/s with pbbuttonsd up/down Matthias: is there a reason to poll battery status so often? can it be decreased to a more sensible value or make it configurable? You are right. There is no need for polling the battery files so often. I split up the timer function and increased the low priority tasks to a one second polling interval. The changed version is in CVS (pbbuttons.cvs.sourceforge.net). On my machine the effect is much lower than on yours. I used the same command 'dstat -cpyi --ipc 2 5' as Joerg to make the results comparable. Without pbbuttons: total-cpu-usage ---procs--- ---system-- interrupts--- --sysv-ipc- usr sys idl wai hiq siq|run blk new|_int_ _csw_|__47_ __48_ __57_|msg sem shm 8 1 90 1 0 0| 0 0 1| 130 654 | 260 5 | 1 1 18 5 0 87 7 0 0| 0 0 0| 75 301 | 060 2 | 1 1 18 3 0 97 0 0 0| 0 0 0| 74 283 | 061 0 | 1 1 18 4 0 97 0 0 0| 0 0 1| 73 283 | 060 0 | 1 1 18 3 0 97 0 0 0| 0 0 0| 74 266 | 061 0 | 1 1 18 4 0 92 4 0 0| 0 0 1| 88 274 | 060 0 | 1 1 18 With pbbuttons 0.7.5: total-cpu-usage ---procs--- ---system-- interrupts--- --sysv-ipc- usr sys idl wai hiq siq|run blk new|_int_ _csw_|__47_ __48_ __57_|msg sem shm 8 1 90 1 0 0| 0 0 1| 130 653 | 260 5 | 2 1 18 7 0 88 5 0 0| 1 0 0| 94 428 | 061 0 | 2 1 18 3 0 96 0 0 0| 0 0 1| 104 444 | 06011 | 2 1 18 4 0 97 0 0 0| 0 0 0| 105 435 | 06111 | 2 1 18 3 0 96 0 0 0| 1 0 0| 92 417 | 060 0 | 2 1 18 3 0 96 0 0 0| 0 0 1| 87 430 | 061 1 | 2 1 18 This is the same cs increase as with gkrellm for instance (on my machine). With the patched version (1 second interval, 10 times slower that 0.75): total-cpu-usage ---procs--- ---system-- interrupts--- --sysv-ipc- usr sys idl wai hiq siq|run blk new|_int_ _csw_|__47_ __48_ __57_|msg sem shm 8 1 90 1 0 0| 0 0 1| 130 653 | 260 5 | 2 1 18 8 1 92 0 0 0| 0 0 0| 74 398 | 060 1 | 2 1 18 4 0 95 0 0 0| 0 0 1| 80 423 | 060 1 | 2 1 18 4 0 96 0 0 0| 0 0 0| 74 402 | 061 1 | 2 1 18 5 0 96 0 0 0| 0 0 1| 73 406 | 060 0 | 2 1 18 4 0 96 0 0 0| 0 0 0| 94 417 | 06111 | 2 1 18 You see the difference is marginal on my machine. Another test with increased 10ms cycle to 100ms: total-cpu-usage ---procs--- ---system-- interrupts--- --sysv-ipc- usr sys idl wai hiq siq|run blk new|_int_ _csw_|__47_ __48_ __57_|msg sem shm 8 1 90 1 0 0| 0 0 1| 130 652 | 260 5 | 3 1 18 8 0 93 0 0 0| 0 0 0| 73 305 | 061 0 | 3 1 18 5 0 96 0 0 0| 0 0 1| 74 309 | 060 0 | 3 1 18 4 0 96 0 0 0| 0 0 0| 73 287 | 060 0 | 3 1 18 4 0 95 0 0 0| 0 0 1| 74 299 | 061 0 | 3 1 18 4 0 96 0 0 0| 0 0 0| 73 277 | 060 0 | 3 1 18 You see this is more effective, but has an impact on usability because pbbuttons will react uncomfortable late on key events then. If you like to try it yourself, change in pbbuttonsd.c the line timerid10 = g_timeout_add (10, cb_timer10, NULL); to timerid10 = g_timeout_add (100, cb_timer10, NULL); Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372760: Additional Info to pbbuttons performance problem
On Fri, 16 Jun 2006 17:53:12 +0200 Filippo Giunchedi [EMAIL PROTECTED] wrote: I looked a bit deeper into the code and found some more actions that will improve the performance: 1. Increase poll interval of IPC messages from 10ms to 100ms 2. allow the display module to use a 100ms interval to change display or keyboard brightness, if fading is disabled 3. terminate 10ms timer function, if it is not needed (That's the case now, if fading was disabled). This actions don't seem to have a at least noticeable impact on usability and functionality. I see no difference on my machine. I'm curious how the results are on your machine. I put the code into CVS, so you might be able to try it out. If you have trouble checking the code out let me know. I will send you a package then. At the end some more numbers for the different cases 1. witout pbbuttonsd running $ dstat -cpyi --ipc 2 5 total-cpu-usage ---procs--- ---system-- interrupts--- --sysv-ipc- usr sys idl wai hiq siq|run blk new|_int_ _csw_|__47_ __48_ __57_|msg sem shm 8 1 90 1 0 0| 0 0 1| 129 645 | 260 5 | 3 1 18 7 0 93 0 0 0| 0 0 0| 74 280 | 060 0 | 3 1 18 5 0 95 0 0 0| 0 0 2| 73 286 | 060 0 | 3 1 18 4 1 95 0 0 0| 0 0 0| 85 266 | 06111 | 3 1 18 4 0 96 0 0 0| 0 0 1| 91 262 | 06011 | 3 1 18 4 0 95 0 0 0| 0 0 1| 74 278 | 061 0 | 3 1 18 2. pbbuttonsd 0.7.5-1 is running $ dstat -cpyi --ipc 2 5 total-cpu-usage ---procs--- ---system-- interrupts--- --sysv-ipc- usr sys idl wai hiq siq|run blk new|_int_ _csw_|__47_ __48_ __57_|msg sem shm 8 1 90 1 0 0| 0 0 1| 129 645 | 260 5 | 4 1 18 9 0 91 0 0 0| 0 0 1| 104 451 | 06011 | 4 1 18 4 1 95 0 0 0| 0 0 0| 94 443 | 061 0 | 4 1 18 5 0 95 0 0 0| 0 0 2| 93 440 | 060 0 | 4 1 18 5 0 95 0 0 0| 0 0 0| 94 417 | 061 0 | 4 1 18 5 0 95 0 0 0| 0 0 0| 101 420 | 060 1 | 4 1 18 3. pbbuttonsd CVS is running $ dstat -cpyi --ipc 2 5 total-cpu-usage ---procs--- ---system-- interrupts--- --sysv-ipc- usr sys idl wai hiq siq|run blk new|_int_ _csw_|__47_ __48_ __57_|msg sem shm 8 1 90 1 0 0| 0 0 1| 129 645 | 260 5 | 4 1 18 8 1 88 4 0 0| 0 0 1| 73 421 | 060 0 | 4 1 18 5 0 96 0 0 0| 0 0 0| 73 410 | 061 0 | 4 1 18 5 0 60 35 0 0| 0 0 0| 151 417 | 060 0 | 4 1 18 4 0 96 0 0 0| 0 0 1| 108 411 | 060 0 | 4 1 18 5 0 96 0 0 0| 0 0 0| 75 407 | 061 1 | 4 1 18 4. pbbuttonsd CVS is running, fadingspeed = 0 (KBD and LCD) $ dstat -cpyi --ipc 2 5 total-cpu-usage ---procs--- ---system-- interrupts--- --sysv-ipc- usr sys idl wai hiq siq|run blk new|_int_ _csw_|__47_ __48_ __57_|msg sem shm 8 1 90 1 0 0| 0 0 1| 129 645 | 260 5 | 4 1 18 8 1 92 0 0 0| 0 0 0| 73 274 | 061 0 | 4 1 18 4 0 95 0 0 0| 0 0 0| 74 272 | 060 0 | 4 1 18 5 0 96 0 0 0| 0 0 1| 74 296 | 061 1 | 4 1 18 4 0 96 0 0 0| 0 0 0| 74 285 | 060 0 | 4 1 18 4 1 71 23 0 0| 0 0 2| 109 307 | 061 0 | 4 1 18 Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345314: pbbuttonsd: lcd brightness can't go under 1 with autoadjust enabled
On Sat, 13 May 2006 15:30:27 -0500 Filippo Giunchedi [EMAIL PROTECTED] wrote: I'm using a powerbook 15 (5,6) with LCD brightness autoadjust. If in pbbuttonsd.conf I set LCD_AutoAdjust = no, I can switch off lcd using LCD_IllumDownKey until brightness is 0. But if I set LCD_IllumDownKey = yes, i can't go below 1, even if I set LCD_AutoAdjMin_(Bat|AC) = 0. I'm not sure what you mean here, LCD_IllumDownKey expects an integer, not yes anyway I can confirm this, setting TAG_LCDAUTOADJMINBAT to 0 does not turn the screen off, but to 2 or 1. Though I'm not sure if this is a feature or a bug, Matthias? First, Filippo is right. LCD_IllumDownKey expects a keycode as integer. It isn't an Boolean option. The behaviour you described is not a bug, more a nuisance. After activating automatic brightness control the ambient light sensor controls the LCD brightness and the minimum brightness level was limited to 1 to prevent the controller to switch off the display under certain environmental conditions. That the user even can't switch off the display by hand wasn't obvious and bothered nobody so far because the automatic controller would switch it back on anyway. On the other hand there was no good reason to limit the users action and so I fixed this behaviour in 0.7.5. See also the Changelog entry: 2006-03-23 0.7.4-2 * SIMUABIENT code was broken - fixed * added sync() before calling any suspend mode. (debian bug #357595) * allow the user to dim the display until it's dark (brightness level zero) even if autoadjusting is active. The former minimum level was one. (debian bug #345314) I hope this makes thinks more clear. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357595: pbbuttonsd: long sync inhibits suspend
Hi Jörg, Just before Suspend-to-RAM sync() is already called. But I think you mean Suspend-to-disk, don't you? I added a call to sync() before calling any suspend mode so that the upcomming version 0.7.5 will fix your problem. Best Regards Matthias
Bug#349266: pbbuttonsd: blocked while reading i2c devices
Sorry, I meant this problem won't show up again with pbbuttonsd _0.7.4_ or later. You currently use 0.7.3-5g which is a beta for 0.7.4. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352802: pbbuttonsd: doesn't recognize powerbook 6,2
Hi Filippo, could you please send me the contents of /proc/pmu/info? Thanks Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350004: pbbuttonsd: CoverAction not taken into account when lid opens
Hi Eugen, When I close the lid, the laptop does nothing. However, when the lid opens, the laptop resumes from the sleep mode, which is IMO a bug. I'm sorry to say that but this is not a bug. Waking the machine up after the cover has been opened is a hardware function I can't influence by software. There might be an undocumented function of the PMU but I don't know it. All pbbuttonsd possibly could do is to sent the machine back to sleep, after detecting that you doesn't want the machine to wake up, but in your case I think this is not possible, sorry. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349266: pbbuttonsd: blocked while reading i2c devices
Hi Michel, According to lsof, the last file opened by pbbuttonsd is an i2c device: I don't know what i2c-5 corresponds to, but it's not the keyboard backlight pbbuttonsd is looking for (which is directly on PMU) The problem doesn't happen all the time. I found no indication what reaveals it. I have not observed it on version 0.7.3-5g which I used for the keyboard backlight. Pbbuttonsd versions before 0.7.3 always search on I2C for the ambient light sensor, nevertheless the machine has one or not. You have a very new PowerBook with the ambient light sensor connected to the PMU and it might be that one of you I2C devices don't like my probing and block the program. In version 0.7.3 I implemented support for the PMU bases ambient light sensor and also a small database which hardware is available in which PowerBook model based on the machine type. It should not show up again with version 0.7.3 and later. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324604: [Fwd: The bug persists]
On Tue, 06 Sep 2005 12:41:08 +0200 Eugen Dedu [EMAIL PROTECTED] wrote: [4] ids - 3 45e 47 300 Name: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM) Supported Events: 0 (Reset) 1 (Key) 2 (Relative) Here it is :-) Only an event device file was missed. Debian has no device handler installed by default and I think this was the cause of our trouble. Now after you have created the missing files it works but I recommend to install udev if you use kernel 2.6. If you still use kernel 2.4, let it as it is. Udev will only work on kernel 2.6. Now if I move the USB mouse or press the 2nd button, the screen gets lighter, so it works now. (The first USB mouse button is not taken into account.) After our short discussion I reviewed my code and found a solution to take the left mouse button into account again without breaking some of the other features. :-) The next version will contain the change. Thanks for your patience and assistance. I think the bug report is done, isn't it? I will forward this mail to the debian bug tracker to close it. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306482: pbbuttonsd: no suspend with lid closed
Hi, I implemented your wish you posted to the debian bugtracker in pbbuttonsd. Could you please get the current version from CVS and test it? If you have trouble accessing the CVS repository tell me and I send you a package per mail. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324604: [Fwd: The bug persists]
On Tue, 6 Sep 2005 15:39:22 +0200 Frank Lichtenheld [EMAIL PROTECTED] wrote: On Tue, Sep 06, 2005 at 02:12:28PM +0200, Matthias Grimm wrote: On Tue, 06 Sep 2005 12:41:08 +0200 Eugen Dedu [EMAIL PROTECTED] wrote: [4] ids - 3 45e 47 300 Name: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM) Supported Events: 0 (Reset) 1 (Key) 2 (Relative) Here it is :-) Only an event device file was missed. Debian has no device handler installed by default and I think this was the cause of our trouble. Just for the record, which file? But that certainly explain why I couldn't reproduce that since I run udev here. /dev/input/event4 was missing. A mknod /dev/input/event4 c 13 68 solved the problem. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324604: an external usb mouse is ignored as event and screen becomes dark
I made a sid upgrade on my G4 ibook, after a few months. So I switched also to gnome 2.10 and xorg. I didn't touch any configurations, pbbuttonsd too and now if I plug an external usb mouse, its events are not considered as events and soon luminosity of scree goes down... Pbbuttonsd scans only at startup for event devices. If you plug in your mouse later, pbbuttonsd won't recognize it automatically (with default configuration). You could tell pbbuttonsd to regularly look for new event devices by setting the configuration option autorescan = yes. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325309: pbbuttonsd: pbbuttons assumes there is a /dev/mixer
Hi, I tried to force, but the result was the same: # pbbuttonsd -c /etc/pbbuttonsd.conf ERROR: Can't open mixer device [/dev/mixer]. No such file or directory INFO: Soundsystem requested: OSS and at least activated: none. you could tell pbbuttonsd which sound system to use with the configuration option SoundSystem. Depending of this setting other configuration options will be used. For example if you set this option to OSS, OSS_Mixer will be read and ALSA_Mixer will be ignored. Changing the option ALSA_Mixer in this context won't have any effect. If you set SoundSystem = OSS pbbuttonsd assumes indeed there is a /dev/mixer device and will complain if it is not there. This is not a bug. There are four possible options to set as SoundSystem: None Use no sound system at all OSSUse OSS, (Dev/mixer must exist) ALSA Use ASLA, (libasound must exist) AUTO Find the sound system to use automatically Restarting pbbuttonsd: No /usr/bin/pbbuttonsd found running; none killed. ERROR: Can't open mixer device [/dev/mixer]. No such file or directory Well, that is odd; anyway, I could set the device to dev/null. Setting OSS_Mixer = /dev/null won't work, because it is not a mixer device and won't behave like a mixer device. Open the device will work but it won't report supported channels or the current volume and this will cause pbbuttonsd to detect an error. You better should set SoundSystem = AUTO. Even if the reading was correct, ppbbuttons should not fail to load, if there is no sound system present. This is a point which I could aggree. Currently pbbuttonsd complains about a missing sound device and quit. I think this is the wrong reaction, too. I changed the code so that the daemon would not exit if the configured sound system couldn't be initialized and the ERROR messages are turned into WARNINGs. Pbbuttonsd should start even if there are errors; I can't agree to this. If pbbuttonsd detects an error, this mostly will have a major impact on functionallity (except the sound system errors). In other words: The daemon can't fullfill it's task if the underlying functions won't work correctly. In this case it is better to do nothing than to do it half or wrong. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318032: pbbuttonsd: volume up/down no longer works
On Fri, 15 Jul 2005 16:36:05 +0200 Benoît Dejean [EMAIL PROTECTED] wrote: Two more things: 1. Please send me the output of amixer and 2. try to change volume with shift+volume up/down. This will change volume in greater steps. shift+up/down works fine. Simple mixer control 'Master',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 176 Front Left: Playback 100 [57%] [on] Front Right: Playback 100 [57%] [on] Ok, the problem has been identified. The Master Channel has 176 volume steps and each key trigger increases or decreases this value by 1. So you need many key trigger (or simply hold it pressed) to get a significant volume change. The shift modifier increases uses a step size of 10 instead of 1 so that you need less key trigger. This is not a good and permanent solution for this type of problem. I think due to the large variety of sound hardware I change the volume control in pbbuttonsd. Volume up/down should change the volume by 10% and fine tuning could be possible with the shift modifier pressed. What do you think? Best Regards Matthias
Bug#318032: pbbuttonsd: volume up/down no longer works
Hi, could you please provide some more information? - what does the logfile say? - are the channels correctly set? - could you change volume with alsamixer? - what happens after you pressed volume up/down? Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315697: 'trackpad notap' command not working anymore
Hi, you wrote the following report to debian bug tracker: /var/cache/apt/archives/pbbuttonsd_0.6.10-2_powerpc.deb (...) # trackpad notap # trackpad show READREG(3, 2) trackpad settings notap nodrag nolock [taps NOT ignored, unwanted mouse clicks everywhere, You set the trackpad mode with external programs. This won't work as long as NoTapTyping is set to 'yes' because pbbuttonsd will restore it's own mode nearly every time a key is released. The tool trackpad modified the trackpad mode but doesn't tell pbbuttonsd about that, so the mode is reset a milisecond or so later. In the default configuration the option NoTapTyping is set to 'yes' by mistake. This will change with the next release. Solution: Set the configuration option NoTapTyping to 'no'. After this you should be able to temporarely change the trackpad mode with the 'trackpad' tool again. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315377: pbbuttonsd: mute key doesn't unmute anymore
I confirm this problem. The alsamixer mute function is broken. The CVS on sourceforge.net contains a fixed version. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#313919: pbbuttonsd: [INTL:de] German PO file corrections
Hi, thanks for your patch. I applied your patch to the upstream source. It will be part of the next release. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312480: pbbuttonsd cannot eject if there's a device symlink
Hi, Thanks for your report. I think I had this problem myself aready but I didn't tracked it down. You gave the right hint. Please try the CVS version. It should solve your problem. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279271: 12 powerbook shutdown after some time when lid is closed
Hi, this is a hardware problem of this type of PowerBook. Pbbuttonsd can do nothing against this. Some kernel developers are working on this, I think. Sorry Matthias Grimm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#273528: pbbuttonsd: pwrctl-local is not called
Hi, pwrctl-local is a pmud script. It is not and will not be supported by pbbuttonsd. All functions of this script are handled by the pbbuttonsd script system. So this is not a bug of pbbuttonsd. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308075: Problem has been identified
Hi, the problem that causes high CPU loads has been identified. I prepared a fix that can be dowloaded from the pbbuttonsd download area of pbbuttons.sourceforge.net. Download the Beta version 0.6.9-3. This patch still has a slight problem with the trackpad and activated 'NoTapTyping' that will be removed with the next release. For now I need to know it the CPU problem is really gone. I am reliant on your tests because I still can't reproduce this behaviour on my machine. I would appreciate any feedback, positive or negative. Best Regrads Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302537: Don't create /etc/acpi on ppc machines
Package: laptop-mode-tools Version: 1.04-1.1 The package shouldn't create the /etc/acpi directory on ppc machines because those machines don't have ACPI and therefore this directory is completely useless. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302550: [PATCH] Native support for pbbuttonsd
Package: laptop-mode-tools Version: 1.04-1.1 The attached script adds support for pbbuttonsd. I have to be copied in /etc/power/scripts.d and a symbolic link to it has to be created in /etc/power/event.d. This installation should be done if a powerpc machine is detected during installation. The scripts for acpi and apm could and should be omitted in that case. If the script is also installed in /etc/apm/event.d it might be lauched twice due to the apmd-compat script from pbbuttonsd. Best Regards Matthias laptop-mode Description: Binary data
Bug#302571: laptop-mode-tools: [PATCH] Native support for pbbuttonsd
Package: laptop-mode-tools Version: 1.04-1.1 Severity: normal Tags: patch The attached script adds support for pbbuttonsd. I have to be copied in /etc/power/scripts.d and a symbolic link to it has to be created in /etc/power/event.d. This installation should be done if a powerpc machine is detected during installation. The scripts for acpi and apm could and should be omitted in that case. If the script is also installed in /etc/apm/event.d it might be lauched twice due to the apmd-compat script from pbbuttonsd. Best Regards Matthias -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Kernel: Linux 2.6.8-powerpc Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages laptop-mode-tools depends on: ii powermgmt-base1.21 Common utils and configs for power -- no debconf information laptop-mode Description: application/shellscript
Bug#278450: powerprefs: eject doesn't work anymore
Hi, you reported a bug to PowerPrefs: Your eject key would not work. I have some questions to get to the bottom of your problem: - Do you still have this problem? - Which version of pbbuttond do you use? - Have you switched to a new kernel version just before the problem ocoured first? - Which type of PowerBook do you use? A recent one with an internal USB keyboard? - Do you have GtkPbbuttons running? If so, appears a popup window when you trigger the eject key? What does it say, busy or ejecting? You don't have to answer all this questions if the problem is already solved. In this case your confirmation is enough. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290369: gtkpbbuttons: not transparent display
On Tue, 1 Feb 2005 17:55:06 +0100 hiroru [EMAIL PROTECTED] wrote: Hi, Sorry for the delay. I compared my libraries with yours and found no difference. Have you tried another theme? Some people reported that problem would only ocour with certain themes. I tried every gnome theme I have on my machine and can't reproduce the effect but I saw it at some pictures in Powerprefs. It seems that themes using smooth colour transitions fource the effect. Nevertheless it seems more to be an X/Gtk rather than a GtkPbbuttons problem. I can't do any more until I get some hints how to reproduce this effect, sorry. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290369: Fw: gtkpbbuttons: not transparent display
Begin forwarded message: Date: Tue, 1 Feb 2005 17:55:06 +0100 From: hiroru [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: gtkpbbuttons: not transparent display Hello, this is the output of ldd: ldd /usr/bin/gtkpbbuttons libgtk-x11-2.0.so.0 = /usr/lib/libgtk-x11-2.0.so.0 (0x0fcc9000) libgdk-x11-2.0.so.0 = /usr/lib/libgdk-x11-2.0.so.0 (0x0fc2b000) libatk-1.0.so.0 = /usr/lib/libatk-1.0.so.0 (0x0fbe5000) libgdk_pixbuf-2.0.so.0 = /usr/lib/libgdk_pixbuf-2.0.so.0 (0x0fbad000) libm.so.6 = /lib/libm.so.6 (0x0fb18000) libpangoxft-1.0.so.0 = /usr/lib/libpangoxft-1.0.so.0 (0x0faf) libpangox-1.0.so.0 = /usr/lib/libpangox-1.0.so.0 (0x0fac3000) libpango-1.0.so.0 = /usr/lib/libpango-1.0.so.0 (0x0fa62000) libgobject-2.0.so.0 = /usr/lib/libgobject-2.0.so.0 (0x0fa06000) libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0 (0x0f9e2000) libdl.so.2 = /lib/libdl.so.2 (0x0f9bf000) libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x0f91c000) libpthread.so.0 = /lib/libpthread.so.0 (0x0f8ab000) libaudiofile.so.0 = /usr/lib/libaudiofile.so.0 (0x0f865000) libc.so.6 = /lib/libc.so.6 (0x0f706000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x0f60d000) libXrandr.so.2 = /usr/X11R6/lib/libXrandr.so.2 (0x0f5e9000) libXi.so.6 = /usr/X11R6/lib/libXi.so.6 (0x0f5bf000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x0f58d000) libXft.so.2 = /usr/lib/libXft.so.2 (0x30027000) libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0x0f49) libz.so.1 = /usr/lib/libz.so.1 (0x3004a000) libfontconfig.so.1 = /usr/lib/libfontconfig.so.1 (0x0f3d) libXcursor.so.1 = /usr/lib/libXcursor.so.1 (0x3006d000) libXrender.so.1 = /usr/lib/libXrender.so.1 (0x30089000) libpangoft2-1.0.so.0 = /usr/lib/libpangoft2-1.0.so.0 (0x0f387000) /lib/ld.so.1 = /lib/ld.so.1 (0x3000) libexpat.so.1 = /usr/lib/libexpat.so.1 (0x0f41) if I compile the debian source, have the same error. -- Sergi Barroso Linux user #313577 PGP ID: D318F5E8 Outlook Users Disclaimer: All rights reserved for my email address. You are not allowed to add it to your Outlook Address Book in any way. .mimetmp Description: PGP signature
Bug#278450: powerprefs: eject doesn't work anymore
On Sat, 02 Apr 2005 00:01:36 +0200 Benoît Dejean [EMAIL PROTECTED] wrote: you reported a bug to PowerPrefs: Your eject key would not work. I have some questions to get to the bottom of your problem: - Do you still have this problem? NO. Not anymore. One day, i realized that my keycode have changed : old keycode = Fn + F12. So i just set the correct keycode and it works (but sometimes, i have to press the eject key many times to eject the cd) old keycode = 88 new working keycode = 161 xev keycode = 161 is that OK ? Pbbuttonsd uses the event devices to get key codes from the keyboard. This keycodes are not the same as that ones xev reports. Regarding your eject key they have the same value by chance. If you need keycodes for pbbuttonsd use the program showkey or the teach-in function of PowerPrefs. Best Regards Matthias
Bug#290369: gtkpbbuttons: not transparent displays
Hi Sergei, Could you please send me the output of 'ldd path/gtkpbbuttons' ? Have you tried to compile gtkpbbuttons by yourself? If not could you do that just for test? To be honest, I can't reproduce the behaviour you observed. I think it's a matter of libgtk or libgdk-pixbuf2 so I want to compare the library versions on your system with them on mine. Maybe this give us a hint where to look at. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
