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"
_______________________________________________
NetworkManager-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/networkmanager-list
