MeeGo wiki - User contributions [en]

MeeGo Conference Fall 2011

2011-05-29T16:43:49Z

Mikeleib:

Call for Venue selection has started for the November 2011 MeeGo Conference. High level requirements are posted below please submit your venue proposals if they fit the criteria!

Conference Organizers have decided that MeeGo Conference November 2011 should be in Europe again!

*Conference facility should be available either: Nov.7-9 or Nov. 8-10
*Accessibility from US and Europe locations should have many direct flights into From US and Europe, and at most 1 connection.Once at location, there should be hotels which are easily accessible to venue and have good transportation options from Airport.

*Collaboration- Networking oppurtunities should be high and venue should be a place to facilitate that

*Uniqueness- Looking for another very unique facility, preferably not your typical conference/convention center

*Cost To Attendee- Cost of Travel/Hotels Looking for a low cost airfare area and wide variety of local hostels and lower to mid level hotels 3* and 4* close to facility

*Cost of Event- Looking to keep costs low for catering and venue rental

'''Specifics'''

*We are looking for venues which can host a plenary session of 2000, 5-6 breakout rooms, a registration and techshowcase area

*Please post only proposals that have been pre-screened, confirming it is available during the dates above and also it has the space needed

'''Venue Proposals'''

'''Venue Suggestions'''
* Amsterdam
* Hawaii

MeeGo Conference Fall 2011

2011-05-29T16:43:03Z

Mikeleib:

MeeGo Conference Fall 2011

2011-05-29T16:39:17Z

Mikeleib: Just my idea

MeeGo Conference 2010/Unconference

2010-10-07T04:12:37Z

Mikeleib: /* I plan to present ... */

