[190] | 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
---|
| 2 | <!-- /home/espenr/tmp/qt-3.3.8-espenr-2499/qt-x11-free-3.3.8/doc/accel.doc:36 -->
|
---|
| 3 | <html>
|
---|
| 4 | <head>
|
---|
| 5 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
---|
| 6 | <title>Adding an accelerated graphics driver to Qt/Embedded</title>
|
---|
| 7 | <style type="text/css"><!--
|
---|
| 8 | fn { margin-left: 1cm; text-indent: -1cm; }
|
---|
| 9 | a:link { color: #004faf; text-decoration: none }
|
---|
| 10 | a:visited { color: #672967; text-decoration: none }
|
---|
| 11 | body { background: #ffffff; color: black; }
|
---|
| 12 | --></style>
|
---|
| 13 | </head>
|
---|
| 14 | <body>
|
---|
| 15 |
|
---|
| 16 | <table border="0" cellpadding="0" cellspacing="0" width="100%">
|
---|
| 17 | <tr bgcolor="#E5E5E5">
|
---|
| 18 | <td valign=center>
|
---|
| 19 | <a href="index.html">
|
---|
| 20 | <font color="#004faf">Home</font></a>
|
---|
| 21 | | <a href="classes.html">
|
---|
| 22 | <font color="#004faf">All Classes</font></a>
|
---|
| 23 | | <a href="mainclasses.html">
|
---|
| 24 | <font color="#004faf">Main Classes</font></a>
|
---|
| 25 | | <a href="annotated.html">
|
---|
| 26 | <font color="#004faf">Annotated</font></a>
|
---|
| 27 | | <a href="groups.html">
|
---|
| 28 | <font color="#004faf">Grouped Classes</font></a>
|
---|
| 29 | | <a href="functions.html">
|
---|
| 30 | <font color="#004faf">Functions</font></a>
|
---|
| 31 | </td>
|
---|
| 32 | <td align="right" valign="center"><img src="logo32.png" align="right" width="64" height="32" border="0"></td></tr></table><h1 align=center>Adding an accelerated graphics driver to Qt/Embedded</h1>
|
---|
| 33 |
|
---|
| 34 |
|
---|
| 35 |
|
---|
| 36 | <p> Qt/Embedded has the capacity to make use of hardware accelerators.
|
---|
| 37 | To use a hardware accelerator for a PCI or AGP driver, you must
|
---|
| 38 | perform the following steps:
|
---|
| 39 | <p> <ol type=1>
|
---|
| 40 | <li>
|
---|
| 41 | Define an accelerated descendant of QLinuxFbScreen.
|
---|
| 42 | <p> This should implement <tt>QVoodooScreen::connect()</tt> to map its
|
---|
| 43 | registers. Use <tt>qt_probe_bus</tt> to get a pointer to the PCI config
|
---|
| 44 | space. This is where you should check that you're being pointed to the
|
---|
| 45 | right device (using the PCI device/manufacturer ID information). Then
|
---|
| 46 | use PCI config space to locate your device's accelerator registers in
|
---|
| 47 | physical memory and mmap the appropriate region from <tt>/dev/mem</tt>.
|
---|
| 48 | There is no need to map the framebuffer, <tt>QLinuxFbScreen</tt> will do
|
---|
| 49 | this for you. Return <tt>FALSE</tt> if a problem occurs at any point. <tt>QVoodooScreen::initDevice()</tt> will be called only by the QWS server and
|
---|
| 50 | is guaranteed to be called before any drawing is done (and so is a
|
---|
| 51 | good place to set registers to known states). <tt>connect()</tt> will be called
|
---|
| 52 | by every connecting client.
|
---|
| 53 | <p> <li>
|
---|
| 54 | Define an accelerated descendant of QGfxRaster.
|
---|
| 55 | <p> This is where the actual drawing code goes. Anything not implemented
|
---|
| 56 | in hardware can be passed back to <tt>QGfxRaster</tt> to do in software. Use
|
---|
| 57 | the optype variable to make sure that accelerated and unaccelerated
|
---|
| 58 | operations are synchronised (if you start drawing via software into an
|
---|
| 59 | area where the hardware accelerator is still drawing then your drawing
|
---|
| 60 | operations will appear to be in the wrong order). optype is stored in
|
---|
| 61 | shared memory and is set to 0 by unaccelerated operations; accelerated
|
---|
| 62 | operations should set it to 1. When a software graphics operation is
|
---|
| 63 | requested and optype is 1, <tt>QGfxRaster::sync()</tt> is called; you should
|
---|
| 64 | provide your own implementation of this that waits for the graphics
|
---|
| 65 | engine to go idle. lastop is also available for optimisation and is
|
---|
| 66 | stored in the shared space: this will not be set by the software-only
|
---|
| 67 | <tt>QGfx</tt> and can be used to store the type of your last operation (e.g.
|
---|
| 68 | drawing a rectangle) so that part of the setup for the next operation
|
---|
| 69 | can be avoided when many of the same operations are performed in
|
---|
| 70 | sequence.
|
---|
| 71 | <p> All drawing operations should be protected via a <tt>QWSDisplay::grab()</tt>
|
---|
| 72 | before any registers, lastop or optype are accessed, and <tt>ungrabbed()</tt> at the end. This prevents two applications trying to
|
---|
| 73 | access the accelerator at once and possibly locking up the machine.
|
---|
| 74 | It's possible that your source data is not on the graphics card so you
|
---|
| 75 | should check in such cases and fall back to software if necessary.
|
---|
| 76 | Note that <tt>QGfxRaster</tt> supports some features not directly supported
|
---|
| 77 | by <a href="qpainter.html">QPainter</a> (for instance, alpha channels in 32-bit data and
|
---|
| 78 | stretchBlt's). These features are used by Qt; stretchBlt speeds up <a href="qpixmap.html#xForm">QPixmap::xForm</a>() and <tt>drawPixmap()</tt> into a transformed <a href="qpainter.html">QPainter</a>,
|
---|
| 79 | alpha channel acceleration is supported for 32-bit pixmaps.
|
---|
| 80 | <p> <li>
|
---|
| 81 | If you wish, define an accelerated descendant of <tt>QScreenCursor</tt>. <tt>restoreUnder()</tt>, <tt>saveUnder()</tt>, <tt>drawCursor()</tt> and <tt>draw()</tt> should
|
---|
| 82 | be defined as null operations. Implement <tt>set()</tt>, <tt>move()</tt>, <tt>show()</tt> and <tt>hide()</tt>. 4KB is left for your cursor at the end of the
|
---|
| 83 | visible part of the framebuffer (i.e. at (width*height*depth)/8 )
|
---|
| 84 | <p> <li>
|
---|
| 85 | Implement <tt>initCursor()</tt> and <tt>createGfx()</tt> in your <a href="qscreen.html">QScreen</a>
|
---|
| 86 | descendant. Implement <tt>useOffscreen()</tt> and return <tt>TRUE</tt> if you can
|
---|
| 87 | make use of offscreen graphics memory.
|
---|
| 88 | <p> <li>
|
---|
| 89 | Implement a small function <tt>qt_get_screen_mychip()</tt>, which simply
|
---|
| 90 | returns a new <tt>QMychipScreen</tt>
|
---|
| 91 | <p> <li>
|
---|
| 92 | Add your driver to the DriverTable table in <tt>qgfxraster_qws.cpp</tt>,
|
---|
| 93 | e.g.
|
---|
| 94 | <pre>
|
---|
| 95 | { "MyChip", qt_get_screen_mychip,1 },
|
---|
| 96 | </pre>
|
---|
| 97 |
|
---|
| 98 | <p> The first parameter is the name used with QWS_DISPLAY to request your
|
---|
| 99 | accelerated driver.
|
---|
| 100 | <p> <li>
|
---|
| 101 | To run with your new driver,
|
---|
| 102 | <pre>
|
---|
| 103 | export QWS_DISPLAY=MyChip
|
---|
| 104 | </pre>
|
---|
| 105 |
|
---|
| 106 | (optionally MyChip:/dev/fb<n> to request a different Linux
|
---|
| 107 | framebuffer than <tt>/dev/fb0</tt>), then run the program
|
---|
| 108 | <p> </ol>
|
---|
| 109 | <p> If your driver is not PCI or AGP you'll need to inherit <a href="qscreen.html">QScreen</a>
|
---|
| 110 | instead of <tt>QLinuxFbScreen</tt> and implement similar functionality to <tt>QLinuxFbScreen</tt>, but otherwise the process should be similar. The most
|
---|
| 111 | complete example driver is <tt>qgfxmach64_qws.cpp</tt>; <tt>qgfxvoodoo_qws.cpp</tt> may provide a smaller and easier-to-understand
|
---|
| 112 | driver.
|
---|
| 113 | <p>
|
---|
| 114 | <!-- eof -->
|
---|
| 115 | <p><address><hr><div align=center>
|
---|
| 116 | <table width=100% cellspacing=0 border=0><tr>
|
---|
| 117 | <td>Copyright © 2007
|
---|
| 118 | <a href="troll.html">Trolltech</a><td align=center><a href="trademarks.html">Trademarks</a>
|
---|
| 119 | <td align=right><div align=right>Qt 3.3.8</div>
|
---|
| 120 | </table></div></address></body>
|
---|
| 121 | </html>
|
---|