Merge commit 'qt/master'

Conflicts:
	doc/src/examples.qdoc
	doc/src/plugins-howto.qdoc
	doc/src/topics.qdoc
	examples/phonon/musicplayer/mainwindow.cpp
	src/3rdparty/freetype/src/base/ftobjs.c
	src/corelib/global/qglobal.h
	src/corelib/tools/qalgorithms.h
	src/corelib/tools/qshareddata.cpp
	src/corelib/tools/qsharedpointer.cpp
	src/corelib/tools/tools.pri
	src/corelib/xml/qxmlstream.h
	src/gui/painting/painting.pri
	src/gui/widgets/qdatetimeedit.cpp
	tests/auto/qdesktopservices/qdesktopservices.pro
	tests/auto/qgraphicsitem/tst_qgraphicsitem.cpp
	tests/auto/qtextcodec/test/test.pro

1 files changed, 143 insertions, 0 deletions

diff --git a/doc/src/platforms/emb-accel.qdoc b/doc/src/platforms/emb-accel.qdoc
new file mode 100644
index 0000000..818538a
--- /dev/null
+++ b/doc/src/platforms/emb-accel.qdoc
@@ -0,0 +1,143 @@
+/****************************************************************************
+**
+** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Contact: Nokia Corporation (qt-info@nokia.com)
+**
+** This file is part of the documentation of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** No Commercial Usage
+** This file contains pre-release code and may not be distributed.
+** You may use this file in accordance with the terms and conditions
+** contained in the either Technology Preview License Agreement or the
+** Beta Release License Agreement.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Nokia gives you certain
+** additional rights. These rights are described in the Nokia Qt LGPL
+** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this
+** package.
+**
+** GNU General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU
+** General Public License version 3.0 as published by the Free Software
+** Foundation and appearing in the file LICENSE.GPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU General Public License version 3.0 requirements will be
+** met: http://www.gnu.org/copyleft/gpl.html.
+**
+** If you are unsure which license is appropriate for your use, please
+** contact the sales department at http://qt.nokia.com/contact.
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+/*!
+    \page qt-embedded-accel.html
+
+    \target add your graphics driver to Qt for Embedded Linux
+
+    \title Adding an Accelerated Graphics Driver to Qt for Embedded Linux
+    \ingroup qt-embedded-linux
+
+    In \l{Qt for Embedded Linux}, painting is a pure software implementation
+    normally performed in two steps. First, each window is rendered
+    onto a QWSWindowSurface using QPaintEngine. Second, the server
+    composes the surface images and copies the composition to the
+    screen (see \l{Qt for Embedded Linux Architecture} for details).
+    \l{Qt for Embedded Linux} uses QRasterPaintEngine (a raster-based implementation of
+    QPaintEngine) to implement painting operations, and uses QScreen
+    to implement window composition.
+
+    It is possible to add an accelerated graphics driver to take
+    advantage of available hardware resources. This is described in
+    detail in the \l {Accelerated Graphics Driver Example} which uses
+    the following approach:
+
+    \tableofcontents
+
+    \warning This feature is under development and is subject to
+    change.
+
+    \section1 Step 1: Create a Custom Screen
+
+    Create a custom screen by deriving from the QScreen class.
+
+    The \l {QScreen::}{connect()}, \l {QScreen::}{disconnect()}, \l
+    {QScreen::}{initDevice()} and \l {QScreen::}{shutdownDevice()}
+    functions are declared as pure virtual functions in QScreen and
+    must be implemented. These functions are used to configure the
+    hardware, or query its configuration. The \l
+    {QScreen::}{connect()} and \l {QScreen::}{disconnect()} are called
+    by both the server and client processes, while the \l
+    {QScreen::}{initDevice()} and \l {QScreen::}{shutdownDevice()}
+    functions are only called by the server process.
+
+    You might want to accelerate the final copying to the screen by
+    reimplementing the \l {QScreen::}{blit()} and \l
+    {QScreen::}{solidFill()} functions.
+
+    \section1 Step 2: Implement a Custom Raster Paint Engine
+
+    Implement the painting operations by subclassing the
+    QRasterPaintEngine class.
+
+    To accelerate a graphics primitive, simply reimplement the
+    corresponding function in your custom paint engine. If there is
+    functionality you do not want to reimplement (such as certain
+    pens, brushes, modes, etc.), you can just call the corresponding
+    base class implementation.
+
+    \section1 Step 3: Make the Paint Device Aware of Your Paint Engine
+
+    To activate your paint engine you must create a subclass of the
+    QCustomRasterPaintDevice class and reimplement its \l
+    {QCustomRasterPaintDevice::}{paintEngine()} function. Let this
+    function return a pointer to your paint engine. In addition, the
+    QCustomRasterPaintDevice::memory() function must be reimplemented
+    to return a pointer to the buffer where the painting should be
+    done.
+
+    \table
+    \header \o Acceleration Without a Memory Buffer
+    \row
+    \o
+
+    By default the QRasterPaintEngine draws into a memory buffer (this can
+    be local memory, shared memory or graphics memory mapped into
+    application memory).
+    In some cases you might want to avoid using a memory buffer directly,
+    e.g if you want to use an accelerated graphic controller to handle all
+    the buffer manipulation. This can be implemented by  reimplementing
+    the QCustomRasterPaintDevice::memory() function to return 0 (meaning
+    no buffer available). Then, whenever a color or image buffer normally
+    would be written into paint engine buffer, the paint engine will call the
+    QRasterPaintEngine::drawColorSpans() and
+    QRasterPaintEngine::drawBufferSpan() functions instead.
+
+    Note that the default implementations of these functions only
+    calls qFatal() with an error message; reimplement the functions
+    and let them do the appropriate communication with the accelerated
+    graphics controller.
+
+    \endtable
+
+    \section1 Step 4: Make the Window Surface Aware of Your Paint Device
+
+    Derive from the QWSWindowSurface class and reimplement its \l
+    {QWSWindowSurface::}{paintDevice()} function. Make this function
+    return a pointer to your custom raster paint device.
+
+    \section1 Step 5: Enable Creation of an Instance of Your Window Surface
+
+    Finally, reimplement QScreen's \l {QScreen::}{createSurface()}
+    function and make this function able to create an instance of your
+    QWSWindowSurface subclass.
+*/