Device Profile Proposal: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 1: Line 1:
==Device Profile==
[[Category:QtEcosystemTeamTasklist]]
 
== 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.
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===
=== Configure option ===
 
We propose to introduce ‘’‘-device’‘’ and ‘’‘-device-option <span class="caps">KEY</span>=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:<br />


===Platform Extensions===
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.


# Platform integration plugins will have a hooks struct (struct of function pointers to init, destroy, etc)
Example:<br /><code><br />./configure -device broadcom/linux-mipsel-97425-gcc <s>device-option BRCM_ROCKFORD_PATH=/opt/bcm/rockford<br /></code>
# Each platform exposes a variable named platform_hook that is the above struct
<br />h3. Platform Extensions
# qplatformdefs.h or qmake.conf adds the define QT_DIRECTFB_HAS_PLATFORM_CODE
<br /># Platform integration plugins will have a hooks struct (struct of function pointers to init, destroy, etc)<br /># Each platform exposes a variable named platform_hook that is the above struct<br /># qplatformdefs.h or qmake.conf adds the define QT_DIRECTFB_HAS_PLATFORM_CODE<br /># The platform plugin initializes it's hooks as so:<br /><code><br />DirectFBPlatformHooks hooks = { 0 };<br />#ifdef QT_DIRECTFB_HAS_PLATFORM_CODE<br />extern DirectFBPlatformHooks platform_hook;<br />hooks = platform_hook;<br />#endif<br /></code><br /># platform plugin calls hooks, checking for null<br /><code><br />if (hook</s>&gt;init)<br /> hook-&gt;init(). // avoids any ifdef usage<br /></code><br /># qmake.conf of the device spec has DIRECTFB_PLATFORM_SOURCES, DIRECTFB_PLATFORM_LIBS etc.<br /># platformplugin.pro can do LIBS += $DIRECTFB_PLATFORM_LIBS
# The platform plugin initializes it’s hooks as so:<br />
# platform plugin calls hooks, checking for null<br />
# qmake.conf of the device spec has <span class="caps">DIRECTFB</span>_PLATFORM_SOURCES, <span class="caps">DIRECTFB</span>_PLATFORM_LIBS etc.
# platformplugin.pro can do <span class="caps">LIBS</span> += $DIRECTFB_PLATFORM_LIBS


===Discussion===
=== Discussion ===


====Configure====
==== 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.
* 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.
Line 28: Line 22:
* What about Fedora/Ubuntu that would like to have exactly ''one'' Qt? Will we end up with runtime detection?
* What about Fedora/Ubuntu that would like to have exactly ''one'' Qt? Will we end up with runtime detection?


====Platform Hooks====
==== Platform Hooks ====


* Easily make out what the hooks are looking at the struct
* Easily make out what the hooks are looking at the struct
* Platform code can bring it’s own libs through <span class="caps">DIRECTFB</span>_PLATFORM_LIBS
* 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
* 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
* Since the hooks can be switched at runtime, we can a device profile supporting mutiple device flavors


===not merged parts===
=== 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.
# -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
# rpath-link vs <s>L needs to be explored. Devices like the pi have some ilbs in $SYSROOT/opt/vc
<br />configure implementation strategy<br />* Put device variables, toolchain path, rootfs path, pkg-config paths (can be auto derived?) in device.pri.<br />'''''' One can use device specific variables to influence the variable values. For example, ubuntu and fedora might have different paths.<br />* include(../device.pri) or load(devicespec) in qmake.conf<br />* [not sure] Add config.sh that is sourced inside configure</s> use this to disable board specific stuff that are known not to work. (disable webkit2 maybe)


configure implementation strategy
== Counter Proposals ==


* Put device variables, toolchain path, rootfs path, pkg-config paths (can be auto derived?) in device.pri.
=== Subclass plugins ===
** 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.
* It might be cleaner to subclass the plugin.
Line 57: Line 45:
** somehow inject the new class name into the main.cpp
** somehow inject the new class name into the main.cpp
* In the case of eglfs this would include:
* In the case of eglfs this would include:
** subclass *Screen to add init code
** subclass '''Screen to add init code<br />'''* subclass '''Integration to create the new screen class<br />'''* somehow inject thew new plugin string into the .json file
** 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
** 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.
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.
===Categories:===
* [[:Category:QtEcosystemTeamTasklist|QtEcosystemTeamTasklist]]

Revision as of 10:21, 24 February 2015


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:

<br />./configure -device broadcom/linux-mipsel-97425-gcc <s>device-option BRCM_ROCKFORD_PATH=/opt/bcm/rockford<br />


h3. 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:

<br />DirectFBPlatformHooks hooks = { 0 };<br />#ifdef QT_DIRECTFB_HAS_PLATFORM_CODE<br />extern DirectFBPlatformHooks platform_hook;<br />hooks = platform_hook;<br />#endif<br />


# platform plugin calls hooks, checking for null

<br />if (hook</s>&gt;init)<br /> hook-&gt;init(). // avoids any ifdef usage<br />


# 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

  1. -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.
  2. 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.