sorry for the delay in responding
On Wed, 25 Jul 2007, Jerome Glisse wrote:
yes I expect that it would be a large list in some conditions. but one
purpose of this API is to make these options able to be discovered by
software. right now nothing could be done at all without driver specific
knowledge. even a lengthy list can be better then that.
presenting the list to the user directly is a last resort, only for
experimentation or when nothing else wants to deal with devices of that
type.
with a description field (which I didn't include initially, but seems
obviously needed now) it should be fairly easy to create descriptions that
let the software see that there are multiple factors involved.
if the driver supports overclocking then list it in the modes (nothing
says that % capacity couldn't go over 100% for example)
if they power themselves down with no notice to the system they should
power themselves back up with no need for the rest of the system to tell
them either. so this ca either be ignored or presented as a mode between
off and on that enables this behavior.
ahh, here we see a disconnect. I was not intending for the power field to
be that exact. there are just too many variables. for example: even for a
cpu, the power used isn't exactly tied to the clock speed and voltage, the
mix of commands that the cpu is running will affect the power it eats,
sometimes by a significant amount. it was intended to be an ordering
factor and approximate the power used so that things could make a
peroformance/power tradeoff with a good chance of makeing a reasonable
choice.
it's not intended for 'make this laptop use 24w of power instead of 25w of
power'
I'll have to look into what the ohm plugin does.....
ok, after a quick google search and reading the wiki, what I was proposing
would potentially allow ohm to use it directly instead of having to go
through HAL (there may still be a place for HAL, but some parts of it
would get significantly simpler if the abstraction was available directly
from the driver instead of haivng to teach a second piece of software all
the nuances of the driver for it to then create an abstraction for the
system to use)
no you don't want to use the same driver for both, however it would be
very nice to have an interfact that would let yo load the driver for yout
specialized DSP card and all the opensouce software would see it and be
able to manipulate it rather then having to modify the HAL, create ohm
plugins, etc (for how many programs?) before they can know that the card
is there.
David Lang
-
