Re: [RFC] Dell Activity LED daemon and udev rule



On 3/2/2010 1:31 AM, Dan Williams wrote:
> On Mon, 2010-03-01 at 16:43 -0600, Bob Rodgers wrote:
>> 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.
> 
> Interesting; this could either be the python that you have, or if I end
> up adding the global connected/disconnected events to the dispatcher, it
> could be a very simple dispatcher shellscript too.
> 
> I'm not quite sure how to handle this at the moment as we don't have any
> sort of NetworkManager-extras, but I'm happy to put it into the
> examples/ directory for the time being.  Distros could then add some
> packaging rules to copy the files from the NM tarball into the correct
> place during NM package build.
> 
> For Fedora maybe we'd create an auxiliary RPM called something like
> "NetworkManager-dell-activity-led" that users could install/remove at
> will to get the functionality.
> 
> Is that the sort of thing you were thinking?
> 
> Dan
> 
>> 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.
>>
>> --
>>
>>
>>
>>
>> _______________________________________________
>> NetworkManager-list mailing list
>> NetworkManager-list gnome org
>> http://mail.gnome.org/mailman/listinfo/networkmanager-list
> 
> 

Thanks, Dan. Yes, we were looking specifically for feedback on if "something" could be included upstream and if so, what form that "something" would be. From your reply, it looks like we could get something in the upstream NM tarball. Once there, we would work with Ubunto (or Fedora), for example, to get them to drop it into their packaging.

Here are the two approaches mentioned:
1 Daemon:
    + only runs on demand on applicable machines
    - approx 8MB memory usage for python daemon, possibly much less for a C/Glib daemon

2 Dispatcher:
    + only runs on demand
    - possibly runs on machines where it isn't needed

Which of these approaches would you prefer we pursue? 

Bob



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]