Touchpad LED on Dell's laptop is not working

[AceLan Kao]

In some of Dell laptops, they support a touchpad LED to indicate the enablement/disablement of the touchpad.
And kernel(after 3.2) supports an interface to turn on/off the LED, user space app should take the responsibility to handle this,
and I think gnome-settings-daemon is the best one.

The interface is in /sys
To turn on the LED
    echo 1 > /sys/class/leds/dell-laptop::touchpad/brightness
To turn it off
    echo 0 > /sys/class/leds/dell-laptop::touchpad/brightness

[AceLan Kao (acelankao)]

Hi,

I'm trying to build a patch for this issue, but I encountered some problems.

1. The permission of the file in sysfs is 0644, so gsd(gnome-settings-daemon) should have root privilege to access the file.
-rw-r--r-- 1 root root 4096 Jan 13 17:04 /sys/class/leds/dell-laptop::touchpad/brightness
But the gsd run as a normal user privilege, so it don't have the permission to control the touchpad LED.
I'm wondering how user space application deals with this kind of issue.

2. After system recovered from S3, the touchpad LED won't turn on again. Is there any way that gsd can know the system recovered from S3 and reset the LED status? I can discuss with the driver maintainer if there is no way to know that.

[AceLan Kao (acelankao)]

I fixed the problem to persist the LED status after S3 in the driver, but I still have no idea how to let user space application access the sysfs without root privilege.
And I don't think it's suitable to change the file mode to 0666, for I can't find any file with that mode in sysfs.

[Rick Spencer (rick-rickspencer3)]

subscribing Martin in case he has a chance to check this out and suggest some direction towards a solution.

[Martin Pitt (pitti)]

Indeed user processes cannot, and should not be able to, change sysctls. First, they do not have the necessary privileges, and second, if you have multiple users logged in at the same time, they would all try to set the value concurrently, possibly to different values.

The usual approach to this kind of problem is to add an API to a system service such as upower, i. e. an API to get and set the touchpad LED. This API then gets a policykit restriction that only the currently active user session can call it, similar to e. g. triggering a suspend. For an example, you can look at org.freedesktop.upower.suspend in /usr/share/polkit-1/actions/org.freedesktop.upower.policy. Programs like gnome-settings-daemon can then call this API as normal user, and the system daemon is able to write the value to sysfs/the kernel, providing proper separation of privileges and avoiding the race condition for multiple users.

However, I would suggest to reconsider implementing this in gnome-settings-daemon. It seems like a hardware design wart that this needs to be controlled by software, but if it has to be done, I think it would be a lot more robust and efficient to do it right in the kernel's touchpad driver. Efficient because it avoids the whole "enable device in the kernel, send notification to userspace, react to it in g-s-d, send to upower, write to sysfs, trigger it in the kernel" loop, and robust because it will also work for other desktop environments which do not have gnome-settings-daemon (XFCE, KDE), in the lightdm greeter, gdm, and so on.

If you decide for an implementation in upower anyway, I suggest talking to Richard Hughes (hughsie) in #udev on freenode about it, as we do not change the API of widely known system daemons in Ubuntu only (this would only introduce long-term incompatibility and a large maintenance overhead), so that this work can get accepted upstream. If you want to go for an in-kernel implementation (which also should be quite a bit smaller), I recommend talking to the kernel team how to get this upstream, as I'm not familiar with that procedure.

Thanks!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Peter Meiser (meiser79)]

Maybe, we could get the following upstream commits into the Ubuntu kernel?

"dell-laptop: touchpad LED should persist its status after S3"
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=2d5de9e84928e35b4d9b46b4d8d5dcaac1cff1fa

"dell-laptop: add 3 machines that has touchpad LED"
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=2a748853ca395c48ea75baa250f7cea6f0f23dbf

[AceLan Kao (acelankao)]

Yes, I'll submit SRU to the kernel team to cherry pick those patches.
But, we still don't have a good way in userspace to cooperate with the kernel driver.

It just comes to my mind, maybe ubuntu kernel team will accept the way turning on/off touchpad LED in the driver until we have a better way doing this in userspace app.
I'll try it.

[Mathieu Trudel-Lapierre (cyphermox)]

AceLan;

Are you still planning on providing those as SRU? What is there left to be done to fix this issue?

[AceLan Kao (acelankao)]

Hi,

In Precise kernel, it already provided an interface to turn on/off the tourchpad LED
   /sys/class/leds/dell-laptop::touchpad/brightness

Other patches are just quirks to add more machines to have this interface, so I don't think it's so urgent.

The problem is that there is no userspace app to take care of this interface, and to turn on/off the LED while touchpad toggle events happened.

It's not suitable to let driver handle this, for it can't access the led subsystem while receiving the key events.

[AceLan Kao (acelankao)]

I submitted the 2 patches mentioned in #6 to stable kernel,
so they will go into precise kernel at next merge.

[Peter Meiser (meiser79)]

The mentioned patches are now included in upstream kernel 3.2.17.

[Rodolfo Guilherme Wottrich (rgwott)]

For me, the LED also won't work, but I don't have a dell-laptop::touchpad/brightness file under /sys/class/leds/.

I'm running Precise with kernel 3.2.0-49.

[Steve Langasek (vorlon)]

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release