Day 3 of the [http://conference2010.meego.com MeeGo Conference] will be primarily an unconference run in the BarCamp style. We will also have one room with scheduled activities running in parallel to the unconference for Birds of a Feather sessions, lightning talks and similar activities.

== What is an Unconference and Why should I attend? ==

We've been getting a lot of questions about the unconference day from people who aren't convinced that it is worth their time to attend. [[User:Dawnfoster|I (Dawn)]] have attended many unconferences and organized several of them, and I can honestly say that I usually get as much, if not more, out of them than I do from traditional conferences.

=== Brief Description ===

An unconference is an ad-hoc gathering organized by the attendees for the attendees. The concept originated out of a desire for people to share and learn in an open environment. It is an intense event with discussions, demos and interaction from participants. You never quite know what to expect at an unconference, since each one is shaped by the attendees. When you arrive on Wednesday morning, there will be an agenda framework (times / rooms), but the content for the sessions will be decided by the participants.

=== Why should I attend ===

'''To Present and Lead'''
* Anyone can present or lead a discussion, so you can talk about any topic of interest to you.
* If you submitted a session, and it wasn't approved for the main conference, but you still think it would be interesting, you can present it here.
* We will have plenty of smaller rooms for niche topics of interest to a few people - those rarely fit into a conference format, but work nicely in one of our smaller unconference rooms.
* It's a great opportunity to follow up on a topic presented in the first days and have a more detailed discussion.

'''To Collaborate and Network'''
* Use the time to collaborate with people on an interesting MeeGo project.
* Great opportunity to talk to experts about subjects not covered in the first two days.
* Network and meet other people interested in our work
* Learn more about what others need and get feedback on new ways to use MeeGo
* Collaborate on actual work related to MeeGo in smaller groups
* Have group discussions or meetings

'''To Learn and Innovate'''
* It is a great way to spot new talents, new movements, tendencies and upcoming technologies that weren't mature enough for the main conference.
* An unconference is basically like the conference, but with subjects chosen by the audience (by interest), which means there's a high chance of finding interesting topics.
* We have a community of interesting smart people, so we should expect plenty of interesting sessions.
* The flexible format allows for interesting out of the box ideas and ways to accommodate different formats.
* You are encouraged to use the [http://en.wikipedia.org/wiki/Law_of_Two_Feet#Law_of_Two_Feet Law of Two Feet] - if you go to a session and it isn't what you had hoped, you are encouraged to get up and move to another session.
* Come home with a fresh set of cutting-edge ideas and inspiration at the front of innovation within MeeGo.

=== More information ===
* [http://www.youtube.com/watch?v=7XlqEDIJzfw What is BarCamp? video] - short and worth your time to watch.
* [http://en.wikipedia.org/wiki/Barcamp BarCamp Wikipedia entry] with some history and other information.

== Session Ideas ==

'''IMPORTANT: Adding a session to the list below does not reserve a spot on the schedule board on Wednesday. The only way to guarantee a schedule slot is by showing up early and putting your session on the grid in person. See the [[#Schedule]] section below for more details.'''

=== Tips for Presenters ===

* Discussion formats work slightly better than standard conference presentations. Leading a group of people in a discussion is much more interactive and gives people a nice break from the past 2 days of presentations.
* Prepare in advance - if you plan to lead a session, prepare as you would for any other conference.
* Have a topic that isn't 45 minutes of material? Team up with one or more people with related topics and share the session.
* Respect people's time and do not allow your session to run longer than scheduled. Other people will be waiting to get into the room to set up for the next session.

=== I plan to present ... ===

Leave a note with the topic you plan to present along with your name and a link to more information about yourself.

* The title of an example topic description --[[User:Dawnfoster|Dawnfoster]] 22:09, 21 September 2010 (UTC)
* [http://conference2010.meego.com/session/accounts-sso Introduction to the new Accounts & Single Sign On framework] --[[User:Mardy|Mardy]] 24 Sep 2010 11:52:11 (UTC)
* [http://conference2010.meego.com/session/content-fw-my-god-its-full-data Introduction to Tracker/Content FW: one of really innovating bits in Meego] --[[User:Ifrade|Frade]] 06 Oct 2010 13:21:00 (EETC)
* [[MeeGo_Conference2010/QtM_BoF_Unconference|QtMobility & MeeGo BoF/Unconference]] -- [[User:mikeleib|mikeleib]] 06 Oct 2010 04:03 UTC

=== I would like to see someone talk about ... ===

Have something that you want to see someone else talk about? Feel free to use this space to brainstorm topics.

* Tips for contributing code to MeeGo and getting it accepted --[[User:Dawnfoster|Dawnfoster]] 22:09, 21 September 2010 (UTC)

== Schedule ==

=== Schedule Grid and Process for Scheduling Sessions ===

We will have a big grid on the wall where people can post their session ideas on the morning of the event (no sessions reserved in advance). Make sure you arrive on time if you plan to lead a session!

'''To Schedule a Session''':
* The schedule board will open up after the welcome is completed.
* Write your topic in big letters on your post it note.
* Include your contact information in smaller letters (name and cell phone or email address)
* Put your post it note on the board picking a room and time that looks good to you.
* Make sure that big meaty topics are in large rooms with niche topics in small rooms.

'''Things to keep in mind''':
* The schedule board is dynamic and may change at any time during the day.
* The schedule board on the wall is always the master.
* We may need to move sessions, so make sure you double check the board to make sure that you are going to the right room / time for the session you want to attend.
* Sessions that seem very similar may be asked to combine.
* We reserve the right to move things around to make sure that popular topics have large rooms.

=== Day Schedule and Grid Format ===

This is an example of how the grid will look and is for planning purposes only - '''please do not enter sessions or add other information to the grid'''

{| border="1"
!Time || Presidents 1 (sits 300) || Presidents 2 (sits 280) || Vavasour (sits 80) || 1872 area (sits 120) || Havelock (sits 130)||Box 1 (sits 20)||Box 2 (sits 20)|| Box 3 (sits 20)|| Box 4 (sits 20)|| Box 5 (sits 20)|| Box 6 (sits 20)|| Other
|-
!9:00 - 9:15 ||colspan=13|Atrium: Welcome - What is an unconference and how do I participate?
|-
!9:15 - 9:45 ||colspan=13|Atrium: Schedule board open - people post sessions on the grid.
|-
!9:45 - 10:00||colspan=13|Atrium: Schedule board adjustments (combine duplicates, adjust rooms, etc.)
|-
|10:00 - 10:45|| BOFs / Scheduled || Unconf Session || Unconf Session || Unconf Session || Unconf Session||Unconf Session||Unconf Session || Unconf Session ||Unconf Session || Unconf Session || Unconf Session
|-
|11:00 - 11:45|| BOFs / Scheduled || Unconf Session || Unconf Session || Unconf Session || Unconf Session||Unconf Session||Unconf Session || Unconf Session ||Unconf Session || Unconf Session || Unconf Session
|-
|12:00 - 12:45|| Lightning Talks || Unconf Session || Unconf Session || Unconf Session || Unconf Session||Unconf Session||Unconf Session || Unconf Session ||Unconf Session || Unconf Session || Unconf Session
|-
!12:45 - 13:45||colspan=13|Lunch and Networking
|-
|13:45 - 14:30|| BOFs / Scheduled || Unconf Session || Unconf Session || Unconf Session || Unconf Session||Unconf Session||Unconf Session || Unconf Session ||Unconf Session || Unconf Session || Unconf Session
|-
|14:45 - 15:30|| BOFs / Scheduled || Unconf Session || Unconf Session || Unconf Session || Unconf Session||Unconf Session||Unconf Session || Unconf Session ||Unconf Session || Unconf Session || Unconf Session
|-
!15:30 - 16:00||colspan=13|We need to be out of Aviva no later than 16:00.
|-
!17:45||colspan=13|Doors open for the Ireland / Norway Football game.
|-
|}

Note: The BOF / Scheduled session room is out of scope of the unconference team and will be decided and planned by the content committee.

== Requirements ==

* Rooms set up - confirm that we do plan to use all of the rooms on the schedule board & we need to know which rooms have projectors.
* A bunch of 4x6" post it notes
* A schedule board pre-printed with times and rooms with spaces large enough to accommodate 4x6" post it notes (alternative is painter's tape & a wall)
* Sharpie pens

== Organizing Team ==

* Lead: [[User:Dawnfoster|Dawn Foster]]
* Notes / wiki organizer - put a process in place to allow people to take notes and maintain a copy (physical board is the master) of the schedule in the wiki.
* Schedule volunteers - 2 people (2 shifts - each working half the day) to help manage the schedule board, help people get things scheduled, update schedule changes in the wiki copy, etc.
* Note taking volunteers - each session needs one or more people to take notes and put them in the wiki

MeeGo Conference2010/QtM BoF Unconference

2010-10-07T04:12:16Z

Mikeleib: Created page with "= Intents & Purposes = I plan to get together with like minded individuals at the unconference part of the MeeGo conference and talk about QtMobilty, MeeGo, and how we can best w…"

= Intents & Purposes =
I plan to get together with like minded individuals at the unconference part of the MeeGo conference and talk about QtMobilty, MeeGo, and how we can best work together to achieve awesome.

= Like Minded Individuals =
* [[User:mikeleib|mikeleib]]

MeeGo Conference 2010/Unconference

2010-10-07T04:06:12Z

Mikeleib: /* I plan to present ... */

Day 3 of the [http://conference2010.meego.com MeeGo Conference] will be primarily an unconference run in the BarCamp style. We will also have one room with scheduled activities running in parallel to the unconference for Birds of a Feather sessions, lightning talks and similar activities.

== What is an Unconference and Why should I attend? ==

We've been getting a lot of questions about the unconference day from people who aren't convinced that it is worth their time to attend. [[User:Dawnfoster|I (Dawn)]] have attended many unconferences and organized several of them, and I can honestly say that I usually get as much, if not more, out of them than I do from traditional conferences.

=== Brief Description ===

An unconference is an ad-hoc gathering organized by the attendees for the attendees. The concept originated out of a desire for people to share and learn in an open environment. It is an intense event with discussions, demos and interaction from participants. You never quite know what to expect at an unconference, since each one is shaped by the attendees. When you arrive on Wednesday morning, there will be an agenda framework (times / rooms), but the content for the sessions will be decided by the participants.

=== Why should I attend ===

'''To Present and Lead'''
* Anyone can present or lead a discussion, so you can talk about any topic of interest to you.
* If you submitted a session, and it wasn't approved for the main conference, but you still think it would be interesting, you can present it here.
* We will have plenty of smaller rooms for niche topics of interest to a few people - those rarely fit into a conference format, but work nicely in one of our smaller unconference rooms.
* It's a great opportunity to follow up on a topic presented in the first days and have a more detailed discussion.

'''To Collaborate and Network'''
* Use the time to collaborate with people on an interesting MeeGo project.
* Great opportunity to talk to experts about subjects not covered in the first two days.
* Network and meet other people interested in our work
* Learn more about what others need and get feedback on new ways to use MeeGo
* Collaborate on actual work related to MeeGo in smaller groups
* Have group discussions or meetings

'''To Learn and Innovate'''
* It is a great way to spot new talents, new movements, tendencies and upcoming technologies that weren't mature enough for the main conference.
* An unconference is basically like the conference, but with subjects chosen by the audience (by interest), which means there's a high chance of finding interesting topics.
* We have a community of interesting smart people, so we should expect plenty of interesting sessions.
* The flexible format allows for interesting out of the box ideas and ways to accommodate different formats.
* You are encouraged to use the [http://en.wikipedia.org/wiki/Law_of_Two_Feet#Law_of_Two_Feet Law of Two Feet] - if you go to a session and it isn't what you had hoped, you are encouraged to get up and move to another session.
* Come home with a fresh set of cutting-edge ideas and inspiration at the front of innovation within MeeGo.

=== More information ===
* [http://www.youtube.com/watch?v=7XlqEDIJzfw What is BarCamp? video] - short and worth your time to watch.
* [http://en.wikipedia.org/wiki/Barcamp BarCamp Wikipedia entry] with some history and other information.

== Session Ideas ==

'''IMPORTANT: Adding a session to the list below does not reserve a spot on the schedule board on Wednesday. The only way to guarantee a schedule slot is by showing up early and putting your session on the grid in person. See the [[#Schedule]] section below for more details.'''

=== Tips for Presenters ===

* Discussion formats work slightly better than standard conference presentations. Leading a group of people in a discussion is much more interactive and gives people a nice break from the past 2 days of presentations.
* Prepare in advance - if you plan to lead a session, prepare as you would for any other conference.
* Have a topic that isn't 45 minutes of material? Team up with one or more people with related topics and share the session.
* Respect people's time and do not allow your session to run longer than scheduled. Other people will be waiting to get into the room to set up for the next session.

=== I plan to present ... ===

Leave a note with the topic you plan to present along with your name and a link to more information about yourself.

* The title of an example topic description --[[User:Dawnfoster|Dawnfoster]] 22:09, 21 September 2010 (UTC)
* [http://conference2010.meego.com/session/accounts-sso Introduction to the new Accounts & Single Sign On framework] --[[User:Mardy|Mardy]] 24 Sep 2010 11:52:11 (UTC)
* [http://conference2010.meego.com/session/content-fw-my-god-its-full-data Introduction to Tracker/Content FW: one of really innovating bits in Meego] --[[User:Ifrade|Frade]] 06 Oct 2010 13:21:00 (EETC)
* QtMobility & MeeGo BoF/Unconference -- [[User:mikeleib|mikeleib]] 06 Oct 2010 04:03 UTC

=== I would like to see someone talk about ... ===

Have something that you want to see someone else talk about? Feel free to use this space to brainstorm topics.

* Tips for contributing code to MeeGo and getting it accepted --[[User:Dawnfoster|Dawnfoster]] 22:09, 21 September 2010 (UTC)

== Schedule ==

=== Schedule Grid and Process for Scheduling Sessions ===

We will have a big grid on the wall where people can post their session ideas on the morning of the event (no sessions reserved in advance). Make sure you arrive on time if you plan to lead a session!

'''To Schedule a Session''':
* The schedule board will open up after the welcome is completed.
* Write your topic in big letters on your post it note.
* Include your contact information in smaller letters (name and cell phone or email address)
* Put your post it note on the board picking a room and time that looks good to you.
* Make sure that big meaty topics are in large rooms with niche topics in small rooms.

'''Things to keep in mind''':
* The schedule board is dynamic and may change at any time during the day.
* The schedule board on the wall is always the master.
* We may need to move sessions, so make sure you double check the board to make sure that you are going to the right room / time for the session you want to attend.
* Sessions that seem very similar may be asked to combine.
* We reserve the right to move things around to make sure that popular topics have large rooms.

=== Day Schedule and Grid Format ===

This is an example of how the grid will look and is for planning purposes only - '''please do not enter sessions or add other information to the grid'''

{| border="1"
!Time || Presidents 1 (sits 300) || Presidents 2 (sits 280) || Vavasour (sits 80) || 1872 area (sits 120) || Havelock (sits 130)||Box 1 (sits 20)||Box 2 (sits 20)|| Box 3 (sits 20)|| Box 4 (sits 20)|| Box 5 (sits 20)|| Box 6 (sits 20)|| Other
|-
!9:00 - 9:15 ||colspan=13|Atrium: Welcome - What is an unconference and how do I participate?
|-
!9:15 - 9:45 ||colspan=13|Atrium: Schedule board open - people post sessions on the grid.
|-
!9:45 - 10:00||colspan=13|Atrium: Schedule board adjustments (combine duplicates, adjust rooms, etc.)
|-
|10:00 - 10:45|| BOFs / Scheduled || Unconf Session || Unconf Session || Unconf Session || Unconf Session||Unconf Session||Unconf Session || Unconf Session ||Unconf Session || Unconf Session || Unconf Session
|-
|11:00 - 11:45|| BOFs / Scheduled || Unconf Session || Unconf Session || Unconf Session || Unconf Session||Unconf Session||Unconf Session || Unconf Session ||Unconf Session || Unconf Session || Unconf Session
|-
|12:00 - 12:45|| Lightning Talks || Unconf Session || Unconf Session || Unconf Session || Unconf Session||Unconf Session||Unconf Session || Unconf Session ||Unconf Session || Unconf Session || Unconf Session
|-
!12:45 - 13:45||colspan=13|Lunch and Networking
|-
|13:45 - 14:30|| BOFs / Scheduled || Unconf Session || Unconf Session || Unconf Session || Unconf Session||Unconf Session||Unconf Session || Unconf Session ||Unconf Session || Unconf Session || Unconf Session
|-
|14:45 - 15:30|| BOFs / Scheduled || Unconf Session || Unconf Session || Unconf Session || Unconf Session||Unconf Session||Unconf Session || Unconf Session ||Unconf Session || Unconf Session || Unconf Session
|-
!15:30 - 16:00||colspan=13|We need to be out of Aviva no later than 16:00.
|-
!17:45||colspan=13|Doors open for the Ireland / Norway Football game.
|-
|}

Note: The BOF / Scheduled session room is out of scope of the unconference team and will be decided and planned by the content committee.

== Requirements ==

* Rooms set up - confirm that we do plan to use all of the rooms on the schedule board & we need to know which rooms have projectors.
* A bunch of 4x6" post it notes
* A schedule board pre-printed with times and rooms with spaces large enough to accommodate 4x6" post it notes (alternative is painter's tape & a wall)
* Sharpie pens

== Organizing Team ==

* Lead: [[User:Dawnfoster|Dawn Foster]]
* Notes / wiki organizer - put a process in place to allow people to take notes and maintain a copy (physical board is the master) of the schedule in the wiki.
* Schedule volunteers - 2 people (2 shifts - each working half the day) to help manage the schedule board, help people get things scheduled, update schedule changes in the wiki copy, etc.
* Note taking volunteers - each session needs one or more people to take notes and put them in the wiki

User:Mikeleib

2010-10-07T04:05:52Z

Mikeleib: now with more

Mikeleib is a MeeGo hacker.
 Mikeleib works for Intel.
 Mikeleib is reachable via freenode as mikeleib.
 Mikeleib speaks in simple sentences.

User:Mikeleib

2010-10-07T04:05:18Z

Mikeleib: mikeleib is this.. mikeleib is that.. mikeleib blah blah

Mikeleib is a MeeGo hacker.
Mikeleib works for Intel.
Mikeleib is reachable via freenode as mikeleib.
Mikeleib speaks in simple sentences.

QtInternationalization

2010-09-23T00:12:10Z

Mikeleib: /* Creating the OBS project */

This page is a draft work in progress and not complete; mainly a stream of consciousness...

=Overview=
MeeGo applications are are to be internationalized by the application developer. For information on how to write internationalized code, see the [http://apidocs.meego.com/mtf/i18n.html MeeGo Touch Framework: i18n] documentation. In its simplest form, the developer should use qtTrId() to wrap all of the user visible strings. If the application uses any type of concatenation, make sure it uses the argument version of QString(). For example:
//% "Displayed contact name %1 is first name. %2 is last name"
QString name = qtTrId("%1 %2").arg(contact.firstName()).arg(contact.lastName());
Make sure you provide a contextual comment describing the string before its usage (as is done in the above example) This facilitates the translation process. The string comment is also used when generating the "engineering English" which is displayed when no translation exist.
==Engineering English==
The engineering English strings are prefixed with '!!' to ensure they are visibly identifiable as having not been officially translated.

The base application projects do not provide '''localized''' translations. Language packages will be installed which provide the various language translations. Lacking a translation, the translation ID will be shown by the system if a translation is not found.

Application packages should install the engineering English translation file into the system. See the section [http://wiki.meego.com/Internationalization#Packaging_engineering_English Packaging engineering English].

The following attempts to describe the general process used by MeeGo to create localized language packs.

==Supported locales==
The locales which must be enabled, per http://bugs.meego.com, are:
American English (en_US), British English (en_GB), French (fr), Spanish (es), German (de), Italian (it), Polish (pl), Dutch (nl), Russian (ru), Swedish (sv), Finnish (fi), Brazilian-Portuguese (pt_BR), Canadian-French (fr_CA), Portuguese (pt), Japanese (ja), Korean (ko), Chinese Simplified (zh_CN), Chinese Traditional (zh_TW).

If in doubt of a language code, see here: http://www.transifex.net/languages/

=Step-by-Step=
For this example, we will create the language package project for the meego-handset-sms application.

The naming convention used is that the GIT tree and OBS package for a translation project are named based on the application GIT tree + -translations. In this case meego-handset-sms-translations.

At the end of this sample, you will have the following directories:
${BASE}/meego-handset-sms <---- application .git project
${BASE}/meego-handset-sms-translations <---- translation .git project for application
${BASE}/obs/meego-handset-sms-translations <---- OBS project for translation package

The following exports are used throughout these script snippets; you can export them once to your shell and then paste the other script components. If you later come back to run an individual step, make sure you set these variables back up.
export BASE='''~''' # Root directory for the various projects
export APP_PACKAGE='''meego-handset-sms''' # Name of the application project
export APP_BINARY='''sms''' # TARGET binary created by application project
export SOURCE_SUBDIR='''/src''' # Subdirectory under ${APP_PACKAGE} which contains the package source files
export PACKAGE=${APP_PACKAGE}-translations
export LANGUAGES="en en_US en_GB fr es de it pl nl ru sv fi pt_BR fr_CA pt ja ko zh_CN zh_TW"
'''BOLD''' items are the ones you need to change for your project.
==Checkout the application .git project==
The first step is to obtain the application project that we'll be creating the translation project for.
cd ${BASE}
git clone git://gitorious.org/meego-handset-ux/${APP_PACKAGE}
Look in the meego-handset-sms directory and you will notice that all of the sources are in the src/ directory. Look at the project files for meego-handset-sms -- notice that while the project is called meego-handset-sms, the binary it installs is called '''sms'''.

You can typically tell the binary name by looking for the TARGET= line in the source's .pro file.

Knowing the location of the source is important when we define the SOURCES variable in the translations.pro file, which is used to derive the translation files from the sources. Knowing the binary installed is important when we define the APP_BINARY value.

The name of the binary is important as it is used by Qt to find the translation file. The translation file used can be overridden by passing a 3rd parameter to MApplication(). The compiled translation files (.qm) are installed using the binary name as their filename base.

==Create the initial translations .git project==
The following snippet will create a blank translations .git repository for you:
cd ${BASE}
[ ! -d ${PACKAGE} ] && mkdir ${PACKAGE}
cd ${PACKAGE}
cat << EOF >> translations.pro
LANGUAGES = ${LANGUAGES}
CATALOGNAME = ${APP_BINARY}
SOURCEDIR = '''\$\$PWD/../${APP_PACKAGE}${SOURCE_SUBDIR}'''
TRANSLATIONDIR = \$\$PWD
DISABLE_QTTRID_ENGINEERING_ENGLISH=yes
include(\$\$[QT_INSTALL_DATA]/mkspecs/features/meegotouch_defines.prf)
include(\$\$[QT_INSTALL_DATA]/mkspecs/features/meegotouch_translations.prf)
EOF
git init
git add *
git commit -s -a -m "Initial translation package commit for ${APP_PACKAGE}"
qmake
make updatets
git add *.ts Makefile
git commit -s -a -m "Initial .ts files generated from ${APP_PACKAGE}"
'''NOTE:''' Do not check in the '.qm' files. Those are generated during package build time and should not be managed in GIT.
'''NOTE2:''' The 'dummy-dependency-this-file-will-never-be-created' file is created and committed to the GIT tree to keep the build process from attempting to update the .ts files every time the .qm files are compiled.

===What is the license for the translation package?===
Translation files (.ts) are derived from the source package. The original author of the source package therefore holds a copyright interest in the derived translation package. In order to comply with the license terms of the source application package, typically the translation package must use the same license as the base source package.

Once you know the license which applies to the translation package, place a copy of that license in the file LICENSE and add it to the git tree:
git add LICENSE
git commit -s -a -m "Added LICENSE terms"

==Changing the set of supported locales==
To add additional translations, you would add the translation name to LANGUAGES in translations.pro:
export LANGUAGES="en fi cz dk he"
cd ${BASE}/${PACKAGE}
sed -i -e "s,^LANGUAGES[ /t]*=.*$,LANGUAGES = ${LANGUAGES},g" translations.pro
qmake
make updatets
git add *ts
git commit -s -a -m "Updated languages to support '${LANGUAGES}' based on ${APP_PACKAGE} commit-id '${REVISION}'"

==Updating the .ts files to match latest source package==
cd ${BASE}/${PACKAGE}
export REVISION=$(git --git-dir=../${APP_PACKAGE}/.git log --pretty=format:"%h" HEAD^..HEAD)
make updatets
git commit -s -a -m "Updated .ts files to package ${APP_PACKAGE} commit-id '${REVISION}'"
'''NOTE:''' You only need to run '''make updatets''' periodically when new application releases are made. It should not be run when translations are being updated. Translators should never need to run the '''make updatets''' script.

=Packaging the translations=
Language packs should be provided as one RPM per locale. Typically, multiple packages would be built from a single OBS package.
==Creating the tar ball==
The first step of packaging is to create a tar file. In the following example, we set the version to 0.0.1. That version string should be updated to match the version of ${APP_PACKAGE} that is in OBS (the VERSION string is used for required dependency checking during package installation)
export '''VERSION=0.0.1'''
To create the tar file in ${BASE}/obs/${PACKAGE}/:
cd ${BASE}
[ ! -d ${BASE}/obs/${PACKAGE} ] && mkdir -p ${BASE}/obs/${PACKAGE}
tar cvjf ${BASE}/obs/${PACKAGE}/${PACKAGE}-${VERSION}.tar.bz2 ${PACKAGE} --exclude=.git

That above tar file would contain:
Makefile
sms-en.ts
sms-fi.ts
sms-de.ts
translations.pro

==Creating the OBS project==
The contents of the '''meego-handset-sms-translations''' OBS project for this example needs to consist of:
meego-handset-sms-translations-0.0.1.tar.bz2
meego-handset-sms-translations.yaml
meego-handset-sms-translations.spec
To create the .yaml file you can use the following script. This assumes the directory .tar.bz2 file was created and exists in ${BASE}/obs/${PACKAGE}:
cd ${BASE}/obs/${PACKAGE}
cat << EOF > ${PACKAGE}.yaml
Name: ${PACKAGE}
Summary: Translation files for ${APP_PACKAGE}
Version: ${VERSION}
Release: 1
Group: System/GUI/Other
License: Apache
URL: http://gitorious.org/meego-handset-ux/${PACKAGE}
Sources:
- "%{name}-%{version}.tar.bz2"
Description: Translation files for ${APP_PACKAGE}
Requires:
- ${APP_PACKAGE} >= %{version}

PkgConfigBR:
- QtCore >= 4.6.0
- meegotouch
Configure: none
Builder: make
NoFiles: yes
EOF
for locale in $(tar xf ${PACKAGE}-${VERSION}.tar.bz2 ${PACKAGE}/translations.pro -O | sed -ne 's,^LANGUAGES[ \t]*=[ \t]*$.*$,\1,p'); do
cat << EOF >> ${PACKAGE}.yaml
SubPackages:
- Name: ${locale}
Summary: ${locale} translation file for ${APP_PACKAGE}
Group: Base/System
Description: ${locale} translation file for ${APP_PACKAGE}
Files:
- "%lang(${locale}) %{_datadir}/l10n/meegotouch/%{name}_${locale}.qm"

EOF
done
See the sample .yaml file at the end of this page for an example of what the above script generates (the sample has additional comments that the above script does not add)

Once you have the .yaml file, you can create the .spec file via spectacle.
specify ${PACKAGE}.yaml

==Updating the OBS package==
Create a new translations package tar ball named meego-handset-sms-translations-${VERSION}.tar.bz2

${VERSION} value for the tar ball must correspond to the 'Version:' string in the yaml file:
sed -i -e 's,^Version:[ \t]*$.*$$,${VERSION},p' meego-handset-translations.yaml

=Sample yaml file=
#
# Use application package name + "-translations"
Name: meego-handset-sms-translations
Summary: Translation files for meego-handset-sms
#
# Keep version # in sync with the application package
Version: 0.0.1
Release: 1
Group: System/GUI/Other
#
# Use application package license; .ts files are derived works from application application
License: Apache
# Use GIT url for translations project on gitorious
URL: http://gitorious.org/meego-handset/meego-handset-sms-translations
Sources:
- "%{name}-%{version}.tar.bz2"
Description: Translation files for meego-handset-sms
# Require the application package - tie these
Requires:
- meego-handset-sms >= %{version}

PkgConfigBR:
- QtCore >= 4.6.0
Configure: none
Builder: make
NoFiles: yes
SubPackages:
- Name: en
Summary: en translation for meego-handset-sms
Group: System/GUI/Other
Description: en translation for meego-handset-sms
Files:
- "%lang(en) %{_datadir}/l10n/meegotouch/sms-en.qm"

- Name: fi
Summary: fi translation for meego-handset-sms
Group: System/GUI/Other
Description: fi translation for meego-handset-sms
Files:
- "%lang(fi) %{_datadir}/l10n/meegotouch/sms-fi.qm"

- Name: de
Summary: de translation for meego-handset-sms
Group: System/GUI/Other
Description: de translation for meego-handset-sms
Files:
- "%lang(de) %{_datadir}/l10n/meegotouch/sms-de.qm"

=Packaging engineering English=
cd ${BASE}/${APP_PACKAGE}
[ ! -e translations ] && mkdir translations
cd translations
cat << EOF >> translations.pro
LANGUAGES = # We only create engineering English in the application package
CATALOGNAME = ${APP_BINARY}
SOURCEDIR = ../${SOURCE_SUBDIR}
TRANSLATIONDIR = \$\$PWD
include(\$\$[QT_INSTALL_DATA]/mkspecs/features/meegotouch_defines.prf)
include(\$\$[QT_INSTALL_DATA]/mkspecs/features/meegotouch_translations.prf)
EOF
qmake
make
git add translations.pro
git commit -s -a -m "Engineering English translation project generated"
Now you need to add '''translations''' to the SUBDIRS in the top level project file (sms.pro in this example):
sed -i -e 's,$SUBDIRS = .*$,\1 translations,g' *.pro
You don't need to commit the .ts file to GIT. It will be extracted from the source code each time the build is run. This ensures the engineering English always provides all of the non-translated strings. Official English translation should be installed via the ${APP_PACKAGE}-translations-en package.

You now need to add the engineering English file to your yaml file for your project in OBS to the FILES section. Edit the yaml file and looking for Files and add the following:
- "%{_datadir}/l10n/meegotouch/%{name}.qm"
If you don't have a Files section in your yaml, you'll can add one to your yaml, or you can edit your spec file directly. See the sample yaml file above for an example how to add a Files section.

After you have done the above you can cut a new release, build, install, and test. All of the displayed strings should now be prefixed with "!!" until a translation package is provided.

[[Category: Localization]]

MeeGo Porting Guide

2010-09-13T16:59:06Z

Mikeleib: /* Location */

== Introduction ==
The goal of MeeGo Porting Guide (MPG) is to provide valuable information and instructions to people who want to run MeeGo OS on their (new) HW and eventually create products based on the MeeGo OS. The MPG starts with an overview of the porting process, tools and other related background information and then moves on to describing what the porting actually means in individual technical/functional areas.

The porting guide is not strictly tied to any particular MeeGo OS version or device category. Instead it tries to be general enough to cover the different device categories as well as follow changes introduced in new MeeGo OS versions.

Detailed porting information in the different technical areas is dependent on the respective [http://meego.com/developers/meego-architecture MeeGo architecture]. In some cases, this architecture may still be open and this is noted in the applicable sections.

=== Feedback ===

Contribution to these pages is open. Any MeeGo community member is free to ''improve'' these pages at any time. You can also leave feedback at the [[Talk:MeeGo_Porting_Guide|discussion page]].

== General porting information/guidelines ==

=== MeeGo compliance ===

Perhaps the most important piece of background information related to the MPG are the [http://wiki.meego.com/Quality/Compliance MeeGo compliance requirements]. A device that is meant to be MeeGo compliant will need to fulfill the requirements listed in the MeeGo compliance specification for the applicable device category (the first version of the specification is supposed to be available in October 2010). In short, a MeeGo compliant device will need to:
* Meet the minimum HW performance and component requirements for the applicable device category
* Include all SW components that form the MeeGo core OS
* Include the additional SW components required to be present in devices in the applicable device category
* Not break the API/ABI of any of the components coming from MeeGo
* Follow the MeeGo SW packaging conventions

The compliance rules will also specify CPU architecture specific requirements concerning how MeeGo OS itself and MeeGo applications are to be compiled to different environments (instruction set used, compiler version, compiler options etc.).

A device vendor may include additional functionality, HW components and SW components in their devices as long as they don't break MeeGo compliance. The vendor can also patch MeeGo OS components if the patches don't break MeeGo compliance. A device vendor's own SW components can be either open source or closed source components as long as they adhere to the rules set by the applicable SW licenses.

From the MeeGo Porting Guide perspective, the compliance requirements - by defining the SW components and HW components that need to be present - effectively define the minimum set of porting tasks required from a device vendor and what SW components are involved from MeeGo OS side.

=== Porting process and tools ===

==== Overview ====

As long as some vendor's device is MeeGo compliant as defined above, it is basically up to the vendor to decide how they build the SW that ends up in the device. The vendor may use their own build machinery or setup an OBS build system that is used also in MeeGo. Regardless of what the vendor's build system is, it needs to integrate with the MeeGo build infrastructure at least to fetch the MeeGo source packages for the builds as well as build each MeeGo component in the same way as it would be built in the MeeGo build system (e.g. with the same compiler and compiler options). Whatever the case, the intention in MeeGo is to use and offer an open toolset that any HW or SW vendor can use for efficient SW creation. It is likely that using the same toolset as MeeGo will offer the easiest way to integrate vendor's own build system with the the MeeGo build infrastructure.

The key ingredients of the MeeGo build infrastructure and toolset are:
* [http://meego.gitorious.org MeeGo Gitorious]
** A version control system for the source files of various MeeGo specific SW components and tools
* [http://build.meego.com MeeGo OBS]
** The build system that is used to build MeeGo packages (RPMs) from their sources
* [http://repo.meego.com MeeGo Repository]
** The place where the built MeeGo releases, i.e. MeeGo packages and images are stored
* [http://wiki.meego.com/Image_Creation MeeGo Image Creator]
** The tool used to build MeeGo images that can be installed/flashed on HW
* MeeGo release tools
** Tools such as BOSS and REVS that are used in the creation of the MeeGo releases under repo.meego.com

For additional information, see [http://wiki.meego.com/Build_Infrastructure Build Infrastructure], [http://wiki.meego.com/Release_Infrastructure Release Infrastructure] and [http://wiki.meego.com/Release_Engineering Release Engineering].

For another overview of the MeeGo porting process, see [http://meego.com/developers/hardware-enabling-process Hardware Enabling Process].

==== Vendor's own OBS ====

So, ultimately, when creating actual products running the MeeGo OS, the vendor may end up setting up their own OBS build system. An own OBS system may also be beneficial in earlier HW/product development phases as it offers a flexible way to modify and build MeeGo OS to test it on the new HW. The vendor's own OBS system can link to the MeeGo OBS for handling packages that come directly from MeeGo and it an link to other sources for handling e.g. closed source packages that are specific to the vendor. An overview picture of this setup can be found from [http://wiki.meego.com/Release_Engineering/Process#Making_a_product_out_of_MeeGo_Release here].

In this setup, the vendor:
* Sets up their own OBS system
** One set of instructions can be found from [http://wiki.meego.com/Build_Infrastructure/Sysadmin_Distro/OBS_setup_openSUSE112 here].
* Creates projects under the their own OBS for their own components
* Links their own OBS to the MeeGo OBS for MeeGo components
* May have trial patches to MeeGo components in their own OBS
** NOTE. Eventually all patches to MeeGo components required in a final MeeGo based product ''should'' be pushed to MeeGo.com. However, this is not an absolute must requirement as long as the MeeGo compliance requirements and applicable SW license rules are fulfilled.
** See [[#Upstream_projects,_MeeGo,_products_and_patches|''Upstream projects, MeeGo, products and patches'']] below
* Needs to setup the necessary machinery to create releases and images from the packages built with OBS
** This machinery can be based on the toolset used in MeeGo (see above)

==== Working under MeeGo.com ====

Another way of porting MeeGo to some new HW is to get the new HW accepted as one MeeGo reference HW and have the MeeGo build machinery create builds for the reference HW as a part of the normal MeeGo release building cycle (see [http://wiki.meego.com/Release_Engineering/Release_Timeline Release Timeline] and [http://wiki.meego.com/Release_Engineering/Process Release Process]). This setup can also include QA support for the reference HW on the MeeGo side (see [http://wiki.meego.com/Quality Quality]). At the time of this writing, the actual process of getting new reference HW to MeeGo is still somewhat unclear. In any case, this model requires active participation from the vendor in MeeGo work in general and especially in supporting their reference HW in MeeGo.

In this setup, the vendor:
* Creates a device/platform development project under the MeeGo OBS for their components. The open source components would then get submitted to MeeGo Trunk:Testing and get reviewed like any other MeeGo component for inclusion.
** Note that it is also possible to have closed source binary components in the MeeGo OBS to be included in the MeeGo builds for some reference HW. These are submitted to the Trunk:non-oss repository. Licensing is usually required to at least include redistributability as the components cannot be mirrored from or hosted at repo.meego.com otherwise. It is not possible to have components within Trunk:Testing require closed source dependencies.
* Pushes patches to other MeeGo components at MeeGo.com as necessary (see [[#Upstream_projects,_MeeGo,_products_and_patches|''Upstream projects, MeeGo, products and patches'']] below)
* Creates (or supports the creation of) a MIC kickstart file for building images for their reference HW
* As necessary, supports adding support for their reference HW and SW components in the MeeGo build and release infrastructure tools

==== Initial bring-up attempt ====

Yet another, lightweight but also more limited "try it out" alternative to the above processes consists of these steps:

* Grab an already built root filesystem / image for a MeeGo reference device that's the most closest to your target. For ARMv7 this is typically the Nokia N900 handset image, for Atom, this could be netbook image or handset image.
* Build a Linux kernel for your device and install the modules into /lib/modules.
* Boot the root filesystem and modify the configuration and drop in components to bring up the device to UX. Note down the things you had to modify or add as this will be input for your porting work.

==== Building your first image ====

The second step to a proper hardware adaptation is making sure you can build your own image. Since we based our work before on a reference device image, it makes sense to try to build this image first. MeeGo images are constructed on the basis of so called 'kickstart files' which describe the intended contents of a image.

* Install the MeeGo Image Creator tool (MIC)
* Download the kickstart file (.ks) from the same directory you found your reference device image.
* Create a image using mic-image-creator (should be elaborated).
* Test our your freshly baked image as in previous step.

==== Building your ports first reproducable image ====

* Download the MeeGo kernel, possibly modifying the kernel with additional patches (including new device drivers) and building the kernel (see [[#Getting_new_chipset_support_to_the_MeeGo_kernel|''Getting new chipset support to the MeeGo kernel'']] below).
* Add the repository containing your kernel package to the kickstart fine (to be elaborated)
* Remove parts of the kickstart file specific to the reference device.
* Add a mention of your kernel package in the %packages section.
* Build packages or include shell scripts in %post section of kickstart file that adds/modifies configuration fitting your device.

A detailed description of a variation of this model can be found from [http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch here] (Better description needed).

==== Getting new chipset support to the MeeGo kernel ====

See [http://wiki.meego.com/How-to:_getting_new_chipset_support_to_the_MeeGo_kernel How-to: getting new chipset support to the MeeGo kernel] for more detailed information about how to work with the MeeGo kernel and make it support new HW.

=== Upstream projects, MeeGo, products and patches ===

When building a product based on MeeGo, the product vendor will typically augment the MeeGo OS with their own SW components as well as make fixes and adjustments to the MeeGo OS code (in the limits set by the compliance rules). While vendors can manage their own SW components as they wish, the strong preference is that any changes made to the MeeGo OS SW components are delivered as patches primarily to the respective upstream projects or secondarily to MeeGo.com. In this way vendors can relieve themselves from the burden of managing a potentially big patch set on top of MeeGo OS and also verify the quality and safety of their patches. Having the patches in upstream projects again lessens the patch set management load at MeeGo.com.

For information about pushing patches to MeeGo, see [http://meego.com/about/contribution-guidelines Contribution Guidelines] and [http://meego.com/developers/hardware-enabling-process Hardware Enabling Process] (especially section ''How Do Patches Get Integrated and Accepted?'') and [http://meego.gitorious.org/meego-os-base/kernel-source/blobs/master/README.workflow Kernel workflow].

== Porting by functional areas ==

=== HW adaptation interfaces ===

The key goal in the sections below is to identify the SW interface(s) through which the MeeGo OS generic SW components communicate with the HW adaptation SW. These interfaces are effectively the SW interfaces that the HW adaptation SW needs to implement/use towards MeeGo OS. Behind these interfaces the HW adaptation SW components can basically do their job as they see best. In some cases, however, there may be some preferred (but not required) way of implementing the adaptation.

In some functional areas, the adaptation work may consist of just writing a suitable Linux device driver for the HW in question. In some other areas, the adaptation work may consist of writing one or more device drivers as well as one or more plugins to some user-space SW frameworks. Various configuration file changes may also be a required part of the adaptation work.

=== Fundamental functionality ===

==== Boot ====

MeeGo places no restrictions as to what SW components are used to handle the pre-OS boot phases in a MeeGo compliant device. Thus, vendors are free to choose e.g. the boot loader as they see fit. Note however that full utilization of the MeeGo platform security requires that the pre-OS boot phases form a trusted boot chain that ultimately builds on chipset-level security support.

At the time of this writing, MeeGo does not define anything special with regard to what information the boot loader is expected to pass to the Linux kernel e.g. via the kernel command line.

The kernel-level boot phases can be tailored as necessary to the specific CPU, chipset or device in a standard Linux manner.

The post-kernel boot phases (startup scripts) can be tailored by device vendors as necessary for their devices in the limits set by MeeGo compliance requirements (certain SW components need to be present in the system).

==== Kernel fundamentals ====

Regarding the Linux kernel, each MeeGo release defines the kernel version to be used and a set of patches on top of that. In addition, the Linux kernel used in MeeGo compliant devices is assumed to have been built with a set of fixed build-time configuration values that are not allowed to be changed. In addition to the fixed values, device vendors can define other kernel configuration values as required by their devices.

MeeGo does place any special requirements concerning how the boot loader passes information to the kernel or how the HW configuration and initialization of the system is handled.

CPU, chipset (SoC) and device vendors are assumed to implement the elementary CPU architecture/chipset/device support for the Linux kernel used in MeeGo in a standard Linux manner. This includes:
* HW (board) configuration
* Mapping the fundamental Linux kernel functionality (e.g. IRQ, DMA, GPIO, RTC and memory handling) to the HW in question
* Creation/modification of the necessary device drivers to support the core SoC interfaces (e.g. I2C, SPI, SDIO)
* Permanent memory support
* Debugging and tracing support

==== Power and thermal management ====

At the time of this writing, the understanding is that MeeGo in general relies on established Linux kernel frameworks and APIs for power management. Some of these frameworks and APIs may be applicable only in certain CPU architectures. In addition, the HW capabilities related to power management may vary between different HW platforms potentially meaning that the SW is assumed perform somewhat different tasks in different environments.

The Linux power management frameworks and APIs include:
* CPU frequency control (support for the different voltage and frequency operating points) via the cpufreq infrastructure
* CPU idle state management (different levels of sleep) through the cpuidle infrastructure
* Clock management through the clock framework
* Suspend/resume
* Runtime power management
* HW voltage/current regulator control via the regulator framework
* PM_QOS (power management quality of service) framework for making and listening to PM QoS requests

Whether MeeGo will have some user space SW components or framework related to power management is under discussion at the time of this writing.

In the thermal management area, the Device State Management Entity (DSME) component in the Device Health subsystem is supposed to make thermal state management decisions in the system. The DSME has a thermal manager module that again uses other DSME modules (thermal objects) to access the actual thermal sensor information in the HW. To port this functionality to new HW, one or more DSME thermal object modules need to be implemented.

The APIs that the thermal object modules use to access the thermal sensor information are not strictly defined by MeeGo. At device driver level, however, the preferred approach is to utilize standard Linux interfaces such as the generic thermal sysfs API or the hwmon sysfs API.

==== Energy management ====

At the time of this writing, basically the only thing that MeeGo requires from HW adaptation in the energy management area (battery charging and monitoring) is support for the Linux power supply sysfs class. Additional energy management related functionality can be handled in a vendor specific manner.

==== Security ====

Work is ongoing in bringing platform security functionality to the MeeGo OS based on the Mandatory Access Control (MAC), Integrity Measurement Architecture (IMA) and Extended Verification Module (EVM) technologies in the Linux kernel. Maximum security can be reached if the MeeGo platform security functionality can rely on trusted platform support "below" the Linux kernel, effectively in the HW and the boot loader(s). MeeGo, however, places no strict requirements as to how the trusted platform support is implemented in MeeGo based devices.

MeeGo also includes the OpenSSL open source toolkit implementing general purpose cryptography functionality. Algorithms and operations supported by the OpenSSL toolkit can be accelerated in HW by using the OpenSSL engine architecture. OpenSSL also supports a cryptodev engine that uses crypto algorithms implemented in the Linux kernel.

Some devices may have a security watchdog in the HW that needs "kicking" at regular intervals to keep the device up and running. In MeeGo, watchdog kicking functionality is implemented in the Device State Management Entity (DSME) component. If security watchdog kicking is needed, the DSME needs to be adapted to handle that through the right device driver interface and at the right intervals.

==== Device state/behaviour management ====

The DSME component participates in device state management e.g. by managing device run level, reboot and shutdown, by monitoring the device thermal state and shutting down the device in fatal thermal conditions, and by handling HW watchdog kicking activity.

In a new HW environment, the DSME needs to be adapted to handle the watchdog kicking through the right device driver interfaces and at the right intervals. In addition, to port the DSME thermal management functionality to new HW, one or more DSME thermal object modules need to be implemented as described above in the [[#Power_and_thermal_management|''Power and thermal management'']] section.

The Resource (Policy) Manager component in the Device Health subsystem offers a generic framework for:
* Monitoring device and application events
* Managing policies that specify rules about what should happen in the device when certain events occur
* Making policy decisions when events occur (determining the needed changes in the device)
* Enforcing changes in the system through policy enforcement points

The Resource Manager can be used e.g. to change the audio routing in the device when the user attaches a wired headset to the device.

Event listening and change enforcement in the Resource Manager happens through plugin modules. Using the MeeGo OS in some new device effectively involves creating suitable Resource Manager policies and writing the necessary plugins for listening device/application events and changing device behaviour accordingly. Though not pure HW adaptation, this can be considered as a form of MeeGo OS "device adaptation".

=== Display and graphics ===

For an overview of the MeeGo visual services architecture, see [http://meego.com/developers/meego-architecture/visual-services Visual Services].

The key ingredients of the display and graphics architecture in MeeGo are the X Window System (X Server with its extensions) and the Khronos graphics APIs (OpenGL ES, OpenVG and EGL with their extensions).

The display and graphics HW adaptation SW needs to enable the X Window System and the Khronos APIs to function on the device HW. In practice, the adaptation SW needs to have an X display/video driver (hosted inside the X Server) and libraries that implement the Khronos graphics APIs, both supporting the features and functionality required by MeeGo. Also some configuration file changes may be needed. Any additional user space and kernel space components needed for the HW adaptation are implementation dependent.

=== Media ===

For an overview of the MeeGo media services architecture, see [http://meego.com/developers/meego-architecture/media-services Media Services].

==== Audio ====

The audio architecture in MeeGo is centered around the GStreamer and PulseAudio frameworks. In addition, the Resource Manager plays a role in coordinating the audio related behavior of the device. The audio HW adaptation SW needs to provide GStreamer elements and PulseAudio plugins that enable the GStreamer and PulseAudio client interfaces used for e.g. for audio playback, recording and volume control to work on the device. Typical required components include e.g. codec elements for GStreamer and sink/source plugins for PulseAudio.

Behind the GStreamer and PulseAudio plugins, the audio HW adaptation SW can be implemented with different technologies and APIs, including ALSA and OpenMAX. In case OpenMAX components are used, the gst-omx package must be used to offer those to the GStreamer framework as needed. Use of the ALSA framework and APIs is encouraged, however, as they allow significant reuse of components and functionality on the PulseAudio level and are already a part of the upstream Linux kernel. If ALSA is not used to implement the kernel side parts of the audio adaptation, the solution that is used instead should still be aligned with the upstream Linux kernel.

==== Still imaging ====

The central pieces of the MeeGo still imaging architecture are the [http://gstreamer.freedesktop.org/ GStreamer] multimedia framework and the CameraBin GStreamer element. The still imaging HW adaptation SW is required to contain a GStreamer camera source element to be used "inside" the CameraBin element. Thus, the required HW adaptation interfaces are the relevant GStreamer plugin interfaces and especially the interfaces expected by the CameraBin element, in particular the GstPhotography interface.

If HW accelerated encoders are supported, they should be also offered to the system as GStreamer elements.

Behind the GStreamer elements, the HW adaptation SW can be implemented with different technologies and APIs, including V4L2 and OpenMAX. In case OpenMAX components are used, the gst-omx package must be used to offer those to the GStreamer framework.

==== Video imaging ====

The central pieces of the MeeGo video imaging architecture are the [http://gstreamer.freedesktop.org/ GStreamer] multimedia framework, the CameraBin GStreamer element (video recording) and the Playbin2 GStreamer element (video playback). The video imaging HW adaptation SW is required to contain:
:* A GStreamer camera source element to be used "inside" the CameraBin element (this is common with still imaging)
:* If HW accelerated codecs are supported, GStreamer elements that wrap the codecs
:* If HW accelerated filters are supported (e.g. video scaler, rotation engines, color conversion engines), GStreamer elements that wrap the filters
:* A GStreamer video sink element that offers the GStreamer X Overlay Interface. Note that if the XVideo extension is supported on the X Server side, the xvimagesink element can be used as the video sink element and no new elements are needed.

Behind the GStreamer elements, the video imaging HW adaptation SW can be implemented with different technologies and APIs, including V4L2 and OpenMAX. In case OpenMAX components are used, the gst-omx package must be used to offer those to the GStreamer framework.

=== Communications ===

For an overview of the MeeGo communications services architecture, see [http://meego.com/developers/meego-architecture/comms-services Comms Services].

==== Cellular ====

The cellular telephony architecture in MeeGo is centered on the oFono, PulseAudio and Telepathy frameworks. In addition, the Resource Manager plays a role in coordinating the device behavior during voice calls.

The cellular modem HW adaptation SW must implement the following interfaces towards the MeeGo OS:
:* oFono modem plugin/driver API
:* Linux network interface for the Linux TCP/IP stack (for data communications)
:* Relevant PulseAudio plugin interfaces for cellular voice call audio handling

For more detailed information about the oFono APIs, see the documentation and source code available at [http://git.kernel.org/?p=network/ofono/ofono.git;a=summary oFono git].

==== USB ====

The foundation of the the MeeGo USB functionality is the standard Linux USB subsystem. The Linux USB subsystem defines the USB related HW adaptation interfaces that need to be supported in MeeGo. In practice, these are kernel side interfaces between the generic USB functionality and a HW dependent USB host controller driver.

==== WLAN ====

The MeeGo WLAN architecture is centered on the [http://linuxwireless.org/ Linux wireless] (IEEE-802.11) subsystem. The Linux wireless SW stack defines the WLAN HW adaptation SW interfaces that need to be used in MeeGo. In practice, the required interfaces are defined by cfg80211 for FullMAC WLAN devices and by mac80211 for SoftMAC WLAN devices. In addition, a Linux network interface needs to be supported towards the Linux TCP/IP stack.

==== Bluetooth ====

The MeeGo Bluetooth architecture is centered on the [http://www.bluez.org/ BlueZ] SW stack. The BlueZ SW stack defines the Bluetooth HW adaptation SW interfaces that need to be used in MeeGo. In practice, these are Linux kernel side interfaces between the generic HCI (Host Controller Interface) core and a HW specific HCI driver.

=== User/environment IO ===

==== Location ====

The MeeGo location architecture is based on [http://http://labs.trolltech.com/page/Projects/QtMobility| QtMobility Location API]. The QtMobility 1.0 Location API provides geographic coordinates only. The QtMobility 1.1 Location API provides geocoding and reverse geocoding, POI search, navigation, and mapping. The 1.0 Location API is available in MeeGo 1.1. The 1.1 or later Location API will be available in MeeGo 1.2. The Location API uses a plugin system for implementations of the underlying backend. MeeGo compliance requirements require support for the QtMobility Location API and thus require one or more plugins to support these APIs. MeeGo places no restrictions as to how the plugins are implemented, however. Adaptation to location related HW happens may be done by manufactureres or service providers and the way how it's done is not defined by the API.

==== Sensors ====

The key component in the MeeGo sensor handling architecture is the Sensor Framework. The Sensor Framework uses both HW independent logical sensor plugins and HW dependent sensor adaptor plugins in its operation. The required sensor HW adaptation interfaces in MeeGo are the interfaces that the Sensor Framework and the logical sensor plugins define for the sensor adaptor plugins to implement. The sensor adaptor plugins typically communicate directly with sensor HW drivers in the Linux kernel. The interfaces that the sensor HW drivers expose to the user space are not defined by MeeGo. Sensor HW adaptation in MeeGo thus consists of adaptor plugins in the Sensor Framework and sensor HW drivers in the Linux kernel.

Note that thermal sensors are handled in a different manner as described in the [[#Power and thermal management|''Power and thermal management'']] section above.

==== Touch ====

The key SW components on the touch input handling path in MeeGo are the touch HW device driver, Linux kernel input subsystem, X server, X input driver, Qt and finally the MeeGo Touch Framework. Enabling touch support for some new HW requires at least the implementation of the corresponding touch HW device driver in the Linux kernel. If this driver communicates touch events to the user space in a "standard" manner via the Linux kernel input subsystem, basically the existing functionality in X server (e.g. evdev input driver) and above can be used as such. In case the kernel-to-user-space interface is non-standard, it is also possible to implement a new X input driver as a part of the touch HW adaptation.

At the time of this writing, official X server support for multi-touch is only on its way to implementations. Multi-touch support in X requires a new version, 2.1, of the [http://cgit.freedesktop.org/~whot/inputproto/tree/XI2proto.txt?h=multitouch X Input Extension] and this means also changes to the client side, in this case Qt's multi-touch support. Once this support has been implemented throughout the SW stack, including X evdev input driver, supporting multi-touch for some new HW should require only the implementation of the corresponding touch HW device driver in the Linux kernel. Meanwhile, multi-touch support in MeeGo uses a special X input driver (mtev), X server multi-pointer support (MPX) and Qt multi-touch support written on top of MPX. Thus, at this point, the user-space interface exposed by the touch HW device driver needs to be compatible with mtev.

==== HW keyboard ====

The key SW components on the HW keyboard input handling path in MeeGo are the keyboard HW device driver, Linux kernel input subsystem, X server, X input driver and Qt. Enabling keyboard support for some new HW requires typically only the implementation of the corresponding keyboard HW device driver in the Linux kernel. If this driver communicates key events to the user space in a "standard" manner via the Linux kernel input subsystem, the existing functionality in X server (e.g. evdev input driver) and above should work as such. In case the kernel-to-user space interface is non-standard, it is also possible to implement a new X input driver as a part of the keyboard HW adaptation.

==== Haptics ====

The MeeGo Touch Framework present (at least) in the MeeGo handset device category contains a component called Feedback Framework (meegotouch-feedback) that handles the creation of auditory and/or haptic feedback to touch events. The haptic feedback can be created e.g. with vibra motors or piezo elements. In the Feedback Framework, the different types of feedback are created by backend libraries implemented as plugins.

The haptics related HW adaptation interface from MeeGo OS perspective is the backend plugin interface defined by the Feedback Framework. The plugins can then communicate with the HW either through some device driver interface or some intermediate SW layers (MeeGo places no restrictions as to how the plugins are implemented).

==== Vibra (notifications/alerts) ====

At the time of this writing, MeeGo does not yet define a HW adaptation interface for notification/alert type vibra playback. Such a definition is likely, however, as e.g. the MeeGo Touch Framework has the capability of playing back vibra as a part of notification handling.

See the previous section for information about how vibra HW adaptation is handled for haptic feedback.

==== Miscellaneous (LEDs, keys, switches etc.) ====

At the time of this writing, MeeGo does not define HW adaptation interfaces for things like:
* Controlling LEDs
* Handling the various keys and switches in the device (e.g. power key, volume key, camera button, slider switch)
* Touch screen or HW keyboard enabling/disabling depending on device state
* Keyboard backlight control
* Display state (on/off) and brightness control

Thus, for now, these issues can be handled in a vendor specific manner.

=== Flashing, testing, tuning, certification ===

The current understanding is that flashing, self-testing, functional testing, tuning and certification related issues are handled in a vendor specific manner.

MeeGo Porting Guide

2010-09-13T16:57:42Z

Mikeleib: /* Location */

== Introduction ==
The goal of MeeGo Porting Guide (MPG) is to provide valuable information and instructions to people who want to run MeeGo OS on their (new) HW and eventually create products based on the MeeGo OS. The MPG starts with an overview of the porting process, tools and other related background information and then moves on to describing what the porting actually means in individual technical/functional areas.

The porting guide is not strictly tied to any particular MeeGo OS version or device category. Instead it tries to be general enough to cover the different device categories as well as follow changes introduced in new MeeGo OS versions.

Detailed porting information in the different technical areas is dependent on the respective [http://meego.com/developers/meego-architecture MeeGo architecture]. In some cases, this architecture may still be open and this is noted in the applicable sections.

=== Feedback ===

Contribution to these pages is open. Any MeeGo community member is free to ''improve'' these pages at any time. You can also leave feedback at the [[Talk:MeeGo_Porting_Guide|discussion page]].

== General porting information/guidelines ==

=== MeeGo compliance ===

Perhaps the most important piece of background information related to the MPG are the [http://wiki.meego.com/Quality/Compliance MeeGo compliance requirements]. A device that is meant to be MeeGo compliant will need to fulfill the requirements listed in the MeeGo compliance specification for the applicable device category (the first version of the specification is supposed to be available in October 2010). In short, a MeeGo compliant device will need to:
* Meet the minimum HW performance and component requirements for the applicable device category
* Include all SW components that form the MeeGo core OS
* Include the additional SW components required to be present in devices in the applicable device category
* Not break the API/ABI of any of the components coming from MeeGo
* Follow the MeeGo SW packaging conventions

The compliance rules will also specify CPU architecture specific requirements concerning how MeeGo OS itself and MeeGo applications are to be compiled to different environments (instruction set used, compiler version, compiler options etc.).

A device vendor may include additional functionality, HW components and SW components in their devices as long as they don't break MeeGo compliance. The vendor can also patch MeeGo OS components if the patches don't break MeeGo compliance. A device vendor's own SW components can be either open source or closed source components as long as they adhere to the rules set by the applicable SW licenses.

From the MeeGo Porting Guide perspective, the compliance requirements - by defining the SW components and HW components that need to be present - effectively define the minimum set of porting tasks required from a device vendor and what SW components are involved from MeeGo OS side.

=== Porting process and tools ===

==== Overview ====

As long as some vendor's device is MeeGo compliant as defined above, it is basically up to the vendor to decide how they build the SW that ends up in the device. The vendor may use their own build machinery or setup an OBS build system that is used also in MeeGo. Regardless of what the vendor's build system is, it needs to integrate with the MeeGo build infrastructure at least to fetch the MeeGo source packages for the builds as well as build each MeeGo component in the same way as it would be built in the MeeGo build system (e.g. with the same compiler and compiler options). Whatever the case, the intention in MeeGo is to use and offer an open toolset that any HW or SW vendor can use for efficient SW creation. It is likely that using the same toolset as MeeGo will offer the easiest way to integrate vendor's own build system with the the MeeGo build infrastructure.

The key ingredients of the MeeGo build infrastructure and toolset are:
* [http://meego.gitorious.org MeeGo Gitorious]
** A version control system for the source files of various MeeGo specific SW components and tools
* [http://build.meego.com MeeGo OBS]
** The build system that is used to build MeeGo packages (RPMs) from their sources
* [http://repo.meego.com MeeGo Repository]
** The place where the built MeeGo releases, i.e. MeeGo packages and images are stored
* [http://wiki.meego.com/Image_Creation MeeGo Image Creator]
** The tool used to build MeeGo images that can be installed/flashed on HW
* MeeGo release tools
** Tools such as BOSS and REVS that are used in the creation of the MeeGo releases under repo.meego.com

For additional information, see [http://wiki.meego.com/Build_Infrastructure Build Infrastructure], [http://wiki.meego.com/Release_Infrastructure Release Infrastructure] and [http://wiki.meego.com/Release_Engineering Release Engineering].

For another overview of the MeeGo porting process, see [http://meego.com/developers/hardware-enabling-process Hardware Enabling Process].

==== Vendor's own OBS ====

So, ultimately, when creating actual products running the MeeGo OS, the vendor may end up setting up their own OBS build system. An own OBS system may also be beneficial in earlier HW/product development phases as it offers a flexible way to modify and build MeeGo OS to test it on the new HW. The vendor's own OBS system can link to the MeeGo OBS for handling packages that come directly from MeeGo and it an link to other sources for handling e.g. closed source packages that are specific to the vendor. An overview picture of this setup can be found from [http://wiki.meego.com/Release_Engineering/Process#Making_a_product_out_of_MeeGo_Release here].

In this setup, the vendor:
* Sets up their own OBS system
** One set of instructions can be found from [http://wiki.meego.com/Build_Infrastructure/Sysadmin_Distro/OBS_setup_openSUSE112 here].
* Creates projects under the their own OBS for their own components
* Links their own OBS to the MeeGo OBS for MeeGo components
* May have trial patches to MeeGo components in their own OBS
** NOTE. Eventually all patches to MeeGo components required in a final MeeGo based product ''should'' be pushed to MeeGo.com. However, this is not an absolute must requirement as long as the MeeGo compliance requirements and applicable SW license rules are fulfilled.
** See [[#Upstream_projects,_MeeGo,_products_and_patches|''Upstream projects, MeeGo, products and patches'']] below
* Needs to setup the necessary machinery to create releases and images from the packages built with OBS
** This machinery can be based on the toolset used in MeeGo (see above)

==== Working under MeeGo.com ====

Another way of porting MeeGo to some new HW is to get the new HW accepted as one MeeGo reference HW and have the MeeGo build machinery create builds for the reference HW as a part of the normal MeeGo release building cycle (see [http://wiki.meego.com/Release_Engineering/Release_Timeline Release Timeline] and [http://wiki.meego.com/Release_Engineering/Process Release Process]). This setup can also include QA support for the reference HW on the MeeGo side (see [http://wiki.meego.com/Quality Quality]). At the time of this writing, the actual process of getting new reference HW to MeeGo is still somewhat unclear. In any case, this model requires active participation from the vendor in MeeGo work in general and especially in supporting their reference HW in MeeGo.

In this setup, the vendor:
* Creates a device/platform development project under the MeeGo OBS for their components. The open source components would then get submitted to MeeGo Trunk:Testing and get reviewed like any other MeeGo component for inclusion.
** Note that it is also possible to have closed source binary components in the MeeGo OBS to be included in the MeeGo builds for some reference HW. These are submitted to the Trunk:non-oss repository. Licensing is usually required to at least include redistributability as the components cannot be mirrored from or hosted at repo.meego.com otherwise. It is not possible to have components within Trunk:Testing require closed source dependencies.
* Pushes patches to other MeeGo components at MeeGo.com as necessary (see [[#Upstream_projects,_MeeGo,_products_and_patches|''Upstream projects, MeeGo, products and patches'']] below)
* Creates (or supports the creation of) a MIC kickstart file for building images for their reference HW
* As necessary, supports adding support for their reference HW and SW components in the MeeGo build and release infrastructure tools

==== Initial bring-up attempt ====

Yet another, lightweight but also more limited "try it out" alternative to the above processes consists of these steps:

* Grab an already built root filesystem / image for a MeeGo reference device that's the most closest to your target. For ARMv7 this is typically the Nokia N900 handset image, for Atom, this could be netbook image or handset image.
* Build a Linux kernel for your device and install the modules into /lib/modules.
* Boot the root filesystem and modify the configuration and drop in components to bring up the device to UX. Note down the things you had to modify or add as this will be input for your porting work.

==== Building your first image ====

The second step to a proper hardware adaptation is making sure you can build your own image. Since we based our work before on a reference device image, it makes sense to try to build this image first. MeeGo images are constructed on the basis of so called 'kickstart files' which describe the intended contents of a image.

* Install the MeeGo Image Creator tool (MIC)
* Download the kickstart file (.ks) from the same directory you found your reference device image.
* Create a image using mic-image-creator (should be elaborated).
* Test our your freshly baked image as in previous step.

==== Building your ports first reproducable image ====

* Download the MeeGo kernel, possibly modifying the kernel with additional patches (including new device drivers) and building the kernel (see [[#Getting_new_chipset_support_to_the_MeeGo_kernel|''Getting new chipset support to the MeeGo kernel'']] below).
* Add the repository containing your kernel package to the kickstart fine (to be elaborated)
* Remove parts of the kickstart file specific to the reference device.
* Add a mention of your kernel package in the %packages section.
* Build packages or include shell scripts in %post section of kickstart file that adds/modifies configuration fitting your device.

A detailed description of a variation of this model can be found from [http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch here] (Better description needed).

==== Getting new chipset support to the MeeGo kernel ====

See [http://wiki.meego.com/How-to:_getting_new_chipset_support_to_the_MeeGo_kernel How-to: getting new chipset support to the MeeGo kernel] for more detailed information about how to work with the MeeGo kernel and make it support new HW.

=== Upstream projects, MeeGo, products and patches ===

When building a product based on MeeGo, the product vendor will typically augment the MeeGo OS with their own SW components as well as make fixes and adjustments to the MeeGo OS code (in the limits set by the compliance rules). While vendors can manage their own SW components as they wish, the strong preference is that any changes made to the MeeGo OS SW components are delivered as patches primarily to the respective upstream projects or secondarily to MeeGo.com. In this way vendors can relieve themselves from the burden of managing a potentially big patch set on top of MeeGo OS and also verify the quality and safety of their patches. Having the patches in upstream projects again lessens the patch set management load at MeeGo.com.

For information about pushing patches to MeeGo, see [http://meego.com/about/contribution-guidelines Contribution Guidelines] and [http://meego.com/developers/hardware-enabling-process Hardware Enabling Process] (especially section ''How Do Patches Get Integrated and Accepted?'') and [http://meego.gitorious.org/meego-os-base/kernel-source/blobs/master/README.workflow Kernel workflow].

== Porting by functional areas ==

=== HW adaptation interfaces ===

The key goal in the sections below is to identify the SW interface(s) through which the MeeGo OS generic SW components communicate with the HW adaptation SW. These interfaces are effectively the SW interfaces that the HW adaptation SW needs to implement/use towards MeeGo OS. Behind these interfaces the HW adaptation SW components can basically do their job as they see best. In some cases, however, there may be some preferred (but not required) way of implementing the adaptation.

In some functional areas, the adaptation work may consist of just writing a suitable Linux device driver for the HW in question. In some other areas, the adaptation work may consist of writing one or more device drivers as well as one or more plugins to some user-space SW frameworks. Various configuration file changes may also be a required part of the adaptation work.

=== Fundamental functionality ===

==== Boot ====

MeeGo places no restrictions as to what SW components are used to handle the pre-OS boot phases in a MeeGo compliant device. Thus, vendors are free to choose e.g. the boot loader as they see fit. Note however that full utilization of the MeeGo platform security requires that the pre-OS boot phases form a trusted boot chain that ultimately builds on chipset-level security support.

At the time of this writing, MeeGo does not define anything special with regard to what information the boot loader is expected to pass to the Linux kernel e.g. via the kernel command line.

The kernel-level boot phases can be tailored as necessary to the specific CPU, chipset or device in a standard Linux manner.

The post-kernel boot phases (startup scripts) can be tailored by device vendors as necessary for their devices in the limits set by MeeGo compliance requirements (certain SW components need to be present in the system).

==== Kernel fundamentals ====

Regarding the Linux kernel, each MeeGo release defines the kernel version to be used and a set of patches on top of that. In addition, the Linux kernel used in MeeGo compliant devices is assumed to have been built with a set of fixed build-time configuration values that are not allowed to be changed. In addition to the fixed values, device vendors can define other kernel configuration values as required by their devices.

MeeGo does place any special requirements concerning how the boot loader passes information to the kernel or how the HW configuration and initialization of the system is handled.

CPU, chipset (SoC) and device vendors are assumed to implement the elementary CPU architecture/chipset/device support for the Linux kernel used in MeeGo in a standard Linux manner. This includes:
* HW (board) configuration
* Mapping the fundamental Linux kernel functionality (e.g. IRQ, DMA, GPIO, RTC and memory handling) to the HW in question
* Creation/modification of the necessary device drivers to support the core SoC interfaces (e.g. I2C, SPI, SDIO)
* Permanent memory support
* Debugging and tracing support

==== Power and thermal management ====

At the time of this writing, the understanding is that MeeGo in general relies on established Linux kernel frameworks and APIs for power management. Some of these frameworks and APIs may be applicable only in certain CPU architectures. In addition, the HW capabilities related to power management may vary between different HW platforms potentially meaning that the SW is assumed perform somewhat different tasks in different environments.

The Linux power management frameworks and APIs include:
* CPU frequency control (support for the different voltage and frequency operating points) via the cpufreq infrastructure
* CPU idle state management (different levels of sleep) through the cpuidle infrastructure
* Clock management through the clock framework
* Suspend/resume
* Runtime power management
* HW voltage/current regulator control via the regulator framework
* PM_QOS (power management quality of service) framework for making and listening to PM QoS requests

Whether MeeGo will have some user space SW components or framework related to power management is under discussion at the time of this writing.

In the thermal management area, the Device State Management Entity (DSME) component in the Device Health subsystem is supposed to make thermal state management decisions in the system. The DSME has a thermal manager module that again uses other DSME modules (thermal objects) to access the actual thermal sensor information in the HW. To port this functionality to new HW, one or more DSME thermal object modules need to be implemented.

The APIs that the thermal object modules use to access the thermal sensor information are not strictly defined by MeeGo. At device driver level, however, the preferred approach is to utilize standard Linux interfaces such as the generic thermal sysfs API or the hwmon sysfs API.

==== Energy management ====

At the time of this writing, basically the only thing that MeeGo requires from HW adaptation in the energy management area (battery charging and monitoring) is support for the Linux power supply sysfs class. Additional energy management related functionality can be handled in a vendor specific manner.

==== Security ====

Work is ongoing in bringing platform security functionality to the MeeGo OS based on the Mandatory Access Control (MAC), Integrity Measurement Architecture (IMA) and Extended Verification Module (EVM) technologies in the Linux kernel. Maximum security can be reached if the MeeGo platform security functionality can rely on trusted platform support "below" the Linux kernel, effectively in the HW and the boot loader(s). MeeGo, however, places no strict requirements as to how the trusted platform support is implemented in MeeGo based devices.

MeeGo also includes the OpenSSL open source toolkit implementing general purpose cryptography functionality. Algorithms and operations supported by the OpenSSL toolkit can be accelerated in HW by using the OpenSSL engine architecture. OpenSSL also supports a cryptodev engine that uses crypto algorithms implemented in the Linux kernel.

Some devices may have a security watchdog in the HW that needs "kicking" at regular intervals to keep the device up and running. In MeeGo, watchdog kicking functionality is implemented in the Device State Management Entity (DSME) component. If security watchdog kicking is needed, the DSME needs to be adapted to handle that through the right device driver interface and at the right intervals.

==== Device state/behaviour management ====

The DSME component participates in device state management e.g. by managing device run level, reboot and shutdown, by monitoring the device thermal state and shutting down the device in fatal thermal conditions, and by handling HW watchdog kicking activity.

In a new HW environment, the DSME needs to be adapted to handle the watchdog kicking through the right device driver interfaces and at the right intervals. In addition, to port the DSME thermal management functionality to new HW, one or more DSME thermal object modules need to be implemented as described above in the [[#Power_and_thermal_management|''Power and thermal management'']] section.

The Resource (Policy) Manager component in the Device Health subsystem offers a generic framework for:
* Monitoring device and application events
* Managing policies that specify rules about what should happen in the device when certain events occur
* Making policy decisions when events occur (determining the needed changes in the device)
* Enforcing changes in the system through policy enforcement points

The Resource Manager can be used e.g. to change the audio routing in the device when the user attaches a wired headset to the device.

Event listening and change enforcement in the Resource Manager happens through plugin modules. Using the MeeGo OS in some new device effectively involves creating suitable Resource Manager policies and writing the necessary plugins for listening device/application events and changing device behaviour accordingly. Though not pure HW adaptation, this can be considered as a form of MeeGo OS "device adaptation".

=== Display and graphics ===

For an overview of the MeeGo visual services architecture, see [http://meego.com/developers/meego-architecture/visual-services Visual Services].

The key ingredients of the display and graphics architecture in MeeGo are the X Window System (X Server with its extensions) and the Khronos graphics APIs (OpenGL ES, OpenVG and EGL with their extensions).

The display and graphics HW adaptation SW needs to enable the X Window System and the Khronos APIs to function on the device HW. In practice, the adaptation SW needs to have an X display/video driver (hosted inside the X Server) and libraries that implement the Khronos graphics APIs, both supporting the features and functionality required by MeeGo. Also some configuration file changes may be needed. Any additional user space and kernel space components needed for the HW adaptation are implementation dependent.

=== Media ===

For an overview of the MeeGo media services architecture, see [http://meego.com/developers/meego-architecture/media-services Media Services].

==== Audio ====

The audio architecture in MeeGo is centered around the GStreamer and PulseAudio frameworks. In addition, the Resource Manager plays a role in coordinating the audio related behavior of the device. The audio HW adaptation SW needs to provide GStreamer elements and PulseAudio plugins that enable the GStreamer and PulseAudio client interfaces used for e.g. for audio playback, recording and volume control to work on the device. Typical required components include e.g. codec elements for GStreamer and sink/source plugins for PulseAudio.

Behind the GStreamer and PulseAudio plugins, the audio HW adaptation SW can be implemented with different technologies and APIs, including ALSA and OpenMAX. In case OpenMAX components are used, the gst-omx package must be used to offer those to the GStreamer framework as needed. Use of the ALSA framework and APIs is encouraged, however, as they allow significant reuse of components and functionality on the PulseAudio level and are already a part of the upstream Linux kernel. If ALSA is not used to implement the kernel side parts of the audio adaptation, the solution that is used instead should still be aligned with the upstream Linux kernel.

==== Still imaging ====

The central pieces of the MeeGo still imaging architecture are the [http://gstreamer.freedesktop.org/ GStreamer] multimedia framework and the CameraBin GStreamer element. The still imaging HW adaptation SW is required to contain a GStreamer camera source element to be used "inside" the CameraBin element. Thus, the required HW adaptation interfaces are the relevant GStreamer plugin interfaces and especially the interfaces expected by the CameraBin element, in particular the GstPhotography interface.

If HW accelerated encoders are supported, they should be also offered to the system as GStreamer elements.

Behind the GStreamer elements, the HW adaptation SW can be implemented with different technologies and APIs, including V4L2 and OpenMAX. In case OpenMAX components are used, the gst-omx package must be used to offer those to the GStreamer framework.

==== Video imaging ====

The central pieces of the MeeGo video imaging architecture are the [http://gstreamer.freedesktop.org/ GStreamer] multimedia framework, the CameraBin GStreamer element (video recording) and the Playbin2 GStreamer element (video playback). The video imaging HW adaptation SW is required to contain:
:* A GStreamer camera source element to be used "inside" the CameraBin element (this is common with still imaging)
:* If HW accelerated codecs are supported, GStreamer elements that wrap the codecs
:* If HW accelerated filters are supported (e.g. video scaler, rotation engines, color conversion engines), GStreamer elements that wrap the filters
:* A GStreamer video sink element that offers the GStreamer X Overlay Interface. Note that if the XVideo extension is supported on the X Server side, the xvimagesink element can be used as the video sink element and no new elements are needed.

Behind the GStreamer elements, the video imaging HW adaptation SW can be implemented with different technologies and APIs, including V4L2 and OpenMAX. In case OpenMAX components are used, the gst-omx package must be used to offer those to the GStreamer framework.

=== Communications ===

For an overview of the MeeGo communications services architecture, see [http://meego.com/developers/meego-architecture/comms-services Comms Services].

==== Cellular ====

The cellular telephony architecture in MeeGo is centered on the oFono, PulseAudio and Telepathy frameworks. In addition, the Resource Manager plays a role in coordinating the device behavior during voice calls.

The cellular modem HW adaptation SW must implement the following interfaces towards the MeeGo OS:
:* oFono modem plugin/driver API
:* Linux network interface for the Linux TCP/IP stack (for data communications)
:* Relevant PulseAudio plugin interfaces for cellular voice call audio handling

For more detailed information about the oFono APIs, see the documentation and source code available at [http://git.kernel.org/?p=network/ofono/ofono.git;a=summary oFono git].

==== USB ====

The foundation of the the MeeGo USB functionality is the standard Linux USB subsystem. The Linux USB subsystem defines the USB related HW adaptation interfaces that need to be supported in MeeGo. In practice, these are kernel side interfaces between the generic USB functionality and a HW dependent USB host controller driver.

==== WLAN ====

The MeeGo WLAN architecture is centered on the [http://linuxwireless.org/ Linux wireless] (IEEE-802.11) subsystem. The Linux wireless SW stack defines the WLAN HW adaptation SW interfaces that need to be used in MeeGo. In practice, the required interfaces are defined by cfg80211 for FullMAC WLAN devices and by mac80211 for SoftMAC WLAN devices. In addition, a Linux network interface needs to be supported towards the Linux TCP/IP stack.

==== Bluetooth ====

The MeeGo Bluetooth architecture is centered on the [http://www.bluez.org/ BlueZ] SW stack. The BlueZ SW stack defines the Bluetooth HW adaptation SW interfaces that need to be used in MeeGo. In practice, these are Linux kernel side interfaces between the generic HCI (Host Controller Interface) core and a HW specific HCI driver.

=== User/environment IO ===

==== Location ====

The MeeGo location architecture is based on [http://http://labs.trolltech.com/page/Projects/QtMobility] Location API. The QtMobility 1.0 Location API provides geographic coordinates only. The QtMobility 1.1 Location API provides geocoding and reverse geocoding, POI search, navigation, and mapping. The 1.0 Location API is available in MeeGo 1.1. The 1.1 or later Location API will be available in MeeGo 1.2. The Location API uses a plugin system for implementations of the underlying backend. MeeGo compliance requirements require support for the QtMobility Location API and thus require one or more plugins to support these APIs. MeeGo places no restrictions as to how the plugins are implemented, however. Adaptation to location related HW happens may be done by manufactureres or service providers and the way how it's done is not defined by the API.

==== Sensors ====

The key component in the MeeGo sensor handling architecture is the Sensor Framework. The Sensor Framework uses both HW independent logical sensor plugins and HW dependent sensor adaptor plugins in its operation. The required sensor HW adaptation interfaces in MeeGo are the interfaces that the Sensor Framework and the logical sensor plugins define for the sensor adaptor plugins to implement. The sensor adaptor plugins typically communicate directly with sensor HW drivers in the Linux kernel. The interfaces that the sensor HW drivers expose to the user space are not defined by MeeGo. Sensor HW adaptation in MeeGo thus consists of adaptor plugins in the Sensor Framework and sensor HW drivers in the Linux kernel.

Note that thermal sensors are handled in a different manner as described in the [[#Power and thermal management|''Power and thermal management'']] section above.

==== Touch ====

The key SW components on the touch input handling path in MeeGo are the touch HW device driver, Linux kernel input subsystem, X server, X input driver, Qt and finally the MeeGo Touch Framework. Enabling touch support for some new HW requires at least the implementation of the corresponding touch HW device driver in the Linux kernel. If this driver communicates touch events to the user space in a "standard" manner via the Linux kernel input subsystem, basically the existing functionality in X server (e.g. evdev input driver) and above can be used as such. In case the kernel-to-user-space interface is non-standard, it is also possible to implement a new X input driver as a part of the touch HW adaptation.

At the time of this writing, official X server support for multi-touch is only on its way to implementations. Multi-touch support in X requires a new version, 2.1, of the [http://cgit.freedesktop.org/~whot/inputproto/tree/XI2proto.txt?h=multitouch X Input Extension] and this means also changes to the client side, in this case Qt's multi-touch support. Once this support has been implemented throughout the SW stack, including X evdev input driver, supporting multi-touch for some new HW should require only the implementation of the corresponding touch HW device driver in the Linux kernel. Meanwhile, multi-touch support in MeeGo uses a special X input driver (mtev), X server multi-pointer support (MPX) and Qt multi-touch support written on top of MPX. Thus, at this point, the user-space interface exposed by the touch HW device driver needs to be compatible with mtev.

==== HW keyboard ====

The key SW components on the HW keyboard input handling path in MeeGo are the keyboard HW device driver, Linux kernel input subsystem, X server, X input driver and Qt. Enabling keyboard support for some new HW requires typically only the implementation of the corresponding keyboard HW device driver in the Linux kernel. If this driver communicates key events to the user space in a "standard" manner via the Linux kernel input subsystem, the existing functionality in X server (e.g. evdev input driver) and above should work as such. In case the kernel-to-user space interface is non-standard, it is also possible to implement a new X input driver as a part of the keyboard HW adaptation.

==== Haptics ====

The MeeGo Touch Framework present (at least) in the MeeGo handset device category contains a component called Feedback Framework (meegotouch-feedback) that handles the creation of auditory and/or haptic feedback to touch events. The haptic feedback can be created e.g. with vibra motors or piezo elements. In the Feedback Framework, the different types of feedback are created by backend libraries implemented as plugins.

The haptics related HW adaptation interface from MeeGo OS perspective is the backend plugin interface defined by the Feedback Framework. The plugins can then communicate with the HW either through some device driver interface or some intermediate SW layers (MeeGo places no restrictions as to how the plugins are implemented).

==== Vibra (notifications/alerts) ====

At the time of this writing, MeeGo does not yet define a HW adaptation interface for notification/alert type vibra playback. Such a definition is likely, however, as e.g. the MeeGo Touch Framework has the capability of playing back vibra as a part of notification handling.

See the previous section for information about how vibra HW adaptation is handled for haptic feedback.

==== Miscellaneous (LEDs, keys, switches etc.) ====

At the time of this writing, MeeGo does not define HW adaptation interfaces for things like:
* Controlling LEDs
* Handling the various keys and switches in the device (e.g. power key, volume key, camera button, slider switch)
* Touch screen or HW keyboard enabling/disabling depending on device state
* Keyboard backlight control
* Display state (on/off) and brightness control

Thus, for now, these issues can be handled in a vendor specific manner.

=== Flashing, testing, tuning, certification ===

The current understanding is that flashing, self-testing, functional testing, tuning and certification related issues are handled in a vendor specific manner.

Who's who

2010-08-17T15:47:30Z

Mikeleib: /* MeeGo developers */

Let's use this page while it's useful. See also the [http://meego.com/community/members full list of meego.com members].

== MeeGo structure ==

=== Technical Steering Group ===
''Members of the [http://meego.com/about/governance TSG]''

* [http://meego.com/users/valhalla Valtteri Halla] (Nokia) - Benevolent dictator
* [http://meego.com/users/imad Imad Sousou/imad] (Intel) - Benevolent dictator

=== Architects ===
* [http://meego.com/users/poussa Sakari Poussa/poussa] (Nokia)
* [http://meego.com/users/mskarpne Mark Skarpness] (Intel)
* [http://meego.com/users/arjan Arjan Van De Ven] (Intel)
* [http://meego.com/users/mythi Mikko Ylinen] (Nokia)

=== Community Office ===

* [http://meego.com/users/dawnfoster Dawn Foster/dawnfoster] (Intel) - Coordinator
* [http://meego.com/users/qgil Quim Gil/qgil] (Nokia) - Coordinator

See also [[Community Office]] - [http://wiki.meego.com/index.php?title=Special%3AListUsers&username=&group=bureaucrat&limit=50 wiki administrators]

== MeeGo developers ==
People paid to contribute to MeeGo and/or have commit rights.

* [http://meego.com/users/hbons Hylke Bons/hbons] - User Experience Designer
* [http://meego.com/users/harrihakulinen Harri Hakulinen/Hah] - N900 Project Lead
* [http://meego.com/users/auke Auke Kok/auke] - Release developer, fast boot
* [http://meego.com/users/jku Jussi Kukkonen/jku] - Developer
* [http://meego.com/users/nmcgovern Neil McGovern/nmcgovern] - Developer
* [http://meego.com/users/nashif Anas Nashif/anaZ] - Distribution Architect
* [http://meego.com/users/pohly Patrick Ohly/pohly] - Developer
* [http://meego.com/users/quang Quang Pham/quang] - Developer
* [http://meego.com/users/zhuyanhai Zhu Yanhai/yanhai] - Developer
* [http://meego.com/users/rogerwang Roger WANG/roger] - Developer
* [http://meego.com/users/jbarnes Jesse Barnes/jbarnes] - Graphics stack developer
* [http://meego.com/users/jausmus James Ausmus/jausmus] - Developer
* [http://meego.com/users/fabo Fathi Boudra/fabo] - Developer
* [http://meego.com/users/sabotage Shane Bryan/sabotage] - Handset Developer
* [http://meego.com/users/mikeleib Michael Leibowitz/mikeleib] - Handset Developer
* [http://meego.com/users/mardy Alberto Mardegan/mardy] - Developer

== Linux Foundation contributors ==
'' Staff Members of the Linux Foundation [http://www.linuxfoundation.org]''

* [http://meego.com/users/martinmohring Martin Mohring/ScriptRipper ] - Build Platform Developer, [http://en.opensuse.org/Build_Service OBS] developer ([http://lizards.opensuse.org/2008/11/18/arm-support-for-opensuse-buildservice-and-opensuse ARM Support], [http://lizards.opensuse.org/2010/08/15/obs-2-1-features-and-status ACL], [http://en.opensuse.org//openSUSE:Build_Service_Testing testing environment] and other parts), Linux Foundation Staff Member
* [http://meego.com/users/dl9pf Jan-Simon Möller/dl9pf ] - Build Platform Developer, long-term [http://en.opensuse.org/Build_Service OBS] source contributor, Linux Foundation Staff Member
* [http://meego.com/users/ibrahim Ibrahim Haddad/ibrahim ] - Linux Foundation Director of Engineering/Technical Alliances, responsible for MeeGo activities at the Linux Foundation (details found [http://meego.com/community/blogs/ibrahim/2010/introducing-myself-meego-community here]).

== Other community members ==
The real deal is in the [http://meego.com/community/members full list of meego.com member profiles] (more than 5.000 already!). See also the list of [[Special:ListUsers|Wiki users]].

If you are in the list below but you are working with a de-facto role in the MeeGo project please help making your role official.

('''Please keep this list alphabetically-ordered, as it will make finding people easier''')

* [http://meego.com/users/qole Alan Bruce/qole] - Maemo Community Council member
* [http://meego.com/users/camahueto Alberto O. / camahueto] - Lawyer working in an unidentified Intellectual Property office. Free Software aficionado.
* [http://meego.com/users/agrin Alejandro Grin / agrin] - Independent developer.
* [http://meego.com/users/locusf Aleksi Suomalainen / LoCusF] - developer
* [http://meego.com/users/alessandro Alessandro Cogliati] - Browser/Flash developer, Nokia Meego.
* [http://meego.com/users/alexbez Alexander 'Sasha' Bezprozvanny / alexbez] Gadget freak and Maemo community member / Former Maemo team member (RTCom/Applications), now Technology Manager @ Ixonos Plc.
* [http://meego.com/users/ab Alexander Bokovoy / ab] - Senior Architect, Media applications, Nokia, Samba Team member
* [http://meego.com/users/aesantos Alexandra Engström Santos / aesantos] - Localisation SW Testing Project Manager, European Portuguese translator
* [http://meego.com/users/indeyets Alexey Zakhlestin/JimiDini] - maemo.org web/Midgard developer
* [http://meego.com/users/andre André Klapper/andre__] - maemo.org bugmaster
* [http://meego.com/users/aboaboit Andrea Borgia / aboaboit] - Maemo community member
* [http://meego.com/users/th0br0 Andreas Osowski / th0br0] - developer, Fedora Packager, interested in the RWG
* [http://meego.com/users/andrewfblack Andrew F Black / AndrewFBlack] - Maemo community member / Theme Designer / talk.maemo.org Moderator and Theme Designer.
* [http://meego.com/users/jaffa Andrew Flegg / Jaffa] - Long term gadget freak & Maemo community member
* [http://meego.com/users/antonr AntonR / AntonR] - Browser/Gecko embedding, Geo services.
* [http://meego.com/users/bdale Bdale Garbee / bdale] - HP, Debian
* [http://meego.com/users/earthling Bernd Stramm / earthling] - Independent developer.
* [http://meego.com/users/bman Brian McKenzie / b-man] - Long term Maemo community member, software porter/developer, beta tester
* [http://meego.com/users/bundyo Bundyo / Bundyo] - Maemo community member, contributor
* [http://meego.com/users/stskeeps Carsten Munk/Stskeeps] - N900 hardware adaptation team member
* [http://meego.com/users/clay Clay Carey / Clay] - Moblin community member, software developer
* [http://meego.com/users/clintcan Clint Christopher Cañada / clintcan] - Moblin oriented netbook user, open source enthusiast and packages rpms for moblin/centos/rhel for personal use in spare time.
* [http://meego.com/users/leinir Dan Leinir Turthra Jensen / leinir] N810 owner, MeeGo community member (via Mer)
* [http://meego.com/users/daperl Da Perl / daperl] - Maemo community member, software developer
* [http://meego.com/users/b0unc3 Daniele Maio / b0unc3] - Maemo community member/contributor, software developer
* [http://meego.com/users/dneary Dave Neary/dneary] - maemo.org docmaster
* [http://meego.com/users/lbt David Greaves / lbt] - Mer OBS build guy
* [http://meego.com/users/dspeed Derek Speed / dspeed] - Linux and open source evangelist at Intel
* [http://meego.com/users/glezos Dimitris Glezos / glezos] - Localization Engineer ([http://www.transifex.net/ Transifex])
* [http://meego.com/users/dirkhh Dirk Hohndel/dirkhh] - Chief Linux and open source technologist at Intel
* [http://meego.com/users/spaghetty Domenico Chierico / spaghetty] - Maemo community member
* [http://meego.com/users/epage Ed Page / epage] - Maemo community member, software developer
* [http://borasky-research.net M. Edward (Ed) Borasky] - Linux capacity planning / audio / openSUSE / Twitter geek
* [http://meego.com/users/townxelliot Elliot Smith/townxelliot] - Moblin.org & meego.com website techy
* [http://meego.com/users/debernardis Ernesto de Bernardis / debernardis] - Maemo community member, mobile device tinkerer
* [http://meego.com/users/fgs Floriano Scioscia / fgs] - Maemo community member, IT engineer and junior researcher
* [http://meego.com/users/frederico Frederico Schardong / frederico] - Maemo community member, open source developer
* [http://meego.com/users/fpp Fred Pacquier / fpp] - maemo.org old-timer, platform-neutrality advocate, Python evangelist, and big mouth.
* [http://meego.com/users/amby Gabor Ambrozy / Amby] - Maemo community member, Save the End-Users advocate
* [http://meego.com/users/gaveen Gaveen Prabhasara / gaveen] - a DevOps guy. Planning to become a Fedora packager soon. FOSS / Linux / Ruby advocate
* [http://meego.com/users/slaine Glen Gray / slaine] - Moblin community member, software engineer
* [http://meego.com/users/gcobb Graham Cobb / gcobb] - Maemo community member and application developer, former Commnunity Council member
* [http://meego.com/users/gbraad Gerard Braad / gbraad] - Maemo community member, Fedora Project member, (open source) Hardware/Software engineer
* [http://meego.com/users/halton Halton Huo/Halton] - Browser Developer, Mozilla Contributor at Intel
* [http://meego.com/users/bergie Henri Bergius/bergie] - maemo.org web/Midgard developer
* [http://meego.com/users/ianbrasil Ian Lawrence / ianbrasil] - Author - Professional Ubuntu Mobile Development, Moblin and Maemo community member
* [http://meego.com/users/jmk Janne Karhunen / jmk] - Maemo system architect, System Software engineering + Security, Nokia MeeGo
* [http://meego.com/users/jannis Jannis Pohlmann / jannis] - Software developer (Xfce, tumbler etc.)
* [http://meego.com/users/zerojay Jason Carter / zerojay] - Long term Maemo community member
* [http://meego.com/users/javispedro Javier S. Pedro / javispedro] - Maemo Community Council member
* [http://meego.com/users/jebba Jeff Moe / jebba] - [http://wiki.maemo.org/User:Jebba Maemo Contributor]
* [http://meego.com/users/jeremiah Jeremiah Foster/jeremiah] - maemo.org debmaster
* [http://meego.com/users/tuju Juha Tuomala / Tuju] - Fedora packager.
* [http://meego.com/users/jak Julian Andres Klode / jak] - Debian developer, Ubuntu member
* [http://meego.com/users/jkridner Jason Kridner / jkridner] - BeagleBoard.org Community Manager, Gentoo user, TI employee
* [http://meego.com/users/Krohon Krohon / Krohon] - Newbie, software developer
* [http://meego.com/users/leoz Leonid Zolotarev / LeoZ] - Browser buddy, Nokia MeeGo
* [http://meego.com/users/lpotter Lorn Potter / lpotter / ljp] - QDF, Mobility, Nokia
* [http://meego.com/users/hrw Marcin Juszkiewicz / hrw ] - OpenEmbedded developer, [http://marcin.juszkiewicz.com.pl/ self-employed] as OpenEmbedded/Poky Linux consultant/developer.
* [http://meego.com/users/margie Margie Foster/mlfoster] - Localization project manager for Moblin & meego.com website developer
* [http://meego.com/users/penguinbait Matthew Lewis/penguinbait] - Maemo Community Council member
* [http://meego.com/users/detective Max Maher / detective] - Maemo community member, software porter/developer, QA Engineer
* [http://meego.com/users/mshaver Michael Shaver/mshaver] - Moblin.org webmaster & meego.com website developer
* [http://meego.com/users/mikael Mikael Söderberg / mksoderberg] - Chair of the GENIVI Alliance Reference System Work Group
* [http://meego.com/users/krypton Mithlesh Thukral / krypton] - Software developer, Linux kernel contributor, India
* [http://meego.com/users/mitsutaka Mitsutaka Amano / mitsutaka] - Moblin community member from Moblin 1.x, [http://git.moblin.org/cgit.cgi/moblin-image-creator Moblin Image Creator] maintainer, MeeGo/Moblin contributor, l10n(Japanese), Japanese evangelist, MIRACLE LINUX CORPORATION.
* [http://meego.com/users/niqt Nicola De FIlippo / niqt] - Qt4 Maemo Contributor, Maemo community member, software engineer
* [http://meego.com/users/xfade Niels Breet/X-Fade] - maemo.org webmaster
* [http://meego.com/users/omaciel Og Maciel / OgMaciel] - GNOME Foundation member ([http://www.gnome.org/ GNOME])
* [http://meego.com/users/mandrake Pasi Heinonen / ode2] - Qt4/GTK+ developer, .NET guy, daddy (read RTL)
* [http://meego.com/users/texrat Randall Arnold/Texrat] - two-term Maemo Community Council member, former Nokia employee (N800 launch team)
* [http://meego.com/users/rhertzog Raphaël Hertzog / buxy ] - Debian developer, [http://www.freexian.com self-employed] as free software consultant/developer.
* [http://meego.com/users/reggie Reggie Suplido] - maemo.org talkmaster
* [http://meego.com/users/ehamloptiran Robbie Newman / Ehamloptiran] - Maemo community member, software developer
* [http://meego.com/users/w00t Robin Burchell / w00t] - Developer of random things, gadget enthusiast, Maemo community member
* [http://meego.com/users/generalantilles Ryan Abel / GeneralAntilles] - Long term Maemo community member
* [http://meego.com/users/macron Ronan Mac Laverty/macron,maclaver(IRC)] - Nokia's Maemo (Application) Developer Advocate
* [http://meego.com/users/slauwers Sebastian Lauwers / crashanddie] - Maemo community member, talk.maemo.org moderator / ActivIdentity Professional Services Technical Consultant
* [http://meego.com/users/sivan Sivan Greenberg / sivang] - Veteran linux developr and python literate, QA specialist and integration engineer.
* [http://meego.com/users/sjgadsby Stephen Gadsby / sjgadsby] - Maemo community member
* [http://meego.com/users/tekojo Tero Kojo/tekojo] - Nokia's Maemo Technical Project Manager
* [http://meego.com/users/timeless timeless / timeless] - Mozilla contributor, Nokia employee
* [http://meego.com/users/timsamoff Tim Samoff / timsamoff] - Designer (graphic, UI, interaction, web), long-time Maemo Community member (two-term Maemo Community Council Member), and forever open source advocate
* [http://meego.com/users/framstag Tim Teulings / framstag] - Maemo community member, software developer
* [http://meego.com/users/timoph Timo Härkönen / timoph] - Maemo community member, software developer
* [http://meego.com/users/tjyrinki Timo Jyrinki / Mirv] - Debian developer, Ubuntu member, Openmoko contributor; all-around community and translations person + some MeeGo related work stuff
* [http://meego.com/users/vdvsx Valério Valério/VDVsx] - Maemo Community member, software developer, Nokia employee
* [http://meego.com/users/vatula Veli-Pekka Vatula/vatula] - Nokia's Head of Maemo SW Testing
* [http://meego.com/users/vilvo Ville Ilvonen/vilvo] - Nokia's Maemo Test Tools and Test Automation
* [http://meego.com/users/wjbaird Warren Baird / wjbaird / photogeekmtl] - Developer, Product Manager, N900 user, Photographer, Digital Artist
* [http://meego.com/users/copyleft Youchen Lee / copyleft] - Debian/Ubuntu community member, software developer, deb packager.
* [http://meego.com/users/corsac Yves-Alexis Perez / Corsac] - Debian developer, Maemo community member, security engineer
* [http://meego.com/users/zaheerm Zaheer Abbas Merali / zaheerm] - GStreamer developer, Maemo community member and app developer
* [http://meego.com/users/romaxa Oleg Romashin / romaxa] - Browser Developer, Mozilla Contributor, Nokia MeeGo

[[Category:Community]]

Use cases for telephony

2010-07-30T20:13:12Z

Mikeleib: /* Use DTMF during a call = */

The intent of this list is to provide a set of use cases that we can use to sanity test our design and implementation approach, to help ensure we are accounting for as many technical areas as possible, as early as possible.

= General =
== Use Cases ==
=== At home screen, I want to view my call history ===
User presses 'Phone' icon in the application quick launch bar, which launches the dialer. The dialer opens to the last view the user was in when they used the dialer previously. If this is not the Call History (Recent) view, the the user presses the Recent tab.

=== I want to view details of a contact in the call history ===
Tap on the '''more details''' part of the people card in the Call History (Recent) view in dialer brings up the contact details.

=== I want to create a contact for an unknown caller in my call history ===
Unknown persons (not already in the contact list) will show up as '''Unknown caller''' in the call history view, showing the phone number. Tapping the '''more details''' button on that contact card entry will take you to a new Contact card (as if you had gone to an existing Contact card and pressed 'Edit'), populated with just the phone number. The user can then enter as much information they want, and press Save.

'''Question:''' Should the '''more details''' button be replaced with '''New contact''' or similar text for entries not in the Contact list, or should it continue saying '''more details'''? If the later, should it really go straight to the edit view, or should the interaction pattern be the same for normal contacts:

call history view => *tap more details on contact* => more details view for contact => *click edit* => edit view for contact

=== I want to edit a contact for a contact in the call history ===
=== I want to configure a specific ring tone for a given contact phone number ===
=== I want to copy a phone number from a contact and paste into email/SMS ===
== Questions ==
=== What mode does the dialer start in when launched from the Dialer button? ===
Per '''Dialer.pdf 2010-06-24 pp. 2:''' The first time the dialer application is launched, the dialer tab will be open. When returning to the dialer, the last state/tab visited will be remembered. This is a fixed setting, not configurable by the user.
==== Question: Does '''first time''' refer to the very first time the dialer is launched by the user (ever) or the first time after having closed the dialer application? ====

= Placing a call =
== Use Cases ==
=== Application Foo wants to place a call ===
An application can use:
QDesktopServices::openUrl("callto:+9163562663");

Internally, QDesktopServices forks xdg-open, passing it the Url. xdg-open then uses the gconf key matching the protocol name under /desktop/gnome/url-handlers. The value for 'command' is then launched, substituting the full Url for %s.

The specific user interaction when the dialer is invoked in this method is TBD; two options are to prompt the user first (Do you want to call ######? Yes / No) only launching the full dialer and placing the call if Yes is pressed, or to launch the full dialer immediately and pre-populate the dialout number, but require the user to manually press Send.
=== I want to call back someone from the call history ===
=== I want to place a call from My Contacts (or generic Contact Card) ===
=== I want to place a call from an email containing a phone number ===
=== I want to call the sender of an SMS message ===
=== I want to place a call using a dial pad ===
=== I want to place a call while the device is locked ===
=== I want to place a call while the screen is locked ===
=== I want to place a call while in another call ===
=== I want to place an emergency call ===
==== ... while the device is locked ====
=== I want to place a call in an FDN SIM locked phone ===
FDN is not required for the first version. The exception to this is if a SIM card is used that has FDN enabled, the SIM card will be rejected -- except for allowing emergency mode. This means that the system must be able to detect an FDN restricted SIM and to then limit the UX accordingly.

=== I want to call back the phone number using the bluetooth headset ===
=== Questions ===

== Can the user configure FDNs? ==
== Can the user view approved FDNs? ==

= Receiving a call =
== Use Cases ==
=== I want to receive a call while in a full screen game ===
=== I want to receive a call while watching a movie ===
=== I want to receive a call while listening to an MP3 ===
=== I want to receive a call while in a call ===
=== I want to receive a call while listening to an internet radio station ===
=== I want to receive a call while the device is locked ===
=== I want to receive a call while the screen is locked ===
=== I want to mute the ringer on an incoming call ===
=== I don't want to answer an incoming call ===
=== I do want to answer an incoming call ===

== Questions ==

= In a call =
== Use Cases ==
=== I want to see what other communication I have had with the other party ===
=== I want to terminate the call ===
=== I want to share a photo with the other party ===
=== I want to switch to/from a different application while remaining on the call ===
==== ... while device locked ====
=== Switch to/from BT headset ===
=== Switch to/from speaker phone ===
=== Use DTMF during a call ===

User dials service provider. The automated system says to "Press 1 for English." User presses 1 and it makes the DTMF code for 1, allowing the user to have a successful customer service experience.

=== Mute on/off ===

== Questions ==

= Terminating a call =
== Use Cases ==
=== I want to terminate a call ===
=== I want to terminate a call that I have switched away from ===
=== The call is terminated by the other party ===
== Questions ==

Devices

2010-07-29T18:26:08Z

Mikeleib: reimposing alphabetical order

Below you find devices where MeeGo was used successfully (atm only user reports, the list below is compiled from [http://forum.meego.com/showthread.php?t=83 this] forum thread). The list is not complete and waits for your input.

==Devices compatible with MeeGo==
''sorted alphabetically''

===Handsets===

General information user and developers for [[Handsets]].

*[[Devices/Aava|Aava]] ([[Developing_With_The_Aava|Tips for developing with the Aava]])
*[[Devices/N900|Nokia N900]] (see install instructions at: [[ARM]])

===Netbooks===

General information user and developers for [[Netbooks]].

We have a list of [http://meego.com/devices/netbook/supported-hardware-platforms supported netbook platforms] that we run through QA. If you have another netbook that you have confirmed works with MeeGo, please add it below.

*[[wikipedia:Acer Aspire One|Acer Aspire]]
** One AO532-h
** One A110L
** One A150L and A150X
** One D250
** One ZG5

*[[wikipedia:Asus Eee PC|Asus EeePC]]
** 701 (root partition formatted with ext3)
** 900 (root partition formatted with ext3)
** 900HA
** 901
** 901 Go (3G not supported yet)
** 1000
** 1000H
** 1005HA
** 1005PE (Intel(R) Atom(TM) N450)
** 1008HA ([http://forum.meego.com/showthread.php?p=1330#post1330 well tested])
* Dell
** Latitude 2100 (including optional touchscreen)
** Inspiron Mini 9 ([http://forum.meego.com/showthread.php?t=287 some issues])
** Vostro A90 (same issues as Mini 9)
** Dell E6400
* HERCULES
** EC-900
* HP
** Mini 110 ([http://slaine.org/_slaine/Meego_1.0_Wifi.html Broadcom WiFi needs to be compiled separately])
** Mini 210 1022eo,1030-NR, others ([http://forum.meego.com/showthread.php?t=328 Broadcom WiFi needs to be compiled separately])
** Mini 5101 HD ([http://forum.meego.com/showthread.php?t=328 Broadcom WiFi needs to be compiled separately])
* Medion Akoya Mini E1210
*[[wikipedia:MSI_Wind_Netbook|MSI Wind]]
** U130
* Samsung
** N130
** N140
** [[wikipedia:Samsung NC10|NC10]]
* [[wikipedia:VAIO|Sony VAIO]]
** VPCW211AX (Intel(R) Atom(TM) N450)
** VGN-TX3XP (Intel(R) Core(R) Solo(R) 1.2GHz, Intel 945GMS video card)
* Toshiba Mini
** NB200
** NB205
** NB305

*[[wikipedia:eMachines_Netbook|eMachines]]
** eM350 (Intel(R) Atom(TM) N450 )

===Nettops===
*Acer
**[[wikipedia:Acer Aspire Revo|Revo]] GN40
**eMachine EZ1601 and KAV60
*Asus
**[[wikipedia:ASUS Eee Box|Eeebox]] B202
**[[wikipedia:ASUS Eee Top|Eeetop]] ET1602
*[[wikipedia:Micro-Star International|MSI]]
**AE1900
*Samsung
**[[wikipedia:Samsung N130|n130]]

===Notebooks===
* Acer Travelmate 6292
* Asus F2F (Celeron M)
* Asus U1F (Core Duo)
* Dell Inspiron 1525 (without wireless networking) [http://forum.meego.com/showthread.php?t=371]
* Dell Latitude D630 (Broadcomm [http://slaine.org/_slaine/Meego_1.0_Wifi.html] wifi driver needed)
* Dell XPS M1210 CoreDuo T2400, Intel 950GM, Intel Wireless 3945abg, Linksys Webcam. [http://forum.meego.com/showthread.php?t=433]
* Fujitsu Lifebook P1610: Working: wifi, sound, screen brightness/sound volume via function keys, SD card reader, trackpoint. Not Working: touchscreenn [--[[User:Rokky|Rokky]] 22:17, 2 June 2010 (UTC)]
* Lenovo IdeaPad Y450 [http://forum.meego.com/showthread.php?t=265]
* Lenovo T60 / T61 [http://forum.meego.com/showthread.php?t=323]
* Lenovo ThinkPad R500 [http://forum.meego.com/showthread.php?t=371]
* Toshiba L500 Satellite low-end Notebook (needs rtl8192se driver from RealTek for wireless)
* Panasonic CF-52 (Centrino2)

===Laptop===
* Toshiba Satellite A300 -> Pentium Dual Core T4200 2GHz X2
·Work: -Trackpad
-Keyboard
-Webcam
-Sound
-Video card (Intel GMA x4500HD) -> HDMI and VGA work
-Wi-fi
-Bluetooth
-USB ports
-Card Reader
·Not Tested:
-ExpressCard

* Dell Inspiron 1545 -> Intel® Core™ 2 Duo T6600 (2.20GHz/800Mhz FSB/2MB cache)
·Work: -Trackpad
-Keyboard
-Sound
-Video card
-Wi-fi ([http://slaine.org/_slaine/Meego_1.0_Wifi.html After installing Broadcom drivers])
-USB ports
-Card Reader
·Not Tested:
-Bluetooth
-ExpressCard

===other===
*[[wikipedia:Beagle Board|Beagle Board]], see [[ARM/Meego on the Beagle]]*
*[[wikipedia:Archos_Internet_Media_Tablet#Archos_5|Archos 5 IT]], simmilar specs like the Beagle, more RAM though.
* O2 Joggler with GMA500 and touchscreen [http://www.youtube.com/watch?v=eUiSnITKeRY] - Initial Testing
* O2 Joggler with GMA500 and touchscreen [http://www.youtube.com/watch?v=vnwfVtHuhoI] - Testing new EMGD driver

==Known problems==
*Netbooks requiring GMA500 drivers, see [[wikipedia:Intel GMA#GMA 500 on Linux]] and [[wikipedia:Poulsbo_(chipset)#Linux_support]]
** [http://en.wikipedia.org/wiki/Nokia_Booklet_3G Nokia Booklet 3G]

* See http://www.youtube.com/watch?v=vnwfVtHuhoI for GMA500 running Meego 1.0

Developing With The Aava

2010-07-29T18:17:34Z

Mikeleib:

[[Category:devguide]]
These are some of the notes that we keep and use to make our development easier at Intel. Feel free to edit/modify/correct as needed.

= Mounting/Chrooting =
Its easiest to do all this on a development system, then burn to your SD card:
mkdir aava-image
sudo mount -o loop,offset=<offset> <image> aava-image
sudo mic-chroot aava-image

= Install Some Development Tools =
zypper install yum
yum install rsync nano perf openssh-server screen gdb abrt{,-plugin-{logger,ccpp}} yum-utils strace

= Add the Ability to 'screen' in =
Install an application launcher that kicks off a screen session:
cat << EOF > /usr/share/applications/screen.desktop
[Desktop Entry]
Name=Screen
Exec=/usr/bin/screen -dmS meego
Icon=moblin-xterm
Type=Application
EOF

With the above, you can then click the 'Screen' application in the launcher screen. Once launched, you can then ssh to your device and run:
screen -dr
to attach to the screen session. From there you can then run MeeGo applications which require access to the display and DBus under the MeeGo user session.

= Finish Up =
Don't forget to exit mic-chroot!
exit

= Transfer to Your SD Card =
dd or rsync as appropriate

Main Page

2010-07-28T17:44:05Z

Mikeleib: add link to Developing With The Aava

= Structure and Governance =

MeeGo is an open source project led by the MeeGo Technical Steering Group (TSG). The governance model is based on meritocracy and best practices and values of the Open Source culture. The MeeGo project lives under the auspices of the Linux Foundation.

* [http://meego.com/about/governance MeeGo Project Structure and Governance Overview]

Anyone can attend the bi-weekly [[Technical Steering Group meetings]] to learn more about the decisions being made in the MeeGo project.

== MeeGo Project Functions ==

* [[Community Office]]
* [[Localization team|Localization]]
* [http://meego.com/about/governance/program-office Program Office]
* [[Quality]]
* [[Release_Engineering|Release Engineering]]
* [http://meego.com/about/governance/ui-design User Interface Design]

= User =

* [[MeeGo 1.0 Netbook FAQ]]
* [http://meego.com/devices/netbook/installing-meego-your-netbook Install MeeGo 1.0 on your netbook]
* [[Devices|Supported devices]]

= Developer =
== Developer Guide ==
[[Developer Guide]]

Instructions for [[ARM|N900 / ARM based devices]] 
Instructions for [[MeeGo_1.0_Netbook_VirtualBox|VirtualBox]] 
Instructions for [[MeeGo SDK on Windows with VirtualBox]] 
Tips for [[Developing With The Aava]]

Documentation for the [[Build_Infrastructure|MeeGo Build Infrastructure]].

== Release Process ==

The MeeGo Release Process includes:
* [[Release_Engineering/Release_Timeline|MeeGo releases every 6 months.]]
* [[Release_Engineering/Process|Nightly builds for developers and weekly releases will be available]]

= Community =

== Regular Meetings ==

[[MeeGo-Meeting IRC Schedule]]

The following groups have regular meetings, see their respective pages for details.

* [[Technical Steering Group meetings]]
* [[Community Working Group Meeting]]
* [[Localization team]]

== Yearly MeeGo Conference ==

The [[MeeGo Conference 2010]] will be held at Aviva Stadium in Dublin, Ireland- November 15-17th, 2010. Visit the [[MeeGo Conference 2010]] wiki page for planning details. The call for papers and registration will be available shortly.

== Contributing to MeeGo ==

If you want to [[Contributing to MeeGo | contribute to MeeGo]], but aren't sure where to start.

See also [[Who's who]].

'''Wiki Contribution Guidelines'''

* Editing permissions are restricted to registered users. [http://meego.com/user/register Register in the main MeeGo site] and you will have single sign-on to the wiki and other tools.
* Consult the [http://www.mediawiki.org/wiki/Help:Contents User's Guide] for information on using the wiki software.
* There is a set of [[Wiki contribution guidelines]].

== Resources ==
* [[MeeGo FAQ]]
* [[Glossary|Glossary and Acronyms]]
* [[Special:PopularPages|Popular Wiki Pages]]
* [[Special:MostLinkedPages|Most Linked-to Pages]]

Developing With The Aava

2010-07-28T17:43:31Z

Mikeleib: tips for hackers

These are some of the notes that we keep and use to make our development easier at Intel. Feel free to edit/modify/correct as needed.

= Mounting/Chrooting =
Its easiest to do all this on a development system, then burn to your SD card:
mkdir aava-image
sudo mount -o loop,offset=<offset> <image> aava-image
sudo mic-chroot aava-image

= Install Some Development Tools =
zypper install yum
yum install rsync nano perf openssh-server screen gdb abrt{,-plugin-{logger,ccpp}} yum-utils strace

= Add the Ability to 'screen' in =
Install an application launcher that kicks off a screen session:
cat << EOF > /usr/share/applications/screen.desktop
[Desktop Entry]
Name=Screen
Exec=/usr/bin/screen -dmS meego
Icon=moblin-xterm
Type=Application
EOF

With the above, you can then click the 'Screen' application in the launcher screen. Once launched, you can then ssh to your device and run:
screen -dr
to attach to the screen session. From there you can then run MeeGo applications which require access to the display and DBus under the MeeGo user session.

= Finish Up =
Don't forget to exit mic-chroot!
exit

= Transfer to Your SD Card =
dd or rsync as appropriate