Joachim Breitner

gaim-thinklight → pidgin-blinklight

Published 2007-05-15 in sections English, Digital World.

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

Do you think you could extend it to use the "standard" Numpad/CapsLock leds? Some other IM software such as Miranda have a plugin that does this.
#1 Dedalus (Homepage) am 2007-05-15
It should be possible, of course, but I’m not personally interested in that. Therefore: Patches welcome :-)

(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.
#2 Joachim Breitner (Homepage) am 2007-05-16
This reminds me of my ITP on gaim-rhythmbox, thanks!
#3 Jon (Homepage) am 2007-05-16
When I enable the plugin, pidgin just crashed. Any idea?
#4 hutu am 2007-05-24
What distribution are you on? Can you provide a stack trace or similar?
#5 Joachim Breitner (Homepage) am 2007-05-24
I get the same crash:

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.)
#6 Chad Harp am 2007-11-15
Do you use a pidgin-blinklight RPM package from OpenSuse or elsewhere, or did you compile it yourself?



I’d like to help, but I can’t until I know how to reproduce the problem, sorry.
#7 Joachim Breitner (Homepage) am 2007-11-15
I complied from source (0.9-1).



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:
#8 Chad Harp am 2007-11-15
Uh, it seems that the plugin is loaded twice. Could that be possible? Can you check if you have two copies of the .so file lying around, maybe both in your home directory and in the system wide directory?
#9 Joachim Breitner (Homepage) am 2007-11-15
I get a crash as well. The crash happens immediately when I check the box in the plugins dialog. I'm running Ubuntu Feisty with a self-compiled Pidgin 2.0.0.



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.
#10 Phil (Homepage) am 2007-05-25
Did you compile piding-blinklight yourself as well? Did it use the right header files ?
#11 Joachim Breitner (Homepage) am 2007-05-27
Hello,



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.
#12 Nicolas am 2007-10-22
Sorry,as I don’t have a Asus laptop myself, I can only rely on what people tell me.



Do you have the file /proc/acpi/asus/mled? Can you switch the LED on and off using that file?
#13 Joachim Breitner (Homepage) am 2007-10-22
I understood that you don't have a Asus laptop while reading you ;) that's just why I proposed my help ...



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
#14 Nicolas am 2007-10-23
Ok, then the problem is not with pidgin-thinklight, I think: I was told that that file controls the LED, and it probably does for some models.



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?
#15 Joachim Breitner (Homepage) am 2007-10-23
Ok, the files don't do nothing. I think I may have a problem as I see this :



# 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 :)
#16 Nicolas am 2007-10-23
Hi,



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
#17 Nicolas am 2007-10-29
Hi all,



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
#18 Nicolas am 2007-11-03
Hi 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?
#19 Joachim Breitner (Homepage) am 2007-11-04
Hi Joachim,



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
#20 Nicolas am 2007-11-05
That phone LED thingy sounds doable. I just wander how to detect what file to use: Should the code try all of them or only the first writable file?



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?
#21 Joachim Breitner (Homepage) am 2007-11-05
It's only root writable and as that tree is created by the module ...



-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.
#22 Nicolas am 2007-11-06
on ASUS A6JC (asus_laptop lkm) mail led is accessible via

/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.
#23 revel am 2008-01-21
So besides the IBM file, pidgin-blinklight should try these files, right:



/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...
#24 Joachim Breitner (Homepage) am 2008-01-21
When compiling the plugin it would crash on me as well. To fix it I compared to the .deb and found that ./src/blinklight-fixperm must be copied to /usr/lib/pidgin-blinklight
#25 Hunter Haugen am 2008-01-14
Yes, that is true; the autoconfig files don’t install that file, I didn’t feel like fighting with autoconfig :-)



I’ll gladly accept a patch that fixes this problem!
#26 Joachim Breitner (Homepage) am 2008-01-14
I'm having trouble w/ this on Slackware 12.1.



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.
#27 Ben am 2008-07-03
Hi,



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!
#28 Joachim Breitner (Homepage) am 2008-07-04
Hi,

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.
#29 ang am 2008-07-30
Hi ang,



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.
#30 Joachim Breitner (Homepage) am 2008-07-30
Hi Joachim,

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.
#31 Ang am 2008-07-31
When I activate the plugin on Pidgin 2.5.5, the following error occurs directly after the X error:



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?
#32 Schmatzler (Homepage) am 2009-03-06
Hi. Haven’t heard of this before. What’s your distribution?
#33 Joachim Breitner (Homepage) am 2009-03-11

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.