Welcome to
Joachim Breitner's Homepage

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.

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.

This reminds me of my ITP on gaim-rhythmbox, thanks!

When I enable the plugin, pidgin just crashed. Any idea?

What distribution are you on? Can you provide a stack trace or similar?

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.)

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.

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:

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?

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.

Did you compile piding-blinklight yourself as well? Did it use the right header files ?

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.

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?

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

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?

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 :)

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

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

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?

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

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?

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.

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.

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...

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

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!

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.

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!

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.

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.

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.

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?

Hi. Haven’t heard of this before. What’s your distribution?