[ohm] Some thoughts on OHM

[Richard Hughes]

> Hi,
> 
> I was at the Open Hardware Manager discussion at FOSDEM and whilst I
> didn't say much at the time I have some thoughts you might be interested
> in. Sorry for the length of this!

No problem. I hope the talk was understandable - we were not sure how to
format it, so we went with an open discussion BOF. I think it worked
well.

> The Zaurus as an example
> ========================
> 
> The Zaurus got a few mentions during the discussion at FOSDEM, probably
> as its a device which has run into some of these difficulties before.
> 
> As background, I am the lead developer on the Sharp Zaurus 2.6
> kernel project. This has been going on for some time and has seen me
> slowly trying to get good support for the Zaurus devices in mainline
> Linux. There have been lots of barriers to this, particularly in the
> areas of power management and the lack of good standardised support for
> things like backlights and LEDs.
> 
> I have some examples of Zaurus specific problems which are probably
> typical of those found on embedded devices and usually lead to adhoc
> solutions:
> 
> 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.

> 2. It has a headphone socket can:
>    * detect when something is plugged in (but not what was plugged in)
>    * support headphones
>    * support a head set (speaker + mic)
>    * support just a mic
>   (there is also an internal speaker)
> 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?

> 4. The backlight is by far the biggest power consumer on the device.
> When battery voltage gets low, the power draw from maximum backlight
> brightness can cause the core voltages to fall too low causing the
> device to crash. We therefore have to limit the backlight intensity at
> low battery.

Sure, a common case for devices I guess. Could you add this to the
use-cases here please: http://ohm.freedesktop.org/wiki/UseCases

> To make the Zaurus a useful device, there are several things that need
> to happen:
> 
> * When it boots, the ALSA mixer needs to be configured
> * When headphones are inserted, the ALSA mixer needs to be reconfigured
> for headphones
> * When a headset is inserted, the ALSA mixer needs to be reconfigured
> for a headset
> * When the user has the device as landscape, no onscreen keyboard is
> needed
> * When the device is portrait, we need an onscreen keyboard available
> * When the lid is closed, the backlight can be off (like a laptop)
> * When the lid is closed, the device can suspend
> * The device shouldn't suspect if you were playing music and the lid was
> closed but the screen should still be blanked (e.g. even if video was
> playing). Ideally, we shouldn't be decoding the video any more, just
> audio.

Sure, another use case.

> * The touchscreen buttons should be connected to something, preferably
> configurable.
> 
> I don't claim to have solved all of the above problems but I did address
> some of them with zaurusd[1]. Zaurusd was an experiment to specifically
> make the zaurus a useful device but also to see how much of that could
> be done more generically.
> 
> [1] http://svn.o-hand.com/view/misc/trunk/zaurusd/

I'll check it out later when I stop running around! :-)

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

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

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

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

> Kernel Interfaces
> =================
> 
> On the kernel side of things, to support backlights and LEDs in mainline
> Linux I've written (or in the case of backlights heavily influenced) two
> class subsystems. These aim is to standardise the way the kernel
> presents these two classes of devices whilst not constraining what you
> can do with these devices. I have tried to keep them simple rather than
> rushing in and adding lots of features. Its much easier to add things
> later rather than the opposite.

Yes, you're a legend for doing that. The backlight class in particular
can make the backlight support in HAL from a hacky 200 line bash script
into about 5 lines of C. Nice one!

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

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

> 1. A way of better handling suspend/resume between userspace and kernel
> space. APM has some nice ideas about userspace being asked before a
> suspend and being able to veto it but in practise the interface is ugly
> and broken on ARM. The question of how you trigger an APM userspace
> suspend request remains open. I currently hack the zaurus kernels to
> wire input KEY_POWER events into APM but having a generic userspace
> solution (which works even without a GUI present) would be good.

Yes. The inhibit thing I talked about might be useful for userspace
(session-space) notification if I think I understand you correctly.

> 2. Somewhere to put battery information, charging information and AC
> status. These should not be part of the suspend/resume handling but
> should be in their own class. A proper sysfs battery class would address
> this.

See above.

> The sharp_pm code also has translation tables to convert ADC readings
> into battery percentage remaining type values needed for APM. This
> shouldn't really be done in kernel space but in userspace. The tables
> are often device specific. I'm wondering if OHM has a role in this
> somewhere.

Sure, add it as an OHM plugin (or HAL addon) - it would be super small.

> ASoC
> ====
> 
> ASoC (ALSA System on Chip) is a good example of where a good
> kernel/userspace split of functionality was found. Its just been merged
> into mainline in 2.6.21-rc1.

Yes, it looks some good stuff, although my knowledge of ALSA is limited.

> ASoC does several good things for sound support including separation of
> the code into layers such as machine specifics, codecs, platform (PXA,
> OMAP etc.) and platform transports (i2c, ssp, i2s etc.). Of interest
> from OHM's point of view is its DAPM (dynamic power management). With
> ASoC's DAPM userspace doesn't really have to care about the power usage
> of the sound subsystem. The mixer controls automatically power on/off
> the different power domains within the sound chip depending on whether
> they're being used. Mixer configuration is therefore all the userspace
> need worry about (hence you can see why zaurusd handles the ALSA mixer).
> Userspace has all the capability is needs but doesn't actually have to
> worry about hardware details itself.
> 
> 
> HAL
> ===
> 
> I still don't 100% like HAL.

Me neither, that's why I send patches :-)

> If someone had originally told me that HAL
> was a dbus interface to sysfs, I think I would have liked it a lot more.
> If in the long run HAL becomes more like that (when compiled for use
> with Linux 2.6 which is one of its main use cases), then I will be a lot
> happier with having it around. At present, as a kernel developer, I
> still generally feel its a layer too many and therefore too inefficient.

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.

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

> Sorry if this rambles a bit, hopefully you can get some useful info from
> it!

Sorry if my answers ramble a bit. ;-)

> Regards,

Thanks for your help with this,

Richard.