desktop-packages team mailing list archive

[Martin Pitt <martin.pitt@xxxxxxxxxx>]

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!

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-settings-daemon in Ubuntu.
https://bugs.launchpad.net/bugs/914348

Title:
  Touchpad LED on Dell's laptop is not working

Status in “gnome-settings-daemon” package in Ubuntu:
  New

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/914348/+subscriptions