2009/12/22 Jakub Adam <[email protected]>: > Subject: xul-ext-traybiff: mail LED notification does not work on Asus > laptops > Package: xul-ext-traybiff > Version: 1.2.3-7 > Severity: normal > Tags: patch > > This plugin is able to autodetect LEDs present on some laptops and use them > for notifications on new mail > arrival (in addition to icon in system panel). Unfortunately this > functionality will not work on > Asus laptops, because the position of special file used to control the LED > state changed. > Following little patch can be used to fix the issue: > > --- traybiff-1.2.3/components/nsMessengerFreeDesktopIntegration.cpp > 2007-05-19 10:01:55.000000000 +0200 > +++ nsMessengerFreeDesktopIntegration.cpp 2009-12-22 > 00:29:35.000000000 +0100 > @@ -93,6 +93,8 @@ > const char* HW_INDICATOR_CONTROL_FILENAMES[] = { > // ASUS laptop led on Linux > "/proc/acpi/asus/mled", > + // ASUS laptop led on Linux, newer interface > + "/sys/class/leds/asus::mail/brightness", > // ACER New Mail led on Linux > "/proc/driver/acerhk/led" > };
Thanks for the patch - I don't have one of these laptops myself, so I'm reliant on users for bug reports about things like this. I'll make sure it gets included in the next upload. > Also, to work properly, file /sys/class/leds/asus::mail/brightness must be > writable by regular users. > Permissions must be changed after every boot and this can be done by > following init script I don't think an init script is the right way (tm) to fix this. The general opinion on #debian-devel seems to be that a setuid helper would be the 'quick fix' although a longer term fix would be to expose a stable, clean interface via a character device in /dev, which could then be granted write access to users via udev. I don't have time right now to do this (and holding off/waiting probably helps get the interface design right too), but I'll try and take a look at it later on. Alan -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
