Work around raster engine not ignoring the pad byte in RGB32

DirectFB sets the alpha byte to 0 in RGB32 for all drawing operations.
The raster paint engine needs this padding byte to be 0xFF as it shares
some code paths with RGBA8888_Premultiplied. So, always fall back to
raster engine for draw operations.

This is really due to a bug in the raster paint engine (Tracked by task
184073), which should ignore the extra byte. Once this task is fixed,
this patch can probably be reverted.

Reviewed-by: Tom Cooksey

1 files changed, 5 insertions, 2 deletions

diff --git a/src/plugins/gfxdrivers/directfb/qdirectfbpaintdevice.h b/src/plugins/gfxdrivers/directfb/qdirectfbpaintdevice.h
index 23fa5d6..7096124 100644
--- a/src/plugins/gfxdrivers/directfb/qdirectfbpaintdevice.h
+++ b/src/plugins/gfxdrivers/directfb/qdirectfbpaintdevice.h
@@ -61,25 +61,28 @@ public:
     void lockDirectFB();
     void unlockDirectFB();
 
+    inline bool forceRasterPrimitives() const { return forceRaster; }
+
     // Reimplemented from QCustomRasterPaintDevice:
     void* memory() const;
     QImage::Format format() const;
     int bytesPerLine() const;
     QSize size() const;
     int metric(QPaintDevice::PaintDeviceMetric metric) const;
-
 protected:
     // Shouldn't create QDirectFBPaintDevice by itself but only sub-class it:
     QDirectFBPaintDevice(QDirectFBScreen *scr = QDirectFBScreen::instance())
         : QCustomRasterPaintDevice(0),
           dfbSurface(0),
           lockedImage(0),
-          screen(scr) {}
+          screen(scr),
+          forceRaster(false) {}
 
     IDirectFBSurface *dfbSurface;
     QImage *lockedImage;
     QDirectFBScreen *screen;
     int bpl;
+    bool forceRaster;
 private:
     Q_DISABLE_COPY(QDirectFBPaintDevice)
 };