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

[Rob Taylor]

Kimmo Hämäläinen wrote:
> 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?

As Richard says, progress has just been on hold for a short while.

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

Yep. I think the idea of having a system hardware policy manager  with
pluggable policy is a useful idea, but atm we don't have enough of an
idea of the tasks that it would be involved in to solidify the idea.

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

Hmm, my take on this is that it isn't really in the domain of OHM. A
user app can just inject input events into the kernel and the rest is
dealt with as usual from there on. In terms of displaying and hiding the
keyboard, a graphical keyboard app can just listen to events from hal
for the hardware keyboard being available or hidden. Its probably
sensible if we can define a key on the keyboard namespace in hal for
hidden/available so this is abstracted.

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

Well, partially HAL exists to sanitise sysfs, but it also exists because
not all platforms have a linux sysfs ;) Having said that, I'd love to
see a less heavy-weight and more typed way of communicating with
kobjects from userland, a lot of the weight of HAL seems to be in
talking to sysfs.

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

Yes, fundamentally a policy manager needs to be able to respond to
requests from user processes and communicate back to them if requests
have been denied. IMO DBus is the right mechanism for this..


>> 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 ;)

Discussion is certainly what's needed at this point :)

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

Agreed, also I'm interested in talking to the desktop guys and big-iron
server guys. Hardware policy management isn't just a mobile devices problem.


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

See my above comment on not everything being linux... I don't think its
useful to talk of HAL as independent from DBus, after all DBus was
pretty much invented for HAL. I think anything we can do kernel wise to
reduce the weight of HAL would be good. I think I need to think a bit on
what would be an ideal interface ;)

For OHM, its plausible that the communication with HAL could be a plugin
that'd be replaceable with something that talks straight to sysfs on
tighter systems.

>>
>> 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 :)

Sounds good to me too.

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

Agreed,

Thanks,
Rob Taylor


> BR; Kimmo
> 
>>
>> Cheers
>>   nils faerber
>>
> _______________________________________________
> Ohm-devel mailing list
> Ohm-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/ohm-devel