Joachim Breitner's Homepage
gaim-thinklight → pidgin-blinklight
I once wrote a plugin gaim called gaim-thinklight, which simply blinks your ThinkPad’s ThinkLight when you get a new messge. Very recently, gaim was renamed to pidgin, so gaim-thinklight is now called pidgin-blinklight. I changed the second part not because of trademark issues (as gaim did, IIUC), but because it also supports ASUS laptops since the last version. At least I hope so, I implemented that, as I do not have an ASUS laptop – please tell me if it does or does not work.
If you run Debian unstable, you’ll soon be able to apt-get install pidgin-blinklight
. Others can find the sources on the debian package page. I’m still too lazy to host that code somewhere else as well...
Comments
(The patches should make it optional, of course)
I also like the way that gaim-thinklight just works without a need for configuration, and I’d like to keep it that way.
opensusue 10.3
The program 'pidgin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadCursor (invalid Cursor parameter)'.
(Details: serial 12423 error_code 6 request_code 95 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
The program 'pidgin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
(Details: serial 12714 error_code 9 request_code 62 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
I’d like to help, but I can’t until I know how to reproduce the problem, sorry.
configure
make
sudo make install
Other details that may help:
Pidgin 2.1.1 (from opensuse rpm)
I enabled all of th(13:59:42) pidgin-blinklight: chose file /proc/acpi/ibm/light.
(13:59:42) pidgin-blinklight: pidgin-blinklight has loaded
(13:59:42) pidgin-blinklight: chose file /proc/acpi/ibm/light.
(13:59:42) pidgin-blinklight: pidgin-blinklight has loaded
(13:59:42) prefs: /pidgin/plugins/loaded changed, scheduling save.
(13:59:42) prefs: /pidgin/plugins/loaded changed, scheduling save.
e dubug messages, here's the output just before the crash:
If you contact me via email, I could get you a stacktrace; I'm not sure how to do that off the top of my head.
My laptop is a Asus A7T and I'm running Gutsy for 3 days now.
With this version I read that blinklight now deals with Asus light ... that doesn't with my machine :(
It should not be a real issue 'cause I can manage the light through the gnome light applet.
Do you have any idea or test to make me run so I get you the result ?
Thanks in advance.
Nico.
Do you have the file /proc/acpi/asus/mled? Can you switch the LED on and off using that file?
cat /proc/acpi/asus/mled returns 0
echo 1 > /proc/acpi/asus/mled gives no change except that cat /proc/acpi/asus/mled now returns 1 :(
I don't know if this helps but:
ls /proc/acpi/asus/ gives
brn disp info lcd mled wled
I suggest you find out what’s wrong there (wrong version of the asus acpi kernel module maybe?). If your laptop has a different way of controlling the LED, I can implement that as well, of course.
Have you tried the wled file?
# cat /proc/acpi/asus/info
Asus Laptop ACPI Extras Driver 0.30
Model reference : M2E
SFUN value : 0xa0ae7
DSDT length : 28339
DSDT checksum : 165
DSDT revision : 1
OEM id : A0463
OEM table id : A0463000
OEM revision : 0x0
ASL comp vendor id : INTL
ASL comp revision : 0x20051117
I do have a M2E motherboard but it's in my desktop computer. The ID under my laptop says :
MB Ver: A7TC which probably means my acpi module is not the one needed to control my MB.
The strange thing is I'm able to control my screen light by the gnome power manager applet ( http://www.gnome.org/projects/gnome-power-manager/ ). I'll glance around and tell you what I've found. Thank for your time :)
sorry for being late, I wrote a note telling I'm looking into this direction :
#cat /proc/acpi/asus/info
Asus Laptop ACPI Extras Driver 0.30
Model reference : M2E
SFUN value : 0xa0ae7
DSDT length : 28339
DSDT checksum : 165
DSDT revision : 1
OEM id : A0463
OEM table id : A0463000
OEM revision : 0x0
ASL comp vendor id : INTL
ASL comp revision : 0x20051117
say my Mobo is asus M2E but it's A7Tc.
Whereas my screen light is perfectly controlled by gnome-brightness-applet (???), there is no response with mled or wled ...
From what I remember, the mled is for new mail and wled for wifi activation ... I'm still searching for information about acpi for my Mobo.
Coming back ;)
Bye
This is what I've found. There's a project name *asus_acpi* that is _included in the kernel_ since 2.4.22 and 2.5.73.
So as you load the asus_acpi module, you get a message via dmesg:
[ 3593.098812] Asus Laptop ACPI Extras version 0.30
[ 3593.099799] unsupported model A7T, trying default values
[ 3593.099803] send /proc/acpi/dsdt to the developers (what I did ;) )
By downloading the sources, I read in the doc that light can be controlled by the directory :
/sys/class/backlight/asus that contains:
-r--r--r-- 1 root root 0 2007-11-03 14:36 actual_brightness
-rw-r--r-- 1 root root 0 2007-11-03 11:20 *brightness*
-r--r--r-- 1 root root 4096 2007-11-03 11:19 max_brightness
-rw-r--r-- 1 root root 4096 2007-11-03 14:34 power
lrwxrwxrwx 1 root root 0 2007-11-03 11:19 subsystem -> ../../../class/backlight
--w------- 1 root root 4096 2007-11-03 11:19 uevent
_max_brightness_ contains 15 and you are able to control backlight by "echo" to the *brightness* file a value beetween 0 and 15 (that immediately set the intensity of the backlight).
Hope this can help ;)
Thanks for your time,
Nico
thanks for the investigation. I notice that you are talking about blinking the backlight of your display − I haven’t considered that. Currently, pidgin-blinklight blinks various LEDs. Are you sure that using the mled to blink the “New Mail“ LED does not work for you?
I'm sure that this can't help as my /proc/acpi only shows :
dr-xr-xr-x 3 root root 0 2007-11-05 10:36 ac_adapter
-rw-r--r-- 1 root root 0 2007-11-05 10:36 alarm
dr-xr-xr-x 3 root root 0 2007-11-05 10:36 battery
dr-xr-xr-x 5 root root 0 2007-11-05 10:36 button
-r-------- 1 root root 0 2007-11-05 10:36 dsdt
dr-xr-xr-x 3 root root 0 2007-11-05 10:36 embedded_controller
-r-------- 1 root root 0 2007-11-05 10:14 event
-r-------- 1 root root 0 2007-11-05 10:36 fadt
dr-xr-xr-x 2 root root 0 2007-11-05 10:36 fan
-r--r--r-- 1 root root 0 2007-11-05 10:36 info
dr-xr-xr-x 2 root root 0 2007-11-05 10:36 power_resource
dr-xr-xr-x 4 root root 0 2007-11-05 10:36 processor
-rw-r--r-- 1 root root 0 2007-11-05 10:36 sleep
dr-xr-xr-x 3 root root 0 2007-11-05 10:36 thermal_zone
dr-xr-xr-x 3 root root 0 2007-11-05 10:36 video
-rw-r--r-- 1 root root 0 2007-11-05 10:36 wakeup
BUT ... I have been investigating a little more since and I've discovered that asus_acpi module is now named asus-laptop but the acpi service still loads asus_acpi (because it's in the kernel/drivers/acpi directory whereas asus-laptop is in kernel/drivers/misc).
Solution: add the line 'blacklist asus_acpi' in /etc/modprobe.d/blacklist (without the quotes) and add the line 'asus-laptop' in /etc/modules (without the quotes).
I'm that precise so that it can help anyone reading the thread ;)
Then my laptop is now recognised when loading the module:
[ 47.335989] asus-laptop: Asus Laptop Support version 0.42
[ 47.336649] asus-laptop: A7T model detected
[ 47.357433] Registered led device: asus:phone
Which means I have access to the phone led (56k modem I guess) by this way :
echo 1 > /sys/class/leds/asus\:phone/brightness
echo 0 > /sys/class/leds/asus\:phone/brightness
This is the only led I know to be reachable by now ... hope this help ;)
Do you think you could propose as an option of your plugin the backlight trick ?
Thanks in advance,
Nicolas
I’d like to avoid making this a user-configuration: It’s something the use should not worry about.
Can you check the default permissions of /sys/class/leds/asus\:phone/brightness − can only root write it by default, or all users?
-rw-r--r-- 1 root root 4096 2007-11-06 15:33 brightness
lrwxrwxrwx 1 root root 0 2007-11-06 14:57 subsystem -> ../../../class/leds
-rw-r--r-- 1 root root 4096 2007-11-06 15:33 trigger
--w------- 1 root root 4096 2007-11-06 14:57 uevent
So I guess it won't be usable easily ...
I agree with you about the no-setup attitude ;) so I guess I will do it myself once I'll have a little more time ...
Thank a lot for your time and if you need any more information I can provide, don't hesitate.
/sys/class/leds/asus:mail/brightness (value 0 or 1)
or /sys/devices/virtual/leds/asus:mail/brightness
(the former is a symlink to the latter)
default permissions: root-only writable
I changed and recompiled source code and it works well.
/sys/class/leds/asus:mail/brightness, /sys/class/leds/asus\:phone/brightness
Maybe thinkpad_acpi comes with support for the new led scheme soon, then I can write configure pidgin-blinklight to use any LED it finds...
I’ll gladly accept a patch that fixes this problem!
I ran ./configure && make && make install.
I even moved blinklight-fixperm to /usr/lib.
When I try to start Pidgin I see:
pidgin: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.pidgin: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
As root, I can start Pidgin, but selecting the plugin causes a crash.
After 'make uninstall' it works fine again. It worked fine in Slackware 11.0 and 12.0, not sure why it doesn't like 12.1.
sorry, but I haven’t seen this error yet myself, and I have no idea what might cause this, so I’m unable to help. But if you find out, let me know!
I have a trouble with pidgin-blinklight too. My system is : IBM/Lenovo Thinkpad T61, os OpenSuse 11 and I'm using KDE 3.5.9 with last security update and pidgin version 2.4.1 (installed via classic rpm package)
All "extra" notebooks keys on my notebook work fine include enable/disable light.
bash commad
echo off >/proc/acpi/ibm/light
echo on >/proc/acpi/ibm/light
works fine too, but only if I'm root user. It is because files permission are set for root.root. I'm not sure if it is ok for pidgin-blinklight.
Then I installed last version of pidgin-blinklight via sourcode a manually compile (./configure, make and make install without any errors or warnings)
but every time when I run pidgin and try enable pidgin-blinklight program crash with this error:
The program 'pidgin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadCursor (invalid Cursor parameter)'.
(Details: serial 29811 error_code 6 request_code 95 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
mcaj@LittleMao:~> The program 'pidgin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadIDChoice (invalid resource ID chosen for this connection)'.
(Details: serial 30090 error_code 14 request_code 53 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Thank you for any help.
thanks for the report. If you manually compiled pidgin blinklight, you might have missed the blinklight-fixperm program that manges the permissions.
I can not help you with the X error, as I have never seen it myself, but others indeed have.
In any case, you might want to contact Don Vosburg < don@vosburgs.org>, it seems that he has made rpms for OpenSuse.
I will try contact Mr.Don Vosburg.
Maybe he knows about this trouble with X window error.
If I fix this trouble I will send you a short info about this.
Ang.
pidgin: xcb_io.c:182: process_responses: Zusicherung »((int) (((dpy->last_request_read)) - ((dpy->request))) <= 0)« nicht erfüllt.
Do you have any idea how to get rid of this? The fixperm-script lies in /usr/local/libexec, all other plugin-files in /usr/local/lib/purple-2. Is it correct to put the script there?
Have something to say? You can post a comment by sending an e-Mail to me at <mail@joachim-breitner.de>, and I will include it here.