[ohm] Some thoughts on OHM

[Richard Purdie]

On Wed, 2007-02-28 at 17:21 +0000, Richard Hughes wrote:
> > 1. The screen can rotate so the device can be configured in a portrait
> > mode (no keyboard) or a landscape mode (keyboard beneath the screen).
> > There are switches that detect the position.
> 
> Surely abstract that out in HAL? That's got to be useful for a desktop
> application. display.rotation or something like that might work.

It is partly abstracted in HAL already. The input SW_LID event is sent
and I think HAL understands that. HAL doesn't know about SW_TABLET_MODE
though.

Also, you need something, somewhere to tell the system that a keyboard
isn't available in "tablet mode" but available in the landscape mode.
The kernel can't really provide that, HAL doesn't, does OHM? Or does
this have to be coded into then policy OHM uses? See my comments below
about information.

> > 3. The devices touchscreen matrix is bigger than the actual LCD and
> > there are some "softkeys" marked. These act as buttons when pressed with
> > the stylus.
> 
> Hmm. How do you squirt these into the input system?

It reads the touchscreen like any normal app and then feeds the events
back through uinput. uinput allows input events to be pushed into the
kernel from userspace.

http://svn.o-hand.com/view/misc/trunk/zaurusd/apps/tskeys/tskeys.c?rev=59&view=auto

> > Of the above, it addressed a lot of the issues:
> > 
> > * tskeys is a generic program that supports softkeys on a touchscreen.
> > It injects events back into the kernel so no specific userspace changes
> > are needed to handle them, you just have to run the daemon with an
> > appropriate config file.
> 
> So you squirt them using evdev back into the kernel?

It uses uinput which creates a new input device which then appears in
the usual way.


> > * ALSA mixer setup was dealt with. Scripts are there to support the
> > different modes (headset, heaphone, mic, speaker) and there is a
> > callback which could launch a UI to ask the user what was plugged in.
> > The actual UI part hasn't been written.
> > 
> > * The hinge switches are processed and adjust the device depending on
> > the position of the screen, enabling/disabling the onscreen keyboard as
> > appropriate. Closing the lid suspends the device which isn't ideal but
> > better than nothing.
> 
> Yes, we have lid position already in HAL for laptops.

Using SW_LID? That was created for the Zaurus originally :) There is the
corresponding SW_TABLET_MODE... 

> > Once, zaurusd was nearly called devmand (device manager daemon) since it
> > includes machine definitions so you could build it for a specific
> > machine or machines and when you did that, it only included what was
> > needed for those specific machines. I think this was an important
> > concept since people only want things on their device they're going to
> > use.
> 
> Yes agree, there's little point having a daemon able to probe for stuff
> that's never going to be connected. HAL has now lots of options to
> configure it for reduced use, for instance removing PCI support.

My question is whether you plan to have this machine specific
information within OHM or whether you're going to have to pass in some
big commandline thats different for every device? Or will you have to
patch in some policy modules for each device?

At the back of my mind, I'm thinking of how a build system (say
OpenEmbedded) might build HAL/OHM for multiple different style devices.
I don't really want to have to teach OE a new configure line for HAL for
every device added to it.

Information about different machines needs to go somewhere but where?

I once had this idea of creating some information store that would
provide extra information about the platform is was running on. HAL
would be able to merge this with what it could work out from the kernel
to then allow the upper layers to act accordingly. Knowledge about the
keyboard's relationship to the screen would be one such piece of
information, I'm sure there could be many others (are softkeys present?,
what is the real screen size?). The x86 world doesn't really have the
concept of machine in quite the way say the ARM world has where
detection of a given machine is much easier and machines are much more
well defined entities. Does OHM have a role here?

> > I'm to first to admit some bits of zaurusd are ugly and maybe hack like
> > and not all the generic infrastructure was fixed to work 100% correctly
> > but I think there are some important ideas there that could be
> > considered with OHM. Does OHM aim to include functionality similar to
> > what I've done with zaurusd?
> 
> Yes, it sounds very similar, but maybe a bit more abstract. There's no
> reason zaurusd couldn't be written as a thin plugin in ohm that just
> sets the zaurus policy that you guys want, and leave all the hardware
> stuff to HAL.

Ok, I'll be interested to see how this works out :).

> > Hopefully classes like these have been or are going to be of great use
> > to HAL since they present things in a simple easy to understand
> > structure. I believe there are several key classes that are still
> > currently missing, particularly batteries. It would be good if someone
> > could look at implementing functionality in the kernel where appropriate
> > to reduce HAL and OHM complexity. I think work will be needed on the
> > kernel as well as OHM.
> 
> I think David Woodhouse (IIRC) proposed a battery class for the kernel,
> and put it in the OLPC builds. I'm not sure if it's upstream yet. Most
> of it looks really sane, but other bits like expressing the ac-adapter
> as a battery seem less sane to me.

I had a very brief at David's class a while ago. It looked rather
complicated to me and I suspect any given device will perhaps only ever
use a fraction of the functionality it provides and I'm also not sure
all the information it provides is actually useful. I need to take a
better look at it really.

Having the AC-apapter as a battery sounds wrong, particularly when you
consider something like a phone might have multiple charging sources
(USB or AC) and you need to abstract this to userspace somehow...

> > sharpsl_pm.c is a collection of fairly zaurus specific code which
> > implements power management on the Zaurus in the kernel. It does various
> > things I'll not get into (unless anyone is interested) but its this code
> > which implements the limit on the backlight (corgi_bl.c in mainline) to
> > get around one of the hardware limitations I mentioned above. Also,
> > sharpsl_pm talks to the world through the ARM APM emulation at the
> > moment which I'd love to see replaced. Two things are needed:
> 
> APM emulation. Ick.

Agreed. As soon as something better exists, I will switch the zaurus to
it. 

> Sure. I appreciate that, and for a long time HAL was pretty bloated and
> inefficient. Now, it's being slimmed down bit by bit, and made much more
> configurable so it might be more suitable for embedded. I've still got
> my reference implementation of "hal-tiny" I made months ago (that still
> compiles) and that uses 40k of memory compared to hal's few hundred k.
> Slowly some of the ideas from hal-tiny will dribble into upstream hal
> and we can have the best of both worlds.

Sounds good :)


> > FOSDEM Slide Comment
> > ====================
> > 
> > The last thing I should mention, at FOSDEM you showed a slide that
> > mentioned simple keys with "brightness_ac" as an example. My work on the
> > kernel classes shows there is nothing as simple as that. 
> 
> Sure, appreciated. It was more to provoke discussion rather than a spec
> suggestion. I'll be uploading some presentation stuff to the wiki
> sometime soon.
> > All you need is a device to come along and want a different brightness
> > depending on whether its day or night regardless of whether AC is
> > plugged in (think of a PDA in a car connected to the car to charge).
> > Don't underestimate what different users will want and try to keep
> > things generic where at all possible.
> 
> Sure, but we have to apply policy somewhere, so we need a simple and
> sane interface for session GUI software.

My point is that by providing that particular interface you rule out the
usefulness of OHM on a certain set of devices though. I know you will
have to make some constraints in implementing OHM, I'm just trying to
highlight that even something this simple is perhaps not so simple and
you need to be careful and not assume things if at all possible.

Cheers,

Richard