[OE-core] The Mythical Sato Replacement

Burton, Ross ross.burton at intel.com
Mon Jul 9 21:06:11 UTC 2012


Hi all,

I've been mulling over a replacement for the Sato environment for some
time now, so I think it's time to talk about my thoughts and get more
feedback from users of oe-core.

Some background: back in 2007[1] Sato was designed to be an
reference/demo PDA environment for mobile devices with (relatively!)
high-DPI but physically small screens[2], such as the Sharp Zaurus and
Nokia 770/N800/N810/etc.  It was designed to look visually distinctive
compared to the competition at the time, and demonstrate all the
features that a handheld PDA should have (at the time).  I think it's
fair to say it mostly succeeded at that although it didn't exactly set
the world on fire.

Fast-forward five years: Sato is still part of oe-core and showing
it's age and unsuitability for the requirements that oe-core now has
compared to the original design requirements for Sato.

So, what does oe-core require from a graphical environment?  As this
is oe-core the list should be fairly short, so how about:
- some way of launching arbitrary applications
- a terminal
- a text editor
- a web browser
- network configuration
- an interactive test suite for verifying that various pieces of
hardware are working: play a media file, show touchscreen events,
display key events, and so on.  More about this later.
- lightweight

There's also a set of anti-requirements:
- no half-baked PIM suite
- no games
- no giant dependency stack or tight integration into the rest of
oe-core.  Pulling the Sato replacement out entirely, or reusing parts
of it, should be easily done.

Re-using an existing environment is one option but I don't think it's
a great one.  LXDE is very minimal but the Windows 95 aesthetic isn't
exactly attractive, XFCE is surprisingly large these days.  We don't
really want much, so I think maintaining our own shell is a worthwhile
investment.

Hopefully there aren't any objections so far?  I'll assume not, and
introduce my proposal for Project Shuku[3].

Shuku will be a descendent of Sato, that is continue to use the
Matchbox Window Manager, Desktop, and Panel; although the latter two
will be updated for GTK+ 3.  All applications will be removed and
fully reconsidered when adding back, so the text editor might well
change from leafpad to something that had a release in two years,
Midori is looking like a good web browser choice instead of Web, the
PIM suite removed, and so on.

The interesting bit is then the test application.  We need a graphical
environment so that we can run applications specific to our needs (and
the desktop handles this fine already) and verify that the system is
in fact working correctly.  Currently this is done in an ad-hoc
manner: using the music player to play audio files, gst-launch to play
videos, poking at the the touchscreen to verify that it works.  I'm
proposing a specific test application so that instead of attempting to
use general purpose applications as test tools, we have a specific
tool.

For example, when playing back a video file it's important that any
hardware acceleration available is actually used.  The test tool could
play the file using GStreamer's playbin and then display the resulting
pipeline so you can verify that VAAPI is being used, the correct audio
sink, the correct network source, and so on.  To verify that the input
devices are working, list them at the evdev level and let you see the
raw events, display touches, and so on.

I've also been considering the brave new world of Wayland.  Whilst
porting to GTK+ 3 all of the X11-specific code can be logically
separated so that a small Weston plugin can be written that integrates
the pieces together.  This will give a Wayland-native graphical
environment that is visually identical to the X environment.

There's plenty of other things to discuss -- visual design and so on
-- but that can wait for another day.

So those are my thoughts.  Any comments?

Ross

[1] Five years ago!
http://www.burtonini.com/wordpress/2007/08/01/poky-linux-3-0-blinky-released/
[2] QVGA, for example, was explicitly not a target.  The Sharp Zaurus,
a typical test device, had a VGA screen.
[3] In the glorious tradition of naming projects by translating words
to other languages, I ended up with 尗 (U+5C17) which means "younger of
brothers", and Shuku is one of the pronunciations.




More information about the Openembedded-core mailing list