Bug 3169

Do we have any kind of specs ? 

I assume this is a 1.4 task ?

1.4, yes.  No hard specification but my proposal was on oe-core.

I think integrating “Phoronix Test Suite” in the YP layer is a good approach as the first step. I aslo get some feedback from the board manufactures that what tools are used for platform validation. most of them are tools in DOS. But I don't know whether there are some similar tools in Linux that could be used. here is the list:
CPU test     : chkcpu.exe (DOS6.22)
com port test: BEAR UART Card (DOS6.22)
LAN port test: novell link test (DOS6.22), Lanconf (DOS), iperf (Linux)
USB port test: bear usb-t02 card (DOS6.22), USBHSET (Windows)
SATA HDD test: copy&compare (DOS6.22)
SATA test    : RU473/ADU461 (DOS)
DRAM test    : read dram size (DOS6.22), Memtest86(Windows/Linux)
PCI-E Test   : bear pci-e card (DOS6.22)
Fan Test     : cmos check (Dos6.22)
buzzer test  : speaker.com (DOS6.22)
Gfx test     : 3DMark (Windows/Linux), OpenArena (Windows/Linux), glxgears, render_bench, VLC
Burn-in for All     : Passmark (Windows) for running 72 hours
Burn-in for Com Port: PCCOM2000 (Windows) for running 72 hours
Burn-in for Storage : Winthrax.exe (Windows)

I'm not entirely convinced phoronix is the best idea as it has a massive range of dependencies (postgres, apache, ...).  My initial goal isn't to focus on raw performance but functional testing:

- does the touchscreen work correctly
- 2D acceleration
- GL support
- VAAPI support
- sound input/output through each output

And so on.

Promoting this to HIGH for 1.5

Ross is clearly doing this ;-)

In progress but not ready for merging.

(In reply to comment #7)
> In progress but not ready for merging.

Hi Ross,
Any updates on this?

To make this bug clear as all the discussion happened on the mailing lists - the Shuku proposal is to take Sato, port to GTK+3 (this is mostly done, needs bug fixing), and drop the pretence that it's a reference UI for a PDA, swapping stuff like "Music Player" for "GStreamer test harness" (this in particular has happened).

*** Bug 8470 has been marked as a duplicate of this bug. ***

Reassigning to Alex as he expressed interest in actually doing this for 2.1.

Not sure if it's too late for 2.1 but I finally have something to show so I'm moving to M3 and sending some patches ...

I've sent a RFC patchset to list: IMO it's too late for 2.1 release, I propose moving to 2.2 M1.

Status update:

* All of the "upstream" patchsets have been sent (mostly to yocto ML)
* There's a WIP poky branch that contains these to-be-upstreamed patches
  and everything else I intend to send:
  http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=jku/matchbox-wip

Possible issues:
* Some recipes still depend on GTK+2 (see list below). These are
  all development tools though: nothing that should be used on actual
  target images
* GTK+3 still currently requires opengl (via libepoxy)
* I've had to replace some software: e.g. adding l3afpad to oe-core
  (as a replacement for leafpad) might still require discussion


List of GTK+2 reverse dependencies in oe-core world build after my patches:
* gnome-themes-standard
  - Gtk+2 theme that matches the current Gtk+3 theme
* alsa-tools
  - some tools depend on Gtk+2
sysprof
  - latest version requires gtk3 & polkit, but can compile without GUI
latencytop			
kernelshark
fstests
oprofileui			
libglade
  - used by by oprofileui and (current) sysprof

It would be good to tag new versions, and make the recipes refer to those versions, instead of just updating the commit ids, e.g. here:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=jku/matchbox-wip&id=9315cad3da18127925ac0c10e2f208bd2b61c40b

So that the recipe reporting system can correctly report those recipes as 'up to date' instead of 'unknown'.

Not sure how close we got to the original "Shuku proposal" (from Yocto 1.3 !) but I'm calling it done: matchbox components (and the rest of oe-core) now use Gtk+3. 

Tweaks and improvements to the UI should be filed as new bugs.