[ohm] Hmm... I have a dull feeling...

[Nils Faerber]

...that there is more to it, i.e. to this project, or should I say
potential project?

The start at FOSDEM was really good and the interest of the audience
(and number of attendees) quite clearly showed that there is a need for
something like OHM.

But I am asking myself why so little is happening right now.
Or do I just not see it?

There are clearly at least half a dozen of projects in need for an
abstracted hardware management and especially a policy framework to
handle not only directly hardware related details.

Some quite interesting use-cases were put-up onto the wiki page
	http://ohm.freedesktop.org/wiki/UseCases

My impression, and please take this as my personal impression from
personal experience, is that if the question is still too vague the
interest to answer it is low.

What does that mean?
That means that the general idea of OHM is good. But the real goal and
the way to that goal is still too vague to raise interest. The current
idea, if I got that right, is "to somehow use HAL", to "have some policy
daemon" with "some plugin interface" and some still quite mysterious
policy descriptions.
Also the use cases, though being a nice start, are for my taste a little
too specific already.

Richard mentioned a very nice example that, in my current understanding,
does not match the current scheme of OHM very well, the keyboard, or
more generic, the input method problem.
This is a very important thing, to switch from hardware buttons, to
keyboard, to virtual keyboard, and back (or to whatever) - especially on
a mobile device. You have hardware controls in charge for detecting
certain conditions, you have the UI involved in presenting or hiding the
virtual keyboard or softkey areas and at some point a physical keyboard
like on the Zaurus. How could the policy manager know what the UI is
capable of? How could you abtract a description for OHM that could match
all the possible states the hardware can be in and how to match them
with UI? And if the UI changes, say you invent a radical new input
method just for one certain UI, how would you integrate this with OHM?
Would the policy descriptions become UI dependant?

Using those examples, and much more of them, and abstracting those to a
certain extend, not like use-cases rather more generic descriptions,
would be good to understand what OHM/HAL tries to solve.

Again, please get me right, I am absolutely in favour of the OHM effort.
I just would like to ask some nasty questions which came to my mind and
where I and possibly others struggle to find an answer for or see the
picture/scheme.
Maybe by discussing those we get a clearer picture which is more
attractive to more contributors ;)


In this sense I would propose to get in closer contact with related
projects directly, proactively, and ask them which problems they face(d)
during their development (in the sense of OHM), how they solved them and
how they would like to see them being solved. For exmaple GPE for sure
has to say some words about this too, former OPIE and upcoming OPIE-II
http://opie.home.linuxtogo.org/, OpenMoko, just to name a few.


What could also be seen at FOSDEM is that the kernel people tend to have
a slightly different view on those problems. They seem to like to drop
HAL altogether and even would like to put parts of the policies in
kernel space. I think it would be important to understand their
motivation better.
In an ideal world where every device conforms to kernel-userspace
interfaces, would we really need HAL in its present form or shape
anymore? Wouldn't a simple small library with some convenience functions
be good enough to locate OHM on top of that? Not, why?
That would be a message we would have to deliver to the kernel folks then.


Since I made this proposal I would volunteer (oh darn, what do I do here
;) to start to contact related projects and ask them for their
experience and requirements.

As a result I would try to write up a summary in a form of (just a
thought) a table or similar:
	| Problem | Project's solution | Abstract Requirement |

In the end we should have a pretty neat list of requirements that need
to be addressed. Then we can see how we can map this to HAL, OHM and the
upper GUI-session layer.


Uh, long text already - I'll stop here.

Does that make sense to you?
Ideas or other suggestions?
Shall I try the above communication effort on behalf of OHM? I would
love to since the addressed problems are not at all new to me from the
experience of GPE and other mobile projects. I was also one that
invented his own nasty hacks and I would very much like to stop that.
But in a way that is acceptable by most projects and that leads to less
fragmentation and not more.


Cheers
  nils faerber

-- 
kernel concepts GbR        Tel: +49-271-771091-12
Sieghuetter Hauptweg 48    Fax: +49-271-771091-19
D-57072 Siegen             Mob: +49-176-21024535
--