First off, a quick hello to everyone. I've lurked linux-hacker.net for a year or more back when I was toying with my Audrey. I got my dot.station about two weeks ago from tigerdirect and have been toying around with it. Since the tiger units come unlocked and with a pretty nice custom debian install, I haven't had to worry about hacking just to make a usable system. Consequently, I started poking around some of the stuff that is unique about the dot.station vs. a normal PC. One of the things I wanted to do was get the new mail LED functional, and in a way, I have.
My theory going into this was that there would be some device on the chipset somewhere that would allow the controll of the LEDs, and then it would just be a matter of creating driver for the device. After poking around, I discovered that the chipset includes a SMBus controller, along with the PCI and USB controllers. After doing a bit of research on what SMBus is, I figured this would be the likely candidate for controlling the LEDs. (SMBus is a simple 2-wire control bus designed for power management, smart batteries, fan control, temperature monitoring, etc. I learned the most about it from the LMSensors project at http://www2.lm-sensors.nu/~lm78/docs.html).
I thought I could use some of the tools from LMSensors to scan the bus and find the LED device, but the kernel that comes with the tiger units did not have i2c enabled. I had just downloaded the kernel source and was getting ready to configure a new kernel when caution got the better of me. I wanted to make sure that my new kernel would have all the stuff enabled that the shipping one did, and that's when I made the following discoveries:
1. If you su - and become root, there are some interesting files in root's home dir (/root). In particular, there is a directory called build, which has 2 sub directories, blueriver_leddriver, and pctel-0.8.6. The latter I assume relates to the phone/modem stuff and will warrent some investigation. The former contains some source and binaries for a couple simple programs to control the LEDs.
2. Initially I couldn't get the ledapp program to do anything. All it does is perform some ioctl calls on a device /dev/Leds, which already exists on my system. After some more digging, I found a binary driver module for the LEDs. In /lib/modules/2.4.18-xfs-1.1/misc/ you'll find 3 modules, Leds.o, pctel.o and ptserial.o. The last 2 were already running on my system, and again, I assume are used to control the modem/phone stuff (none of which I've tried yet, incidently). Leds.o is the driver for the LEDs on the system. If you insert the module (insmod Leds.o) then the ledapp program will let you control the Mail, Online, and Power LEDs. You can turn them on and off, or set them to blink.
Now for the big dilema.
The ledapp source code has Intel copyrights on it, along with a proprietary notice and a "may not be copied or disclosed except in accordance with the terms of [license or nondisclosure] agreement." I haven't found any source code for the Leds.o driver module, and I'm not sure I want to. There are some tarballs and rpms in the blueriver-leddriver directory that I haven't checked out yet, but likely, anything I find is going to be under the same 'nondistribution' coverage as what I've turned up so far. I still think the LEDs probably run off of the SMBus, and the best bet might be to try to develop a "clean-room" driver for them. The other option is to try and trace the license and non-disclosure agreements back and convince whoever owns the code now to release it under some sort of usable license. The refurb house that tiger got the machines from had to be the ones who put the binaries (and bits of source I've found) on the machine, and they probably got it from AOL Avant. The terms of that agreement would dictate whether or not we'd be able to co-opt what's on the machines for general use/distribution.
Well, this turned into a longer post than I thought. At least now everyone with a dot.tiger will be able to make their LEDs blink.
I think my next course of action will be to try and build a new kernel so I can get lm-sensors stuff working and scan the SMBus. This will also let me figure out if the binary drivers we've got are generic enough to use with custom kernels or if we're stuck with the kernel images that come with it.
I'll also add that I do know quite a bit about Linux, and the Debian distribution in particular, so I'll try to answer those sorts of questions as I see them.
Happy hacking,
-tiR
