david at fubar.dk
Mon Nov 27 10:17:37 PST 2006
On Sun, 2006-11-26 at 16:49 +0000, Richard Hughes wrote:
> On Sun, 2006-11-05 at 21:11 -0500, Stu Hood wrote:
> > You're right, this needs to be partitioned more. I still think the
> > thermal_zone capability is a good idea, but the temperature data could
> > be made more useful if it was placed into the 'sensor' namespace. That
> > way, systems with ACPI could have an abstract thermal_zone device in
> > HAL with the capabilities 'thermal_zone' and 'sensor', and systems
> > without ACPI could still expose temperature data for physical devices
> > with the 'sensor' namespace.
> > I've posted v2 of the spec... which moves the temperature data into
> > the 'sensor' namespace so that it can be more generally useful.
> > http://www.hoodidge.net/development/thermal_zone_v2.html
> The sensor stuff looks great and ready to commit IMO.
Have you looked at the new kernel lm_sensors code? I haven't done this
myself but before we commit to an interface for HAL we really need to
understand what the hardware and/or kernel is capable of giving us.
Perhaps their user space library is even the right approach for desktop
apps; I mean, is having sensors / thermal zones etc. useful to have in
HAL apart from powering a UI gizmo?
I'm also not convinced that sensor.* as an abstract name space is that
useful; for the record we already have light_sensor.*, perhaps that
level of abstraction is better... e.g. we'd have
... and so on
I'm also unconvinced that sensor.reporting.current is the right
approach. For the light sensor stuff the interface is poll-based, e.g.
g-p-m actually polls the light sensor, through HAL method calls, and I
think that is fine.. Because.. I think.. What I'm trying to say... I'd
hate to have a bunch of processes in hal sitting and polling only to be
ready if someone launches a UI gizmo that displays the fan RPM and
motherboard temperature etc.
More information about the hal