Viadeo Twitter Google Bookmarks ! Facebook Digg del.icio.us MySpace Yahoo MyWeb Blinklist Netvouz Reddit Simpy StumbleUpon Bookmarks Windows Live Favorites 
Logo Documentation Qt ·  Page d'accueil  ·  Toutes les classes  ·  Classes principales  ·  Annotées  ·  Classes groupées  ·  Fonctions  · 

Adding an accelerated graphics driver to Qt/Embedded

Qt/Embedded has the capacity to make use of hardware accelerators. To use a hardware accelerator for a PCI or AGP driver, you must perform the following steps:

  1. Define an accelerated descendant of QLinuxFbScreen.

    This should implement QVoodooScreen::connect() to map its registers. Use qt_probe_bus to get a pointer to the PCI config space. This is where you should check that you're being pointed to the right device (using the PCI device/manufacturer ID information). Then use PCI config space to locate your device's accelerator registers in physical memory and mmap the appropriate region from /dev/mem. There is no need to map the framebuffer, QLinuxFbScreen will do this for you. Return FALSE if a problem occurs at any point. QVoodooScreen::initDevice() will be called only by the QWS server and is guaranteed to be called before any drawing is done (and so is a good place to set registers to known states). connect() will be called by every connecting client.

  2. Define an accelerated descendant of QGfxRaster.

    This is where the actual drawing code goes. Anything not implemented in hardware can be passed back to QGfxRaster to do in software. Use the optype variable to make sure that accelerated and unaccelerated operations are synchronised (if you start drawing via software into an area where the hardware accelerator is still drawing then your drawing operations will appear to be in the wrong order). optype is stored in shared memory and is set to 0 by unaccelerated operations; accelerated operations should set it to 1. When a software graphics operation is requested and optype is 1, QGfxRaster::sync() is called; you should provide your own implementation of this that waits for the graphics engine to go idle. lastop is also available for optimisation and is stored in the shared space: this will not be set by the software-only QGfx and can be used to store the type of your last operation (e.g. drawing a rectangle) so that part of the setup for the next operation can be avoided when many of the same operations are performed in sequence.

    All drawing operations should be protected via a QWSDisplay::grab() before any registers, lastop or optype are accessed, and ungrabbed() at the end. This prevents two applications trying to access the accelerator at once and possibly locking up the machine. It's possible that your source data is not on the graphics card so you should check in such cases and fall back to software if necessary. Note that QGfxRaster supports some features not directly supported by QPainter (for instance, alpha channels in 32-bit data and stretchBlt's). These features are used by Qt; stretchBlt speeds up QPixmap::xForm() and drawPixmap() into a transformed QPainter, alpha channel acceleration is supported for 32-bit pixmaps.

  3. If you wish, define an accelerated descendant of QScreenCursor. restoreUnder(), saveUnder(), drawCursor() and draw() should be defined as null operations. Implement set(), move(), show() and hide(). 4KB is left for your cursor at the end of the visible part of the framebuffer (i.e. at (width*height*depth)/8 )

  4. Implement initCursor() and createGfx() in your QScreen descendant. Implement useOffscreen() and return TRUE if you can make use of offscreen graphics memory.

  5. Implement a small function qt_get_screen_mychip(), which simply returns a new QMychipScreen

  6. Add your driver to the DriverTable table in qgfxraster_qws.cpp, e.g.
    { "MyChip", qt_get_screen_mychip,1 },
    

    The first parameter is the name used with QWS_DISPLAY to request your accelerated driver.

  7. To run with your new driver,
    export QWS_DISPLAY=MyChip 
    
    (optionally MyChip:/dev/fb<n> to request a different Linux framebuffer than /dev/fb0), then run the program

If your driver is not PCI or AGP you'll need to inherit QScreen instead of QLinuxFbScreen and implement similar functionality to QLinuxFbScreen, but otherwise the process should be similar. The most complete example driver is qgfxmach64_qws.cpp; qgfxvoodoo_qws.cpp may provide a smaller and easier-to-understand driver.

Publicité

Best Of

Actualités les plus lues

Semaine
Mois
Année
  1. « Quelque chose ne va vraiment pas avec les développeurs "modernes" », un développeur à "l'ancienne" critique la multiplication des bibliothèques 94
  2. Apercevoir la troisième dimension ou l'utilisation multithreadée d'OpenGL dans Qt, un article des Qt Quarterly traduit par Guillaume Belz 0
  3. Pourquoi les programmeurs sont-ils moins payés que les gestionnaires de programmes ? Manquent-ils de pouvoir de négociation ? 43
  4. Les développeurs ignorent-ils trop les failles découvertes dans leur code ? Prenez-vous en compte les remarques des autres ? 17
  5. Quelles nouveautés de C++11 Visual C++ doit-il rapidement intégrer ? Donnez-nous votre avis 10
  6. Qt Commercial : Digia organise un webinar gratuit le 27 mars sur la conception d'interfaces utilisateur et d'applications avec le framework 0
  7. 2017 : un quinquennat pour une nouvelle version du C++ ? Possible, selon Herb Sutter 9
Page suivante

Le blog Digia au hasard

Logo

Déploiement d'applications Qt Commercial sur les tablettes Windows 8

Le blog Digia est l'endroit privilégié pour la communication sur l'édition commerciale de Qt, où des réponses publiques sont apportées aux questions les plus posées au support. Lire l'article.

Communauté

Ressources

Liens utiles

Contact

  • Vous souhaitez rejoindre la rédaction ou proposer un tutoriel, une traduction, une question... ? Postez dans le forum Contribuez ou contactez-nous par MP ou par email (voir en bas de page).

Qt dans le magazine

Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia. Qt 3.3
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP !
 
 
 
 
Partenaires

Hébergement Web