Hi,
Let me start with a quick self intro:
I'm an open source developer / enthusiast for
10+ years. I've worked on / maintain various webcam and hardware
monitoring linux kernel drivers, libv4l (userspace video format
conversion library), v4l-utils, anaconda (the Red Hat installer),
parted, over 200 Fedora packages and now a days also Spice.
What is missing from this summary is that approx a year ago
I bought my first cheap keychain digital photoframe for 5 euros,
with the idea that it would be a nice project to get the thing
to work under Linux.
A couple of months and 10 frames later (to ensure my software
works with different models) I had software to upload / download
pictures to / from st2205 and ax203 / ax206 / ax3003 based frames
using gphoto, see:
http://picframe.spritesserver.nl/wiki/index.php/UsingAsPicframe
Yes I wrote software to use these little frames as intended,
without any firmware hacking. That said I'm interested in
firmware hacking and using them as an external lcd together
with lcd4linux too.
So this weekend I flashed all 5 st2205 frames I have with hacked
firmware and set forward to use them with lcd4linux. Only to find
out lcd4linux was not packaged for Fedora. So now I've created
(and submitted for official inclusion) packages for Fedora for
libst2205
serdisplib
lcd4linux
While creating the lcd4linux package I hit a few issues, resulting
in 3 patches for lcd4linux (attached):
lcd4linux-st2205-width-height-swap.patch:
The st2205 driver has the width and height of the frame swapped,
which is fine for 128x128 frames, but works less good for 96x64
frames.
lcd4linux-wireless.patch:
The configure script fails to properly detect the linux/wireless.h
header with recent kernels, this fixes this.
lcd4linux-hwmon.patch:
The i2c_sensors plugin, as it names suggests it was written
to get information from hardware monitoring sensors attached to the
i2c bus. But now a days machines often have hwmon sensors attached
to different busses (such as those builtin to CPUs). This patch
makes the i2c_sensors driver also work with for example sensors
builtin to CPUs.
Note there still is a problem when you have multiple sensor devices.
In this case the i2c_sensors plugin will just pick the first one (hwmon0).
You can use the i2c_sensors plugin with multiple sensor devices by
explicitly setting the i2c_sensors-path variable and specifying the hwmon
device in the i2c_sensors call. Example configuration code
(note how some hwmon devices need 'hwmon#/device/...',
and others 'hwmon#/...'):
i2c_sensors-path '/sys/class/hwmon/'
Widget Temp1 {
class 'Text'
width 16
align 'R'
prefix 'ACPI: '
postfix '°C'
precision 1
expression i2c_sensors('hwmon0/temp1_input') / 1000.0
}
Widget Temp2 {
class 'Text'
width 16
align 'R'
prefix 'CPU1: '
postfix '°C'
precision 1
expression i2c_sensors('hwmon1/device/temp1_input') / 1000.0
}
It would propably be good to document this on the wiki
(this trick will work with an unpatched i2c_sensors too)
Note that I'm an active contributor to lm_sensors upstream too,
and a such I must say that it would be better if there would be
a plugin using libsensors rather then accessing sysfs directly.
The advantages are that libsensors takes care of the details
of sysfs parsing, and more importantly that it offers one
central configuration file for things like scaling and offsets
of sensors, as often some conversion is needed to go from raw
sysfs value to a "real" value.
Regards,
Hans
|
