Re: iBook and batteries
On 26 Aug 2006 06:34:00 GMT "Jack Malmostoso" <[EMAIL PROTECTED]> wrote: Hi, > My iBook is 32 months old and around the 24th month I noticed a sudden > loss in battery performance: I thought it was related to some changes in > power management under linux (never really had the nerves to use OSX as > long as the battery life...), but (using a small .app called > "coconutBattery") I have now found out that only 69% of my battery is > still alive after *only* 167 charge cycles. > Now that's some lousy performance if you ask me, although I guess only > complete charge-discharge cycles are counted. I'm sorry to disappoint you here but every cycle counts nevertheless how far it was charged/discharged. In that moment you switch from AC to battery, or otherwise round one cycle is lost. Nevertheless LiION batteries degrade over time even they are not used at all. Taking all this into account 69% of remaining battery power after 32 month of battery life is not bad at all. Normal Laptop batteries have a lifetime of about two years, depending on the manufacturer. My battery died (less than 1h or 20% left) after 4 years. I used the battery a lot but unfortunately I don't know the cycle count. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttons - issues with lidclose->display off options (backlight remains off)
On Wed, 20 Sep 2006 14:52:20 +0300 "Eddy Petrişor" <[EMAIL PROTECTED]> wrote: > I have configured pbuttonsd to just turn off the display when on AC > and the lid is closed. I found that, sometimes, when opening the lid > again, the backlight will not be turned back on (I can see the locking > screen of KDE); if I try o swith to a text console, the backlight is > turned back on for a split second, I can see the display properly, > then is back to off. Switching back and forth between the X console > and a text console does not fix the issue, but the > light-on-for-a-split-second thing is present. > [MODULE DISPLAY] > UseFBBlank= yes Try to set this to "no". Similar problems reported to me could be solved with this. I think recent kernel versions don't need this option any longer because the backlight is mostly controlled by the framebuffer driver and switching the backlight off will automatically lead to a switched off framebuffer display. Please tell me your result. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
pbbuttons with sysfs backlight support
Hi, I did it or better I *believe* I did it :-) The code of the upcoming release is in CVS. It has got a class backlight with several low level drivers (two at the moment: sysfs and pmu). The driver which suits best will be auto-detected. Because the SysFS interface supports much more brightness steps I had to redefine parts of the client API. Especially the brightness messages and the fading mechanism. You need to update following options in your configuration file: LCD_Brightness, LCD_Fadingspeed, KBD_Brightness and KBD_Fadingspeed. Please see the man page pbbuttonsd.conf.5 for details. The brightness message sent to clients uses percentage now and the fading speed will be given as device independent time value (see man page for details). This assures that the behaviour of pbbuttonsd is always the same, whatever backlight driver is used. Unfortunately this will confuse most of the clients including gtkpbbuttons. A patched version of gtkpbbuttons is in the repository too. Please try the CVS version and tell me any issues you find. Also positive feedback is welcome. If you are unfamiliar with CVS but nevertheless want to test the release candidate, please see on http://sourceforge.net/cvs/?group_id=47862 You will find a detailed information how to get the source. After the source is on your hard disk, run the autogen.sh script in the main directory. After that 'make' and 'make install' should do the job. Best Regards Matthias PS: If anybody has problems with CVS please tell me. I will send you a preliminary package for test. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
kernel 2.6.18: Confusion about Macintosh backlight configuration
Hi, 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: 1. CONFIG_PMAC_BACKLIGHT Use this option for the generic backlight code only or compile it always in and get rid of this option. 2. 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. 3. 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. If you have any questions, please ask. Any option names are only suggestions. Feel free to choose other names as you like. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttons with sysfs backlight support
On Mon, 2 Oct 2006 21:38:34 + (UTC)
Jörg Sommer <[EMAIL PROTECTED]> wrote:
Hi Jörg,
> file=./`echo ca | sed 's,.*/,,'`.gmo \
> && rm -f $file && /usr/bin/msgfmt -c -o $file ca.po
> ca.po:205: Anzahl der Formatspezifikationen in »msgid« und »msgstr[1]« stimmt
> nicht überein
> /usr/bin/msgfmt: es ist 1 fataler Fehler aufgetreten
> make[3]: *** [ca.gmo] Fehler 1
Which versions of gettext, autoconf and automake do you use?
Did you modify any file before starting the package building process?
The misspelled translation is marked as "fuzzy" and therefore should not
be part of the output. I use gettext 0.14.6-1 and I got the above error
only if I call msgfmt as follows:
$> /usr/bin/msgfmt -f -c -o ca.gmo ca.po
Even if the program stability won't be affected by this error, the
language file should be corrected in the mid term or catalan must be disabled.
> checking pkg-config is at least version 0.9.0... yes
> checking for PACKAGE... yes
> ./configure: line 6524: syntax error near unexpected token `1.0.0,'
> ./configure: line 6524: ` AM_PATH_ALSA(1.0.0, pbb_have_alsa=yes,
> pbb_have_alsa=no)'
I can't reproduce this error. Do you have libasound2-dev installed?
I used 1.0.11 and just updated to 1.0.12 and both versions show no error
during configure.
Best regards
Matthias
Most packages from testing:
||/ Name Version Beschreibung
+++---
ii libasound2 1.0.12-1 ALSA library
ii libasound2-dev 1.0.12-1 ALSA library development files
ii automake1.4 1.4-p6-11A tool for generating GNU
Standards-compliant Ma
ii automake1.9 1.9.6-5 A tool for generating GNU
Standards-compliant Ma
ii autotools-dev20060702.1 Update infrastructure for
config.{guess,sub} fil
ii autoconf 2.59a-3 automatic configure script builder
ii gettext 0.14.6-1 GNU Internationalization utilities
ii gettext-base 0.14.6-1 GNU Internationalization utilities for
the base
Re: pbbuttons with sysfs backlight support
On Tue, 3 Oct 2006 22:23:31 + (UTC) Jörg Sommer <[EMAIL PROTECTED]> wrote: Hi Jörg, > % gettext --version > gettext (GNU gettext-runtime) 0.15 Oops. This version is not yet in the testing archive. They still use 0.14.6 > % autoconf --version > autoconf (GNU Autoconf) 2.60a With this version I got warnings about unsupported path variables in Makefile.in of the gettext package. Maybe this is fixed with gettext 0.15. Until this all is part of testing I stick to 2.59a (stable) > % automake --version > automake (GNU automake) 1.9.6 I use the same. > > I can't reproduce this error. Do you have libasound2-dev installed? > > No. It's not a build dependency. But with it configure still fails, > because automake failed, because cvs could not checkout the file NEWS You are right. It should even compile without libasound. > cvs checkout: nothing known about pbbuttons/pbbuttonsd/NEWS This is really strange because NEWS *is* in the repository. Did you configure your CVS not to get files with zero length? > With an empty NEWS ./autgen.sh reaches the end, but now dpkg-buildpackage > fails. The error log you attached didn't tell me anything and I don't know what's wrong here. Did configure run without errors or warnings? The last release only added some source files so I don't know why the build process doesn't work anymore. I think it's an issue of autoconf 2.60a. Maybee you should try with 2.59a. Sorry for this insufficient answer but I prefer to spend my time to develop pbbuttonsd rather than the GNU autotools. They should simply work. ;-) Best Regards Matthias
Re: suspend to ram/disk
On Fri, 6 Oct 2006 22:11:46 +0200 Tim Dijkstra <[EMAIL PROTECTED]> wrote: > Do you need also need to do all these weird quirks to get your graphics > card to get out of sleep (vbetool, radeontool and the like)? > I saw some code flying around doing some ioctl()s on /dev/pmu. Is that > all you need to safely s2ram? I use a G3 PowerBook with a ATI R128 Mobility graphics chip and one ioctl() is all I need to suspend the machine (s2ram). Unfortunately the keyboard and trackpad configuration would be lost if you limit your activities to a single ioctl(). Additionally you need to save the keyboard and trackpad configuration and restore them after wakeup. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Scanning etc with Airport Driver
On Wed, 10 Jan 2007 11:52:34 +1100 Dean Hamstead <[EMAIL PROTECTED]> wrote: Hi, > whats the status with scanning in the airport/orinoco driver? has > anything been finalized and committed to the kernel? I use the debian kernel 2.6.18-3 here on a Pismo with Airport card and scanning worked out of the box (iwlist scanning). Also kismet worked with the orinoco driver. It instantly found my Airport station but also detected a steadily increasing number of phantom networks with invalid data (floating hardware address and no information about the used channel). I think this are non-WLAN devices using the 2.4GHz band and wrongly detected by airport/orinoco-driver/kismet. Has anyone seen a similar phenomenon? Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Wakeup on mouse movement
Hi, I just upgraded to the debian kernel 2.6.18-3 (I used a self-configured kernel before) and found an odd behaviour: When the machines was suspended to RAM it woke up again after I moved the mouse. In the past The machine woke only up after triggering a key on the keyboard but never on mouse movement. Is this a feature or a bug? How could I disable this "feature" in case it is one? I used the 2.6.18 kernel before with my own configuration and it never woke up on mouse movement. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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]
Re: 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]
Re: Missing CONFIG_PMAC_BACKLIGHT_LEGACY breaks backlight control
On Sat, 20 Jan 2007 15:21:20 +0100 "Bin Zhang" <[EMAIL PROTECTED]> wrote: > No problem on my ibook G4 using debian pbbuttons package. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389770 Thanks. I didn't remember this bug report. I think the backlight control itself is not the problem here. Since version 0.7.9 pbbuttonsd uses the sysfs interface too and depends no longer on the PMU ioctl interface (except IOC_GRAB_BACKLIGHT). But we have another side effect here. If you press the brightness up key, the kernel itself processes the key trigger and makes the display brighter. After that a key event is sent out and pbbuttonsd does the same again. You got a double brightness increase for the price of one. That sounds not very serious but if you use the display fading feature I would expect that the brightness change smoothly from one level to another after I hit the brightness up key. What happens here is that you could see the brightness jump up and then maybe the rest changes smoothly. The reason for that is that the kernel changes the brightness still hard in 15 steps (It doesn't know anything about fading) although the sysfs interface supports 127 steps (on my machine) and therefore the step size of the kernel must not be the same as of pbbuttonsd . The key problem here is if you can't safely disable old interfaces you have to keep them fully intact. Don't disable them partly. If debian doesn't add CONFIG_PMAC_BACKLIGHT_LEGACY people will recognise odd backlight behaviour on powerpc machines. I have no problem with that because I compile my own kernel and that's it. At least I hope Frank, pbbuttons' debian maintainer, would remove such bug reports instantly if someone blamed pbbuttons for that. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: No synaptics touchpad on pbook-12"
On Sun, 25 Feb 2007 13:27:20 +0100 Johannes Berg <[EMAIL PROTECTED]> wrote: > http://johannes.sipsolutions.net/files/cev.c as root and tell me what > output you get. (I didn't write cev.c but I can't find who did and I > can't find a version with google either) If it helps you any further, I did. cev is only a development tool and has no home in the web. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: function key usage switched
On Sat, 16 Jun 2007 19:37:14 +0200 "Bin Zhang" <[EMAIL PROTECTED]> wrote: > > > You are right. > > > In pbbuttonsd-0.7.9's src/module_pmac, > > > #define PATH_FNMODE "/sys/module/usbhid/parameters/pb_fnmode" > > > > > > It should be /sys/module/hid/parameters/pb_fnmode for 2.6.21. > > > > File a bug against pbbuttonsd then. > > > > Done. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429267 Hi, I'm sorry to enter this discussion so late but better late than never ;-) Your bug report comes pretty late because pbbuttonsd is able to handle the new path since 10. February 2007. Update to version 0.8.0 and it should work out of the box. Best Regrads Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PowerBook G4 screen in Debian not as bright as Mac OS X or OpenBSD
On Fri, 10 Aug 2007 21:07:55 + (UTC) Amit Uttamchandani <[EMAIL PROTECTED]> wrote: Hi, > However, I have a small issue with the brightness level. I had OpenBSD (4.1) > and > Mac OS X (10.4) installed at one point and the brightness level was much > higher > than what I have here in Debian. I installed pbbuttonsd and brightness keys > were > working but still can't get it as bright as OpenBSD or OS X. Searching the ppc > mailinglist suggest the use of ikeys to give 15 brightness levels? But > checking > aptitude it seems that this package is out of date and would conflict with the > installed pbbuttonsd. ikeys won't be a solution for your problem, because it controls the brightness level in the same way as pbbuttonsd. I think your system uses the new SysFS Brightness interface which has 128 or maybe 256 brightness steps on your system. You could check this with the program Powerprefs, go to the display page (light bulb) and check which "Driver" is currently active in pbbuttonsd to control the display brightness. The programming of the graphics card's backlight controller is done by the kernel. There might be various reasons for setting the max brightness level as it is. Maybe the OpenBSD guys love to take higher risks regarding their hardware? Who knows ;-) You might want to ask this question on the kernel mailing list as well. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PowerBook G4 screen in Debian not as bright as Mac OS X or OpenBSD
On Sun, 12 Aug 2007 00:32:04 + (UTC) Amit Uttamchandani <[EMAIL PROTECTED]> wrote: > I installed 'powerprefs' from aptitude and followed your instructions. A few > points from the display page. > > * Under LCD Tab: Current Brightness Level: 100% > * Under Options: Simply has framebuffer options The driver is printed right below the current brightness level. I use powerprefs 0.8.0 and pbbuttonsd 0.8.1. Debian is a little bit behind because unfortunately the package is currently marked as orphaned. > I tried looking at other places but I can't seem to find the place where it > displays Driver information. I installed it from the stable branch. Maybe the > version is outdated? Yes, but the version in stable works quite well on PowerPC. The changes in the new releases are mainly aimed at the new Intel based MacBooks. I think also the new versions won't fix your brightness problem because it does nothing else as Yves-Alexis wrote in his email. Nevertheless you might want to give it a try. > Also, I've read something about pommed package available in testing and > unstable. Do you have any experiences with that? Pommed is a small daemon created to support the Intel-based MacBooks. The latest version got also support for PowerBooks but the main focus is MacBook. It has only a subset of pbbuttonsd's features, but it does a good job. Nevertheless it won't fix your brightness problem because it uses the same methods to control the brightness as pbbuttonsd. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What is pbbuttonsd used for nowadays?
On Fri, 30 Jan 2009 22:21:48 -0500 Stefan Monnier wrote: Hi, I follow this discussion with some astonishment. As pbbuttond was born, none of the programs named here existed except pmud. It started as a small project to just make the brightness and volume function keys work and developed over time to what it is today: A program that supports any vendor-specific hardware on iBooks and PowerBooks and some on MacBooks and make it convienient to use them. Of course no program satisfies all people and many think they could do it better and start their own projects, so did I. So over time many programs were created that have a lot of overlapping functionality. Because most of the code for Linux is under the GPL, it is very easy to learn and use code from other projects. But this is nothing evil, its evolution. Discussions about "This program is better than that" are quite useless and reserved for Windows extremists. Many of the programs you mentioned in this discussion use pbbuttonsd code and whenever I discover this, I feel a warm feeling of satisfaction and know that pbbuttonsd moved GNU/Linux a step forward. What I learned in my time programming pbbuttonsd is, that you cannot claim the ultimate solution for yourself, that you cannot force people to use "your" program. People will always use programs they want to so embrace the variaty of solutions with welcome and appreciate it as a chance that makes GNU/Linux so unique. > I think it would be good if someone who understands these issues could > complete the pbbuttonsd webpage&documentation describing how it differs > and/or interacts with other programs providing overlapping functionality. To know what pbbuttons is able to do, look into the README. It is quite easy to compare this list with the features of other programs finding your prefered solution. Why should you rely on my word? I'm not objective ;-) > E.g. is pbbuttonsd's cpu throttling similar to what cpufreqd/powernowd > do or does it work differently? What about the comparison with the > kernel's "ondemand" scaling governor (tho this doesn't work on my G4, so > it's maybe not a relevant question)? What happens if two of them are > installed at the same time? To answer your question regarding CPU Throtteling: Pbbuttonsd does no CPU throtteling at all, neither cpufreqd, powernowd or laptop-mode tools do. Only the kernel is able to do this in an efficient way. So all this programs only provide an interface to control the kernel feature. In other words the algorithm behind all this programs is exactly the same (only depending on the CPU you use). > How does pbbuttonsd's hard-disk power save compare to the usual > laptop-mode thingy? Both programs use hdparm to do the work. If laptop-mode tools is installed, pbbuttonsd will use it, because it also tweaks the disk buffer and sync inverval of the harddisk, so that it could spin-down for more than ten seconds. > For someone like myself who uses Debian on a variety of platforms, it'd > help me figure out how best to adapt my generic Debian config. I use debian with Gnome too, nevertheless I still use pbbuttonsd because it is convienent, small, fast, does anything I need and tells me the precise time left on battery (thanks to IBAM for that) and not the crap read out from the batteries itself that Gnome will sell to you. Best Regards Matthias -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Disable selecting with trackpad?
On Thu, 18 Jun 2009 08:36:41 -0500 Ross Gohlke wrote: Hi, > Thanks for the reply! Looking at /etc/pbbuttonsd.conf (and man > pbbuttonsd.conf), I tried the following: > > TPMode= > TPMode= notap > #TPMode= The option is completly right but this will only work, if your powermac has an ADB trackpad. The newer ones have an USB trackpad. If you are not sure which one you have please check > cat /proc/cpuinfo Look for the line "machine" in the output. There you will find something like "PowerBook5.1" or similar. The numbers tells you which machine you have. Machines up to 5.5 and from 6.0 to 6.7 have an ADB trackpad and the option should work. All other don't and the option will be ignored. Because you wrote that the option changed nothing, I assume you have an USB trackpad. Unfortunately I have no idea how to configure this thing. Best Regards Matthias Grimm -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: help with airport card on g3 powerbook
On Sun, 4 Sep 2005 13:07:33 -0700 (PDT) gm c <[EMAIL PROTECTED]> wrote: > I am unable to get my airport card to connect to a wireless base > station. I am using /etc/network/interfaces. > iface eth1 inet dhcp > wireless-essid myessid > wireless-mode managed > wireless-key mykey > wireless-ap myap The key wireless-key is named wireless-key1 in my interfaces file. Furthermore the key wireless-ap is not used. I hope this will help Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: help with airport card on g3 powerbook
On Sun, 4 Sep 2005 13:07:33 -0700 (PDT) gm c <[EMAIL PROTECTED]> wrote: > I am unable to get my airport card to connect to a wireless base > station. I am using /etc/network/interfaces. > iface eth1 inet dhcp > wireless-essid myessid > wireless-mode managed > wireless-key mykey > wireless-ap myap > > when I iwconfig eth1 the ap is all 4's or all 0's. If I iwconfig > essid, mode, key, and ap the ap is not get recognized. > what am I missing??? Lets collect the facts: - You use the built-in Airport card from Apple. - The module airport is loaded. - iwconfig deliver approriate results. You said you tried to connect to a wireless access point. Is this base station the apple base station or an alien product? If you don't use the Apple base station you have to disable encrypted communication in the acces point, because the original Apple Airport card only supports 40Bit WEP which is not longer supported by recent access points. They use 128bit WEP or WPA. The Apple Airport card can't connect to base stations configured for 128Bit WEP or WPA. > wireless-key mykey In my configuration the key is set with wireless-key1, but you only need this key if your base station is able to talk WEP40. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: help with airport card on g3 powerbook
On Wed, 7 Sep 2005 16:08:06 + Chris Martin <[EMAIL PROTECTED]> wrote: > On 9/7/05, Matthias Grimm <[EMAIL PROTECTED]> wrote: > > > If you don't use the Apple base station you have to disable encrypted > > communication in the acces point, because the original Apple Airport > > card only supports 40Bit WEP which is not longer supported by recent > > access points. They use 128bit WEP or WPA. The Apple Airport card can't > > connect to base stations configured for 128Bit WEP or WPA. > > > > Are you sure of this? My router is set to 128Bit Hex. It's also an > option in OS X. If we talk about the airport card from year 2000 mounted in an Powerbook G3, I'm pretty sure about this. Maybe Apple changed this with later Powerbooks. Somewhere I read about 104-Bit key encryption in conjunction with Apple airport cards (but I can't remember where) but my key looks like this: wireless-key1 aabb-ccdd-ee (This is not my real key ;-)) That are 5 bytes = 40 Bit. How many bytes has your key? For the Apple access point there was a possibility to update because they use a PCMCIA card from Lucent (Silver Card, if I remember correctly) and it could be replaced with a Gold card, which is able to handle WEP128. But I never heard about such a update for the built-in airport card. > > In my configuration the key is set with wireless-key1, but you only > > need this key if your base station is able to talk WEP40. > > Again, are you sure? I was under the impression you use this if your > access point uses multiple keys, regardless of which WEP. 128 can use > multiple keys as well. I always failed to connect to recent wireless routers, but I never looked for the reason for long. Maybe there is a configuration that works. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: help with airport card on g3 powerbook
On Thu, 8 Sep 2005 15:27:07 -0400 "Daniel R. Killoran,Ph.D." <[EMAIL PROTECTED]> wrote: > > On Sep 7, 2005, at 5:47 AM, Matthias Grimm wrote: > > > If you don't use the Apple base station you have to disable encrypted > > communication in the acces point, because the original Apple Airport > > card only supports 40Bit WEP which is not longer supported by recent > > access points. They use 128bit WEP or WPA. The Apple Airport card > > can't > > connect to base stations configured for 128Bit WEP or WPA. > > > > The Airport CARD supports 128-bit encryption. I don't know whether > the BASE STATION does, though! It seems that threre are different cards aout there. See mail from Chris Martin in this thread. Is there a method to read the encryption capabilities from the card? What makes you sure that your card supports WEP128? Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Research on cpufreq for power management - please help
Hi, I need some information from machines with scalable CPU frequency. Could you please send me the contents of /sys/devices/cpu/cpu0/* ? The following line may help you with this for i in /sys/devices/cpu/cpu0/*/*; do echo $i; cat $i; done I do some research on this issue to integrate CPU scaling policy into a future power management concept. Your help will be appreciated. Best Regrads Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: help with airport card on g3 powerbook
On Wed, 7 Sep 2005 20:47:02 + Chris Martin <[EMAIL PROTECTED]> wrote: > > If we talk about the airport card from year 2000 mounted in an > > Powerbook G3, I'm pretty sure about this. Maybe Apple changed this with > > later Powerbooks. > > > > Looks like we're both right. I asked one of our techs here (who used > to work at Apple), he said originally they didn't. But they released > an update to support it. > > I knew I wasn't crazy. I'm using 128 on both Linux, and OS X (dual boot). I found out that my airport card also support two key lengths: 40Bit, 104Bit (told by iwlist eth0 key). It seems that only my base station is limited to 40 Bit (Licent Silver). The only question left is: Is 104Bit key = WEP128? Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: help with airport card on g3 powerbook
On Sat, 10 Sep 2005 11:52:15 -0700 (PDT) gm c <[EMAIL PROTECTED]> wrote: > The "iwlist eth1 scan" should report ap's but gives error message > that it is not permmited. Is it broken in PPC wireless-tools??? It > works in x86 wireless-tools. > anybody know how to make this work? > mike I have just installed the orinoco replacement driver from http://savannah.nongnu.org/cvs/?group=orinoco and iwlist eth0 scan works :-) I use kernel 2.6.12.2 Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Research on cpufreq for power management - please help
On Sat, 10 Sep 2005 19:36:34 +0200 Matthias Grimm <[EMAIL PROTECTED]> wrote: Hi, Whow, a lot of helpfull people here :-) Thanks to everybody. I think for now I have enough data. Thanks again for your pretty fast help. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Powerbook 12" USB power
On Mon, 12 Sep 2005 11:04:25 +0200 "Federico 'Pain' Pistono" <[EMAIL PROTECTED]> wrote: > For some reasons my 12" Powerbook does not provide enough energy to > the USB device. > > I have an external hard-drive, 80 GB USB 2.0, that has two connecting > cables. It usually works fine with just the connection cable on a > desktop with a USB 2, but if you have only a USB 1 or you have a > particular situation you can use the other cable as well, its purpose > is solely to provide energy when needed. > > When I first used the powerbook on OSX it worked fine with just a > cable, and the same with Linux. Now it's gradually getting worse, and > I can't even transfer decently any file. I am sure thr USB 2 works and > it's configured, since if I plug the energy cable into another > computer and the connecting cable in my 12" it works fine, meaning > that I just nedd to provide more energy from my USB ports. Be carefull with that. USB is specified for 5V/500mA = 2.5W per Port/Hub. Most hard disks, even the 2.5" Laptop ones, use more power so you may damage your laptop if you use an external hard drive without external power supply. Read the datasheet of your hard drive carefully. Some time ago I replaced my internal hard drive with a bigger 40GB one. This hard disk has a nominal power consumption of 2.5W (USB limits) but needs 5W during power up sequence. I put the old one in an external USB housing. This hard disk has 2.5W nominal power consumtion and also 2.5W during power up sequence, but nevertheless I don't have the courage to use it without external power supply at my PowerBook. I don't know what the manufacturer use to limit the current at USB ports, but a famous german computer magazin wrote that they mostly don't use melting fuses. I could imagine that they use polyswitches. This are reversable fuses. The current through the polymer heats the material and at a certain temperature it changes its crystal structure and therefore its resistance rapidly. After some time the polymer recovers and returns to low resistance state. The problem with polyswitches is that they don't recover completely to their former performance. Furthermore heat and current pulses increase the resistance and they grew old fast. This would match the behaviour you observed. The current out of your USB port decreases and would not be able to power the hard drive any longer. > I was told that I had to configure this through the open firmware, but > I have no idea of how to do it. I don't think this problem could be solved by tweaking open firmware. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Powerbook 12" USB power
On Mon, 12 Sep 2005 22:00:21 +0200 Sven Luther <[EMAIL PROTECTED]> wrote: > Hehe, i got a nice usb+firewire 2.5" housing which had 2 usb connectors, one > for dat transfer, and the second plugged into the power adapter of the > housing, so you get the 5W you need for that :) I never heard about this trick, but it could work. Anyway my usb+firewire housing has only one usb port. > I am using it as firewire disk anyway though, so ... me too, but this won't help Federico. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Powerbook 12" USB power
On Tue, 13 Sep 2005 23:33:36 +1000 Cedric Pradalier <[EMAIL PROTECTED]> wrote: > Hmm you're worried me. My ipod-mini is recommended for > usb-2, but I guess that's for data transfer. I usually > charge it with the usb-1 port of my ibook. > > Do you have any idea how much power it takes? Am I putting > my usb port at risk? Don't know. Only Apple could tell you that. The specs regarding power supply of USB-1 and USB-2 are the same. Is charging through an USB-port a standard feature of the iPod mini? If so I would say it is ok. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Powerbook G4 configure some stuff
On Fri, 28 Oct 2005 21:55:37 +0200 "Johannes H. Jensen" <[EMAIL PROTECTED]> wrote: > You might also want to have a look at my Ubuntu on the PowerBook G4 page > at http://joh.deworks.net/powerbook/ as Ubuntu is mostly based on > debian :) Hi, I've read your page with interrest, although I don't have a PowerBook G4. :-) You mentioned that the 'eject key' controlled by pbbuttonsd won't unmount a mounted CDROM. Is this still so with pbbuttonsd 0.7.2? If so I should really think of removing the unmount/eject stuff from pbbuttonsd and call 'eject' instead. :-/ Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd vs. mouseemu
On Sun, 30 Oct 2005 20:49:38 +0100 Gaudenz Steinlin <[EMAIL PROTECTED]> wrote: > On Fri, Oct 28, 2005 at 10:34:39PM +0200, Guido Guenther wrote: > > Hi, > > during bootup mouseemu starts before pbbuttonsd. After that pbbuttonsd > > doesn't care about _any_ keyboard events. Brightness/Volume control, > > etc. doesn't work. > > Restarting pbbuttonsd "fixes" this. Restarting mouseemu breaks it again. > > Anybody else seen this? This is fairly old (USB 1.1) 12" PB. > > This is probably Bug #304734. Sorry, but as my PowerBook got stolen, I'm > currently unable to work on this. I just ordered a new one and will > hopefully find some time to work on mouseemu when it arrives. In the > meantime feel free to fix and NMU. The problem is to find a solution, > that does not break mouseemu (as does not reintroduce to passthrough of > the mouse button hotkeys). I think the main problem here is that mouseemu EVIOCGRAB all keyboard event devices and therefore block them for other programs like pbbuttonsd. Is it necessary that mouseemu block event devices? What I don't understand is why it sometimes works? I use kernel 2.4.12 and something like EVIOCGRAB is already implemented and I have mouseemu and pbbuttonsd running without problems. Mouseemu was started first. According my theory from above mouseemu should block all keyboard devices and pbbuttonsd won't work anymore. But this doesn't happen. This leads to the conclusion that EVIOCGRAB is not fully functional in 2.6.12. Can anyone confirm this? Best regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mouse movements not identified as activity (sleep in 2.6.12)
On Sun, 30 Oct 2005 16:44:36 +0200
Eddy Petrişor <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have a little problem with the sleep functionality in 2.6.12. While
> i am browsing sometimes I see a warning from gtkpbbuttons-gtk that the
> laptop (PowerBook 5,2) will go to sleep (and the counting starts. This
> happens and does not stop when I click the USB mouse attached to the
> laptop, while is stops if I tap the touchpad or press a few keys.
>
> Why is this happening? Does anybody else has this problem? (Notice
> that I almost never shutdown my laptop, but meerly lock it and put it
> to sleep, so it can reach an "uptime" of more than 4-5 days, but I met
> this behaviour even after a day up)
Do you use udev? If not there might be an event device missing for your
usb mouse in /dev/input/. With the attached program you could check, if
there is a proper device. (Compile with gcc -Wall -o cev cev.c, run as
root because access to the event devices is needed.)
If no event device is available you have multiple choices:
1. install and run udev
2. create missing devices by hand with mknod
Pbbuttonsd will automatically recognize newly attached devices only if
it was configured with autorescan = yes. See the man page for all
details.
Best Regards
Matthias
#include
#include
#include
#include
#include
#include
#define BITS_PER_LONG (sizeof(long) * 8)
#define NBITS(x) x)-1)/BITS_PER_LONG)+1)
#define OFF(x) ((x)%BITS_PER_LONG)
#define LONG(x) ((x)/BITS_PER_LONG)
#define test_bit(bit, array) ((array[LONG(bit)] >> OFF(bit)) & 1)
char *events[EV_MAX + 1] = {"Reset", "Key", "Relative", "Absolute",
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
NULL, NULL, "LED", "Sound", NULL, "Repeat", "ForceFeedback", NULL,
"ForceFeedbackStatus"};
int main(int argc, const char **argv)
{
int eventfd = -1;
/*struct input_event inp;*/
short ids[4];
char filename[20];
char name[256];
unsigned long bit[EV_MAX][NBITS(KEY_MAX)];
/* int rep=0; */
int i, j;
for (i = 0; i < 32; i++) {
sprintf(filename, "/dev/input/event%d", i);
if (i == 32)
eventfd = open("/dev/input/mice", O_RDONLY);
else
eventfd = open(filename, O_RDONLY);
if (eventfd >= 0) {
ioctl(eventfd, EVIOCGID, ids);
printf("[%d] ids - %x %x %x %x", i, ids[0], ids[1], ids[2], ids[3]);
ioctl(eventfd, EVIOCGNAME(sizeof(name)), name);
printf(" Name: %s\n", name);
ioctl(eventfd, EVIOCGBIT(0, EV_MAX), bit[0]);
printf(" Supported Events:\n ");
for(j=0; j < EV_MAX; j++)
if (test_bit(j, bit[0]))
printf("%d (%s) ", j, events[j] ? events[j] : "?");
printf("\n");
close(eventfd);
eventfd = -1;
} else {
fprintf(stderr, "[%d] nil\n", i);
}
}
/*
eventfd = open("/dev/input/event0", O_RDONLY);
while (read(eventfd, &inp, sizeof(inp))) {
if (rep != ((inp.value << 8) + inp.code)) {
rep = (inp.value << 8) + inp.code;
printf("\tEvent: type=0x%02x (%d) code=0x%02x (%d) value=0x%02x (%d)\n",
inp.type, inp.type, inp.code, inp.code, inp.value, inp.value);
}
}
close(eventfd);
*/
return 0;
}
Re: pbbuttonsd vs. mouseemu
On Mon, 31 Oct 2005 18:51:50 +0100 (CET) Michael Schmitz <[EMAIL PROTECTED]> wrote: > > > This is probably Bug #304734. Sorry, but as my PowerBook got stolen, I'm > > > currently unable to work on this. I just ordered a new one and will > > > hopefully find some time to work on mouseemu when it arrives. In the > > > meantime feel free to fix and NMU. The problem is to find a solution, > > > that does not break mouseemu (as does not reintroduce to passthrough of > > > the mouse button hotkeys). > > > > I think the main problem here is that mouseemu EVIOCGRAB all keyboard > > event devices and therefore block them for other programs like pbbuttonsd. > > Is it necessary that mouseemu block event devices? > > mouseemu grabs keyboard events, but passes them on to a virtual keyboard > device that other applications can use. You need enough input event > devices for this to work. Ok, I understand now. I'm running udev so I never got the problem with too less event devices. I agree that wouldn't have any problem if enough event devices were available. Because udev need some time to create newly created event devices, there might be a race condition if mouseemu and pbbuttonsd were lauched directly after another. The virtual keyboard device might not have been appeared in /dev/input/ when pbbuttonsd scans for it. This race won't occour if udev was not used or pbbuttonsd was set up to scan reguarly for new devices. I don't know how often this race will happen, just a thought. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mouse movements not identified as activity (sleep in 2.6.12)
On Mon, 31 Oct 2005 20:51:02 +0200 Eddy Petrişor <[EMAIL PROTECTED]> wrote: > > Pbbuttonsd will automatically recognize newly attached devices only if > > it was configured with autorescan = yes. See the man page for all > > details. > > Apparently the stock debian pbbuttonsd package does not have that > option explicitly set to yes. What is the default value? The default setting for 'autorescan' is 'no'. Change the option in /etc/pbbuttonsd.conf to 'yes' and your problem should be solved. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Powerbook5,6: keyboard's backlight
On Mon, 07 Nov 2005 15:36:21 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > Can anybody help me? I enclose my /etc/pbbuttonsd.conf > > Last time I looked, the way pbbuttons detects the lmu controller on i2c > is a disgusting hack which might not work on those new models. I you know a better way, please tell me. I would be pleased to update this code in pbbuttonsd. A patch would be perfect but I would also be confident with a piece of code which I can learn from. ;-) Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: powerbook fn-key & pbbuttonsd
On Wed, 09 Nov 2005 10:48:33 +0100 Yves-Alexis Perez <[EMAIL PROTECTED]> wrote: > I've just noticed that pbbuttonsd reacted wether I pressed > Ctrl+F1/F2/... or FN+F1/F2/ It's a bit annoying, because I'd like to > bind Ctrl+Fx on others commands. In xev, Ctrl is known as Ctrl_L > (keycode 37) and Fn as Super_L (keycode 109). How does your configuration for LCD_IllumUpKey and LCD_IllumUpKey look like? What keycode does 'showkey -s' or better the event device report for Fn on your system (sorry I didn't read the Fn thread on this list very carefully)? Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: powerbook fn-key & pbbuttonsd
On Fri, 11 Nov 2005 19:23:27 +0100 Yves-Alexis Perez <[EMAIL PROTECTED]> wrote: > As as side note, I've seend that pbbuttons still forward events to the > window manager (well, only Fx it seem). So it outputs garbage in my > terminal. Should I fill a bugreport agains pbbuttonsd ? No. :-) Pbbuttonsd forwards nothing to nobody. If your terminal receives garbage look for virtual event devices that are able to do so. The only key that pbbuttonsd reads from hardware is the power key on some recent powerbooks and this is used only internally. Forwarding it to the input layer is only on my todo list yet ;-) So please don't blame be before I have started to work :-) Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
pbbuttonsd and NoTapTyping option?
Hi, does anybody use the NoTapTyping function of pbbuttonsd with success? How much would you pay to keep it? ;-) If this is not the case and due to the problems this function could cause, I would remove the function from pbbuttond again with the next release. Any comments? Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd and NoTapTyping option?
On Sun, 20 Nov 2005 12:30:31 +0100 (CET) Michael Schmitz <[EMAIL PROTECTED]> wrote: > > does anybody use the NoTapTyping function of pbbuttonsd with success? > > How much would you pay to keep it? ;-) > > I don't use that function - at least not in pbbuttonsd. moussemu takes > care of that for me. That's what I thought. So there is no real need for that function in pbbuttonsd anymore (maybe never was), because mouseemu is much better in doing it. Thanks for your comment. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Looking for ALSA specialist willing to support pbbuttonsd
Hi, I am looking for an ALSA programmer who is willing to help me with the ALSA module of pbbuttonsd. It needs some feature enhencements. What should be done: If the headphones are _not_ plugged in the volume keys should control the PC speakers. The Mute key will mute/unmute the speakers (This already works). If the headphones are plugged in, the speakers will be muted and the sound will be redirected to the headphones (This is already done by ALSA). With plugged in headphones the volume keys should control the volume level of the headphones and the PC speakers should remain muted. The Mute key should now mute/unmute the headphones (This need some work) If the headphones will be removed again, the volume control should switch back to the speakers. (This needs some work too) I'm neither an ALSA specialist nor I have enough spare time to do this in a short term. But on the other hand I would like to have this fixed in the next release if possible. So I ask here: Would you help me and fix this in pbbuttonsd? I appreciate any help. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Public Beta Version - PBButtonsd 0.7.3beta1 released
Hi, I released a Beta of the upcomming pbbuttons 0.7.3 and request your assistance to test it and tell me about anything weird you will find. The Beta could be downloaded from: http://pbbuttons.berlios.de/ IMPORTANT: Compile PBButtons with '--with-ibam' to enable IBaM and read the IBaM chapters in the man-page carefully. It needs some preparations to unfold it's full power. Create a directory /var/lib/ibam in which IBaM can store its data. This directory is not created by the installation script yet. The upcomming relase will get a new time estimation algorithm. This new algoritm leads to amazing accurate runtime predictions on battery. Also battery warnings will be very accurate and reliable. If it says you have 10 minutes left, you _will_ have 10 minutes left. Battery aging will be continously tracked so that the time predictions will be accurate over time nevertheless how old the battery is. Adjusting battery warnlevels in a configuration file is yesterday, IBaM is now. Intelligent Battery Monitoring uses statistical and linear adaptive methods to estimates the time remaining on battery and also the time until batteries are fully recharged. Nevertheless it works already very well, IBaM is still beta software. Please test this version and give me any feedback you think is usefull. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd: call pbbcmd in power scripts
On Sun, 15 Jan 2006 13:56:00 + (UTC) Joerg Sommer <[EMAIL PROTECTED]> wrote: > I want to increase or decrease the backlight level upon plug in and > unplug the power supply unit. I achieve this with a script in > /etc/power/event.d/. But it seams the script hangs in the call of pbbcmd. > Is this possible? If I enable the call I get a message "INFO: Script > '/etc/power/pmcs-pbbuttonsd resume ac ram' lauched but killed after 6 > seconds". I tracked it down to the call of pbbcmd. So what might happen > there? It's a classic deadlock situation. Pbbuttonsd started the script which started pbbcmd. pbbcmd sent a message to pbbuttonsd and waited for the result, which won't come because pbbuttonsd waits for the script to terminate. But there is a solution :-) Call pbbcmd with option '-i' and it will immedately return without waiting for a receipt or an error code. The script will terminate in time and pbbuttonsd process the formerly sent message. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd: call pbbcmd in power scripts
On Mon, 16 Jan 2006 18:50:43 +0100 Kiko Piris <[EMAIL PROTECTED]> wrote: > On 16/01/2006 at 15:51 +, Joerg Sommer wrote: > > > This does not help: > > > > + ltrace -t -e msgget,msgsnd,msgrcv,msgctl pbbcmd -i query TAG_LCDBRIGHTNESS > > According to pbbcmd man page, -i applies only to config commands. > > If you need to query LCD brightness, you can use /sbin/fblevel (that's > what my own script uses). > > If you need to query any other tag, then I can't help you. Joerg, I'm sorry but Kiko is completely right. You can only send commands to pbbuttonsd inside the scripts yet but you can't query any values. Sorry. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Powerbook5,8: function keys not working
On Fri, 20 Jan 2006 00:35:44 +0100 Michael Hanselmann <[EMAIL PROTECTED]> wrote: > See linux/include/linux/input.h for the constants. In the Fn+ cases, the > latter two events might be swapped, depending on in which order you > release the keys. pb_fnmode=1 is the default, known as fkeysfirst in > pbbuttonsd or also as the Mac OS X default mode. Where do you set pb_mode=1? Is it a module parameter? Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Powerbook5,8: FN key mode
On Fri, 20 Jan 2006 23:29:09 +0100 Michael Hanselmann <[EMAIL PROTECTED]> wrote: Hi Michael, > On Fri, Jan 20, 2006 at 07:30:12PM +0100, Matthias Grimm wrote: > > Where do you set pb_mode=1? Is it a module parameter? > > Yes. You can change it during runtime trough > /sys/modules/usbhid/parameters/pb_fnmode (that's what pbbuttonsd might > have to do). I added this function to pbbuttonsd beta. You should be able to set the fnmode as usual with the config option KBDMode = fkeysfirst / fkeyslast. Because the option pb_fnmode could be set to "disabled", I added this mode as well: "KBDMode = disabled". On machines with ADB keyboard the option "disabled" is not possible and will be forced to "fkeyslast". The beta version is available at: ftp://ftp.berlios.de/pub/pbbuttons/pbbuttonsd-0.7.3-6g.tar.gz It would be nice if you could test this feature and tell me the results. Best Regards Matthias PS: The offer to test is not limited to Michael ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
On Sun, 22 Jan 2006 14:34:54 +0100 (CET) Michael Schmitz <[EMAIL PROTECTED]> wrote: > > Well, no luck, it's not that easy. Neither the fact that mouseemu is > > running in parallel, nor the order in which thez are started seems to > > matter. There are a couple of applications fiddle around with /dev/input/event so I try to bring some light into it. Udev is responsible for creating an /dev/input/event% device for each HID. Udev is the most comfortable way to have up-to-date devices in /dev. If you don't have udev running, be sure that each HID is represented by an event devive in /dev/input/. Pbbuttonsd opens all /dev/input/event% devices and uses them for input (at least to reset the user idle timer). If autorescan = yes (which should be set by default now), devices will be automatically added or removed as soon as they appear or vanish. So called 'fake' devices, created for example by the uinput kernel driver, will be used as usual. Pbbuttonsd makes no difference between a real event device or one from uinput. With the new beta version there is no limit anymore for used event devices. In worst case all 32 devices will be read. Mouseemu exclusively locks all input devices related to mice for full control. After that it routes the mouse events through a newly created input device (or two of them). This way it can filter out unwanted mouse events or create new ones. Pbbuttonsd can't access the locked event devices anymore but it uses the newly created uinput devices instead. You won't see any difference in behaviour. Synaptics Trackpad driver, often used on recent PowerBooks, also locks all mouse input events for exclusive use but in contrast to mouseemu it doesn't create an uinput device to let other applications receive mouse events. This problem is well known and Luca Bigliardi prepared a patch to work around this problem. Furthermore some people including Luca are working on a final solution of this problem. If you used the unmodified synaptics driver you would deprive pbbuttonsd and mouseemu of mouse events. I hope this will help to identify where the problems come from or at least give some hinte where to look at next. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
On Mon, 23 Jan 2006 00:00:19 +0100 (CET) Mich Lanners <[EMAIL PROTECTED]> wrote: > > devices will be automatically added or > > removed as soon as they appear or vanish. > > That doesn't seem to work. Input devices with mouseemu stopped: > [...] > pbbuttonsd opens event0 and event2 only. X has event3 and mice open. Where have you this information from? /proc ? There might be an error in pbbuttonsd but I just checked interoperability with mouseemu and this is the result (Pbbuttonsd beta with debug output): # src/pbbuttonsd INFO: DBG: InputSource added: 00010001 <- input devices scan at startup INFO: DBG: InputSource added: 000122c4 <- the numbers are vendor/product INFO: DBG: InputSource added: 0001771f INFO: DBG: InputSource added: 00013301 INFO: DBG: InputSource added: 001f0001 INFO: DBG: Machine: 31<- machine code of my ancient PowerBook INFO: DBG: Keyboard: ADB INFO: DBG: Trackpad: ADB INFO: DBG: Ambient: None INFO: DBG: InputSource added: <- internal input source INFO: Soundsystem angefordert: auto, erkannt: ALSA und letztlich aktiviert: ALSA. INFO: Speichern der Konfig auf /usr/local/etc/pbbuttonsd.conf freigegeben. pbbuttonsd 0.7.3-6g: iBook/G3 PB Pismo/G4 PB Titanium (PMU version: 12) INFO: Script '/usr/local/etc/power/pmcs-pbbuttonsd performance ac ' gestartet und normal beendet INFO: DBG: InputSource added: 7fe9d570 <- another internal input source Mouse: Rel-X 0, Rel-Y -1 <- some mouse movement Mouse: Rel-X -1, Rel-Y 0 Mouse: Rel-X 0, Rel-Y -1 Mouse: Rel-X 0, Rel-Y -1 [...] INFO: DBG: InputSource added: 001f001f <- mouseemu started, pbbuttonsd INFO: DBG: InputSource added: 001f001e <- detected 2 new input devices Mouse: Rel-X -1, Rel-Y 0 <- some more mouse movement Mouse: Rel-X -1, Rel-Y 0 Mouse: Rel-X -1, Rel-Y 0 [...] INFO: DBG: InputSource received G_IO_IN <- pbbuttonsd received CTRL-C INFO: DBG: InputSource removed: 7fe9d570 INFO: DBG: InputSource removed: 00010001 INFO: DBG: InputSource removed: 000122c4 INFO: DBG: InputSource removed: 0001771f INFO: DBG: InputSource removed: 00013301 INFO: DBG: InputSource removed: 001f0001 INFO: DBG: InputSource removed: INFO: DBG: InputSource removed: 001f001f INFO: DBG: InputSource removed: 001f001e Key events were also recognized but not printed in the debug log. On the other hand I got some strange behaviour with mouseemu running: 1. F10 in X doesn't work anymore 2. paste with middle mouse button (F11, kernel mouse button emulation) opens the context menu ?!? After stopping mouseemu, everything works as usual again. I never had this before. > mouseemu has event0, event1 and event2 open, as well as uinput (two times). > However, pbbuttonsd does _not_ seem to reopen any devices, in particular > after a few minutes it still hasn't opened the uinput event devices. Could you compile pbbuttonsd with debug information (--enable-debug) and check if the debug output confirms your observation? There might be a bug in pbbuttonsd that I doesn't see on my machine (would not be the first one :-)) > > Mouseemu exclusively locks all input devices related to mice for full > > control. After that it routes the mouse events through a newly created > > input device (or two of them). This way it can filter out unwanted > > mouse events or create new ones. Pbbuttonsd can't access the locked > > event devices anymore but it uses the newly created uinput devices > > instead. You won't see any difference in behaviour. > > So no problem to be expected here, is there? And pbbuttonsd should be > able to detect buttons 2&3 as activity, in contrast to mouse movement > and button1 (whose event dev is locked by synaptics), since those are > created on the new uinput event device, accessible to pbbuttonsd? I > haven't noticed this, but I would need to check. In theory this should all work fine :-) > It still doesn't explain why Fn'ed keys aren't detected by pbbuttonsd > anymore while mouseemu is running. I had similar experiences (see above). Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Gnome 2.12 doesn't show icons of removable media on desktop
Hi, I have a problem with the debian gnome installation and I don't know which package to blame. I came from sarge and updated the gnome packages (2.12) from testing. After that I don't see any removable media devices on the desktop. Nautlius won't create appropriate icons anymore. I had the gnome-volume-manager running and after plugging in a USB memory device, the volume manager mounted it under /media as usual. So far so good. But no icon on the desktop. I opened the "Computer" Icon and there it is: a memory device icon was there, but a double click ends in the error message: "Device already mounted". This is strange, because the gnome-volume-manager has mounted the device and nautilus doesn't seem to know about that. For the next test I removed the volume manager, so no one mounted anything. I plugged in the USB device and an Icon appeared in "Computer". Double Click -> error: Device already mounted. (???). This time Nautilus itself seems to mount the device and doesn't recognise it?. What's going up here? Famd is running so gnome should be able to watch /media. During all my tests I never got an device icon on the desktop. With the initial sarge installation this worked fine. The kernel have not been changed since then. Any hints? Which package I should file a bug to? Nautilus? gnome-vfs? fam? I don't know. How this mechanism works is no longer clear to me so any tips, hints, clues are appreciated. Best Regards Matthias ||/ Name Version Beschreibung +++--- ii libgnomevfs2-0 2.14.0-2 GNOME virtual file-system (runtime libraries) ii libgnomevfs2-com 2.14.0-2 GNOME virtual file-system (common files) ii libgnomevfs2-ext 2.14.0-2 GNOME virtual file-system (extra modules) ii libnautilus-exte 2.12.2-2 libraries for nautilus components - runtime vers ii nautilus 2.12.2-2 file manager and graphical shell for GNOME ii nautilus-data2.12.2-2 data files for nautilus ii fam 2.7.0-9 File Alteration Monitor ii pmount 0.9.9-2 mount removable devices as normal user ii hal 0.5.7-1 Hardware Abstraction Layer ii libhal-storage1 0.5.7-1 Hardware Abstraction Layer - shared library for ii libhal1 0.5.7-1 Hardware Abstraction Layer - shared library ii dbus 0.61-5 simple interprocess messaging system ii libdbus-1-2 0.61-5 simple interprocess messaging system ii libdbus-glib-1-2 0.61-5 simple interprocess messaging system (GLib-based ii libc62.3.6-3 GNU C Library: Shared libraries and Timezone dat Kernel: Linux version 2.6.14.4 (gcc-Version 3.3.5 (Debian 1:3.3.5-13)) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gnome 2.12 doesn't show icons of removable media on desktop
On Fri, 14 Apr 2006 22:56:20 -0500 Mannequin* <[EMAIL PROTECTED]> wrote: > > It is an unlucky combination of udev+kernel+gnome-volume-manager. IIRC the > > bug was filed against udev (search bugs.debian.org) but it was easily > > solved with a newer udev version. Try pulling it from unstable, it should > > do the trick. > > You might have to pull in a newer kernel with a newer udev... Anyone in > the know, uh, know if there is that difference between the udev in > testing and unstable? I remember having to deal with that a while back, > but my memory is foggy now that it's been a while since updating my PPC > to Unstable. Thanks for your help. A new kernel and the latest udev did the job: ii udev 0.089-1 Linux version 2.6.16.2 (gcc version 4.0.3 (Debian 4.0.3-1)) Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ignore accidental input
On Wed, 26 Apr 2006 15:11:12 +0200 Johannes Berg <[EMAIL PROTECTED]> wrote: > On Wed, 2006-04-26 at 08:09 +0200, Michael Schmitz wrote: > > > Nope, something like 'dont send mouse clicks when the user taps the > > touchpad'. Ignoring events while typing we can already do in user space. > > Figuring out if the mouse button was hit, or just the surface of the pad > > is something only the kernel driver can handle. > > That ought to be easy to add, just some sysfs variable can do it. If you > want, I can cook up a patch later today. Is this already available in the driver or do you have to patch it? Is it possible to change the trackpad mode as well? like with the ADB Trackpad: notap, tap, drag and lock? I would like to update pbbuttonsd to support this for USB trackpads as well. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ignore accidental input
On Tue, 25 Apr 2006 23:53:57 +0200 Børge Holen <[EMAIL PROTECTED]> wrote: > I've been lookin at both the mouseemu and pbbuttonsd and I got to agree with > Jörg that the "ignore while typing" is done far better with pbbuttonsd than > the mouseemu. Do you use the "NoTapTyping" option with pbbuttonsd? It was reported as dangerous because it might cause severe machine lockups. Best Regards Matthias
Re: Ignore accidental input
On Thu, 27 Apr 2006 14:57:43 +0200 Johannes Berg <[EMAIL PROTECTED]> wrote: > On Wed, 2006-04-26 at 20:00 +0200, Matthias Grimm wrote: > > > Is this already available in the driver or do you have to patch it? > > No, I'd have to patch it, but see my earlier mail. > > > Is it possible to change the trackpad mode as well? like with the ADB > > Trackpad: notap, tap, drag and lock? I would like to update pbbuttonsd > > to support this for USB trackpads as well. > > What are those modes? I wonder that you don't know. Anyway, the ADB trackpad supports four operating modes: notap: the trackpad only move the cursor tap : tapping with a finger on the trackpad emits a left mouse button click drag : tapping on the trackpad and moving the finger on the trackpad right afterwards emulates mouse movement with pressed left mouse button for instance to move a window on screen. lock : same as drag except that lifting the finger from the pad doesn't release the left mouse button. To release the button another short tap is needed. The ADB Trackpad performs all of those modes in hardware. Are similar modes available in the USB trackpad and if so, are they accessible from user space? Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ignore accidental input
On Thu, 27 Apr 2006 15:26:22 +0200 Michel Dänzer <[EMAIL PROTECTED]> wrote: > On Wed, 2006-04-26 at 20:02 +0200, Matthias Grimm wrote: > > On Tue, 25 Apr 2006 23:53:57 +0200 > > Børge Holen <[EMAIL PROTECTED]> wrote: > > > > > I've been lookin at both the mouseemu and pbbuttonsd and I got to agree > > > with > > > Jörg that the "ignore while typing" is done far better with pbbuttonsd > > > than > > > the mouseemu. > > > > Do you use the "NoTapTyping" option with pbbuttonsd? It was reported as > > dangerous because it might cause severe machine lockups. > > I was suspecting that option as well, but I had frequent sudden > poweroffs even with it disabled, so I'm back on pmud for now. Are you sure that these "poweroffs" are caused by pbbuttonsd? To freeze the machine is not easy but possible, but to power it off? I don't think pbbuttonsd is capable of doing this. Best Regards Matthias
Re: keyboard backlight on PB 5,4 and question about modem
On Sat, 24 Jun 2006 08:19:25 GMT Marco Stagno <[EMAIL PROTECTED]> wrote: > I'm using Debian/SID (kernel 2.6.16) on my PB G4 (15",rev 5.4, 1.5GHz) and > I'm unable to make the keyboard backlight working :( > the module i2c-dev is loaded but not used by anyone... You might need i2c-powermac, too. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kblevel - set keyboard illumination directly
On Tue, 20 Jun 2006 01:44:56 +1000
Paul Collins <[EMAIL PROTECTED]> wrote:
> Thanks of course are due to Matthias Grimm for writing the original
> pbbuttonsd code.
Thank you too. I added support for 255 KBD Brightnesslevel in pbbuttons too :-)
I tried to improve your sysfs LMU detection routines and add the OF
stuff to get the LMU address from the device tree. Unfortunately I have
no PowerBook with a LMU built in so I could test it only with device
tree copies other people sent to me.
I don't know how constant OF device tree names are over the different
models and kernel versions. So any feedback would be welcome.
Best Regards
Matthias
#include
#include
#include
#include
#include
#define OFBASE "/proc/device-tree"
#define SYSI2CDEV "/sys/class/i2c-dev"
#define I2CCHIP"uni-n"
#define I2C_SLAVE 0x0703
int
probeLMU(char *device, int addr)
{
char buffer[4];
int fd, rc = 0;
if ((fd = open(device, O_RDWR)) >= 0) {
if (ioctl(fd, I2C_SLAVE, addr) >= 0) {
if (read (fd, buffer, 4) == 4)
rc = 1;
}
close(fd);
}
return rc;
}
int
addPath(char *path, int maxlen, char *pattern)
{
DIR *dh;
struct dirent *dir;
int rc = 1;
if ((dh = opendir(path))) {
while (dir = readdir(dh)) {
if ((strncmp(dir->d_name, pattern, strlen(pattern)) == 0)) {
strncat(path, "/", maxlen-1);
strncat(path, dir->d_name, maxlen-1);
rc = 0;
break;
}
}
closedir(dh);
}
return rc;
}
int
getLMUAddress()
{
char path[200];
FILE *fd;
long reg;
int n, rc = 0, err = 0;
path[0] = 0; /* terminate path buffer */
strncat(path, OFBASE, sizeof(path)-1);
err += addPath(path, sizeof(path), "uni-n");
err += addPath(path, sizeof(path), "i2c");
err += addPath(path, sizeof(path), "lmu-controller");
strncat(path, "/reg", sizeof(path)-1);
printf("\nOF: '%s'\n", path);
if (err > 0)
printf("Path incomplete! One or more elements not found.\n");
else if ((fd = fopen(path, "r")) >= 0) {
n = fread(®, sizeof(long), 1, fd);
if (n == 1)
rc = (int) (reg >> 1);
fclose(fd);
}
return rc;
}
int
findI2CDevice(int addr)
{
char buffer[40];
DIR *dh;
FILE *fd;
struct dirent *dir;
int n;
if ((dh = opendir(SYSI2CDEV))) {
while (dir = readdir(dh)) {
if (dir->d_name[0] == '.') continue;
snprintf(buffer, sizeof(buffer), SYSI2CDEV"/%s/name", dir->d_name);
if ((fd = fopen(buffer, "r")) >= 0) {
n = fread(buffer, 1, sizeof(buffer), fd);
if (n > 0 && n < sizeof(buffer)) {
buffer[n-1] = 0;
printf("I2C: '%s', '%s'", dir->d_name, buffer);
if ((strncmp(I2CCHIP" ", buffer, 6) == 0)) {
snprintf(buffer, sizeof(buffer), "/dev/%s", dir->d_name);
if ((probeLMU(buffer, addr)))
printf(" <- this one!");
}
printf("\n");
}
fclose(fd);
}
}
closedir(dh);
}
}
int
main (int argc, char *argv[])
{
int addr;
addr = getLMUAddress();
if (addr) {
printf("LMU: address %x \n", addr);
findI2CDevice(addr);
} else
printf("No LMU found!\n");
return 0;
}
Re: kblevel - set keyboard illumination directly
On Tue, 20 Jun 2006 01:44:56 +1000 Paul Collins <[EMAIL PROTECTED]> wrote: By the way, could somebody test the 255 brightness steps stuff in pbbuttonsd? It works in theory, but I would like to have the confirmation. ;-) The code is in CVS on sourceforge.net Thanks and Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
New I2C and machine probing method
Hi,
I want to use some OF and kernel 2.6 features to improve device probing
in pbbuttonsd. Unfortunately I have only an ancient PowerBook so I need
your help to test the new routines on as many different machines as
possible.
I attached the source code of a short program. You could compile it as
follows:
$> gcc -o of_probing of_probing.c
This program does three things:
1. detecting the machine ID.
Any PowerBook user can test this feature. Launch the program and
check if the machine ID is correctly detected on your machine. If
you don't know which ID your machine have see in
$> cat /proc/device-tree/model or
$> cat /proc/cpuinfo
Tell me if your machine is not correctly identified. PowerBooks
before the G3 Pismo will get the dummy ID "1", because Apple started
his numbering system just with the Pismo.
2. detecting the LMU I2C address
The program looked for the "lmu-controller" in the device tree and
read the attached data to find out the I2C address.
This test will only have a result, if you have a PowerBook with an
ambient light sensor. Otherwise the program won't find an LMU.
If your machine definitely has an ambient light sensor and the program
won't find it, the device tree path might be wrong. In this case please
send me the correct path or an tar archive of /proc/device-tree.
3. detecting of the /dev/i2c device to communicate with the LMU
This test reads /sys to find out which i2c devices are available and
which one is connected to the "uni-n" controller the LMU is attached
to. Each found i2c device will then be checked for the LMU.
The program lists all found i2c devices to the console and mark the
device with the LMU connected.
This test needs the kernel module i2c-dev to be loaded. If not
already done, you could load the module with
$> modprobe i2c-dev
I would appreciate any feedback.
Thank you and Best Regards
Matthias
#include
#include
#include
#include
#include
#define OFBASE "/proc/device-tree"
#define SYSI2CDEV "/sys/class/i2c-dev"
#define I2CCHIP"uni-n"
#define I2C_SLAVE 0x0703
int
probeLMU(char *device, int addr)
{
char buffer[4];
int fd, rc = 0;
if ((fd = open(device, O_RDWR)) >= 0) {
if (ioctl(fd, I2C_SLAVE, addr) >= 0) {
if (read (fd, buffer, 4) == 4)
rc = 1;
}
close(fd);
}
return rc;
}
int
addPath(char *path, int maxlen, char *pattern)
{
DIR *dh;
struct dirent *dir;
int rc = 1;
if ((dh = opendir(path))) {
while (dir = readdir(dh)) {
if ((strncmp(dir->d_name, pattern, strlen(pattern)) == 0)) {
strncat(path, "/", maxlen-1);
strncat(path, dir->d_name, maxlen-1);
rc = 0;
break;
}
}
closedir(dh);
}
return rc;
}
int
getLMUAddress()
{
char path[200];
FILE *fd;
long reg;
int n, rc = 0, err = 0;
path[0] = 0; /* terminate path buffer */
strncat(path, OFBASE, sizeof(path)-1);
err += addPath(path, sizeof(path), "uni-n");
err += addPath(path, sizeof(path), "i2c");
err += addPath(path, sizeof(path), "lmu-controller");
strncat(path, "/reg", sizeof(path)-1);
printf(" OF: '%s'\n", path);
if (err > 0)
printf("Path incomplete! One or more elements not found.\n");
else if ((fd = fopen(path, "r")) >= 0) {
n = fread(®, sizeof(long), 1, fd);
if (n == 1)
rc = (int) (reg >> 1);
fclose(fd);
}
return rc;
}
int
findI2CDevice(int addr)
{
char buffer[40];
DIR *dh;
FILE *fd;
struct dirent *dir;
int n;
if ((dh = opendir(SYSI2CDEV))) {
while (dir = readdir(dh)) {
if (dir->d_name[0] == '.') continue;
snprintf(buffer, sizeof(buffer), SYSI2CDEV"/%s/name", dir->d_name);
if ((fd = fopen(buffer, "r")) >= 0) {
n = fread(buffer, 1, sizeof(buffer), fd);
if (n > 0 && n < sizeof(buffer)) {
buffer[n-1] = 0;
printf(" I2C: '%s', '%s'", dir->d_name, buffer);
if ((strncmp(I2CCHIP" ", buffer, 6) == 0)) {
snprintf(buffer, sizeof(buffer), "/dev/%s", dir->d_name);
if ((probeLMU(buffer, addr)))
printf(" <- this is the LMU device");
}
printf("\n");
}
fclose(fd);
}
}
closedir(dh);
}
}
int
getMachineID()
{
char buffer[32];
int fd, n, machine = 0;
if ((fd = open(OFBASE"/model", O_RDONLY))) {
if ((n = read(fd, buffer, sizeof(buffer) - 1)) != -1) {
buffer[n] = 0; /* terminate buffer, only to be sure */
if (strncmp("PowerBook", buffer, 9) == 0) {
if (buffer[9] == 0)
machine = 1; /* Dummy code for pre-Pismo PowerBooks */
else {
machine = (atoi(&buffer[9]) & 0xf) << 4;
for (n = 9; buffer[n] != ',' && buffer[n] != '\0'; ++n);
if (buffer[n] == ',')
machine |= atoi(&buffer[n+1]) & 0xf;
}
}
}
close(fd);
}
return machine;
}
int
main (int argc, char *argv[])
{
int addr, machine;
printf("\nProbing machine...\n");
machine = getMachineID();
if (machine != 0) {
printf (" Machine: ID = %x\n", machine);
addr = getLMUAddress();
if (addr) {
printf(" LMU: I2C address = %x \n", addr);
fin
Re: New I2C and machine probing method
On Sun, 16 Jul 2006 15:45:57 +0200
Matthias Grimm <[EMAIL PROTECTED]> wrote:
Thanks a lot for your support so far. I put the new knowledge into a
revised program and attached it again. Changes are:
- There are two known locations for the lmu-controller in the
device-tree so far. Both are supported now.
- adding I/O error support. To communicate with the LMU the program
must be run as root. If there was any problem with the device, an
I/O error message would occur on terminal.
- removing all the silly warnings
- detailed machine identification by name added
I hope you give it another try :-)
Best Regards
Matthias
#include
#include
#include
#include
#include
#include
#include
#include
#define OFBASE "./device-tree"
#define SYSI2CDEV "/sys/class/i2c-dev"
#define I2CCHIP"uni-n"
#define I2C_SLAVE 0x0703
#define OHARE_PMU 9
static char *machines[7][10] = {
{ "unknown",
"PowerBook 3400",/* 0,1 */
"PowerBook 3500",/* 0,2 */
"PowerBook Wallstreet (Apr 1998)", /* 0,3 */
NULL, NULL, NULL, NULL, NULL, NULL },
{ NULL,
"PowerBook 101 Lombard (Apr 1999)", /* 1,1 */
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL },
{ NULL,
"iBook (Feb 2000)", /* 2,1 */
"iBook FireWire (Sep 2000)", /* 2,2 */
NULL, NULL, NULL, NULL, NULL, NULL, NULL },
{ NULL,
"PowerBook G3 Pismo (Feb 2000)", /* 3,1 */
"PowerBook G4 Titanium (Dec 2000)", /* 3,2 */
"PowerBook G4 Titanium II (Oct 2001)", /* 3,3 */
"PowerBook G4 Titanium III (Apr 2002)", /* 3,4 */
"PowerBook G4 Titanium IV (Nov 2002)", /* 3,5 */
NULL, NULL, NULL, NULL },
{ NULL,
"iBook 2 (May 2001)",/* 4,1 */
"iBook 2 (May 2002)", /* 4,2 */
"iBook 2 rev. 2 (Nov 2002)", /* 4,3 */
NULL, NULL, NULL, NULL, NULL, NULL },
{ NULL,
"PowerBook G4 17\" (Mar 2003)", /* 5,1 */
"PowerBook G4 15\" (Sep 2003)", /* 5,2 */
"PowerBook G4 17\" (Sep 2003)", /* 5,3 */
"PowerBook G4 15\" (Apr 2004)", /* 5,4 */
"PowerBook G4 17\" (Apr 2004)", /* 5,5 */
"PowerBook G4 15\" (Feb 2005)", /* 5,6 */
"PowerBook G4 17\" (Feb 2005)", /* 5,7 */
"PowerBook G4 15\" (Oct 2005)", /* 5,8 */
"PowerBook G4 17\" (Oct 2005)" },/* 5,9 */
{ NULL,
"PowerBook G4 12\" (Jan 2003)", /* 6,1 */
"PowerBook G4 12\" (Sep 2003)", /* 6,2 */
"iBook G4 (Oct 2003)", /* 6,3 */
"PowerBook G4 12\" (Apr 2004)", /* 6,4 */
"iBook G4 (Apr 2004)", /* 6,5 */
NULL,
"iBook G4 (Jul 2005)", /* 6,7 */
"PowerBook G4 12\" (Oct 2005)", /* 6,8 */
NULL }
};
int
probeLMU(char *device, int addr)
{
char buffer[4];
int fd, rc = 0;
if ((fd = open(device, O_RDWR)) >= 0) {
if (ioctl(fd, I2C_SLAVE, addr) >= 0) {
if (read (fd, buffer, 4) == 4)
rc = 1;
}
close(fd);
} else
printf (" %s!", strerror(errno));
return rc;
}
int
addPath(char *path, int maxlen, char *pattern)
{
DIR *dh;
struct dirent *dir;
int rc = 1;
if ((dh = opendir(path))) {
while ((dir = readdir(dh))) {
if ((strncmp(dir->d_name, pattern, strlen(pattern)) == 0)) {
strncat(path, "/", maxlen-1);
strncat(path, dir->d_name, maxlen-1);
rc = 0;
break;
}
}
closedir(dh);
}
return rc;
}
int
getLMUAddress()
{
char path[200];
long reg;
int fd, n, rc = 0, err = 0;
path[0] = 0; /* terminate path buffer */
strncat(path, OFBASE, sizeof(path)-1);
if ((err = addPath(path, sizeof(path), "uni-n")) == 0)
if ((err = addPath(path, sizeof(path), "i2c")) == 0)
if ((err = addPath(path, sizeof(path), "lmu-controller")) != 0)
if ((err = addPath(path, sizeof(path), "i2c-bus")) == 0)
err = addPath(path, sizeof(path), "lmu-micro");
strncat(path, "/reg", sizeof(path)-1);
printf(" OF: '%s'\n", path);
if (err > 0)
printf("Path incomplete! One or more elements not found.\n");
else if ((fd = open(path, O_RDONLY)) >= 0) {
n = read(fd, ®, sizeof(long));
if (n == sizeof(long))
rc = (int) (reg >> 1);
close(fd);
}
return rc;
}
int
findI2CDevice(int addr)
{
char buffer[40];
DIR *dh;
struct dirent *dir;
unsigned int n;
int fd;
if ((dh = opendir(SYSI2CDEV))) {
while ((dir = readdir(dh))) {
if (dir->d_name[0] == '.') continue;
snprintf(buffer, sizeof(buffer), SYSI2CD
Re: New I2C and machine probing method
On Mon, 17 Jul 2006 21:19:30 +0200
Matthias Grimm <[EMAIL PROTECTED]> wrote:
Damn, I didn't removed my debugging stuff and so the program used a
wrong device tree path. Sorry for that. Replace line
#define OFBASE "./device-tree"
with line
#define OFBASE "/proc/device-tree"
The attached program source contains the change.
Best Regards
Matthias
#include
#include
#include
#include
#include
#include
#include
#include
#define OFBASE "/proc/device-tree"
#define SYSI2CDEV "/sys/class/i2c-dev"
#define I2CCHIP"uni-n"
#define I2C_SLAVE 0x0703
#define OHARE_PMU 9
static char *machines[7][10] = {
{ "unknown",
"PowerBook 3400",/* 0,1 */
"PowerBook 3500",/* 0,2 */
"PowerBook Wallstreet (Apr 1998)", /* 0,3 */
NULL, NULL, NULL, NULL, NULL, NULL },
{ NULL,
"PowerBook 101 Lombard (Apr 1999)", /* 1,1 */
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL },
{ NULL,
"iBook (Feb 2000)", /* 2,1 */
"iBook FireWire (Sep 2000)", /* 2,2 */
NULL, NULL, NULL, NULL, NULL, NULL, NULL },
{ NULL,
"PowerBook G3 Pismo (Feb 2000)", /* 3,1 */
"PowerBook G4 Titanium (Dec 2000)", /* 3,2 */
"PowerBook G4 Titanium II (Oct 2001)", /* 3,3 */
"PowerBook G4 Titanium III (Apr 2002)", /* 3,4 */
"PowerBook G4 Titanium IV (Nov 2002)", /* 3,5 */
NULL, NULL, NULL, NULL },
{ NULL,
"iBook 2 (May 2001)",/* 4,1 */
"iBook 2 (May 2002)", /* 4,2 */
"iBook 2 rev. 2 (Nov 2002)", /* 4,3 */
NULL, NULL, NULL, NULL, NULL, NULL },
{ NULL,
"PowerBook G4 17\" (Mar 2003)", /* 5,1 */
"PowerBook G4 15\" (Sep 2003)", /* 5,2 */
"PowerBook G4 17\" (Sep 2003)", /* 5,3 */
"PowerBook G4 15\" (Apr 2004)", /* 5,4 */
"PowerBook G4 17\" (Apr 2004)", /* 5,5 */
"PowerBook G4 15\" (Feb 2005)", /* 5,6 */
"PowerBook G4 17\" (Feb 2005)", /* 5,7 */
"PowerBook G4 15\" (Oct 2005)", /* 5,8 */
"PowerBook G4 17\" (Oct 2005)" },/* 5,9 */
{ NULL,
"PowerBook G4 12\" (Jan 2003)", /* 6,1 */
"PowerBook G4 12\" (Sep 2003)", /* 6,2 */
"iBook G4 (Oct 2003)", /* 6,3 */
"PowerBook G4 12\" (Apr 2004)", /* 6,4 */
"iBook G4 (Apr 2004)", /* 6,5 */
NULL,
"iBook G4 (Jul 2005)", /* 6,7 */
"PowerBook G4 12\" (Oct 2005)", /* 6,8 */
NULL }
};
int
probeLMU(char *device, int addr)
{
char buffer[4];
int fd, rc = 0;
if ((fd = open(device, O_RDWR)) >= 0) {
if (ioctl(fd, I2C_SLAVE, addr) >= 0) {
if (read (fd, buffer, 4) == 4)
rc = 1;
}
close(fd);
} else
printf (" %s!", strerror(errno));
return rc;
}
int
addPath(char *path, int maxlen, char *pattern)
{
DIR *dh;
struct dirent *dir;
int rc = 1;
if ((dh = opendir(path))) {
while ((dir = readdir(dh))) {
if ((strncmp(dir->d_name, pattern, strlen(pattern)) == 0)) {
strncat(path, "/", maxlen-1);
strncat(path, dir->d_name, maxlen-1);
rc = 0;
break;
}
}
closedir(dh);
}
return rc;
}
int
getLMUAddress()
{
char path[200];
long reg;
int fd, n, rc = 0, err = 0;
path[0] = 0; /* terminate path buffer */
strncat(path, OFBASE, sizeof(path)-1);
if ((err = addPath(path, sizeof(path), "uni-n")) == 0)
if ((err = addPath(path, sizeof(path), "i2c")) == 0)
if ((err = addPath(path, sizeof(path), "lmu-controller")) != 0)
if ((err = addPath(path, sizeof(path), "i2c-bus")) == 0)
err = addPath(path, sizeof(path), "lmu-micro");
strncat(path, "/reg", sizeof(path)-1);
printf(" OF: '%s'\n", path);
if (err > 0)
printf("Path incomplete! One or more elements not found.\n");
else if ((fd = open(path, O_RDONLY)) >= 0) {
n = read(fd, ®, sizeof(long));
if (n == sizeof(long))
rc = (int) (reg >> 1);
close(fd);
}
return rc;
}
int
findI2CDevice(int addr)
{
char buffer[40];
DIR *dh;
struct dirent *dir;
unsigned int n;
int fd;
if ((dh = opendir(SYSI2CDEV))) {
while ((dir = readdir(dh))) {
if (dir->d_name[0] == '.') continue;
snprintf(buffer, sizeof(buffer), SYSI2CDEV"/%s/name", dir->d_name);
if ((fd = open(buffer, O_RDONLY)) >= 0) {
n = read(fd, buffer, sizeof(buffer));
if (n > 0 && n < sizeof(buffer)) {
buffer[n-1] = 0;
printf(" I2C: '%s&#
Re: New I2C and machine probing method
On Thu, 20 Jul 2006 22:54:04 -0700 (PDT) brian <[EMAIL PROTECTED]> wrote: > debian:/home/brian/Downloads# ./of_probing > > Probing machine... >Machine: ID = 3 -> PowerBook Wallstreet (Apr 1998) >OF: '/proc/device-tree/reg' > Path incomplete! One or more elements not found. >LMU: No LMU found! > > youre improving, before it said "not a powerbook" I didn't implement routines to talk to the PMU in the test program, so that it can't identify machines before Wallstreet correctly. It needs the PMU version to differentiate the early PowerBooks. It will work after integrating into pbbuttonsd. :-) Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New I2C and machine probing method
On Mon, 17 Jul 2006 21:19:30 +0200 Matthias Grimm <[EMAIL PROTECTED]> wrote: It would be very kind if someone with a PowerBook5,1 to PowerBook5,7 could run the test program and send me the output. The machine identification seems to work good, but primarily I wanted to test the LMU detection. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New I2C and machine probing method
On Sat, 22 Jul 2006 13:22:11 +0200 Johannes Berg <[EMAIL PROTECTED]> wrote: > On Fri, 2006-07-21 at 17:33 +0200, Johannes Berg wrote: > > I2C: 'i2c-7', 'uni-n 0' probing /dev/i2c-7 ... gotcha, this is the > > LMU device I2C: 'i2c-6', 'mac-io 0' > > Btw, this makes it seem that you don't understand how the i2c devices > work; /dev/i2c-7 isn't the LMU device, /dev/i2c-7 is the device node for > the bus that the LMU is on. What are you trying to tell me? Do you want to argue about the wording in my test program? In this case you will win. ;-) I surely know that the /dev/i2c-7 is not the LMU device itself. It's the interface to the I2C controller built into the uni-n memory controller and bus bridge IC the LMU is connected to. But this makes no difference for the normal user who wants that this thing simply works. I2C is a two line serial bus invented and patented by Philips and up to 400 KBit fast, where you can attach multiply devices to and each device could be addressed by a unique (on that specific bus) device address. I read this address from the open firmware device-tree and use it to connect to the LMU via /dev/i2c-7. It would be much better if I could read the address somewhere from /sys, but it isn't provided by /sys yet. Any further questions? ;-) Best regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
upcoming new pbbuttonsd in CVS
Hi, the upcoming new version of pbbuttonsd is in CVS. This version got new detection routines for the machine type and the LMU controller. Both use the open firmware device-tree now. Following conditions must be fulfilled for the new detection routines to work: 1. /proc/device-tree must exist 2. i2c-dev kernel module must be loaded (on machines with a LMU). Please test it and give me any feedback. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PowerBook5,2 = Which brand? (slightly off toppic)
On Fri, 28 Jul 2006 19:36:44 +0300 "Eddy Petrişor" <[EMAIL PROTECTED]> wrote: > Hello all, > > I have been thinking of adding more RAM to my powerbook, but I > realised that I am not sure about the Apple identification scheme > giving correct answers for me, so I don't know what kind of RAM I > need. You should have a look into you PowerBook documentation. The needed RAM specification should be found there. I found the following spec at Apple.com: The RAM expansion modules used in the 15-inch PowerBook G4 are standard 200-pin PC2700 DDR333 RAM SO-DIMMs, as defined in the JEDEC specifications. The mechanical characteristics of the RAM expansion DDR SO-DIMM are given in the JEDEC specification number JESD95 To obtain a copy of the specification, see the references listed at “RAM Expansion Modules”. The specification defines DDR SO-DIMMs with nominal heights of 1.0, 1.25, 1.5, and 2.0 inches. The 15-inch PowerBook G4 can accommodate DDR SO-DIMMS with heights of 1.25 inches or less. If you need more information about your machine, have a look on following page: http://developer.apple.com/documentation/Hardware/Developer_Notes/Macintosh_CPUs-G4/15inchPowerBookG4_Sept03/index.html Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Power on powerbook G4
On Thu, 20 Jan 2005 11:33:36 +0100 Guillaume Florey <[EMAIL PROTECTED]> wrote: > Hi all, > I have one question about the behaviour of the battery on my powerbook G4: > When the battery is full, and the electricity cable is still plug-in, does > this damage the battery ? I heard that when the battery full is, you have to > unplug the cable and wait before plug-in, till the battery empty is. I wanted > to know if I can leave the electricity cable plug-in with full battery, > without damaging my battery ? The plugged in AC connector doesn't do any harm to your battery. The battery charge is kept at maximum level controlled by an internal charging electronic. Usually high temperatures decrease battery life time and mobile computers with high speed processors mostly generate a lot of heat. Due to this it is recommended to remove a 75% charged battery while working on AC power but I think this not an option for you. Fortunately the Apple powerbooks don't get as hot as intel counterparts. :-) Another interesting fact about Li-Ion batteries is that the maximum live time is not only a matter of time but of charge cycles. Current battery packs usually allow 500 charge cycles (more or less) before they get useless. Even if you use you laptop only one hour on battery until recharging or drain it completely empty, the stress for the battery is the same. So batteries should always be used until they are completly empty before recharging. Best Regards Matthias Grimm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PBButtonsd 0.6.7 released - major feature enhencement
On Fri, 28 Jan 2005 09:17:12 +0100 Stefano Zacchiroli <[EMAIL PROTECTED]> wrote: > On Wed, Jan 26, 2005 at 06:45:04PM +0100, Matthias Grimm wrote: > > As second highlight on supported graphics cards the external > > video output could be switched on/off with a hotkey (m*mirror). > > Is there any list of the supported graphics cars? This depends on the kernel. As far as I could discover it following cards or chips are supported: ATI Rage 128 or Rage M3 Chip Radeon M6, Radeon M7 and Radeon M9 chips > (Or simply: "is a radeon mobility 9000 supported?" :-) If I interpret your card number right you have a Radeon M9 chip and the chance is good that the mirror feature will work. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.6.*: vlock breaks sleep button?
On Tue, 22 Feb 2005 02:15:20 +0100 Wolfgang Pfeiffer <[EMAIL PROTECTED]> wrote: Hi, Some time ago I heard of this problem and a possible sollution. The following test shows parts of the appropriate thread: ## THREAD START ## > When you trigger sleep with kernel 2.6 or later the kernel will > switch to a new vt to keep the current vt clean and don't mess > it with annoying sleep and resume messages. If you had 'vlock -a' > running exactly this is not possilbe anymore -> the kernel got stuck > and wait until it is possible again. > > There is a symbol in the kernel sources calles SUSPEND_CONSOLE, > defined in kernel/power/power.h. If you remove this symbol (there is > no config option for that so you have to modify the source files > directly), compile and install this patched kernel, your script worked > as desired. But be carefull: I just verified my theory and haven't > checked all side effects of this patch. Me again... with solution, now. "vlock -a" prevents console switching and kernel tries to switch to console MAX_NR_CONSOLES-1, which is 63. But if we are on the console 63, then kernel does not switch (or something) and there is no incompatibility. :] The script below works quite well (but not perfectly): suspend) case "$3" in ram) ;; disk) ;; esac openvt -swfc 63 -- su - wrobell -c "tput clear; vlock -a" & ## THREAD END ## I hope this will help you solving your problem Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disable sound in gtkpbbuttons
On Tue, 22 Feb 2005 14:37:31 +0100 Jorge Bernal <[EMAIL PROTECTED]> wrote: > On Monday 21 February 2005 14:20, Joerg Sommer wrote: > > Hi, > > > > how to disable the sound in gtkpbbuttons? Version 0.6.5-1 want start > > if > > /dev/dsp doesn't exist. I use "-a /dev/null", but this is a dirty > > hack. > > How do it right? > > > > Quick way: modify the Classic theme.desc and remove all the *.wav > lines. If > the theme has no sound, I think gtkppbuttons won't try to initialize > it That is correct. There is no other way to disable sound in general. With introduction of themes most general options go to the theme definition file. > Another option: rebuild the package modifying debian/rules to pass > --disable-sound to configure. This will disable sound in general. I don't know if you really want this. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.6.*: vlock breaks sleep button?
On Wed, 23 Feb 2005 00:26:03 +0100 Wolfgang Pfeiffer <[EMAIL PROTECTED]> wrote: > Thanks, but no: I don't understand anything of the code in the > sources: Sorry to hear that. > So I'll mess with stuff I understand, and keep my hands off the rest > of it .. And, yes, I also didn't quite get so far on how to adjust > some new script safely to the scripts already being in /etc/power/ ... > > So I'll simply wait and hope that the kernel folks working for IBM, > RedHat etc. will fix the problem that results from the new feature > with the extra console for sleep mode: That is also a solution ;-) > This bug will be rather annoying in production environments where > people would leave for some period of time their office chairs, > vlocking their computers, and trying to get the machine into sleep > mode -- wondering that it doesn't work as it did in 2.4 ... :) > > 3 months, or sooner, and this bug will be fixed. I'd bet ... :) > Or that's what I'd hope at least ... :) > > PS: With Google I could not find the thread mentioned above: Did you? It is a personal thread from a pbbuttonsd user to me. He also wanted to lock all consoles and put the machine to sleep and run into the same pitfall as you did. I doesn't use vlock myself to I'm sorry that I can't help you further. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu replacement in pbbuttonsd
On Mon, 28 Feb 2005 13:52:44 + (UTC) Joerg Sommer <[EMAIL PROTECTED]> wrote: > Hi, > > my problem with the touchpad is, while typing hitting on the touchpad > and > this generates a click and my cursor jumps away. I know mouseemu > exists. > But pbbuttonsd already watches for key events. Isn't it possible to > make > it switch the mode of the touchpad, while typing? Yes it would be. Is this a feature request? :-) Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: record mic and linein on powerbook G3
On Fri, 4 Mar 2005 08:49:13 -0800 (PST) gm c <[EMAIL PROTECTED]> wrote: > I was wondering if it is now possible to record from the mic or linein > on the powerbook G3 pismo? If so , how? Install (already done, if you use kernel 2.6) and run the ALSA sound driver. Pull Mic input lever in an mixer application to full level. Then use a tool like audacity to record from internal mic. Have fun. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu replacement in pbbuttonsd
On Tue, 1 Mar 2005 09:58:54 + (UTC) Joerg Sommer <[EMAIL PROTECTED]> wrote: Hi, following feature has been added to pbbuttonsd: The trackpad will be reconfigured to 'notap' while typing. The old trackpad mode is restored after roundabout 0.6 seconds. This seems a good value to me also for people using the two finger typing method (like me :-)) and who is not so fast in typing. This feature is only availabe from CVS (on sourceforge.net) for test and it is not configurable yet. This may change before next release and depends on users feedback. Pbbuttonsd can't replace mouseemu. Although mouseemu uses some of pbbuttonsd original code and routines, its excellent features can't be integrated easily. Anyway, some people think pbbuttonsd is 'fat' enough and needs no more features. ;-) The latest feature extension simply reconfigures the trackpad hardware to its 'move only' or 'notap' mode. This is pretty simple but works also with kernel 2.4. Please test the feature and have an eye on possible conflicts with mouseemu. Thanks and best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu replacement in pbbuttonsd
On Sun, 6 Mar 2005 13:50:08 +0100 wrobell <[EMAIL PROTECTED]> wrote: > > This feature is only availabe from CVS (on sourceforge.net) for > > test and it is not configurable yet. This may change before next > > release and depends on users feedback. > Any patch? attached, it is based on 0.6.7a. Best Regards Matthias notap.patch.gz Description: Binary data
Re: pbbuttonsd: don't dim the display while watching video
On Sat, 12 Mar 2005 01:03:43 + (UTC) Joerg Sommer <[EMAIL PROTECTED]> wrote: > Hi, > > how can I tell pbbuttons not to dim the backlight while watching video? > It's annoying! pbbcmd config onac_timedim 0 pbbcmd config onbattery_timedim 0 will disable display dimming until next reboot. pbbcmd query onac_timedim will give current settings. With this tools it should be easy to built a script that disable dimming before watching a video and restore the settings afterwards. Best Regards Matthias PS: Don't forget to enable 'cpulock' to prevent pbbuttonsd from going to sleep. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd: don't dim the display while watching video
On Sun, 13 Mar 2005 23:11:01 + (UTC) Joerg Sommer <[EMAIL PROTECTED]> wrote: > > PS: Don't forget to enable 'cpulock' to prevent pbbuttonsd from going to > > sleep. > > How to do this? Set this in pbbuttonsd.conf: CPULoad_sleeplock = yes CPULoad_min = 20 ; value in percent CPULoad_period= 20 ; time in seconds This will allow pbbuttonsd going to sleep only if the CPU load is below 20 percent for at least 20 seconds. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Hibernate pbbuttonsd
On Wed, 16 Mar 2005 11:29:15 -0600 [EMAIL PROTECTED] (Jeremiah Benham) wrote: > Is there a way to have pbbuttonsd launch hibernate when I hit the > power button? yes. Since version 0.6.5 pbbuttonsd supports more suspend modes which can be configured independently for AC and battery operation. The options are called: onAC_TimerAction = none ; none, suspend-to-ram, suspend-to-disk, blankscreen onAC_CoverAction = suspend-to-ram onAC_KeyAction = suspend-to-ram ; SleepKey same options exist for onBattery_<>. See man pbbuttonsd.conf for full details. If you set onXX_KeyAction = suspend-to-disk a script is called each time you press the sleepkey. All you have to do is to place a pmcs-script into /etc/power/event.d which then calls your hibernate script. The hibernate script is not expected to return. This feature is not fully tested because my machine was not prepared to use suspend-to-disk. Some weeks ago I reconfigured my system so that suspend-to-disk might be possible but until now I haven't set it up. So I am very interested in your experiences and results. Especially how pbbuttonsd reacts after wakeup from hibernation. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
pbbuttonsd 0.6.8beta1 has been released for testing
Hi, As consequence of the high number of critical bugs in the last release I publish a beta release first this time: PBButtonsd 0.6.8beta1 available at: http://pbbuttons.sourceforge.net This beta release has got a new internal configuration file management which allows to save options of inactive modules too. This becomes necessary with introduction of the ALSA mixer module. Beside this the mixer could be automatically detected at startup, the tapping of the trackpad could be temporarely disabled while typing on the keyboard and last but not least some minor bugs have been fixed. This is a beta release and should be used for testing only. Please play with it and report any bugs or comments to me or to the pbbuttons mailing list. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
event device and X11 keycodes
Hi, Is there a relation between the keycodes from the event devices /dev/input/event% and the X11 key events? Which? How can I get the event deveice keycodes in an X11 application without opening the /dev/input/event% devices? Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbutons wont put my PB to sleep
On Sun, 27 Mar 2005 22:02:06 -0400 (CLT) Rolando Abarca <[EMAIL PROTECTED]> wrote: > I have a lombard with kernel 2.6.11.5 (recently compiled) I thought that > pbbutons will work now, but it's doing the same thing that before, it > won't put my PB to sleep if I close the lid (only turn off the screen). Do > I have to include some special module/option for this to work?... > thanks! Please check out the configuration file. There is an option that tells pbbuttonsd what to to when the lid has been closed. It's named onAC_CoverAction and onBattery_CoverAction. See man pbbuttonsd.conf for detailed description. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd 0.6.8beta1 has been released for testing
On Fri, 25 Mar 2005 15:35:11 + (UTC) Joerg Sommer <[EMAIL PROTECTED]> wrote: > Matthias Grimm <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > As consequence of the high number of critical bugs in the last release I > > publish a beta release first this time: > > > > PBButtonsd 0.6.8beta1 > > available at: http://pbbuttons.sourceforge.net > > I've build it and started it (not installed), but the touchpad suspend > doesn't work. I can type and use the touchpas. How to enable this new > feature? In this beta realease the function is always enabled. To track if the trackpad tap is currently en- or disabled, you could compile with --enable-debug. The tapping is only disabled for 0.6 seconds and key repetition is not covered. Only normal key strokes will disable trackpad tapping. To continously disable the tapping you need constant typing. Pressing one single key for a while is not the same. The best way to test this feature is to type constantly on the keyboard while trying to activate another window with a tap on the trackpad. This should not be possible. But keep in mind: 0.6 seconds are really short so don't type too slowly :-). In the main release this time value has been increades to 0,8 seconds. Best Regrads Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Patch for pbbuttonsd 0.6.8 improved trackpad control
On Wed, 30 Mar 2005 13:29:42 +0200 Colin Leroy <[EMAIL PROTECTED]> wrote: > On 30 Mar 2005 at 12h03, Matthias Grimm wrote: > > Hi, > > > The tapping is only disabled for 0.6 seconds and key repetition is > > not covered. Only normal key strokes will disable trackpad tapping. > > To continously disable the tapping you need constant typing. Pressing > > one single key for a while is not the same. > > In mouseemu i (think to remember) used key _press_ to disable trackpad > until key _release_ + delta. So that handles either constant typing or > constant press. Maybe you can do like that too? I created a patch based on the last release 0.6.8 that disables the trackpad also if the key is hold (repeat). Furtheron the trackpad is disabled now as soon the first key is pressed. In the current release the trackpad is disabled with the first key release for technical reasons. This technical reasons makes is necessary to restructure the trackpad code a bit. The trackpad will be reconfigured as soon as someone requests. In the past pbbuttonsd waited the ADB bus to be inactive before programming the trackpad. For the keyboard it is necessary to wait for the ADB bus but I haven't discovered any side effects with the trackpad yet. Please report any problems and send a notice too when you have no problems at all :-) Best Regards trackpad.patch Description: Binary data
Re: some way to start gtkbuttons at X startup
On Thu, 21 Apr 2005 01:04:15 +0300 Eddy Petrisor <[EMAIL PROTECTED]> wrote: > Is there a way to start automatically gtkbuttons at X startup? > I am really annoyed of the fact that I saw the equivalent in kde 3.4 > (kubuntu) made by default (although i don't know if it was at X > startup > or just user login) and I have been thinking about it. I think the only way to get rid of the KDE brightness popup it to deinstall the laptop-tools package, except that there are new options in KDE 3.4 I don't know about. The easiest way to get gtkpbbuttons startet after login is to compile it with gnome session management (this should also work with KDE). Then it will connect to a session manager and after saving the current session it should always reapear after login. If gtkpbbuttons was compiled without support for session management, create a KDE link to gtkpbbuttons in your autostart directory. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: some way to start gtkbuttons at X startup
On Fri, 22 Apr 2005 10:01:57 +0300 Eddy Petrisor <[EMAIL PROTECTED]> wrote: > > > > > Is there a way to start automatically gtkbuttons at X startup? > > my request was ^ > to _start_ gtkbuttons when X or gdm starts. GtkPBButtons is designed to start as normal user and should be used in that way. If you run it as root you need to weaken X's security mechanisms to allow root to open the popups on user's screen. My X11 configuration doesn't allow this by default. I don't know if multiple users use the machine you talked about or if you are the only one, but a second point is that each user might want to configure GtkPBButtons for his or her own needs. > now we are getting somewhere... > how do I "compile it with gnome session management" ? > This would be nice enough. ./configure --with-gnome > Still, is there a way to have gtkbuttons _before_anybody_ logs in? I haven't used it that way yet, but there are enough hints in the mailinglist so you should get it it work. You need to authorize root to open windows on every users display. Please ask a X11 expert how to do this. I always give temporarely permission with the xhost command when needed. > > Then it will connect to a session manager and after saving the current > > session it should always reapear after login. > > Again the question: now do I compile it with session management? > Do I have to fiddle with the source? Will gtkbuttons need a patch? see above, No patch needed. You need the development files of libgnomeui and releated. Best regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: syncing palm T5 on deb ppc
On Sun, 24 Apr 2005 11:55:26 -0700 Adam Done <[EMAIL PROTECTED]> wrote: > I have been looking to sync my palm T5 with mol but using udev and > hotplug, I can't get the dev to show up. By > reading /usr/src/linux/Documentation/usb/usb-serial.txt and learning > that I need a device /dev/ttyUSB0 but udev does not create one. I am Hi, The first thing you need is the visor kernel module. You will find it under USB Serial Converter/Handspring visor. Compile it as a module. This kernel module will provide the /dev/ttyUSBx devices and udev creates them without changes after the module is loaded. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd eats my cpu
On Fri, 13 May 2005 10:25:55 +0200 Johannes Berg <[EMAIL PROTECTED]> wrote: > > On 2.16.12-rc2 pbbuttonsd also usually consumes 96-99% of my CPU, > > according to top. > > > I've recently also seen this on 2.6.12-rc1, but *only* if I boot to > single mode and then enter runlevel 2, not if I go straight to runlevel > 2. Apparently it loops not finding some device (from strace). Could you sent me the strace logs? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12-rc4 lots faster than any kernel before?
On Sun, 15 May 2005 13:07:58 +0200 Wolfgang Pfeiffer <[EMAIL PROTECTED]> wrote: Hi, > > >>Am I the only who got impressed? After all this cheering I wanted to see it with my own eyes. So I installed 2.6.12-rc4 last night. What should I say: My machine behaves as slow as before. I can't see any improvement in speed. On the other hand all my hardware seems to run out of the box including ALSA and sleep. Ok, on a G3 Pismo sleep haven't been a problem since ages ;-) > But as I said: I have problems with ALSA (no sound so far) and with > pbbuttonsd: I enabled userspace Power Management in the .config, and > I'm not sure yet why the speed on the machine (Titanium IV, 867 MHz) > is set to ~665 MHz after booting the machine. Dynamic CPU frequency scaling should only be done by the kernel itself. Pbbuttons changes the CPU speed if the power profile changes only and the external script 'cpufreq' must be active for this to work. So please check if you have a link in /etc/power/event.d called 'cpufreq' linked to /etc/power/scripts.d/cpufreq. Because my PowerBook doesn't support frequency scaling, I never tested this script sufficiently. I would apprecieate your feedback if you got it work. Another interresting fact: Up to now I haven't got high cpu loads (100%) with pbuttonsd and kernel 2.6.12 as reported multiple times on this list. Maybe it has something to do with hardware components I don't have. The solution of Elimar Riesebieter might be evidence for that Any hints are welcome. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Battery charge cycles
On Wed, 18 May 2005 13:50:53 + (UTC) Joerg Sommer <[EMAIL PROTECTED]> wrote: > Hi, > > I saw OS X can show the count of charge cycles. Can we have this in Linux > too? Pbbuttond does this if enabled. See option batlog. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Battery charge cycles
On Wed, 18 May 2005 22:32:49 + (UTC) Joerg Sommer <[EMAIL PROTECTED]> wrote: > Matthias Grimm <[EMAIL PROTECTED]> wrote: > > On Wed, 18 May 2005 13:50:53 + (UTC) > > Joerg Sommer <[EMAIL PROTECTED]> wrote: > > > >> Hi, > >> > >> I saw OS X can show the count of charge cycles. Can we have this in Linux > >> too? > > > > Pbbuttond does this if enabled. See option batlog. > > I thought pbbuttonsd counts the cycles itself. Can pbbuttons tell me the > count of charging cycles now after a year? Yes, pbbuttonsd counts the cycles by itself and no, except you have told pbbuttonsd one year ago to count the cycles. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: stepping down ibook g3
On Thu, 19 May 2005 14:08:07 +0200 Moritz Lutz <[EMAIL PROTECTED]> wrote: > Yes i know that i can use the F keys but they dont work look at my > configure i take the showkey -m to get the number for the key and put > them in the config but the dont work if i press the f1 key to dim the > screen nothing hapens According your configuration you have to press Fn+F1 to change display brighhtness. If you don't like this behaviour change the option kbdmode to fkeyslast. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: stepping down ibook g3
On Thu, 19 May 2005 14:08:07 +0200 Moritz Lutz <[EMAIL PROTECTED]> wrote: > Yes i know that i can use the F keys but they dont work look at my > configure i take the showkey -m to get the number for the key and put > them in the config but the dont work if i press the f1 key to dim the > screen nothing hapens Please get the keycodes with showkey -s. You need the scancodes, not the codes from an unknown keymap. Best Regards Matthas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd eats my cpu
On Thu, 19 May 2005 00:01:54 +0200 Johannes Berg <[EMAIL PROTECTED]> wrote: Hi, > Just happened again by reloading the usbhid module. I uploaded a beta version to http://pbbuttons.sourceforge.net. Please check if you still have this problem with the beta. I changed event device handling and read now not only keyboards but also mice direct from the event devices. But this has a strange side effect on my machine: The tip from the trackpad work with delay. The trackpad is configured as 'drag' but when I tip to the trackpad, no mouse button event is sent. When I then move the mouse (trackpad) again, the mouse button event will be emitted. I observed this behaviour only with the tip on the trackpad. The mouse button reacts instantly. If pbbuttonsd is not running everything works as usual. I will really appreciate any hint in this case. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd eats my cpu
On Thu, 19 May 2005 00:01:54 +0200 Johannes Berg <[EMAIL PROTECTED]> wrote: The trackpad tapping problem is related to the NoTapTyping mechanism and the event handling reorganisation. The mousebutton is now handled as keycode, but keycodes switch 'tapping' off. This seems to be a tail hunting cat ... tricky ... see what we can do on this ... Thanks for listening :-) Nevertheless I would like to see the beta version tested a lot :-) Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: keyboard backlight working on PowerBook5,6?
On Tue, 31 May 2005 21:32:35 -0400 Barry Hawkins <[EMAIL PROTECTED]> wrote: Hi, first for the files: You have an 1.67GHz PowerBook G4 and keyboard illumination wont work You had an 15" 1.25GHz PowerBook G4 with working keyboard light. The code in pbbuttonsd controlling the keyboard illumination is rather old and might be outdated. I have only an G3 Powerbook at hand so that I can't do any tests myself. Lets analyze the environment on your machine: 1. Are appropriate I2C modules loaded? According what I have read here I would say: Yes. 2. Do all needed devices exist? /dev/i2c-0 ... i2c-n? Check this even if you used udev or devfs. So lets analyze if the code in pbbuttonsd should still work or if it needs some refreshment. 1. Pbbuttonsd uses it's own i2c-dev.h and don't use the kernel version. This is so because as I built in keyboard light support, I2C was at its beginning and the kernel files prevent pbbuttonsd from compiling. Most of the I2C programs uses this include file that is still part of the pbbuttonsd source. - New kernel versions might have problems with this old file? - Could you exchange it with the current kernel files and try it again? What happend? 2. Pbbuttonsd looks for the I2C Device 0x42, which is not defined in the new kernel include files: ioctl (fd, I2C_SLAVE, 0x42) - Did the address change in new kernel versions? Don't know how to check this. 3. If the above ioctl call was successful, four bytes would be read from the device. If we receive exactly four bytes, the device is identified. This worked in the past. - Maybe the driver or device behaviour changed and we get more or less than four bytes now? You see, if we can't find a simple configuration error it could become very hard. As I already told you I can't do any tests on this issue myself because I don't have the right hardware. So it would be nice if someone of you with some programming skills could do the research. I will assist as good as I can. The other way would be you send me your machine and I will do it. :-) Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ibook g4 battery status/blankscreen problems
On Sun, 05 Jun 2005 15:58:54 +0200 "[ATR]Dj-Death" <[EMAIL PROTECTED]> wrote: > I'm running 2.6.12-rc4 kernel on my ibook G4. It works quite fine but I > have still some little bug. Since I'm using 2.6.12-rc4, when I close the > lid with AC connected, the screen becomes blank, then I open the lid but > the screen keeps blank, I need to press fn+F1 fn+F2 to blank out the > screen. Which powermanagement daemon do you use? Pbbuttonsd had a bug that causes the behaviour you describe in. This should be fixed if you update to a up-to-date version. > Then when booting my ibook without battery, the kernel seems to believe > the battery is connected but not AC, so cpufreqd scale down the CPU > frequency, and harddrive automaticly stops after 10seconds of > inactivity. To fix it I need to put the battery in and disconnect AC > power, then I can reconnect AC and remove the battery everything works > fine. I always had this problem since earliest sleep patch (2.6.9). That is a problem with the Apple hardware and a kernel bug that can't cope with it. The power source is only recognized if PMU interrupts are coming and those interrupts will only be received if at least on battery is plugged in. If you boot your machine without battery, the kernel never check the power source and all depending programs will fail. I reported this bug roundabout two years ago but it is still present in recent kernel versions. I think because new Powerbooks have a built in battery which can't be removed, this problem is realized only by a few people. If you weren't a passionated kernel hacker and able to fix this problem by yourself, I think this bug would stay forever. On the other hand there are more serious bugs to fix, whatever... Best regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ibook g4 battery status/blankscreen problems
On Tue, 07 Jun 2005 00:24:11 -0400 Eric Pineault <[EMAIL PROTECTED]> wrote: Hi, > I've also got this bug on two version of the Ibook, ie on revision 1.1 > and revision 1.2 (just installed ubuntu on a new Ibook). Did all the > other fixing and bug still around. Same question to you: When you press fn+F1 after the screen stayed dark, how does the machine react? Does the brightness starts from low level or jumped it right back to the brightness it had before you closed the lid? How are your programming skills? Could you recompile pbbuttonsd from the source package with debugging enabled? If so I would like to send you a debugging configuration that possible give us some hints. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd script interface - future?
Am Donnerstag, 27. Mai 2004 20:26 schrieb Guido Guenther: > > I think this script system will be part of pbbuttonsd 0.6.0. It then has > > a chance to prove itself under real conditions. > > It'd be great to have 0.6.X in debian soon, to have this tested by a > broader audience and to split out the necessary things into > powermgmt-base. Jan, any chances we see this soon, maybe in experimental? Hi, I think so. I have just published pbbuttonsd 0.6.1, which only contains bugfixes to the script system and pbbuttonsd itself, no new features. I think this version could be stable for a while so I discussed with Jan to build official debian packages as soon as possible, solve all distribution related problems and try to push pbbuttonsd into the testing branch. I hope this will be possible. From my side I slow down development now so that this process has enough time and won't be disturbed by new releases. I think this is possible because the last big bug on the list has been fixed recently and my todo list is nearly empty for now. Best Regards Matthias
Re: PBButtonsd gatwick IRQ
Am Freitag, 28. Mai 2004 02:56 schrieb Zach Weinberg:
> Also, When my computer is not plugged into AC it goes into sleep at the
> time given in /etc/pbbuttonsd.conf even while im worknig on it. This
> problem is unrelated, but if anyone could help with either of these, I
> would extremely grateful.
Hi,
I assume you use the internal keyboard and not an external one?
Do you have the event devices installed? Please use the attached
program cev (compile with gcc -Wall -o cev cev.c). It will scan the
event devices and displays what it has found. Please check if there
is any keyboard in the list.
If anything is all right till this point please replace the attached include
file 'debug.h' with that one in your pbbuttonsd source tree and compile
with --enable-debug. Start pbbuttonsd in a console (not as daemon) and watch
the additional debug output. It shows the keycodes pbbuttonsd receives. Type
a few keys and see if the keycode value changes.
Tell me your results
Best Regards
Matthias
#include
#include
#include
#include
#include
#include
#define BITS_PER_LONG (sizeof(long) * 8)
#define NBITS(x) x)-1)/BITS_PER_LONG)+1)
#define OFF(x) ((x)%BITS_PER_LONG)
#define LONG(x) ((x)/BITS_PER_LONG)
#define test_bit(bit, array) ((array[LONG(bit)] >> OFF(bit)) & 1)
char *events[EV_MAX + 1] = {"Reset", "Key", "Relative", "Absolute",
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
NULL, NULL, "LED", "Sound", NULL, "Repeat", "ForceFeedback", NULL,
"ForceFeedbackStatus"};
int main(int argc, const char **argv)
{
int eventfd = -1;
struct input_event inp;
short ids[4];
char filename[20];
char name[256];
unsigned long bit[EV_MAX][NBITS(KEY_MAX)];
int rep=0;
int i, j;
for (i = 0; i < 33; i++) {
sprintf(filename, "/dev/input/event%d", i);
if (i == 32)
eventfd = open("/dev/input/mice", O_RDONLY);
else
eventfd = open(filename, O_RDONLY);
if (eventfd >= 0) {
ioctl(eventfd, EVIOCGID, ids);
printf("[%x] ids - %x %x %x %x", i, ids[0], ids[1], ids[2], ids[3]);
ioctl(eventfd, EVIOCGNAME(sizeof(name)), name);
printf(" Name: %s\n", name);
ioctl(eventfd, EVIOCGBIT(0, EV_MAX), bit[0]);
printf(" Supported Events:\n ");
for(j=0; j < EV_MAX; j++)
if (test_bit(j, bit[0]))
printf("%d (%s) ", j, events[j] ? events[j] : "?");
printf("\n");
close(eventfd);
eventfd = -1;
} else {
fprintf(stderr, "[%x] nil\n", i);
}
}
eventfd = open("/dev/input/event0", O_RDONLY);
while (read(eventfd, &inp, sizeof(inp))) {
if (rep != ((inp.value << 8) + inp.code)) {
rep = (inp.value << 8) + inp.code;
printf("\tEvent: type=0x%02x (%d) code=0x%02x (%d) value=0x%02x (%d)\n",
inp.type, inp.type, inp.code, inp.code, inp.value, inp.value);
}
}
close(eventfd);
return 0;
}
#ifndef INCLUDE_DEBUG_H
#define INCLUDE_DEBUG_H
/* ----
* debug.h
* definitions for debugging. This file describes in detail which debug
* information should be printed to console. The symbol DEBUG must also
* be defined. It is the master key for all of this options.
*
* Copyright 2002 Matthias Grimm
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
* */
/* module_powersave.c */
#define SLEEPLOCKS0 /* =1 for printing sleeplock status to console */
/* module_pmac.c */
#define PMUINTR 0 /* =1 for printing PMU interrupts to console */
#define SIMUAMBIENT 0 /* =1 for simulating ambient light sensor */
#define TESTAMBIENT 0 /* =1 for printing some ambient values to console */
/* module_peep.c */
#define PEEP_IPC 0 /* =1, all tags sent to clients will be printed */
#define PEEP_CONFIG 1 /* =1, all configure tags will be printed */
#define PEEP_QUERY0 /* =1, all query tags will be printed */
#define PEEP_SECURE 0 /* =1, all security tags will be printed */
#define PEEP_KEYBOARD 1 /* =1, keyboard events are printed */
#define PEEP_MOUSE0 /* =1, mouse events are printed */
#define PEEP_TIMER0 /* =1, timer events are printed */
#define PEEP_NOCYCLIC 1 /* =1, some cyclic tags will be filtered out */
#endif/* INCLUDE_MODULE_CDROM_H */
Re: PBButtonsd gatwick IRQ
Am Freitag, 28. Mai 2004 20:34 schrieb Zach Weinberg: > ANd as a sidenote, after running cev before uninstalling pbbutonsd, the > list consists of multipile entries of, literally, "nil" cev is an easy event device scanner with no highly developes interface. I just wanted to know what event devices are existing on my system and how they identify themselves. Linux support 32 event devices (kernel 2.4), but normally you only use three or four of them. All unused or not existing devices will be printed as 'nil'. Unless there are one or more entries in the list everything is ok. cev will work either with pbbuttonsd installed or not. Both programs will open the event devices only for reading so none of them will block the other. If you are in doubt about the output please send it to me and I will try to explain it. Best Regards Matthias
Re: pmud & pbbuttonsd confilct in sarge-testing ?
Am Sonntag, 4. Juli 2004 06:23 schrieb Sean Schertell: > I think pbuttonsd obsoletes pmud -- because it also provides power mgmt > including sleep/wake, etc. Thats correct. In fact if pbbuttonsd is forced to work in cooperative mode (which is still possible but not recommended) pbbuttonsd take only limited control over the powermanagement functions because pmud doesn't care about other programs which may do a better job. In this case pbbuttonsd step back to keep systems stability. A lot of nice functions have to disabled by pbbuttonsd because pmud beside others claims the cover control and power emergency control. Pbbuttonsd in the meantime does all pmud do and a lot more so please don't cripple pbbuttonsd functionallity by forcing it into cooperative mode with pmud. Best Regards > There's another little gui program you'll want to download to simplify > setting up your power mgmt prefs with pbbuttonsd but I can't remember what > it's called. PowerPrefs. Best Regards Matthias
Re: Power management
Am Montag, 5. Juli 2004 12:01 schrieb Adrian Lester: > My problem now is merely that I can not get the thing to standby or suspend > in the way I would expect on an x86 laptop, I have installed apm but cannot > seem to call it in a way which succeeds. Searching the internet is has not > proved particularly informative. APM does not work on Powerbook or iBooks because Apple doesn't support APM. APM is a x86-only thing. To make powermanagement working on an Apple Laptop you need pbbuttonsd (and maybe the related packages gtkpbbuttons and powerprefs). You might want to switch on Kernel's APM emulation to make some APM monitors for ex. Batterymonitors) working. But you can't suspend your machine through this interface. Best Regards Matthias
