[RFC] Dell Activity LED daemon and udev rule

[Bob Rodgers <Robert_Rodgers dell com>]

The Dell Latitude 2100 and upcoming follow-on models are netbooks intended for classroom use and have a prominent Activity LED embedded in the top of the lid so classroom instructors can observe it from a distance. This Activity LED on older models only tracked the wireless LAN LED indicator. Newer models (as well as older models with updated BIOS) have the capability to drive this LED from software using ACPI WMI methods.

Dell recently submitted a driver to linux-kernel called dell-led, and it is in the process of working its way upstream for inclusion in the next kernel release. See mailing list thread here: http://patchwork.kernel.org/patch/80071/.

We have written a trivial example python program that will turn on the LED based on network up/down state as determined by the NetworkManager dbus interface. We would like to have this Activity LED work out of the box on any NetworkManager-enabled distribution and would like to propose two additions to NetworkManager: 1) Activity LED daemon and 2) udev rule to launch the Activity LED daemon.

Proposed process:
   -- Dell laptop boots
   -- udev automatically loads the dell-led driver based on auto-detection of the ACPI WMI GUID
   -- loading of the driver triggers another udev event which starts the Activity LED daemon
   -- Activity LED daemon listens to nm dbus interface to drive LED as appropriate

Benefits:
   -- This daemon is only loaded and run on appropriate Dell systems, incurring zero overhead for non-Dell systems or Dell systems without the Activity LED
   -- The Activity LED will work out of the box for anybody loading NetworkManager enabled distros.

Possible improvements:
   -- Currently the daemon only turns on the Activity LED when it detects internet connectivity (either wired or wireless). This is the functionality for the Activity LED daemon. Other functionality can be included but this is the default functionality.

   -- LED control handoff: Teachers may want to have another program control the LED. For example a quiz application can light up when students are complete, or a game show application can be used to let students buzz-in for answering. The daemon will need a way to know that another app wants to take over the LED, and also when to resume control when that other app relinquishes control.

Alternate processes are possible, we are very open to suggestions.

Attached are our current daemon example and udev rules. We have not done too much work on these as they are just proof-of-concepts for now. We first want to see if this idea is acceptable for inclusion into NetworkManager before we refine it. You're comments are welcome. Thank you.

--




#! /usr/bin/python
import dbus
from dbus.mainloop.glib import DBusGMainLoop
import gobject
from os import fork, chdir, setsid, umask
from sys import exit, stdin, stdout, stderr

# Dual fork hack to make process run as a daemon
if __name__ == "__main__":
	try:
		pid = fork()
		if pid > 0:
			exit(0)
	except OSError, e:
		exit(1)

chdir("/")
setsid()
umask(0)

try:
	pid = fork()
	if pid > 0:
		exit(0)
except OSError, e:
	exit(1)

stdin.close()
stdout.close()
stderr.close()

DBusGMainLoop(set_as_default=True)

bus = dbus.SystemBus()

def signal_callback(state):
	if state == 3:
		f = open("/sys/class/leds/dell::lid/brightness", 'w' )
		f.write('1')
		f.close()
	else:
		f = open("/sys/class/leds/dell::lid/brightness", 'w' )
		f.write('0')
		f.close()
	return

# Catch signals from a specific interface and object, and call signal_callback
# when they arrive.
bus.add_signal_receiver(signal_callback,
			dbus_interface="org.freedesktop.NetworkManager",
			signal_name="StateChanged")

# Enter the event loop, waiting for signals
loop = gobject.MainLoop()
loop.run()



KERNEL=="dell::lid", ACTION=="add", RUN+="/usr/bin/led_inet_svc.py"