Hi!
>
> > I doubt it is impossible, would you mind sharing your knowledge why you
> > think it is impossible or point to some related discussion, pls.
>
> Because, as Len has pointed out, you end up with two different ideas
> about what the trip points are - the kernel's and the hardware's. That
> works fine until some event in the firmware either forcibly
> resynchronises the two or makes assumptions about the spec-compliance of
> the interpreter.
...and suggested workaround is to drive fans directly from userspace,
which not only violates the specs and has all the problems with
desynchronized state, but ALSO FAILS TO WORK IN PRACTICE.
> > I could imagine an implementation for this, that e.g. critical...active9
> > get module parameters. BIOS updates for trip points get ignored as soon
> > as one is set and you can only decrease a value. Nothing bad can happen
> > and it will make some people happy (yes it's hacky, violates the specs
> > and so on..., but some more people have a working machine). Will this
> > (or similar) get accepted?
>
> The interface would need to be more complicated than that if you wanted
> to be able to implement hysteresis, and there's the potential for
> hardware damage if paramaters are set inappropriately. Even then,
> there's no easy way of programatically determining whether it would work
> on any given hardware.
Not sure why you try to scare people with 'hardware damage'. HP XE3
bios already _was_ damaging hardware (it cooked the hard drive using
cpu as a heater), and no acpi magic can damage correctly working
machine.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
