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

[Nils Faerber]

Rob Taylor schrieb:
Kimmo Hämäläinen wrote:
>> On Tue, 2007-04-10 at 20:18 +0200, ext Nils Faerber wrote:
[...]
>>> 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.

OK, then let's ask the people who do know better.
In my previous mail I mentioned a list of projects that I would be
willing to contact about their ideas, focus, experience, requirements.

What do you think about that list? Any more to add?
That should hopefully help us then to have a clearer idea of the tasks.

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

But it might be the scope of OHM to choose one input method over the other?
An application requiring an input method should just do that, along with
possible extra parameters like "numbers only" or "hex only". OHM could
specify policies in that sense that would choose one method over the
other, like "no physical keyboard, but touchscreen -> virtual keyboard",
"physical keyboard and touchscreen -> physical keyboard", etc. In this
sense this is pretty similar to the backlight example.

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

Exactly ;)
We might one day hopefully see OHM on BSD :)

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

Is it really this?
So a lot of resources is indeed used for text parsers to parse the
readout of sysfs? That should be optimisable, indeed.

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

Right.
And in most cases we will have DBus running already. I guess we can
safely assume systems in the sense of GMAE which will all provide DBus.

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

Good!
Let's continue this then!

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

Excellent!
If you have some specific point you would liek to ask them, maybe from
your experience with hacking HAL, please let me know!
I will try to compile some kind of questionnaire which I will send out
to most of those projects to collect ideas, views, experiences and
requirements. Asking some good questions would clearly help ;)

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

He ;)
That will be hard to convince the Linux-kernel people of, but anyway it
is a good point for OHM development.

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

Do you have any clearer picture you could explain in a few words, what
causes HAL to be ... um ... big? Is it the parsing? Recursive traversal
of the sysfs directories? Or what is it more specifically? I am just
talking about the situation as is, not what it could be. Just a
description of the problems discovered. Maybe this could even helpthe
kernel people to change it to the better in some next version.

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

Ah, good!
That sounds like a good compromise.

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

Great!
I'll draft that up next week then and post it on the list for "public"
review ;)

> Thanks,
> Rob Taylor

Thank you too!

>> BR; Kimmo
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
--

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/ohm-devel/attachments/20070429/1ae477bb/signature.pgp