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

[Kimmo Hämäläinen]

On Tue, 2007-04-10 at 20:18 +0200, ext Nils Faerber wrote:
> ...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.

Maybe I'm wrong, but I feel as if HAL exists only because the (sysfs,
kevent) interface provided by the kernel is so clumsy. If the kernel
would provide a function to get the list of all devices (information
that is now in sysfs) and a method for detecting changes in that list,
HAL could be replaced with a convenience library. However, this would
still require some standardisation of the device information, similar to
the HAL specification. The library would be able to hide some kernel-
specific conventions behind it and implement this specification, as the
HAL now does. This would be very good for low-RAM devices, because no
daemons would be needed. In short: HAL-like interface implemented
without the HAL daemon or D-Bus daemon.

But in other to implement system-wide policies, some kind of daemon like
OHM would still be needed. Now, I'm not sure why D-Bus would be still
needed... unless OHM needs it to communicate with other daemons and
applications.

> 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.

Sounds good. Something like OHM is definitely needed, even if HAL is not
needed :)

> 
> 
> 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.

Makes sense to me. Learning about the requirements is very important.

BR; Kimmo

> 
> 
> Cheers
>   nils faerber
>