View source for Device Profile Proposal

[[Category:QtEcosystemTeamTasklist]]
[[Category:Devices]]
== Device Profile ==

Modern devices require platform/device init code for OpenGL and possible other features in the future. We have gained some experience with device profile in Qtopia and would like to propose the following development path.

=== Configure option ===

We propose to introduce '''-device''' and '''-device-option KEY=VALUE''' configure options. The first will select a mkspec and the second will add variables that can be used by the mkspec. Right now we don't plan to inject configure options through the device profile.

Example:
<code>
./configure -device broadcom/linux-mipsel-97425-gcc -device-option BRCM_ROCKFORD_PATH=/opt/bcm/rockford
</code>

=== Platform Extensions ===
# Platform integration plugins will have a hooks struct (struct of function pointers to init, destroy, etc)
# Each platform exposes a variable named platform_hook that is the above struct
# qplatformdefs.h or qmake.conf adds the define QT_DIRECTFB_HAS_PLATFORM_CODE
# The platform plugin initializes it's hooks as so:
<code>
DirectFBPlatformHooks hooks = { 0 };
#ifdef QT_DIRECTFB_HAS_PLATFORM_CODE
extern DirectFBPlatformHooks platform_hook;
hooks = platform_hook;
#endif
</code>

# platform plugin calls hooks, checking for null
<code>
if (hook->init)
 hook->init(). // avoids any ifdef usage
</code>
# qmake.conf of the device spec has DIRECTFB_PLATFORM_SOURCES, DIRECTFB_PLATFORM_LIBS etc.
# platformplugin.pro can do LIBS += $DIRECTFB_PLATFORM_LIBS

=== Discussion ===

==== Configure ====

* The mkspec needs to start with linux as the dirname will end up as a scope in QMake and given the future of qmake it might not make sense to provide an variable inside the mkspecs to replace the name/scope.
* How to keep a consistent interface between different implementations? Do we ever need to keep state? Where would we keep it? Influence strategy?
* Alternatively keep all this code in the main file and only have a define that activates the code?
* What about Fedora/Ubuntu that would like to have exactly ''one'' Qt? Will we end up with runtime detection?

==== Platform Hooks ====

* Easily make out what the hooks are looking at the struct
* Platform code can bring it's own libs through DIRECTFB_PLATFORM_LIBS
* Keep usage QT_DIRECTFB_HAS_PLATFORM_CODE to one place in the platform plugin
* Since the hooks can be switched at runtime, we can a device profile supporting mutiple device flavors

=== not merged parts ===

# -device argument to configure will mandate 3 other flags -sysroot, -toolchain and -pkg-config-path. Maybe we can require pkg-config support for the whole -device stuff. And automatically setup pkg-config-sysroot-dir.
# rpath-link vs -L needs to be explored. Devices like the pi have some ilbs in $SYSROOT/opt/vc

configure implementation strategy
* Put device variables, toolchain path, rootfs path, pkg-config paths (can be auto derived?) in device.pri.
* One can use device specific variables to influence the variable values. For example, ubuntu and fedora might have different paths.
* include(../device.pri) or load(devicespec) in qmake.conf
* [not sure] Add config.sh that is sourced inside configure- use this to disable board specific stuff that are known not to work. (disable webkit2 maybe)

== Counter Proposals ==

=== Subclass plugins ===

* It might be cleaner to subclass the plugin.
* In the case of directfb this would include:
** subclass DirectFBEGLIntegration and implement platformInit
** somehow inject the new plugin string into the .json file
** somehow inject the new class name into the main.cpp
* In the case of eglfs this would include:
** subclass Screen to add init code
** subclass Integration to create the new screen class
** somehow inject thew new plugin string into the .json file
** somehow inject the new class name into the main.cpp

Right now I think it will be a major pain in terms of buildsystem to somehow make this work, and with eglfs it requires to subclass a class just to create another one.