Yocto Project - User contributions [en]

Web Application for Interactive Kiosk Devices

2013-01-31T14:19:02Z

Emma.ciobanu:

__FORCETOC__
[[File:Screenshot from 2012-10-05 15 28 34.png|thumb|upright=1.8|Kiosk device that runs Midori browser]]
An [http://http://en.wikipedia.org/wiki/Interactive_kiosk Interactive Kiosk Device] is a computer terminal with proper hardware and software support that provides public access to different kinds of information. They're used in a large variety of domains including commerce, education, entertaining, tourist information and many others.

== Goal Of The Project ==
The project focuses on developing a minimal image with an integrated browser aimed to be used in touchscreen kiosk applications/operating systems. It consists of creating a yocto based application that will automatically start a Midori browser immediately after boot. The login is made automatically after boot and before the browser starts.

The image is developed as a new layer that is added to poky, a platform-independent, cross-compiling layer that provides useful features and functionalities for embedded solutions. For further information about the Yocto, please visit the project’s [http://wiki.yoctoproject.org wiki page] or the [http://www.yoctoproject.org official website].

The application integrates Midori as the main web browser. The browser was used as a fast and lightweight solution that meets up all the expectations of the project. More information on this topic can be found at http://en.wikipedia.org/wiki/Midori_(web_browser).

== Integration Of meta-web-kiosk Into Poky ==
This tutorial assumes that you already have a poky distribution on the local machine. If this is not the case follow the steps described in the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html poky manual] to download and configure poky.
Here are the steps to follow in order to get the new image to work:
* Download the repository from [http://git.yoctoproject.org/cgit/cgit.cgi/meta-web-kiosk/ yoctoproject.org] by tracking the emac/meta-web-kiosk branch. This step will generate a new folder called meta-web-kiosk.
* Copy the newly cloned folder in the root of poky.
* Open <tt>meta/classes/core-image.classes</tt> and add the following line
PACKAGE_GROUP_x11-browser=”packagegroup-core-x11-browser”
* If you are using proxies in your network settings uncomment the following lines from <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session_0.1.bb</tt>
install –d ${D}/home/${USER}/.config/${BROWSER}/
install ${S}/config/ ${D}/home/${USER}/.config/${BROWSER}
** open <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session/config</tt> and add you proxy settings.
* Source the oe-init-build-env script
. oe-init-build-env
* Open <tt>conf/bblayers.conf</tt> to add the newly configured layer
[...]
${path_to_poky}/meta \
[...]
${path_to_poky}/meta-web-kiosk \
[...]
[[File:Screenshot from 2012-10-05 15 35 12.png|thumb|right|upright=1.8| Web Kiosk Application with touchscreen Support]]
* Now that everything is set you can build the new image with bitbake
bitbake core-image-web-kiosk
* and run it in qemu or install it on a device with touchscreen support.

== Enable touchscreen support ==
If you need touchscreen support you should first of all make sure it is enabled in the bsp recipes. For this edit
* edit <tt>/meta/recipes-bsp/formfactor/${arch}</tt> to make sure you have the HAVEKEYBOARD variable disabled
[...]
HAVEKEYBOARD=0
[...]
Replace <tt>${path_to_poky}</tt> with the actual path to poky root and <tt>${arch}</tt> with the machine you are building the image for. This is specified either by editing <tt>${path_to_build_folder}/conf/local.conf</tt> in the MACHINE variable, or, directly, when building the new image by adding MACHINE=${arch} before the image name. The command should look something like this:
MACHINE=${arch} bitbake core-image-web-kiosk
If you have a particular arch, then you should add it into the new layer. For this
* edit <tt>meta-web-kiosk/recipes-bsp/formfactor/formfactor</tt>
* create a new folder with the architecture name
* create a new file inside the arch folder and name it machconfig
* edit the <tt>machconfig file</tt> to make sure you disable the keyboard
[...]
HAVEKEYBOARD=0
[...]
* add the rest of arch-dependent configuration and save the file.
* build the image by either specifying the arch in <tt>${path_to_build_folder}/conf/local.conf</tt> or by adding the MACHINE variable in front of bitbake when building, as shown before.

Web Application for Interactive Kiosk Devices

2013-01-31T08:56:43Z

Emma.ciobanu:

__FORCETOC__
[[File:Screenshot from 2012-10-05 15 28 34.png|thumb|upright=1.8|Kiosk device that runs Midori browser]]
An [http://http://en.wikipedia.org/wiki/Interactive_kiosk Interactive Kiosk Device] is a computer terminal with proper hardware and software support that provides public access to different kinds of information. They're used in a large variety of domains including commerce, education, entertaining, tourist information and many others.

== Goal Of The Project ==
The project focuses on developing a minimal image with an integrated browser aimed to be used in touchscreen kiosk applications/operating systems. It consists of creating a yocto based application that will automatically start a Midori browser immediately after boot. The login is made automatically after boot and before the browser starts.

The image is developed as a new layer that is added to poky, a platform-independent, cross-compiling layer that provides useful features and functionalities for embedded solutions. For further information about the Yocto, please visit the project’s [http://wiki.yoctoproject.org wiki page] or the [http://www.yoctoproject.org official website].

The application integrates Midori as the main web browser. The browser was used as a fast and lightweight solution that meets up all the expectations of the project. More information on this topic can be found at http://en.wikipedia.org/wiki/Midori_(web_browser).

== Integration Of meta-web-kiosk Into Poky ==
This tutorial assumes that you already have a poky distribution on the local machine. If this is not the case follow the steps described in the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html poky manual] to download and configure poky.
Here are the steps to follow in order to get the new image to work:
* Download the repository from [http://git.yoctoproject.org/cgit/cgit.cgi/meta-web-kiosk/ yoctoproject.org] by tracking the emac/meta-web-kiosk branch. This step will generate a new folder called meta-web-kiosk.
* Copy the newly cloned folder in the root of poky.
* Open <tt>meta/classes/core-image.classes</tt> and add the following line
PACKAGE_GROUP_x11-browser=”packagegroup-core-x11-browser”
* If you are using proxies in your network settings uncomment the following lines from <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session_0.1.bb</tt>
install –d ${D}/home/${USER}/.config/${BROWSER}/
install ${S}/config/ ${D}/home/${USER}/.config/${BROWSER}
** open <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session/config</tt> and add you proxy settings.
* Source the oe-init-build-env script
. oe-init-build-env
* Open <tt>conf/local.conf</tt> file and add the following line:
[...]
DISTRO_FEATURES = "ext2 largefile usbhost xattr nfs zeroconf pci ${DISTRO_FEATURES_LIBC} x11"
[...]
* Open <tt>conf/bblayers.conf</tt> to add the newly configured layer
[...]
${path_to_poky}/meta \
[...]
${path_to_poky}/meta-web-kiosk \
[...]
[[File:Screenshot from 2012-10-05 15 35 12.png|thumb|right|upright=1.8| Web Kiosk Application with touchscreen Support]]
* Now that everything is set you can build the new image with bitbake
bitbake core-image-web-kiosk
* and run it in qemu or install it on a device with touchscreen support.

== Enable touchscreen support ==
If you need touchscreen support you should first of all make sure it is enabled in the bsp recipes. For this edit
* edit <tt>/meta/recipes-bsp/formfactor/${arch}</tt> to make sure you have the HAVEKEYBOARD variable disabled
[...]
HAVEKEYBOARD=0
[...]
Replace <tt>${path_to_poky}</tt> with the actual path to poky root and <tt>${arch}</tt> with the machine you are building the image for. This is specified either by editing <tt>${path_to_build_folder}/conf/local.conf</tt> in the MACHINE variable, or, directly, when building the new image by adding MACHINE=${arch} before the image name. The command should look something like this:
MACHINE=${arch} bitbake core-image-web-kiosk
If you have a particular arch, then you should add it into the new layer. For this
* edit <tt>meta-web-kiosk/recipes-bsp/formfactor/formfactor</tt>
* create a new folder with the architecture name
* create a new file inside the arch folder and name it machconfig
* edit the <tt>machconfig file</tt> to make sure you disable the keyboard
[...]
HAVEKEYBOARD=0
[...]
* add the rest of arch-dependent configuration and save the file.
* build the image by either specifying the arch in <tt>${path_to_build_folder}/conf/local.conf</tt> or by adding the MACHINE variable in front of bitbake when building, as shown before.

Web Application for Interactive Kiosk Devices

2013-01-24T12:51:29Z

Emma.ciobanu:

Web Application for Interactive Kiosk Devices

2013-01-24T12:44:27Z

Emma.ciobanu:

__FORCETOC__
[[File:Screenshot from 2012-10-05 15 28 34.png|thumb|upright=1.8|Kiosk device that runs Midori browser]]
An [http://http://en.wikipedia.org/wiki/Interactive_kiosk Interactive Kiosk Device] is a computer terminal with proper hardware and software support that provides public access to different kinds of information. They're used in a large variety of domains including commerce, education, entertaining, tourist information and many others.

== Goal Of The Project ==
The project focuses on developing a minimal image with an integrated browser aimed to be used in touchscreen kiosk applications/operating systems. It consists of creating a yocto based application that will automatically start a Midori browser immediately after boot. The login is made automatically after boot and before the browser starts.

The image is developed as a new layer that is added to poky, a platform-independent, cross-compiling layer that provides useful features and functionalities for embedded solutions. For further information about the Yocto, please visit the project’s [http://wiki.yoctoproject.org wiki page] or the [http://www.yoctoproject.org official website].

The application integrates Midori as the main web browser. The browser was used as a fast and lightweight solution that meets up all the expectations of the project. More information on this topic can be found at http://en.wikipedia.org/wiki/Midori_(web_browser).

== Integration Of meta-web-kiosk Into Poky ==
This tutorial assumes that you already have a poky distribution on the local machine. If this is not the case follow the steps described in the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html poky manual] to download and configure poky.
Here are the steps to follow in order to get the new image to work:
* Download the repository from [http://git.yoctoproject.org/git/meta-web-kiosk/ yoctoproject.org] by tracking the emac/meta-web-kiosk branch. This step will generate a new folder called meta-web-kiosk.
* Copy the newly cloned folder in the root of poky.
* Open <tt>meta/classes/core-image.classes</tt> and add the following line
PACKAGE_GROUP_x11-browser=”packagegroup-core-x11-browser”
* If you are using proxies in your network settings uncomment the following lines from <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session_0.1.bb</tt>
install –d ${D}/home/${USER}/.config/${BROWSER}/
install ${S}/config/ ${D}/home/${USER}/.config/${BROWSER}
** open <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session/config</tt> and add you proxy settings.
* Source the oe-init-build-env script
. oe-init-build-env
* Open <tt>conf/bblayers.conf</tt> to add the newly configured layer
[...]
${path_to_poky}/meta \
[...]
${path_to_poky}/meta-web-kiosk \
[...]
[[File:Screenshot from 2012-10-05 15 35 12.png|thumb|right|upright=1.8| Web Kiosk Application with touchscreen Support]]
* Now that everything is set you can build the new image with bitbake
bitbake core-image-web-kiosk
* and run it in qemu or install it on a device with touchscreen support.

== Enable touchscreen support ==
If you need touchscreen support you should first of all make sure it is enabled in the bsp recipes. For this edit
* edit <tt>/meta/recipes-bsp/formfactor/${arch}</tt> to make sure you have the HAVEKEYBOARD variable disabled
[...]
HAVEKEYBOARD=0
[...]
Replace <tt>${path_to_poky}</tt> with the actual path to poky root and <tt>${arch}</tt> with the machine you are building the image for. This is specified either by editing <tt>${path_to_build_folder}/conf/local.conf</tt> in the MACHINE variable, or, directly, when building the new image by adding MACHINE=${arch} before the image name. The command should look something like this:
MACHINE=${arch} bitbake core-image-web-kiosk
If you have a particular arch, then you should add it into the new layer. For this
* edit <tt>meta-web-kiosk/recipes-bsp/formfactor/formfactor</tt>
* create a new folder with the architecture name
* create a new file inside the arch folder and name it machconfig
* edit the <tt>machconfig file</tt> to make sure you disable the keyboard
[...]
HAVEKEYBOARD=0
[...]
* add the rest of arch-dependent configuration and save the file.
* build the image by either specifying the arch in <tt>${path_to_build_folder}/conf/local.conf</tt> or by adding the MACHINE variable in front of bitbake when building, as shown before.

Web Application for Interactive Kiosk Devices

2013-01-21T12:21:18Z

Emma.ciobanu:

__FORCETOC__
[[File:Screenshot from 2012-10-05 15 28 34.png|thumb|upright=1.8|Kiosk device that runs Midori browser]]
An [http://http://en.wikipedia.org/wiki/Interactive_kiosk Interactive Kiosk Device] is a computer terminal with proper hardware and software support that provides public access to different kinds of information. They're used in a large variety of domains including commerce, education, entertaining, tourist information and many others.

== Goal Of The Project ==
The project focuses on developing a minimal image with an integrated browser aimed to be used in touchscreen kiosk applications/operating systems. It consists of creating a yocto based application that will automatically start a Midori browser immediately after boot. The login is made automatically after boot and before the browser starts.

The image is developed as a new layer that is added to poky, a platform-independent, cross-compiling layer that provides useful features and functionalities for embedded solutions. For further information about the Yocto, please visit the project’s [http://wiki.yoctoproject.org wiki page] or the [http://www.yoctoproject.org official website].

The application integrates Midori as the main web browser. The browser was used as a fast and lightweight solution that meets up all the expectations of the project. More information on this topic can be found at http://en.wikipedia.org/wiki/Midori_(web_browser).

== Integration Of meta-web-kiosk Into Poky ==
This tutorial assumes that you already have a poky distribution on the local machine. If this is not the case follow the steps described in the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html poky manual] to download and configure poky.
Here are the steps to follow in order to get the new image to work:
* Download the repository from [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/ yoctoproject.org] by tracking the emac/meta-web-kiosk branch. This step will generate a new folder called meta-web-kiosk.
* Copy the newly cloned folder in the root of poky.
* Open <tt>meta/classes/core-image.classes</tt> and add the following line
PACKAGE_GROUP_x11-browser=”packagegroup-core-x11-browser”
* If you are using proxies in your network settings uncomment the following lines from <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session_0.1.bb</tt>
install –d ${D}/home/${USER}/.config/${BROWSER}/
install ${S}/config/ ${D}/home/${USER}/.config/${BROWSER}
** open <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session/config</tt> and add you proxy settings.
* Source the oe-init-build-env script
. oe-init-build-env
* Open <tt>conf/bblayers.conf</tt> to add the newly configured layer
[...]
${path_to_poky}/meta \
[...]
${path_to_poky}/meta-web-kiosk \
[...]
[[File:Screenshot from 2012-10-05 15 35 12.png|thumb|right|upright=1.8| Web Kiosk Application with touchscreen Support]]
* Now that everything is set you can build the new image with bitbake
bitbake core-image-web-kiosk
* and run it in qemu or install it on a device with touchscreen support.

== Enable touchscreen support ==
If you need touchscreen support you should first of all make sure it is enabled in the bsp recipes. For this edit
* edit <tt>/meta/recipes-bsp/formfactor/${arch}</tt> to make sure you have the HAVEKEYBOARD variable disabled
[...]
HAVEKEYBOARD=0
[...]
Replace <tt>${path_to_poky}</tt> with the actual path to poky root and <tt>${arch}</tt> with the machine you are building the image for. This is specified either by editing <tt>${path_to_build_folder}/conf/local.conf</tt> in the MACHINE variable, or, directly, when building the new image by adding MACHINE=${arch} before the image name. The command should look something like this:
MACHINE=${arch} bitbake core-image-web-kiosk
If you have a particular arch, then you should add it into the new layer. For this
* edit <tt>meta-web-kiosk/recipes-bsp/formfactor/formfactor</tt>
* create a new folder with the architecture name
* create a new file inside the arch folder and name it machconfig
* edit the <tt>machconfig file</tt> to make sure you disable the keyboard
[...]
HAVEKEYBOARD=0
[...]
* add the rest of arch-dependent configuration and save the file.
* build the image by either specifying the arch in <tt>${path_to_build_folder}/conf/local.conf</tt> or by adding the MACHINE variable in front of bitbake when building, as shown before.

Web Application for Interactive Kiosk Devices

2013-01-21T12:20:23Z

Emma.ciobanu:

__FORCETOC__
[[File:Screenshot from 2012-10-05 15 28 34.png|thumb|upright=1.8|Kiosk device that runs Midori browser]]
An [http://http://en.wikipedia.org/wiki/Interactive_kiosk Interactive Kiosk Device] is a computer terminal with proper hardware and software support that provides public access to different kinds of information. They're used in a large variety of domains including commerce, education, entertaining, tourist information and many others.

== Goal Of The Project ==
The project focuses on developing a minimal image with an integrated browser aimed to be used in touchscreen kiosk applications/operating systems. It consists of creating a yocto based application that will automatically start a Midori browser immediately after boot. The login is made automatically after boot and before the browser starts.

The image is developed as a new layer that is added to poky, a platform-independent, cross-compiling layer that provides useful features and functionalities for embedded solutions. For further information about the Yocto, please visit the project’s [http://wiki.yoctoproject.org wiki page] or the [http://www.yoctoproject.org official website].

The application integrates Midori as the main web browser. The browser was used as a fast and lightweight solution that meets up all the expectations of the project. More information on this topic can be found at http://en.wikipedia.org/wiki/Midori_(web_browser).

== Integration Of meta-web-kiosk Into Poky ==
This tutorial assumes that you already have a poky distribution on the local machine. If this is not the case follow the steps described in the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html poky manual] to download and configure poky.
Here are the steps to follow in order to get the new image to work:
* Download the repository from [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/ yoctoproject.org]. This step will generate a new folder called meta-web-kiosk.
* Copy the newly cloned folder in the root of poky.
* Open <tt>meta/classes/core-image.classes</tt> and add the following line
PACKAGE_GROUP_x11-browser=”packagegroup-core-x11-browser”
* If you are using proxies in your network settings uncomment the following lines from <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session_0.1.bb</tt>
install –d ${D}/home/${USER}/.config/${BROWSER}/
install ${S}/config/ ${D}/home/${USER}/.config/${BROWSER}
** open <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session/config</tt> and add you proxy settings.
* Source the oe-init-build-env script
. oe-init-build-env
* Open <tt>conf/bblayers.conf</tt> to add the newly configured layer
[...]
${path_to_poky}/meta \
[...]
${path_to_poky}/meta-web-kiosk \
[...]
[[File:Screenshot from 2012-10-05 15 35 12.png|thumb|right|upright=1.8| Web Kiosk Application with touchscreen Support]]
* Now that everything is set you can build the new image with bitbake
bitbake core-image-web-kiosk
* and run it in qemu or install it on a device with touchscreen support.

== Enable touchscreen support ==
If you need touchscreen support you should first of all make sure it is enabled in the bsp recipes. For this edit
* edit <tt>/meta/recipes-bsp/formfactor/${arch}</tt> to make sure you have the HAVEKEYBOARD variable disabled
[...]
HAVEKEYBOARD=0
[...]
Replace <tt>${path_to_poky}</tt> with the actual path to poky root and <tt>${arch}</tt> with the machine you are building the image for. This is specified either by editing <tt>${path_to_build_folder}/conf/local.conf</tt> in the MACHINE variable, or, directly, when building the new image by adding MACHINE=${arch} before the image name. The command should look something like this:
MACHINE=${arch} bitbake core-image-web-kiosk
If you have a particular arch, then you should add it into the new layer. For this
* edit <tt>meta-web-kiosk/recipes-bsp/formfactor/formfactor</tt>
* create a new folder with the architecture name
* create a new file inside the arch folder and name it machconfig
* edit the <tt>machconfig file</tt> to make sure you disable the keyboard
[...]
HAVEKEYBOARD=0
[...]
* add the rest of arch-dependent configuration and save the file.
* build the image by either specifying the arch in <tt>${path_to_build_folder}/conf/local.conf</tt> or by adding the MACHINE variable in front of bitbake when building, as shown before.

Web Application for Interactive Kiosk Devices

2012-10-11T12:30:20Z

Emma.ciobanu:

__FORCETOC__
[[File:Screenshot from 2012-10-05 15 28 34.png|thumb|upright=1.8|Kiosk device that runs Midori browser]]
An [http://http://en.wikipedia.org/wiki/Interactive_kiosk Interactive Kiosk Device] is a computer terminal with proper hardware and software support that provides public access to different kinds of information. They're used in a large variety of domains including commerce, education, entertaining, tourist information and many others.

== Goal Of The Project ==
The project focuses on developing a minimal image with an integrated browser aimed to be used in touchscreen kiosk applications/operating systems. It consists of creating a yocto based application that will automatically start a Midori browser immediately after boot. The login is made automatically after boot and before the browser starts.

The image is developed as a new layer that is added to poky, a platform-independent, cross-compiling layer that provides useful features and functionalities for embedded solutions. For further information about the Yocto, please visit the project’s [http://wiki.yoctoproject.org wiki page] or the [http://www.yoctoproject.org official website].

The application integrates Midori as the main web browser. The browser was used as a fast and lightweight solution that meets up all the expectations of the project. More information on this topic can be found at http://en.wikipedia.org/wiki/Midori_(web_browser).

== Integration Of meta-web-kiosk Into Poky ==
This tutorial assumes that you already have a poky distribution on the local machine. If this is not the case follow the steps described in the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html poky manual] to download and configure poky.
Here are the steps to follow in order to get the new image to work:
* Download the repository from [TODO – link to repo]. This step will generate a new folder called meta-web-kiosk.
* Copy the newly cloned folder in the root of poky.
* Open <tt>meta/classes/core-image.classes</tt> and add the following line
PACKAGE_GROUP_x11-browser=”packagegroup-core-x11-browser”
* If you are using proxies in your network settings uncomment the following lines from <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session_0.1.bb</tt>
install –d ${D}/home/${USER}/.config/${BROWSER}/
install ${S}/config/ ${D}/home/${USER}/.config/${BROWSER}
** open <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session/config</tt> and add you proxy settings.
* Source the oe-init-build-env script
. oe-init-build-env
* Open <tt>conf/bblayers.conf</tt> to add the newly configured layer
[...]
${path_to_poky}/meta \
[...]
${path_to_poky}/meta-web-kiosk \
[...]
[[File:Screenshot from 2012-10-05 15 35 12.png|thumb|right|upright=1.8| Web Kiosk Application with touchscreen Support]]
* Now that everything is set you can build the new image with bitbake
bitbake core-image-web-kiosk
* and run it in qemu or install it on a device with touchscreen support.

== Enable touchscreen support ==
If you need touchscreen support you should first of all make sure it is enabled in the bsp recipes. For this edit
* edit <tt>/meta/recipes-bsp/formfactor/${arch}</tt> to make sure you have the HAVEKEYBOARD variable disabled
[...]
HAVEKEYBOARD=0
[...]
Replace <tt>${path_to_poky}</tt> with the actual path to poky root and <tt>${arch}</tt> with the machine you are building the image for. This is specified either by editing <tt>${path_to_build_folder}/conf/local.conf</tt> in the MACHINE variable, or, directly, when building the new image by adding MACHINE=${arch} before the image name. The command should look something like this:
MACHINE=${arch} bitbake core-image-web-kiosk
If you have a particular arch, then you should add it into the new layer. For this
* edit <tt>meta-web-kiosk/recipes-bsp/formfactor/formfactor</tt>
* create a new folder with the architecture name
* create a new file inside the arch folder and name it machconfig
* edit the <tt>machconfig file</tt> to make sure you disable the keyboard
[...]
HAVEKEYBOARD=0
[...]
* add the rest of arch-dependent configuration and save the file.
* build the image by either specifying the arch in <tt>${path_to_build_folder}/conf/local.conf</tt> or by adding the MACHINE variable in front of bitbake when building, as shown before.

Web Application for Interactive Kiosk Devices

2012-10-11T12:26:08Z

Emma.ciobanu:

__FORCETOC__
[[File:Screenshot from 2012-10-05 15 28 34.png|thumb|upright=1.8|Kiosk device that runs Midori browser]]
An [http://http://en.wikipedia.org/wiki/Interactive_kiosk Interactive Kiosk Device] is a computer terminal with proper hardware and software support that provides public access to different kinds of information. They're used in a large variety of domains including commerce, education, entertaining, tourist information and many others.

== Goal Of The Project ==
The project focuses on developing a minimal image with an integrated browser aimed to be used in touchscreen kiosk applications/operating systems. It consists of creating a yocto based application that will automatically start a Midori browser immediately after boot. The login is made automatically after boot and before the browser starts.

The image is developed as a new layer that is added to poky, a platform-independent, cross-compiling layer that provides useful features and functionalities for embedded solutions. For further information about the Yocto, please visit the project’s [http://wiki.yoctoproject.org wiki page] or the [http://www.yoctoproject.org official website].

The application integrates Midori as the main web browser. The browser was used as a fast and lightweight solution that meets up all the expectations of the project. More information on this topic can be found at http://en.wikipedia.org/wiki/Midori_(web_browser).

== Integration Of meta-web-kiosk Into Poky ==
This tutorial assumes that you already have a poky distribution on the local machine. If this is not the case follow the steps described in the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html poky manual] to download and configure poky.
Here are the steps to follow in order to get the new image to work:
* Download the repository from [TODO – link to repo]. This step will generate a new folder called meta-web-kiosk.
* Copy the newly cloned folder in the root of poky.
* Open <tt>meta/classes/core-image.classes</tt> and add the following line
PACKAGE_GROUP_x11-browser=”packagegroup-core-x11-browser”
* If you are using proxies in your network settings uncomment the following lines from <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session_0.1.bb</tt>
install –d ${D}/home/${USER}/.config/${BROWSER}/
install ${S}/config/ ${D}/home/${USER}/.config/${BROWSER}
** open <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session/config</tt> and add you proxy settings.
* Source the oe-init-build-env script
. oe-init-build-env
* Open <tt>conf/bblayers.conf</tt> to add the newly configured layer
[...]
${path_to_poky}/meta \
[...]
${path_to_poky}/meta-web-kiosk \
[...]
[[File:Screenshot from 2012-10-05 15 35 12.png|thumb|right|upright=1.8| Web Kiosk Application with touchscreen Support]]
* Now that everything is set you can build the new image with bitbake
bitbake core-image-web-kiosk
* and run it in qemu or install it on a device with touchscreen support.

== Enable touchscreen support ==
If you need touchscreen support you should first of all make sure it is enabled in the bsp recipes. For this edit
* edit <tt>/meta/recipes-bsp/formfactor/${arch}</tt> to make sure you have the HAVEKEYBOARD variable disabled
[...]
HAVEKEYBOARD=0
[...]
Replace <tt>${path_to_poky}</tt> with the actual path to poky root and <tt>${arch}</tt> with the machine you are building the image for. This is specified either by editing <tt>${path_to_build_folder}/conf/local.conf</tt> in the MACHINE variable, or, directly, when building the new image by adding MACHINE=${arch} before the image name. The command should look something like this:
MACHINE=${arch} bitbake core-image-web-kiosk
If you have a particular arch, then you should add it into the new layer. For this
* edit <tt>meta-web-kiosk/recipes-bsp/formfactor/formfactor</tt>
* create a new folder with the architecture name
* create a new file inside the arch folder and name it machconfig
* edit the <tt>machconfig file</tt> to make sure you disable the keyboard
[...]
HAVEKEYBOARD=0
[...]
* add the rest of arch-dependent configuration and save the file.
* build the image by either specifying the arch in <tt>${path_to_build_folder}/conf/local.conf</tt> or by add the MACHINE variable in front of bitbake when building, as shown before.

Web Application for Interactive Kiosk Devices

2012-10-11T12:23:34Z

Emma.ciobanu:

__FORCETOC__
[[File:Screenshot from 2012-10-05 15 28 34.png|thumb|upright=1.8|Kiosk device that runs Midori browser]]
An [http://http://en.wikipedia.org/wiki/Interactive_kiosk Interactive Kiosk Device] is a computer terminal with proper hardware and software support that provides public access to different kinds of information. They're used in a large variety of domains including commerce, education, entertaining, tourist information and many others.

== Goal Of The Project ==
The project focuses on developing a minimal image with an integrated browser aimed to be used in touchscreen kiosk applications/operating systems. It consists of creating a yocto based application that will automatically start a Midori browser immediately after boot. The login is made automatically after boot and before the browser starts.

The image is developed as a new layer that is added to poky, a platform-independent, cross-compiling layer that provides useful features and functionalities for embedded solutions. For further information about the Yocto, please visit the project’s [http://wiki.yoctoproject.org wiki page] or the [http://www.yoctoproject.org official website].

The application integrates Midori as the main web browser. The browser was used as a fast and lightweight solution that meets up all the expectations of the project. More information on this topic can be found at http://en.wikipedia.org/wiki/Midori_(web_browser).

== Integration Of meta-web-kiosk into Poky ==
This tutorial assumes that you already have a poky distribution on the local machine. If this is not the case follow the steps described in the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html poky manual] to download and configure poky.
Here are the steps to follow in order to get the new image to work:
* Download the repository from [TODO – link to repo]. This step will generate a new folder called meta-web-kiosk.
* Copy the newly cloned folder in the root of poky.
* Open <tt>meta/classes/core-image.classes</tt> and add the following line
PACKAGE_GROUP_x11-browser=”packagegroup-core-x11-browser”
* If you are using proxies in your network settings uncomment the following lines from <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session_0.1.bb</tt>
install –d ${D}/home/${USER}/.config/${BROWSER}/
install ${S}/config/ ${D}/home/${USER}/.config/${BROWSER}
** open <tt>meta-web-kiosk/recipes-browser/midori-session/midori-session/config</tt> and add you proxy settings.
* Source the oe-init-build-env script
. oe-init-build-env
* Open <tt>conf/bblayers.conf</tt> to add the newly configured layer
[...]
${path_to_poky}/meta \
[...]
${path_to_poky}/meta-web-kiosk \
[...]
[[File:Screenshot from 2012-10-05 15 35 12.png|thumb|right|upright=1.8| Web Kiosk Application with touchscreen Support]]
* Now that everything is set you can build the new image with bitbake
bitbake core-image-web-kiosk
* and run it in qemu or install it on a device with touchscreen support.

== Enable touchscreen support ==
If you need touchscreen support you should first of all make sure it is enabled in the bsp recipes. For this edit
* edit <tt>/meta/recipes-bsp/formfactor/${arch}</tt> to make sure you have the HAVEKEYBOARD variable disabled
[...]
HAVEKEYBOARD=0
[...]
Replace <tt>${path_to_poky}</tt> with the actual path to poky root and <tt>${arch}</tt> with the machine you are building the image for. This is specified either by editing <tt>${path_to_build_folder}/conf/local.conf</tt> in the MACHINE variable, or, directly, when building the new image by adding MACHINE=${arch} before the image name. The command should look something like this:
MACHINE=${arch} bitbake core-image-web-kiosk
If you have a particular arch, then you should add it into the new layer. For this
* edit <tt>meta-web-kiosk/recipes-bsp/formfactor/formfactor</tt>
* create a new folder with the architecture name
* create a new file inside the arch folder and name it machconfig
* edit the <tt>machconfig file</tt> to make sure you disable the keyboard
[...]
HAVEKEYBOARD=0
[...]
* add the rest of arch-dependent configuration and save the file.
* build the image by either specifying the arch in <tt>${path_to_build_folder}/conf/local.conf</tt> or by add the MACHINE variable in front of bitbake when building, as shown before.

File:Screenshot from 2012-10-05 15 35 12.png

2012-10-11T12:01:29Z

Emma.ciobanu: Web Kiosk with Touchscreen Support

Web Kiosk with Touchscreen Support

Web Application for Interactive Kiosk Devices

2012-10-11T12:00:19Z

Emma.ciobanu:

__FORCETOC__
[[File:Screenshot from 2012-10-05 15 28 34.png|thumb|upright=1.5|Kiosk device that runs Midori browser]]
An [http://http://en.wikipedia.org/wiki/Interactive_kiosk Interactive Kiosk Device] is a computer terminal with proper hardware and software support that provides public access to different kinds of information. They're used in a large variety of domains including commerce, education, entertaining, tourist information and many others.

== Goal Of The Project ==
The project focuses on developing a minimal image with an integrated browser aimed to be used in touchscreen kiosk applications/operating systems. It consists of creating a yocto based application that will automatically start a Midori browser immediately after boot. The login is made automatically after boot and before the browser starts.

The image is developed as a new layer that is added to poky, a platform-independent, cross-compiling layer that provides useful features and functionalities for embedded solutions. For further information about the Yocto, please visit the project’s [http://wiki.yoctoproject.org wiki page] or the [http://www.yoctoproject.org official website].

The application integrates Midori as the main web browser. The browser was used as a fast and lightweight solution that meets up all the expectations of the project. More information on this topic can be found at http://en.wikipedia.org/wiki/Midori_(web_browser).

== Integration Of meta-web-kiosk into Poky ==
This tutorial assumes that you already have a poky distribution on the local machine. If this is not the case follow the steps described in the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html poky manual] to download and configure poky.
Here are the steps to follow in order to get the new image to work:
* Download the repository from [TODO – link to repo]. This step will generate a new folder called meta-web-kiosk.
* Copy the newly cloned folder in the root of poky.
* Open meta/classes/core-image.classes and add the following line
PACKAGE_GROUP_x11-browser=”packagegroup-core-x11-browser”
* If you are using proxies in your network settings uncomment the following lines from meta-web-kiosk/recipes-browser/midori-session/midori-session_0.1.bb
install –d ${D}/home/${USER}/.config/${BROWSER}/
install ${S}/config/ ${D}/home/${USER}/.config/${BROWSER}
** open meta-web-kiosk/recipes-browser/midori-session/midori-session/config and add you proxy settings.
* Source the oe-init-build-env script
. oe-init-build-env
* Open conf/bblayers.conf to add the newly configured layer
…
${path_to_poky}/meta \
…
${path_to_poky}/meta-web-kiosk \
…
* Now that everything is set you can build the new image with bitbake
bitbake core-image-web-kiosk
* and run it in qemu or install it on a device with touchscreen support.

Web Application for Interactive Kiosk Devices

2012-10-11T11:57:42Z

Emma.ciobanu:

__FORCETOC__
[[File:Screenshot from 2012-10-05 15 28 34.png|thumb|upright=1.5|Kiosk device that runs Midori browser]]
An [http://http://en.wikipedia.org/wiki/Interactive_kiosk Interactive Kiosk Device] is a computer terminal with proper hardware and software support that provides public access to different kinds of information. They're used in a large variety of domains including commerce, education, entertaining, tourist information and many others.

== Goal Of The Project ==
The project focuses on developing a minimal image with an integrated browser aimed to be used in touchscreen kiosk applications/operating systems. It consists of creating a yocto based application that will automatically start a Midori browser immediately after boot. The login is made automatically after boot and before the browser starts.

The image is developed as a new layer that is added to poky, a platform-independent, cross-compiling layer that provides useful features and functionalities for embedded solutions. For further information about the Yocto, please visit the project’s [http://wiki.yoctoproject.org wiki page] or the [http://www.yoctoproject.org official website].

The application integrates Midori as the main web browser. The browser was used as a fast and lightweight solution that meets up all the expectations of the project. More information on this topic can be found at http://en.wikipedia.org/wiki/Midori_(web_browser).

== Integration Of meta-web-kiosk into Poky ==
This tutorial assumes that you already have a poky distribution on the local machine. If this is not the case follow the steps described in the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html poky manual] to download and configure poky.
Here are the steps to follow in order to get the new image to work:
* Download the repository from [TODO – link to repo]. This step will generate a new folder called meta-web-kiosk.
* Copy the newly cloned folder in the root of poky.
* Open meta/classes/core-image.classes and add the following line
PACKAGE_GROUP_x11-browser=”packagegroup-core-x11-browser”
* If you are using proxies in your network settings
*# uncomment the following lines from meta-web-kiosk/recipes-browser/midori-session/midori-session_0.1.bb
install –d ${D}/home/${USER}/.config/${BROWSER}/
install ${S}/config/ ${D}/home/${USER}/.config/${BROWSER}
*# open meta-web-kiosk/recipes-browser/midori-session/midori-session/config and add you proxy settings.
* Source the oe-init-build-env script
. oe-init-build-env
* Open conf/bblayers.conf to add the newly configured layer
…
${path_to_poky}/meta \
…
${path_to_poky}/meta-web-kiosk \
…
* Now that everything is set you can build the new image with bitbake
bitbake core-image-web-kiosk
* and run it in qemu or install it on a device with touchscreen support.

File:Screenshot from 2012-10-05 15 28 34.png

2012-10-11T09:30:57Z

Emma.ciobanu: Web Kiosk Application

Web Kiosk Application

Web Application for Interactive Kiosk Devices

2012-10-11T09:29:43Z

Emma.ciobanu: Created page with "__FORCETOC__ An [http://http://en.wikipedia.org/wiki/Interactive_kiosk Interactive Kiosk Device] is a computer terminal with proper hardware and software support that provides pu..."

__FORCETOC__
An [http://http://en.wikipedia.org/wiki/Interactive_kiosk Interactive Kiosk Device] is a computer terminal with proper hardware and software support that provides public access to different kinds of information. They're used in a large variety of domains including commerce, education, entertaining, tourist information and many others.

Projects

2012-10-11T09:24:21Z

Emma.ciobanu:

== Welcome to the Projects Page ==
* [[AutoBuilder]]
* [[Poky]]
* [[SDK Generator]]
* [[Eclipse Plug-in]]
* [[Anjuta Plug-in]]
* [[Pseudo]]
* [[Swabber]]
* [[Cross-Prelink]]
* [[QA]]
* [[Documentation]]
* [[BSPs]]
* [[Tracing and Profiling]]
* Linux Kernel
** [[Linux_Kernel/Boot_Time|Boot Time]]
** [[Linux_kernel/Image_Size|Image Size]]
* [[Multilib]]
* [[BitBake/GUI|BitBake GUI's]]
* [[x32 abi]]
* [[Baryon]]
* [[Build Appliance Design]]
* [[Hob2 (Hob v2)]]
* [[Web UI]]
* [[OpenGL pass-through in QEMU]]
* [[DLNA Media Server Virtual Appliance]]
* [[Running an x86 Yocto Linux image under QEMU KVM]]
* [[Web Application for Interactive Kiosk Devices]]

DLNA Media Server Virtual Appliance

2012-10-11T07:08:53Z

Emma.ciobanu:

__FORCETOC__
[[File:Rygel_Example.png|thumb|upright=1.5|A practical example of how the Media Server using Rygel package is seen by a renderer Media Player.]]
A [http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance DLNA] Media Server is a device that stores media content that can be accessed by media players and rederers found in the same local network. It is developed using the [http://en.wikipedia.org/wiki/Universal_Plug_and_Play Universal Plug and Play] protocol which permits devices to see each other in a local network and enables different data sharing services between them.
 The goal of the project was creating a minimal solution to meet theese requirements. This was achieved using the tools provided by the [http://www.yoctoproject.org/ yocto] project through the creation of the meta-dlna layer.

== Introduction ==

Poky is a platform-independant layer that provides useful features and functionalities for embedded solutions. [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html A Quick Start Guide] and further information can be found on the main page of the [http://www.yoctoproject.org/projects/poky Poky Project].
The functionality of the Media Server was implemented as a new layer, the meta-dlna layer, which can easily be integrated over any poky distribution. Stability and reliability was achieved by using the denzil branch of the yocto project.
 Media Server is built as a virtual appliance, destined to be run under a [http://en.wikipedia.org/wiki/QEMU QEMU] KVM Virtual Machine Manager.
 The linux core of Media Server makes use of the following virtualization acceleration technologies built in the host and guest kernel:
* [http://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine KVM]
* [http://en.wikipedia.org/wiki/Paravirtualization Paravirtualization]
* [http://wiki.libvirt.org/page/Virtio Virtio drivers virtualization]

== Arhitecture design ==
[[File:MediaServer Terminal.png|thumb|left|upright=1.1|Media Server with Rygel]]
 
A basic requirement for the application is giving a minimal solution that meets all the tehnical specifications. That is why the Media Server application was designed to be a headless image. This means that after the system boots a console will automatically pop up.
 The operating system image has no WiFi configuration. However, if possible, wired network connections are automatically set up by the init script of the os.
 

== Package dependencies ==
===== Rygel =====
The solution was build around [https://live.gnome.org/Rygel/ rygel], an application used for media content sharing on a home network. Rygel can act both as a Media Renderer, e.g. an application that plays media content received from the local network and as an Universal Plug and Play Media Server, e.g. and application that makes the media available throughout the network. The project implemented the second solution, that of a UPnP Media Server.
===== Tracker plugin for Rygel =====
[http://projects.gnome.org/tracker/ Tracker] reprezents a data storage for devices that keeps semantic metadata about files and folders and enables data sharing throughout a local network.
===== MediaExport plugin for Rygel =====
The [https://live.gnome.org/Rygel/ MediaExport] plugin exports files and folders over the network. This solution was preferred to Tracker because it represents a more lightweight alternative and meets to all project requirements.

== How to integrate DLNA and KVM into a poky distribution ==
The tutorial assumes that a poky distribution already exists on the local machine. If this is not the case, follow the steps described in the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#dev-manual-start poky manual].
 
The meta-dlna layer was created using the [https://wiki.yoctoproject.org/wiki/Combo-layer combo-layer tool]. To enable it, follow the next steps:
* Copy the <tt>meta-dlna</tt> folder into the root directory of a <tt>poky</tt> distribution. <tt>Cd</tt> into the poky folder.
* Add the layer to <tt>build/conf/bblayers.conf</tt>:
[...]
BBLAYERS="
$POKY_HOME/meta-dlna/meta-guacamayo \
$POKY_HOME/meta-kvm \
[...]

* Add some extra features to <tt>build/local.conf</tt>:
[...]
DISTRO_FEATURES = "ext2 largefile usbhost xattr nfs zeroconf pci ${DISTRO_FEATURES_LIBC} x11"
[...]

* source the oe-init-env script
* build the image using the guacamayo-image-mediaserver target
bitbake <tt>guacamayo-image-mediaserver</tt>
For testing purposes, demo content can be added by inserting the following line into <tt>build/conf/local.conf</tt>:

[...]
IMAGE_FEATURES_append = " guacamayo-demos"
[...]

The demo media will be automatically added into the <tt>/usr/share/demos</tt>. You can now start a media player on a renderer device and be able to navigate trough the demo content from the Media Server.
 At boot the system configures <tt>/home/rygel/</tt> as the default home for rygel. Any additional media files that is added in this folder will automatically be shared throughout the local network. If demo content is added, the <tt>/usr/share/demos</tt> will also be appended in the rygel configuration file as one of the media sources.

== How to run MediaServer using QEMU KVM ==
In order to run Media Server under a VM manager with full virtualization acceleration technologies follow this [https://wiki.yoctoproject.org/wiki/Running_an_x86_Yocto_Linux_image_under_QEMU_KVM guide].
 Please note that Media Server is already configured for KVM, paravirtualization and virtio, so Yocto Linux guest OS will not need further configuration (Guest OS preparation section is already integrated).

== Network configurations ==
The DLNA server will only appear in the local LAN. Because of this, testing the dlna image using the qemu tool requires the VM to be in the same network as the host (bridged network configuration). The standard runqemu script creates a NAT configuration. To create the necessary configuration you first have to run the qemu-bridge script with the start parameter (The script needs the bridge-utils and the uml-utilities packages to be installed on the host system). After this you simply run the qemu command with the following parameters:

sudo /home/ema/ssd/work/poky/build/tmp/sysroots/x86_64-linux/usr/bin/qemu-system-i386 -kernel \
${path_to_build_folder}/poky/tmp/deploy/images/bzImage-qemux86.bin -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no -hda \
${path_to_build_folder}/tmp/deploy/images/core-image-mediaserver-qemux86.ext3 -show-cursor -usb -usbdevice wacom-tablet \
-vga vmware -no-reboot -m 128 --append "vga=0 root=/dev/hda rw mem=128M opr[Bofile.timer=1 "

The command supposes that you build the image for a x86 architecture.
 The qemu-bridge script can be found here - [[File:Qemu-bridge-configuration.txt|qemu-bridge.sh]]. After downloading the qemu-bridge script, make sure you have changed its extension to .sh and added execution rights (chmod a+x qemu-bridge.sh).

After you finished all the testing you can run ./qemu-bridge.sh stop to revert the configuration to your initial one.

DLNA Media Server Virtual Appliance

2012-10-11T06:57:01Z

Emma.ciobanu:

__FORCETOC__
[[File:Rygel_Example.png|thumb|upright=1.5|A practical example of how the Media Server using Rygel package is seen by a renderer Media Player.]]
A [http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance DLNA] Media Server is a device that stores media content that can be accessed by media players and rederers found in the same local network. It is developed using the [http://en.wikipedia.org/wiki/Universal_Plug_and_Play Universal Plug and Play] protocol which permits devices to see each other in a local network and enables different data sharing services between them.
 The goal of the project was creating a minimal solution to meet theese requirements. This was achieved using the tools provided by the [http://www.yoctoproject.org/ yocto] project through the creation of the meta-dlna layer.

== Introduction ==

Poky is a platform-independant layer that provides useful features and functionalities for embedded solutions. [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html A Quick Start Guide] and further information can be found on the main page of the [http://www.yoctoproject.org/projects/poky Poky Project].
The functionality of the Media Server was implemented as a new layer, the meta-dlna layer, which can easily be integrated over any poky distribution. Stability and reliability was achieved by using the denzil branch of the yocto project.
 Media Server is built as a virtual appliance, destined to be run under a [http://en.wikipedia.org/wiki/QEMU QEMU] KVM Virtual Machine Manager.
 The linux core of Media Server makes use of the following virtualization acceleration technologies built in the host and guest kernel:
* [http://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine KVM]
* [http://en.wikipedia.org/wiki/Paravirtualization Paravirtualization]
* [http://wiki.libvirt.org/page/Virtio Virtio drivers virtualization]

== Arhitecture design ==
[[File:MediaServer Terminal.png|thumb|left|upright=1.1|Media Server with Rygel]]
 
A basic requirement for the application is giving a minimal solution that meets all the tehnical specifications. That is why the Media Server application was designed to be a headless image. This means that after the system boots a console will automatically pop up.
 The operating system image has no WiFi configuration. However, if possible, wired network connections are automatically set up by the init script of the os.
 

== Package dependencies ==
===== Rygel =====
The solution was build around [https://live.gnome.org/Rygel/ rygel], an application used for media content sharing on a home network. Rygel can act both as a Media Renderer, e.g. an application that plays media content received from the local network and as an Universal Plug and Play Media Server, e.g. and application that makes the media available throughout the network. The project implemented the second solution, that of a UPnP Media Server.
===== Tracker plugin for Rygel =====
[http://projects.gnome.org/tracker/ Tracker] reprezents a data storage for devices that keeps semantic metadata about files and folders and enables data sharing throughout a local network.
===== MediaExport plugin for Rygel =====
The [https://live.gnome.org/Rygel/ MediaExport] plugin exports files and folders over the network. This solution was preferred to Tracker because it represents a more lightweight alternative and meets to all project requirements.

== How to integrate DLNA and KVM into a poky distribution ==
The tutorial assumes that a poky distribution already exists on the local machine. If this is not the case, follow the steps described in the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#dev-manual-start poky manual].
 
The meta-dlna layer was created using the [https://wiki.yoctoproject.org/wiki/Combo-layer combo-layer tool]. To enable it, follow the next steps:
* Copy the <tt>meta-dlna</tt> folder into the root directory of a <tt>poky</tt> distribution. <tt>Cd</tt> into the poky folder.
* Add the layer to <tt>build/conf/bblayers.conf</tt>:
[...]
BBLAYERS="
$POKY_HOME/meta-dlna/meta-guacamayo \
$POKY_HOME/meta-kvm \
[...]

* Add some extra features to <tt>build/local.conf</tt>:
[...]
DISTRO_FEATURES = "ext2 largefile usbhost xattr nfs zeroconf pci ${DISTRO_FEATURES_LIBC} x11"
[...]

* source the oe-init-env script
* build the image using the guacamayo-image-mediaserver target
bitbake <tt>guacamayo-image-mediaserver</tt>
For testing purposes, demo content can be added by inserting the following line into <tt>build/conf/local.conf</tt>:

[...]
IMAGE_FEATURES_append = " guacamayo-demos"
[...]

The demo media will be automatically added into the <tt>/usr/share/demos</tt>. You can now start a media player on a renderer device and be able to navigate trough the demo content from the Media Server.
 At boot the system configures <tt>/home/rygel/</tt> as the default home for rygel. Any additional media files that is added in this folder will automatically be shared throughout the local network. If demo content is added, the <tt>/usr/share/demos</tt> will also be appended in the rygel configuration file as one of the media sources.

== How to run MediaServer using QEMU KVM ==
In order to run Media Server under a VM manager with full virtualization acceleration technologies follow this [https://wiki.yoctoproject.org/wiki/Running_an_x86_Yocto_Linux_image_under_QEMU_KVM guide].
 Please note that Media Server is already configured for KVM, paravirtualization and virtio, so Yocto Linux guest OS will not need further configuration (Guest OS preparation section is already integrated).

== Network configurations ==
The DLNA server will only appear in the local LAN. Because of this, testing the dlna image using the qemu tool requires the VM to be in the same network as the host (bridged network configuration). The standard runqemu script creates a NAT configuration. To create the necessary configuration you first have to run the qemu-bridge script with the start parameter (The script needs the bridge-utils and the uml-utilities packages that have to be installed on the host system). After this you simply run the qemu command with the following parameters:

sudo ${path_to_build_folder}/tmp/sysroots/x86_64-linux/usr/bin/qemu-system-i386 -kernel ${path_to_build_folder}/poky/tmp/deploy/images/bzImage-qemux86.bin -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no -hda ${path_to_build_folder}/tmp/deploy/images/core-image-mediaserver-qemux86.ext3 -show-cursor -usb -usbdevice wacom-tablet -vga vmware -no-reboot -m 128 --append "vga=0 root=/dev/hda rw mem=128M opr[Bofile.timer=1 "

The command supposes that you build the image for a x86 architecture.
 The qemu-bridge script can be found here - [[File:Qemu-bridge-configuration.txt|qemu-bridge.sh]]. After downloading the qemu-bridge script, make sure you have changed its extension to .sh and added execution rights (chmod a+x qemu-bridge.sh).
 After you finished all the testing you can run ./qemu-bridge.sh stop to revert the configuration to your initial one.

File:Qemu-bridge-configuration.txt

2012-10-11T06:46:04Z

Emma.ciobanu: Use this script to create the proper network configurations.

Use this script to create the proper network configurations.

DLNA Media Server Virtual Appliance

2012-10-11T06:41:34Z

Emma.ciobanu:

__FORCETOC__
[[File:Rygel_Example.png|thumb|upright=1.5|A practical example of how the Media Server using Rygel package is seen by a renderer Media Player.]]
A [http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance DLNA] Media Server is a device that stores media content that can be accessed by media players and rederers found in the same local network. It is developed using the [http://en.wikipedia.org/wiki/Universal_Plug_and_Play Universal Plug and Play] protocol which permits devices to see each other in a local network and enables different data sharing services between them.
 The goal of the project was creating a minimal solution to meet theese requirements. This was achieved using the tools provided by the [http://www.yoctoproject.org/ yocto] project through the creation of the meta-dlna layer.

== Introduction ==

Poky is a platform-independant layer that provides useful features and functionalities for embedded solutions. [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html A Quick Start Guide] and further information can be found on the main page of the [http://www.yoctoproject.org/projects/poky Poky Project].
The functionality of the Media Server was implemented as a new layer, the meta-dlna layer, which can easily be integrated over any poky distribution. Stability and reliability was achieved by using the denzil branch of the yocto project.
 Media Server is built as a virtual appliance, destined to be run under a [http://en.wikipedia.org/wiki/QEMU QEMU] KVM Virtual Machine Manager.
 The linux core of Media Server makes use of the following virtualization acceleration technologies built in the host and guest kernel:
* [http://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine KVM]
* [http://en.wikipedia.org/wiki/Paravirtualization Paravirtualization]
* [http://wiki.libvirt.org/page/Virtio Virtio drivers virtualization]

== Arhitecture design ==
[[File:MediaServer Terminal.png|thumb|left|upright=1.1|Media Server with Rygel]]
 
A basic requirement for the application is giving a minimal solution that meets all the tehnical specifications. That is why the Media Server application was designed to be a headless image. This means that after the system boots a console will automatically pop up.
 The operating system image has no WiFi configuration. However, if possible, wired network connections are automatically set up by the init script of the os.
 

== Package dependencies ==
===== Rygel =====
The solution was build around [https://live.gnome.org/Rygel/ rygel], an application used for media content sharing on a home network. Rygel can act both as a Media Renderer, e.g. an application that plays media content received from the local network and as an Universal Plug and Play Media Server, e.g. and application that makes the media available throughout the network. The project implemented the second solution, that of a UPnP Media Server.
===== Tracker plugin for Rygel =====
[http://projects.gnome.org/tracker/ Tracker] reprezents a data storage for devices that keeps semantic metadata about files and folders and enables data sharing throughout a local network.
===== MediaExport plugin for Rygel =====
The [https://live.gnome.org/Rygel/ MediaExport] plugin exports files and folders over the network. This solution was preferred to Tracker because it represents a more lightweight alternative and meets to all project requirements.

== How to integrate DLNA and KVM into a poky distribution ==
The tutorial assumes that a poky distribution already exists on the local machine. If this is not the case, follow the steps described in the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#dev-manual-start poky manual].
 
The meta-dlna layer was created using the [https://wiki.yoctoproject.org/wiki/Combo-layer combo-layer tool]. To enable it, follow the next steps:
* Copy the <tt>meta-dlna</tt> folder into the root directory of a <tt>poky</tt> distribution. <tt>Cd</tt> into the poky folder.
* Add the layer to <tt>build/conf/bblayers.conf</tt>:
[...]
BBLAYERS="
$POKY_HOME/meta-dlna/meta-guacamayo \
$POKY_HOME/meta-kvm \
[...]

* Add some extra features to <tt>build/local.conf</tt>:
[...]
DISTRO_FEATURES = "ext2 largefile usbhost xattr nfs zeroconf pci ${DISTRO_FEATURES_LIBC} x11"
[...]

* source the oe-init-env script
* build the image using the guacamayo-image-mediaserver target
bitbake <tt>guacamayo-image-mediaserver</tt> [TODO]
For testing purposes, demo content can be added by inserting the following line into <tt>build/conf/local.conf</tt>:

[...]
IMAGE_FEATURES_append = " guacamayo-demos"
[...]

The demo media will be automatically added into the <tt>/usr/share/demos</tt>. You can now start a media player on a renderer device and be able to navigate trough the demo content from the Media Server.
 At boot the system configures <tt>/home/rygel/</tt> as the default home for rygel. Any additional media files that is added in this folder will automatically be shared throughout the local network. If demo content is added, the <tt>/usr/share/demos</tt> will also be appended in the rygel configuration file as one of the media sources.

== How to run MediaServer using QEMU KVM ==
In order to run Media Server under a VM manager with full virtualization acceleration technologies follow this [https://wiki.yoctoproject.org/wiki/Running_an_x86_Yocto_Linux_image_under_QEMU_KVM guide].
 Please note that Media Server is already configured for KVM, paravirtualization and virtio, so Yocto Linux guest OS will not need further configuration (Guest OS preparation section is already integrated).

== Network configurations ==
The DLNA server will only appear in the local LAN. Because of this, testing the dlna image using the qemu tool requires the VM to be in the same network as the host (bridged network configuration). The standard runqemu script creates a NAT configuration. To create the necessary configuration you first have to run the qemu-bridge.sh script with the start parameter (The script needs the bridge-utils and the uml-utilities packages that have to be installed on the host system). After this you simply run the qemu command with the following parameters:

sudo ${path_to_build_folder}/tmp/sysroots/x86_64-linux/usr/bin/qemu-system-i386 -kernel ${path_to_build_folder}/poky/tmp/deploy/images/bzImage-qemux86.bin -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no -hda ${path_to_build_folder}/tmp/deploy/images/core-image-mediaserver-qemux86.ext3 -show-cursor -usb -usbdevice wacom-tablet -vga vmware -no-reboot -m 128 --append "vga=0 root=/dev/hda rw mem=128M opr[Bofile.timer=1 "

The command supposes that you build the image for a x86 architecture.

After you finished all the testing you can run ./qemu-bridge.sh stop to revert the configuration to your initial one.

DLNA Media Server Virtual Appliance

2012-09-07T09:40:02Z

Emma.ciobanu:

__FORCETOC__
[[File:Rygel_Example.png|thumb|upright=1.5|A practical example of how the Media Server using Rygel package is seen by a renderer Media Player.]]
A [http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance DLNA] Media Server is a device that stores media content that can be accessed by media players and rederers found in the same local network. It is developed using the [http://en.wikipedia.org/wiki/Universal_Plug_and_Play Universal Plug and Play] protocol which permits devices to see each other in a local network and enables different data sharing services between them.
 The goal of the project was creating a minimal solution to meet theese requirements. This was achieved using the tools provided by the [http://www.yoctoproject.org/ yocto] project through the creation of the meta-dlna layer.

== Introduction ==

Poky is a platform-independant layer that provides useful features and functionalities for embedded solutions. [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html A Quick Start Guide] and further information can be found on the main page of the [http://www.yoctoproject.org/projects/poky Poky Project].
The functionality of the Media Server was implemented as a new layer, the meta-dlna layer, which can easily be integrated over any poky distribution. Stability and reliability was achieved by using the denzil branch of the yocto project.
 Media Server is built as a virtual appliance, destined to be run under a [http://en.wikipedia.org/wiki/QEMU QEMU] KVM Virtual Machine Manager.
 The linux core of Media Server makes use of the following virtualization acceleration technologies built in the host and guest kernel:
* [http://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine KVM]
* [http://en.wikipedia.org/wiki/Paravirtualization Paravirtualization]
* [http://wiki.libvirt.org/page/Virtio Virtio drivers virtualization]

== Arhitecture design ==
[[File:MediaServer Terminal.png|thumb|left|upright=1.1|Media Server with Rygel]]
 
A basic requirement for the application is giving a minimal solution that meets all the tehnical specifications. That is why the Media Server application was designed to be a headless image. This means that after the system boots a console will automatically pop up.
 The operating system image has no WiFi configuration. However, if possible, wired network connections are automatically set up by the init script of the os.
 

== Package dependencies ==
===== Rygel =====
The solution was build around [https://live.gnome.org/Rygel/ rygel], an application used for media content sharing on a home network. Rygel can act both as a Media Renderer, e.g. an application that plays media content received from the local network and as an Universal Plug and Play Media Server, e.g. and application that makes the media available throughout the network. The project implemented the second solution, that of a UPnP Media Server.
===== Tracker plugin for Rygel =====
[http://projects.gnome.org/tracker/ Tracker] reprezents a data storage for devices that keeps semantic metadata about files and folders and enables data sharing throughout a local network.
===== MediaExport plugin for Rygel =====
The [https://live.gnome.org/Rygel/ MediaExport] plugin exports files and folders over the network. This solution was preferred to Tracker because it represents a more lightweight alternative and meets to all project requirements.

== How to integrate DLNA and KVM into a poky distribution ==
The tutorial assumes that a poky distribution already exists on the local machine. If this is not the case, follow the steps described in the [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#dev-manual-start poky manual].
 
The meta-dlna layer was created using the [https://wiki.yoctoproject.org/wiki/Combo-layer combo-layer tool]. To enable it, follow the next steps:
* Copy the <tt>meta-dlna</tt> folder into the root directory of a <tt>poky</tt> distribution. <tt>Cd</tt> into the poky folder.
* Add the layer to <tt>build/conf/bblayers.conf</tt>:
[...]
BBLAYERS="
$POKY_HOME/meta-dlna/meta-guacamayo \
$POKY_HOME/meta-kvm \
[...]

* Add some extra features to <tt>build/local.conf</tt>:
[...]
DISTRO_FEATURES = "ext2 largefile usbhost xattr nfs zeroconf pci ${DISTRO_FEATURES_LIBC} x11"
[...]

* source the oe-init-env script
* build the image using the guacamayo-image-mediaserver target
bitbake <tt>guacamayo-image-mediaserver</tt> [TODO]
For testing purposes, demo content can be added by inserting the following line into <tt>build/conf/local.conf</tt>:

[...]
IMAGE_FEATURES_append = " guacamayo-demos"
[...]

The demo media will be automatically added into the <tt>/usr/share/demos</tt>. You can now start a media player on a renderer device and be able to navigate trough the demo content from the Media Server.
 At boot the system configures <tt>/home/rygel/</tt> as the default home for rygel. Any additional media files that is added in this folder will automatically be shared throughout the local network. If demo content is added, the <tt>/usr/share/demos</tt> will also be appended in the rygel configuration file as one of the media sources.

== How to run MediaServer using QEMU KVM ==
In order to run Media Server under a VM manager with full virtualization acceleration technologies follow this [https://wiki.yoctoproject.org/wiki/Running_an_x86_Yocto_Linux_image_under_QEMU_KVM guide].
 Please note that Media Server is already configured for KVM, paravirtualization and virtio, so Yocto Linux guest OS will not need further configuration (Guest OS preparation section is already integrated).

Running an x86 Yocto Linux image under QEMU KVM

2012-09-07T09:18:02Z

Emma.ciobanu:

== Host OS preparation (VM manager host OS) ==

1.[https://wiki.yoctoproject.org/wiki/How_to_enable_KVM_for_Poky_qemu Enable KVM] on the host machine

2. Enable on host OS vhost-net virtio networking accelerator to mitigate overhead on QEMU virtualization environment.
 Load vhost-net module on KVM Host.
[root@dlp ~]#modprobe vhost_net
[root@dlp ~]#lsmod | grep vhost
The result of running the commands should be similar to the following:
vhost_net 24241 0
macvtap 7867 1 vhost_net
tun16825 3 vhost_net

Basically, follow the same guide as for enabling KVM on the host (step 1.), but replace kvm with vhost_net

3. Start the VM using the line below:

ubik@sentry:~/yoctoproject/build$ sudo kvm -kernel /home/ubik/yoctoproject/build/tmp/deploy/images/bzImage-qemux86.bin -net nic,model=virtio -net \
tap,vlan=0,ifname=tap0,script=no,downscript=no,vhost=on -drive file=/home/ubik/yoctoproject/build/tmp/deploy/images/core-image-core-qemux86.ext3,if=virtio \
-show-cursor -usb - usbdevice wacom-tablet -vga vmware -no-reboot -enable-kvm -cpu host -m 128 --append "vga=0 root=/dev/vda rw mem=128M \
ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 "

This is an example of running a virtualized Yocto image, with KVM active, cpu host features exported in the Yocto VM, paravirtualization enabled, and using virtio interfaces for disk access and networking.
On a machine equipped with a Core i7 2600 (3.4GHz, 4 cores, 8 threads)/8 GB RAM/Intel SSD G3 120GB qemux86 Yocto Linux boots in around 7 seconds for a core-image-x11. The same image boots in 20 seconds without virtualization optimizations and feels slower in usage.

== Guest OS preparation ==

The following kernel configs needs to be enabled for Yocto Linux guest OS:

[...]
CONFIG_PARAVIRT_GUEST=y
CONFIG_KVM_CLOCK=y
CONFIG_KVM_GUEST=y
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_CLOCK=y
CONFIG_VIRTIO_MMIO=y
[..]

Screenshots example:
[[File:Core-image-x11.png|thumb|upright=2|left|Yocto Linux guest running under QEMU KVM with paravirtualization and virtio tech.]]
[[File:YL-guest-QEMU-cpu-host.png|thumb|left|upright=2|CPU host features exported to Yocto Linux guest.]]

Running an x86 Yocto Linux image under QEMU KVM

2012-09-07T09:16:47Z

Emma.ciobanu:

== Host OS preparation (VM manager host OS) ==

1.[https://wiki.yoctoproject.org/wiki/How_to_enable_KVM_for_Poky_qemu Enable KVM] on the host machine

2. Enable on host OS vhost-net virtio networking accelerator to mitigate overhead on QEMU virtualization environment.
 Load vhost-net module on KVM Host.
[root@dlp ~]#modprobe vhost_net
[root@dlp ~]#lsmod | grep vhost
The result of running the commands should be similar to the following:
vhost_net 24241 0
macvtap 7867 1 vhost_net
tun16825 3 vhost_net

Basically, follow the same guide as for enabling KVM on the host (step 1.), but replace kvm with vhost_net

3. Start the VM using the line below:

ubik@sentry:~/yoctoproject/build$ sudo kvm -kernel /home/ubik/yoctoproject/build/tmp/deploy/images/bzImage-qemux86.bin -net nic,model=virtio -net \
tap,vlan=0,ifname=tap0,script=no,downscript=no,vhost=on -drive file=/home/ubik/yoctoproject/build/tmp/deploy/images/core-image-core-qemux86.ext3,if=virtio \
-show-cursor -usb - usbdevice wacom-tablet -vga vmware -no-reboot -enable-kvm -cpu host -m 128 --append "vga=0 root=/dev/vda rw mem=128M \
ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 "

This is an example of running a virtualized Yocto image, with KVM active, cpu host features exported in the Yocto VM, paravirtualization enabled, and using virtio interfaces for disk access and networking.
On a machine equipped with a Core i7 2600 (3.4GHz, 4 cores, 8 threads)/8 GB RAM/Intel SSD G3 120GB qemux86 Yocto Linux boots in around 7 seconds for a core-image-x11. The same image boots in 20 seconds without virtualization optimizations and feels slower in usage.

See the following screenshots:
[[File:Core-image-x11.png|thumb|upright=2|left|Yocto Linux guest running under QEMU KVM with paravirtualization and virtio tech.]]
[[File:YL-guest-QEMU-cpu-host.png|thumb|upright=2|CPU host features exported to Yocto Linux guest.]]

== Guest OS preparation ==

The following kernel configs needs to be enabled for Yocto Linux guest OS:

[...]
CONFIG_PARAVIRT_GUEST=y
CONFIG_KVM_CLOCK=y
CONFIG_KVM_GUEST=y
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_CLOCK=y
CONFIG_VIRTIO_MMIO=y
[..]

File:YL-guest-QEMU-cpu-host.png

2012-09-07T09:16:09Z

Emma.ciobanu: CPU host features exported to Yocto Linux guest.

CPU host features exported to Yocto Linux guest.

File:Core-image-x11.png

2012-09-07T09:12:50Z

Emma.ciobanu: Yocto Linux guest running under QEMU KVM with paravirtualization and virtio tech.

Yocto Linux guest running under QEMU KVM with paravirtualization and virtio tech.

Running an x86 Yocto Linux image under QEMU KVM

2012-09-07T08:59:16Z

Emma.ciobanu:

== Host OS preparation (VM manager host OS) ==

1. [https://wiki.yoctoproject.org/wiki/How_to_enable_KVM_for_Poky_qemu Enable KVM] on the host machine

2. Enable vhost-net to mitigate overhead on QEMU virtualization environment.
 Load vhost-net module on KVM Host.
[root@dlp ~]#modprobe vhost_net
[root@dlp ~]#lsmod | grep vhost
The result of running the commands should be similar to the following:
vhost_net 24241 0
macvtap 7867 1 vhost_net
tun16825 3 vhost_net

Basically, follow the same guide as for enabling KVM on the host (step 1.), but replace kvm with vhost_net

3. Start the VM using the line below:

ubik@sentry:~/yoctoproject/build$ sudo kvm -kernel /home/ubik/yoctoproject/build/tmp/deploy/images/bzImage-qemux86.bin -net nic,model=virtio -net tap,vlan=0,ifname=tap0,script=no,downscript=no,vhost=on -drive file=/home/ubik/yoctoproject/build/tmp/deploy/images/core-image-core-qemux86.ext3,if=virtio -show-cursor -usb -usbdevice wacom-tablet -vga vmware -no-reboot -enable-kvm -cpu host -m 128 --append "vga=0 root=/dev/vda rw mem=128M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 "

KVM version:
ubik@sentry:~/yoctoproject/build$ kvm --version
QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard

This is an example of running a virtualized Yocto image, with KVM active, cpu host features exported in the Yocto VM, paravirtualization enabled, and using virtio interfaces for disk access and networking.
On my machine, a Core i7 2600 (3.4GHz, 4 cores, 8 threads)/8 GB RAM/Intel SSD G3 120GB it start in around 7 seconds for a core-image-core. The same image boots in 20 seconds without virtualization optimization and it feels slower in usage.

See attached screenshots for VM running and proof of concept.
Also attached is the patch for running our runqemu script with KVM and paravirt and virtio tech.
In order to run it, use:

runqemu qemux86 core-image-core kvm

Log:

ubik@sentry:~/yoctoproject/build$ runqemu qemux86 core-image-core kvm
Assuming core-image-core really means /home/ubik/yoctoproject/build/tmp/deploy/images/core-image-core-qemux86.ext3

Continuing with the following parameters:
KERNEL: [/home/ubik/yoctoproject/build/tmp/deploy/images/bzImage-qemux86.bin]
ROOTFS: [/home/ubik/yoctoproject/build/tmp/deploy/images/core-image-core-qemux86.ext3]
FSTYPE: [ext3]
Setting up tap interface under sudo
[sudo] password for ubik:
Acquiring lockfile for tap0...
WARNING: distccd not present, no distcc support loaded.
Running qemu...
/home/ubik/yoctoproject/build/tmp/sysroots/x86_64-linux/usr/bin/qemu -kernel /home/ubik/yoctoproject/build/tmp/deploy/images/bzImage-qemux86.bin -net nic,model=virtio -net tap,vlan=0,ifname=tap0,script=no,downscript=no,vhost=on -drive file=/home/ubik/yoctoproject/build/tmp/deploy/images/core-image-core-qemux86.ext3,if=virtio -show-cursor -usb -usbdevice wacom-tablet -vga vmware -no-reboot -enable-kvm -cpu host -m 128 --append "vga=0 root=/dev/vda rw mem=128M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 "
vmsvga_value_write: guest runs Linux.
Set 'tap0' nonpersistent
Releasing lockfile of preconfigured tap device 'tap0'
ubik@sentry:~/yoctoproject/build$

== Guest OS preparation ==

The following kernel configs needs to be enabled:

CONFIG_PARAVIRT_GUEST=y
# CONFIG_PARAVIRT_TIME_ACCOUNTING is not set
# CONFIG_XEN_PRIVILEGED_GUEST is not set
CONFIG_KVM_CLOCK=y
CONFIG_KVM_GUEST=y
# CONFIG_LGUEST_GUEST is not set
CONFIG_PARAVIRT=y
# CONFIG_PARAVIRT_SPINLOCKS is not set
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_VIRTIO_MMIO=y

Running an x86 Yocto Linux image under QEMU KVM

2012-09-07T08:52:04Z

Emma.ciobanu: Created page with "== Host OS preparation (VM manager host OS) == 1. Enable KVM on the host machine, according to the guide below: https://wiki.yoctoproject.org/wiki/How_to_enable_KVM_for_Poky_qe..."

== Host OS preparation (VM manager host OS) ==

1. Enable KVM on the host machine, according to the guide below:
https://wiki.yoctoproject.org/wiki/How_to_enable_KVM_for_Poky_qemu

2. Enable vhost-net to mitigate overheads on virtualization environment.
Load vhost-net module on KVM Host.
[root@dlp ~]#modprobe vhost_net
[root@dlp ~]#lsmod | grep vhost

vhost_net 24241 0
macvtap 7867 1 vhost_net
tun16825 3 vhost_net

Basically, follow the same guide as for enabling KVM on the host (step 1.), but replace kvm with vhost_net

3. Start the VM using the line below:

ubik@sentry:~/yoctoproject/build$ sudo kvm -kernel /home/ubik/yoctoproject/build/tmp/deploy/images/bzImage-qemux86.bin -net nic,model=virtio -net tap,vlan=0,ifname=tap0,script=no,downscript=no,vhost=on -drive file=/home/ubik/yoctoproject/build/tmp/deploy/images/core-image-core-qemux86.ext3,if=virtio -show-cursor -usb -usbdevice wacom-tablet -vga vmware -no-reboot -enable-kvm -cpu host -m 128 --append "vga=0 root=/dev/vda rw mem=128M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 "

KVM version:
ubik@sentry:~/yoctoproject/build$ kvm --version
QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard

This is an example of running a virtualized Yocto image, with KVM active, cpu host features exported in the Yocto VM, paravirtualization enabled, and using virtio interfaces for disk access and networking.
On my machine, a Core i7 2600 (3.4GHz, 4 cores, 8 threads)/8 GB RAM/Intel SSD G3 120GB it start in around 7 seconds for a core-image-core. The same image boots in 20 seconds without virtualization optimization and it feels slower in usage.

See attached screenshots for VM running and proof of concept.
Also attached is the patch for running our runqemu script with KVM and paravirt and virtio tech.
In order to run it, use:

runqemu qemux86 core-image-core kvm

Log:

ubik@sentry:~/yoctoproject/build$ runqemu qemux86 core-image-core kvm
Assuming core-image-core really means /home/ubik/yoctoproject/build/tmp/deploy/images/core-image-core-qemux86.ext3

Continuing with the following parameters:
KERNEL: [/home/ubik/yoctoproject/build/tmp/deploy/images/bzImage-qemux86.bin]
ROOTFS: [/home/ubik/yoctoproject/build/tmp/deploy/images/core-image-core-qemux86.ext3]
FSTYPE: [ext3]
Setting up tap interface under sudo
[sudo] password for ubik:
Acquiring lockfile for tap0...
WARNING: distccd not present, no distcc support loaded.
Running qemu...
/home/ubik/yoctoproject/build/tmp/sysroots/x86_64-linux/usr/bin/qemu -kernel /home/ubik/yoctoproject/build/tmp/deploy/images/bzImage-qemux86.bin -net nic,model=virtio -net tap,vlan=0,ifname=tap0,script=no,downscript=no,vhost=on -drive file=/home/ubik/yoctoproject/build/tmp/deploy/images/core-image-core-qemux86.ext3,if=virtio -show-cursor -usb -usbdevice wacom-tablet -vga vmware -no-reboot -enable-kvm -cpu host -m 128 --append "vga=0 root=/dev/vda rw mem=128M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 "
vmsvga_value_write: guest runs Linux.
Set 'tap0' nonpersistent
Releasing lockfile of preconfigured tap device 'tap0'
ubik@sentry:~/yoctoproject/build$

== Guest OS preparation ==

The following kernel configs needs to be enabled:

CONFIG_PARAVIRT_GUEST=y
# CONFIG_PARAVIRT_TIME_ACCOUNTING is not set
# CONFIG_XEN_PRIVILEGED_GUEST is not set
CONFIG_KVM_CLOCK=y
CONFIG_KVM_GUEST=y
# CONFIG_LGUEST_GUEST is not set
CONFIG_PARAVIRT=y
# CONFIG_PARAVIRT_SPINLOCKS is not set
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_VIRTIO_MMIO=y

Projects

2012-09-07T08:45:12Z

Emma.ciobanu:

DLNA Media Server Virtual Appliance

2012-09-06T15:45:44Z

Emma.ciobanu:

DLNA Media Server Virtual Appliance

2012-09-06T14:01:00Z

Emma.ciobanu:

DLNA Media Server Virtual Appliance

2012-09-06T13:49:40Z

Emma.ciobanu:

Main Page

2012-09-06T13:04:59Z

Emma.ciobanu:

== Welcome to the Yocto Project Wiki! ==
=== Current Project Status ===
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status

=== Main Wiki Sections ===
* [[Planning and Governance]]
* [[Community Guidelines]]
* [[Processes and Activities]]
** [[YoctoCalendar]]
* [[Projects]]
* [[Yocto Interest Groups]]
* [[FAQ]]
* [[How do I]]
* [[Contributors]]
* [[Training]]

== Other resources ==
* [http://yoctoproject.org Yocto Project Front Page]

DLNA Media Server Virtual Appliance

2012-09-06T12:58:59Z

Emma.ciobanu:

DLNA Media Server Virtual Appliance

2012-09-06T12:49:03Z

Emma.ciobanu:

DLNA Media Server Virtual Appliance

2012-09-06T12:43:01Z

Emma.ciobanu:

DLNA Media Server Virtual Appliance

2012-09-06T12:35:57Z

Emma.ciobanu:

__FORCETOC__
A [http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance DLNA] Media Server is a device that stores media content that can be accessed by media players and rederers found in the same local network. The goal of the project was creating a minimal solution to meet theese requirements. This was achieved using the tools provided by the [http://www.yoctoproject.org/ yocto] project through the creation of the meta-dlna layer.
[[File:Rygel_Example.png|thumb|upright=1.5|A practical example of how the Media Server using Rygel package is seen by a renderer Media Player.]]

== Introduction ==

Poky is a platform-independant layer that provides useful features and functionalities for embedded solutions. [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html A Quick Start Guide] and further information can be found on the main page of the [http://www.yoctoproject.org/projects/poky Poky Project].
The functionality of the Media Server was implemented as a new layer, the meta-dlna layer, which can easily be integrated over any poky distribution. Stability and reliability was achieved by using the denzil branch of the yocto project.
 
[TODO] - KVM

== Arhitecture design ==

A basic requirement for the application is giving a minimal solution that meets all the tehnical specifications. That is why the Media Server application was designed to be a headless image. This means that after the system boots a console will automatically pop up.
[[File:MediaServer Terminal.png|thumb|upright=1.5|Media Server with Rygel]]

== Package dependencies ==
===== Rygel =====
The solution was build around [https://live.gnome.org/Rygel/ rygel], an application used for media content sharing on a home network. Rygel implements its functionality through a plugin mechanism.
===== Tracker plugin =====
[http://projects.gnome.org/tracker/ Tracker] reprezents a data storage for devices that keeps semantic metadata about files and folders and enables data sharing throughout a local network.
===== MediaExport plugin =====
The [https://live.gnome.org/Rygel/ MediaExport] plugin exports files and folders over the network. This solution was preferred to Tracker because it represents a more lightweight alternative and meets to all project requirements.
 [TODO] - KVM

== How to integrate DLNA to a poky distribution ==
The meta-dlna layer was created using the [https://wiki.yoctoproject.org/wiki/Combo-layer combo-layer tool]. To enable it, follow the next steps:
* Copy the <tt>meta-dlna</tt> folder into the root directory of a <tt>poky</tt> distribution. <tt>Cd</tt> into the poky folder.
* Add the layer to <tt>build/conf/bblayers.conf</tt>:
[...]
BBLAYERS="
$POKY_HOME/meta-dlna/meta-guacamayo
[...]

* Add some extra features to <tt>build/local.conf</tt>:
[...]
DISTRO_FEATURES = "ext2 largefile usbhost xattr nfs zeroconf pci ${DISTRO_FEATURES_LIBC} x11"
[...]

* source the oe-init-env script
* build the image using the guacamayo-image-mediaserver target
bitbake <tt>guacamayo-image-mediaserver</tt> [TODO]
For testing purposes, demo content can be added by inserting the following line into <tt>build/conf/local.conf</tt>:

[...]
IMAGE_FEATURES_append = " guacamayo-demos"
[...]

File:MediaServer Terminal.png

2012-09-06T12:34:45Z

Emma.ciobanu: uploaded a new version of "File:MediaServer Terminal.png"

File:MediaServer Terminal.png

2012-09-06T12:32:12Z

Emma.ciobanu:

DLNA Media Server Virtual Appliance

2012-09-06T11:34:38Z

Emma.ciobanu:

__FORCETOC__
A [http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance DLNA] Media Server is a device that stores media content that can be accessed by media players and rederers found in the same local network. The goal of the project was creating a minimal solution to meet theese requirements. This was achieved using the tools provided by the [http://www.yoctoproject.org/ yocto] project through the creation of the meta-dlna layer.
[[File:Rygel_Example.png|thumb|upright=1.5|A practical example of how the Media Server using Rygel package is seen by a renderer Media Player.]]

== Introduction ==

Poky is a platform-independant layer that provides useful features and functionalities for embedded solutions. [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html A Quick Start Guide] and further information can be found on the main page of the [http://www.yoctoproject.org/projects/poky Poky Project].
The functionality of the Media Server was implemented as a new layer, the meta-dlna layer, which can easily be integrated over any poky distribution. Stability and reliability was achieved by using the denzil branch of the yocto project.
 
[TODO] - KVM

== Arhitecture design ==

A basic requirement of the system is represented by

== Package dependencies ==
===== Rygel =====
The solution was build around [https://live.gnome.org/Rygel/ rygel], an application used for media content sharing on a home network. Rygel implements its functionality through a plugin mechanism.
===== Tracker plugin =====
[http://projects.gnome.org/tracker/ Tracker] reprezents a data storage for devices that keeps semantic metadata about files and folders and enables data sharing throughout a local network.
===== MediaExport plugin =====
The [https://live.gnome.org/Rygel/ MediaExport] plugin exports files and folders over the network. This solution was preferred to Tracker because it represents a more lightweight alternative and meets to all project requirements.
 [TODO] - KVM

== How to integrate DLNA to a poky distribution ==
The meta-dlna layer was created using the [https://wiki.yoctoproject.org/wiki/Combo-layer combo-layer tool]. To enable it, follow the next steps:
* Copy the <tt>meta-dlna</tt> folder into the root directory of a <tt>poky</tt> distribution. <tt>Cd</tt> into the poky folder.
* Add the layer to <tt>build/conf/bblayers.conf</tt>:
[...]
BBLAYERS="
$POKY_HOME/meta-dlna/meta-guacamayo
[...]

* Add some extra features to <tt>build/local.conf</tt>:
[...]
DISTRO_FEATURES = "ext2 largefile usbhost xattr nfs zeroconf pci ${DISTRO_FEATURES_LIBC} x11"
[...]

* source the oe-init-env script
* build the image using the guacamayo-image-mediaserver target
bitbake <tt>guacamayo-image-mediaserver</tt> [TODO]
For testing purposes, demo content can be added by inserting the following line into <tt>build/conf/local.conf</tt>:

[...]
IMAGE_FEATURES_append = " guacamayo-demos"
[...]

DLNA Media Server Virtual Appliance

2012-09-06T11:34:11Z

Emma.ciobanu:

__FORCETOC__
A [http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance DLNA] Media Server is a device that stores media content that can be accessed by media players and rederers found in the same local network. The goal of the project was creating a minimal solution to meet theese requirements. This was achieved using the tools provided by the [http://www.yoctoproject.org/ yocto] project through the creation of the meta-dlna layer.
[[File:Rygel_Example.png|thumb|upright=1.5|A practicle example of how the Media Server using Rygel package is seen by a renderer Media Player.]]

== Introduction ==

Poky is a platform-independant layer that provides useful features and functionalities for embedded solutions. [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html A Quick Start Guide] and further information can be found on the main page of the [http://www.yoctoproject.org/projects/poky Poky Project].
The functionality of the Media Server was implemented as a new layer, the meta-dlna layer, which can easily be integrated over any poky distribution. Stability and reliability was achieved by using the denzil branch of the yocto project.
 
[TODO] - KVM

== Arhitecture design ==

A basic requirement of the system is represented by

== Package dependencies ==
===== Rygel =====
The solution was build around [https://live.gnome.org/Rygel/ rygel], an application used for media content sharing on a home network. Rygel implements its functionality through a plugin mechanism.
===== Tracker plugin =====
[http://projects.gnome.org/tracker/ Tracker] reprezents a data storage for devices that keeps semantic metadata about files and folders and enables data sharing throughout a local network.
===== MediaExport plugin =====
The [https://live.gnome.org/Rygel/ MediaExport] plugin exports files and folders over the network. This solution was preferred to Tracker because it represents a more lightweight alternative and meets to all project requirements.
 [TODO] - KVM

== How to integrate DLNA to a poky distribution ==
The meta-dlna layer was created using the [https://wiki.yoctoproject.org/wiki/Combo-layer combo-layer tool]. To enable it, follow the next steps:
* Copy the <tt>meta-dlna</tt> folder into the root directory of a <tt>poky</tt> distribution. <tt>Cd</tt> into the poky folder.
* Add the layer to <tt>build/conf/bblayers.conf</tt>:
[...]
BBLAYERS="
$POKY_HOME/meta-dlna/meta-guacamayo
[...]

* Add some extra features to <tt>build/local.conf</tt>:
[...]
DISTRO_FEATURES = "ext2 largefile usbhost xattr nfs zeroconf pci ${DISTRO_FEATURES_LIBC} x11"
[...]

* source the oe-init-env script
* build the image using the guacamayo-image-mediaserver target
bitbake <tt>guacamayo-image-mediaserver</tt> [TODO]
For testing purposes, demo content can be added by inserting the following line into <tt>build/conf/local.conf</tt>:

[...]
IMAGE_FEATURES_append = " guacamayo-demos"
[...]

DLNA Media Server Virtual Appliance

2012-09-06T10:57:48Z

Emma.ciobanu:

__FORCETOC__
A [http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance DLNA] Media Server is a device that stores media content that can be accessed by media players and rederers found in the same local network. The goal of the project was creating a minimal solution to meet theese requirements. This was achieved using the tools provided by the [http://www.yoctoproject.org/ yocto] project through the creation of the meta-dlna layer.
[[File:Rygel_Example.png|thumb|upright=1.5|A practicle example of how the Media Server using Rygel package is seen by a renderer Media Player.]]

== Introduction ==

Poky is a platform-independant layer that provides useful features and functionalities for embedded solutions. [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html A Quick Start Guide] and further information can be found on the main page of the [http://www.yoctoproject.org/projects/poky Poky Project].
The functionality of the Media Server was implemented as a new layer, the meta-dlna layer, which can easily be integrated over any poky distribution. Stability and reliability was achieved by using the denzil branch of the yocto project.
 
[TODO] - KVM

== Package dependencies ==
===== Rygel =====
The solution was build around [https://live.gnome.org/Rygel/ rygel], an application used for media content sharing on a home network. Rygel implements its functionality through a plugin mechanism.
===== Tracker plugin =====
[http://projects.gnome.org/tracker/ Tracker] reprezents a data storage for devices that keeps semantic metadata about files and folders and enables data sharing throughout a local network.
===== MediaExport plugin =====
The [https://live.gnome.org/Rygel/ MediaExport] plugin exports files and folders over the network. This solution was preferred to Tracker because it represents a more lightweight alternative and meets to all project requirements.
 [TODO] - KVM

== How to integrate DLNA to a poky distribution ==
The meta-dlna layer was created using the [https://wiki.yoctoproject.org/wiki/Combo-layer combo-layer tool]. To enable it, follow the next steps:
* Copy the <tt>meta-dlna</tt> folder into the root directory of a <tt>poky</tt> distribution. <tt>Cd</tt> into the poky folder.
* Add the layer to <tt>build/conf/bblayers.conf</tt>:
[...]
BBLAYERS="
$POKY_HOME/meta-dlna/meta-guacamayo
[...]

* Add some extra features to <tt>build/local.conf</tt>:
[...]
DISTRO_FEATURES = "ext2 largefile usbhost xattr nfs zeroconf pci ${DISTRO_FEATURES_LIBC} x11"
[...]

* source the oe-init-env script
* build the image using the guacamayo-image-mediaserver target
bitbake <tt>guacamayo-image-mediaserver</tt> [TODO]
For testing purposes, demo content can be added by inserting the following line into <tt>build/conf/local.conf</tt>:

[...]
IMAGE_FEATURES_append = " guacamayo-demos"
[...]

DLNA Media Server Virtual Appliance

2012-09-06T10:52:11Z

Emma.ciobanu:

__FORCETOC__
A [http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance DLNA] Media Server is a device that stores media content that can be accessed by media players and rederers found in the same local network. The goal of the project was creating a minimal solution to meet theese requirements. This was achieved using the tools provided by the [http://www.yoctoproject.org/ yocto] project through the creation of the meta-dlna layer.
[[File:Rygel_Example.png|thumb]]

== Introduction ==

Poky is a platform-independant layer that provides useful features and functionalities for embedded solutions. [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html A Quick Start Guide] and further information can be found on the main page of the [http://www.yoctoproject.org/projects/poky Poky Project].
The functionality of the Media Server was implemented as a new layer, the meta-dlna layer, which can easily be integrated over any poky distribution. Stability and reliability was achieved by using the denzil branch of the yocto project.
 
[TODO] - KVM

== Package dependencies ==
===== Rygel =====
The solution was build around [https://live.gnome.org/Rygel/ rygel], an application used for media content sharing on a home network. Rygel implements its functionality through a plugin mechanism.
===== Tracker plugin =====
[http://projects.gnome.org/tracker/ Tracker] reprezents a data storage for devices that keeps semantic metadata about files and folders and enables data sharing throughout a local network.
===== MediaExport plugin =====
The [https://live.gnome.org/Rygel/ MediaExport] plugin exports files and folders over the network. This solution was preferred to Tracker because it represents a more lightweight alternative and meets to all project requirements.
 [TODO] - KVM

== How to integrate DLNA to a poky distribution ==
The meta-dlna layer was created using the [https://wiki.yoctoproject.org/wiki/Combo-layer combo-layer tool]. To enable it, follow the next steps:
* Copy the <tt>meta-dlna</tt> folder into the root directory of a <tt>poky</tt> distribution. <tt>Cd</tt> into the poky folder.
* Add the layer to <tt>build/conf/bblayers.conf</tt>:
[...]
BBLAYERS="
$POKY_HOME/meta-dlna/meta-guacamayo
[...]

* Add some extra features to <tt>build/local.conf</tt>:
[...]
DISTRO_FEATURES = "ext2 largefile usbhost xattr nfs zeroconf pci ${DISTRO_FEATURES_LIBC} x11"
[...]

* source the oe-init-env script
* build the image using the guacamayo-image-mediaserver target
bitbake <tt>guacamayo-image-mediaserver</tt> [TODO]
For testing purposes, demo content can be added by inserting the following line into <tt>build/conf/local.conf</tt>:

[...]
IMAGE_FEATURES_append = " guacamayo-demos"
[...]

File:Rygel Example.png

2012-09-06T07:58:04Z

Emma.ciobanu: uploaded a new version of "File:Rygel Example.png": A practical example of how a media server using rygel package is seen by a Media Player renderer.

A practicle example of how the Media Server using Rygel package is seen by a renderer Media Player.

File:Rygel Example.png

2012-09-06T07:55:36Z

Emma.ciobanu: uploaded a new version of "File:Rygel Example.png": Reverted to version as of 07:55, 6 September 2012

A practicle example of how the Media Server using Rygel package is seen by a renderer Media Player.

File:Rygel Example.png

2012-09-06T07:55:20Z

Emma.ciobanu: uploaded a new version of "File:Rygel Example.png": A practicle example of how the Media Server using Rygel package is seen by a renderer Media Player.

A practicle example of how the Media Server using Rygel package is seen by a renderer Media Player.

File:Rygel Example.png

2012-09-06T07:55:04Z

Emma.ciobanu: A practicle example of how the Media Server using Rygel package is seen by a renderer Media Player.

A practicle example of how the Media Server using Rygel package is seen by a renderer Media Player.

DLNA Media Server Virtual Appliance

2012-09-06T07:51:15Z

Emma.ciobanu:

__FORCETOC__
A [http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance DLNA] Media Server is a device that stores media content that can be accessed by media players and rederers found in the same local network. The goal of the project was creating a minimal solution to meet theese requirements. This was achieved using the tools provided by the [http://www.yoctoproject.org/ yocto] project through the creation of the meta-dlna layer.[[File:Example.jpg]]

== Introduction ==

Poky is a platform-independant layer that provides useful features and functionalities for embedded solutions. [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html A Quick Start Guide] and further information can be found on the main page of the [http://www.yoctoproject.org/projects/poky Poky Project].
The functionality of the Media Server was implemented as a new layer, the meta-dlna layer, which can easily be integrated over any poky distribution. Stability and reliability was achieved by using the denzil branch of the yocto project.
 
[TODO] - KVM

== Package dependencies ==
===== Rygel =====
The solution was build around [https://live.gnome.org/Rygel/ rygel], an application used for media content sharing on a home network. Rygel implements its functionality through a plugin mechanism.
===== Tracker plugin =====
[http://projects.gnome.org/tracker/ Tracker] reprezents a data storage for devices that keeps semantic metadata about files and folders and enables data sharing throughout a local network.
===== MediaExport plugin =====
The [https://live.gnome.org/Rygel/ MediaExport] plugin exports files and folders over the network. This solution was preferred to Tracker because it represents a more lightweight alternative and meets to all project requirements.
 [TODO] - KVM

== How to integrate DLNA to a poky distribution ==
The meta-dlna layer was created using the [https://wiki.yoctoproject.org/wiki/Combo-layer combo-layer tool]. To enable it, follow the next steps:
* Copy the <tt>meta-dlna</tt> folder into the root directory of a <tt>poky</tt> distribution. <tt>Cd</tt> into the poky folder.
* Add the layer to <tt>build/conf/bblayers.conf</tt>:
[...]
BBLAYERS="
$POKY_HOME/meta-dlna/meta-guacamayo
[...]

* Add some extra features to <tt>build/local.conf</tt>:
[...]
DISTRO_FEATURES = "ext2 largefile usbhost xattr nfs zeroconf pci ${DISTRO_FEATURES_LIBC} x11"
[...]

* source the oe-init-env script
* build the image using the guacamayo-image-mediaserver target
bitbake <tt>guacamayo-image-mediaserver</tt> [TODO]
For testing purposes, demo content can be added by inserting the following line into <tt>build/conf/local.conf</tt>:

[...]
IMAGE_FEATURES_append = " guacamayo-demos"
[...]

DLNA Media Server Virtual Appliance

2012-09-06T07:30:21Z

Emma.ciobanu:

__FORCETOC__
A [http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance DLNA] Media Server is a device that stores media content that can be accessed by media players and rederers found in the same local network. The goal of the project was creating a minimal solution to meet theese requirements. This was achieved using the tools provided by the [http://www.yoctoproject.org/ yocto] project through the creation of the meta-dlna layer.

== Introduction ==

Poky is a platform-independant layer that provides useful features and functionalities for embedded solutions. [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html A Quick Start Guide] and further information can be found on the main page of the [http://www.yoctoproject.org/projects/poky Poky Project].
The functionality of the Media Server was implemented as a new layer, the meta-dlna layer, which can easily be integrated over any poky distribution. Stability and reliability was achieved by using the denzil branch of the yocto project.
 

== Package dependencies ==

The solution was build around [https://live.gnome.org/Rygel/ rygel], an application used for media content sharing on a home network. Rygel implements its functionality through a plugin mechanism. A solution uses the [https://live.gnome.org/Rygel/ MediaExport] plugin which exports files and folders over the network. This was preffered because it represents a more lightweight alternative.

== How to integrate DLNA to a poky distribution ==
The meta-dlna layer was created using the [https://wiki.yoctoproject.org/wiki/Combo-layer combo-layer tool]. To use it follow the next steps:
* Copy the <tt>meta-dlna</tt> folder into the root directory of a <tt>poky</tt> distribution. <tt>Cd</tt> into the poky folder.
* Add the layer to <tt>build/conf/bblayers.conf</tt>:
[...]
BBLAYERS="
$POKY_HOME/meta-dlna/meta-guacamayo
[...]

* Add some extra features to <tt>build/local.conf</tt>:
[...]
DISTRO_FEATURES = "ext2 largefile usbhost xattr nfs zeroconf pci ${DISTRO_FEATURES_LIBC} x11"
[...]

* source the oe-init-env script
* build the image using the guacamayo-image-mediaserver target
bitbake <tt>guacamayo-image-mediaserver</tt> [TODO]
For testing purposes, demo content can be added by inserting the following line into <tt>build/conf/local.conf</tt>:

[...]
IMAGE_FEATURES_append = " guacamayo-demos"
[...]

DLNA Media Server Virtual Appliance

2012-09-06T06:49:57Z

Emma.ciobanu:

== Introduction ==

A DLNA[1] Media Server is a device that stores media content that can be accessed by media players and rederers found in the same local network. The goal was creating a minimal solution to meet theese requirements. This was achieved using the tools provided by the yocto project through the creation of the meta-dlna layer.

== Package dependencies ==

The solution was build around rygel[2], an application used for media content sharing on a home network. Rygel implements its functionality through a plugin mechanism. A solution provided by Tracker. An alternative solution is uses the MediaExport plugin which exports files and folders over the network. This was preffered because it represents a more lightweight solution.

== How to integrate DLNA to a poky distribution ==

The meta-dlna layer was created using the combo-layer tool[3]. To use it follow the next steps:
* Copy the <tt>meta-dlna</tt> folder into the root directory of a <tt>poky</tt> distribution. <tt>Cd</tt> into the poky folder.
* Add the layer to <tt>build/conf/bblayers.conf</tt>:
[...]
BBLAYERS="
$POKY_HOME/meta-dlna/meta-guacamayo
[...]

* Add some extra features to <tt>build/local.conf</tt>:
[...]
DISTRO_FEATURES = "ext2 largefile usbhost xattr nfs zeroconf pci ${DISTRO_FEATURES_LIBC} x11"
[...]

* source the oe-init-env script
* build the image using the guacamayo-image-mediaserver target
bitbake <tt>guacamayo-image-mediaserver</tt> [TODO]
For testing purposes, demo content can be added by inserting the following line into <tt>build/conf/local.conf</tt>:

[...]
IMAGE_FEATURES_append = " guacamayo-demos"
[...]

__FORCETOC__

DLNA Media Server Virtual Appliance

2012-09-06T06:49:26Z

Emma.ciobanu:

DLNA Media Server Virtual Appliance

2012-09-05T16:46:59Z

Emma.ciobanu: